解决 Ubuntu 中 /sbin/init 缺失问题


背景

Description:    Ubuntu 18.04.6 LTS
Release:        18.04
Codename:       bionic

服务器安装的Ubuntu18.04 ,重启后卡在logo界面,又被强制断电。随后重启遇到如上图情况,显示报错

run-init:/sbin/init:No such file or directory

end kernel panic - not syncing:Attempted to kill init !exitcode=0x00007f00 

解决方法

/sbin/init 是 Linux 系统中至关重要的初始化进程,缺失它将导致系统无法启动。以下是一些解决方法:

1. 从 Live CD/USB 复制 init 文件:

  • 准备工作:

    • Ubuntu Live CD/USB 启动盘。

  • 步骤:

    1. 使用 Live CD/USB 启动系统。

    2. 挂载你的根分区,例如:sudo mount /dev/sda1 /mnt (将 /dev/sda1 替换成你的实际分区,我的文件系统是sda5)。

    3. 复制 init 文件: sudo cp /sbin/init /mnt/sbin/

    4. 卸载根分区并重启系统。

2.使用 dpkg 命令重新安装 init 软件包:

  • 准备工作:

    • Live CD/USB 启动盘。

  • 步骤:

    1. 在 Live CD 环境下,挂载根分区。

    2. 使用 chroot 命令进入你的系统环境: sudo chroot /mnt

    3. 重新安装 init 软件包: sudo apt-get install --reinstall init

    4. 退出 chroot 环境: exit

    5. 卸载根分区并重启系统

3.使用 Ubuntu 安装盘修复系统:

  • 准备工作:

    • Ubuntu 安装盘。

  • 步骤:

    1. 使用 Ubuntu 安装盘启动系统。

    2. 选择 "Try Ubuntu" 进入试用模式。

    3. 打开终端,并运行 sudo apt-get update 更新软件包列表。

    4. 运行 sudo apt-get install --reinstall ubuntu-minimal 重新安装基础系统软件包,其中包含 init。

    5. 重启系统。

结合方法1、2在 Live USB 启动Try Ubuntu系统,挂载根分区后,在/sbin目录下,没有init

 sudo cp /sbin/init /mnt/sbin/

之后发现,与Live USB下的init不一致(然而在这一步当时没有用ldd命令确定具体连接,并不确定简答复制是否有用!!

简单cp后发现区别[如下与上面的截图]
lrwxrwxrwx 1 root root 20 Dec 10 15:33 /mnt/sbin/init -> /lib/systemd/systemd*

随后进入chroot,重新安装 init 软件包: sudo apt-get install --reinstall init。

但是此步骤有可能遇到在chroot中无法访问网络的问题,ping不到baidu,apt会无法解析源地址,通过在/mnt/etc/resolv.conf 插入 nameserver 8.8.8.8 后(添加Google 提供的公共 DNS 服务器的 IP 地址 8.8.8.8) 可以正常使用apt-get install init。

 本步骤参考了UBUNTU系统开机报错处理_ubuntu开机找不到sbin/init-优快云博客

※一定要使用ldd /sbin/init 确定init是否正确。所以,最终没有确定是cp还是apt重新安装确保了init的正确。随后重启服务器,正常进入。

本人仅是Linux使用者,并非专家。仅以此记录未知成功原因的报错处理,供大家交流。

### SQL 注入类型及其防护 #### 字符型数字型注入的区别 在处理SQL注入时,字符型数字型的主要区别在于输入参数的格式以及如何在查询语句中表示这些参数。对于字符型注入而言,由于字符串通常需要用单引号包裹,因此攻击者需要考虑如何正确地闭合这些引号以便执行恶意命令[^1]。 而对于数字型注入来说,则无需使用单引号来包围数值,这使得某些情况下更难以察觉潜在的安全漏洞。例如,在构建动态SQL查询的过程中如果开发者假设某个字段永远只会接收整数而不做额外验证的话,就可能给黑客留下可乘之机[^2]。 具体表现形式上: - **字符型**:当应用程序期望接收到的是文本数据(如用户名、密码),那么这类输入往往会被放在一对单引号之间作为字符串处理; ```sql SELECT * FROM users WHERE username='admin' ``` - **数字型**:相反地,如果是用于比较大小或者索引定位之类的纯数字值,则不会被加引号; ```sql DELETE FROM orders WHERE order_id=98765; ``` 为了更好地理解两者之间的差异,下面给出一个简单的对比表格: | 特征 | 字符型注入 | 数字型注入 | |--|------------------------------------|----------------------------------| | 输入格式 | 需要单引号 `'` 来界定 | 不需任何特殊符号 | | 常见场景 | 用户名/密码登录界面 | 商品ID, 订单编号等 | | 利用方式 | 添加额外的 `OR '1'='1` | 使用逻辑运算符如 `AND 1=1` 或直接修改条件 | #### 如何有效防止SQL注入? 无论是面对哪种类型的SQL注入威胁,采取适当措施加强应用安全性都是非常重要的。这里列举了几种常见的防御策略: - **预编译语句 (Prepared Statements)** 和 参数化查询 是最有效的手段之一。它们允许程序先定义好结构化的SQL模板再填充实际变量值,从而避免了拼接字符串带来的风险。 ```java String query = "SELECT * FROM accounts WHERE custID=?"; PreparedStatement pstmt = connection.prepareStatement(query); pstmt.setString(1, customerInput); // 安全传递用户输入 ResultSet rs = pstmt.executeQuery(); ``` - 对于所有来自外部源的数据都应实施严格的 **输入验证** ,包括但不限于长度限制、正则表达式匹配等方式确保只接受预期范围内的合法输入。 - 应用最小权限原则配置数据库账户,默认情况下仅授予必要的操作许可,并定期审查访问控制列表以移除不必要的授权。 - 启用并监控日志记录功能,及时捕捉异常行为模式或可疑活动迹象,有助于快速响应安全事件的发生。 最后值得注意的是,虽然上述方法能够大大降低遭受SQL注入攻击的风险,但没有任何单一技术能提供绝对保障。最佳实践建议综合运用多种保护机制形成多层次防线体系。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值