gentoo linux启动过程,linux – 如何解决udev在gentoo启动时没有创建...

我的旧gentoo笔记本电脑似乎与udev存在问题,可能是因为我使用emerge更新软件,升级udev内核,获取一些消息“在升级udev / kernel之后做这些事情”并且想“我会查看屏幕输出,阅读这些消息,并在重新启动系统之前处理这些事情“.不幸的是,有点匆忙,我当然忘了查看这些消息,关闭机器,将其物理移动到它现在位于家中并启动,只是遇到未能找到/ dev / hda3的.

现在我已经设法通过手动创建/ dev / hda3然后使init继续系统启动来解决这个问题(下面将详细介绍),但我需要一些关于如何一劳永逸地解决这个问题的建议(所以我不知道)我必须在每次启动时重复以下程序).

(如果有人可以指向Gentoo机器的某个地方,我可以找到我安装的软件包的所有安装后消息,那么我可以找到那些与udev和内核相关的指令,我应该阅读.)

相关软件版本：

Gentoo硬化的内核2.6.36-r6(优选)和2.6.28-r9(在关闭前使用21个月).下面描述的繁琐的手动启动过程已经过验证,适用于两个内核版本.

udev包是udev-151-r4.

启动时一切似乎都很好(机器启动是内核,它安装/ proc,/ sys和/ dev,启动udevd并根据uevents填充/ dev,处理uevents,安装/ dev / pts)直到它出现“检查根文件系统”的步骤.

它在那里散发出来

无法打开设备’/ dev / hda3’：没有这样的文件或目录

然后它会询问我root密码(或Ctrl-D继续).

我输入,在shell中,mount告诉我rootfs已挂载,/ dev / root也挂载在/上.另外,mount抱怨/ etc / mtab不可写(例如read / only filesystem).鉴于启动没有完成,所有这一切对我都有意义.

做ls / dev会发现没有hda,hda1,hda2或hda3设备,它们通常应该存在(我希望udev可以创建).另外值得一提的是,/ dev也不包含sda,sda1,sda2或sda3设备,所以我们没有看到更新的udev或内核的问题,改变了它调用不同磁盘设备的惯例.也没有任何/ dev / disk目录,磁盘设备可以“隐藏”.

所以我的下一步,可能是脏的步骤是在/ dev下手动创建hda,hda1,hda2和hda3(我偷偷看了一下我的其他gentoo服务器,找出主要和次要数字以及适当的权限和组成员身份)：

mknod / dev / hda b 3 0

mknod / dev / hda1 b 3 1

mknod / dev / hda2 b 3 2

mknod / dev / hda3 b 3 3

chmod 660 / dev / hda *

chgrp disk / dev / hda *

不幸的是,在这里执行Ctrl-D或写入退出不会继续中断的启动顺序,而是会启动重启(这会使机器达到/ dev / hda未找到的状态),以便解决此问题的路径不幸的是,没有帮助.

我尝试了另一种解决方法(失败了)在init启动后立即按下’我'(以及尝试’我’)并开始运行各种init脚本(如mount / proc,/ sys等)但我在引导序列到达(失败)尝试检查/ dev / hda3之前,永远不会进入交互式引导模式.

相反,我继续使用我的/ dev / hda3设备来安装我的操作系统文件系统：

mount -o remount -o rw / dev / hda3 /

所以,现在我可以对我的机器的文件系统进行写访问,这为我提供了一些解决这种情况的选项：修改配置文件,启动各种init-scripts和子系统等.

有一点不起作用的是改变运行级别.原因是init 3失败并显示错误消息init：/ dev / initctl：没有这样的文件或目录.我再次偷看我的其他Gentoo服务器并发现/ dev / initctl是一个权限为600并且属于root：root的管道,所以我重新创建：

mknod / dev / initctl p

chmod 600 / dev / initctl

现在init 3失败了,但有点不同;它会挂起一段时间,然后放弃消息init：timeout打开/写入控制通道/ dev / initctl.这是有道理的,因为原始的init进程(进程ID为1)没有打开这个新创建的/ dev / initctl进行读取.

现在,阅读init手册页,我意识到发送SIGUSR将使init关闭并重新打开/ dev / initctl.正是我需要的,所以我执行命令kill -l来获取所有信号及其编号的列表(我在其中看到SIGUSR1的编号为10)然后我发出命令

杀-10 1

要使init重新打开/ dev / initctl,然后我重试进入运行级别3：

init 3

现在init尝试进入运行级别3并执行大量脚本.不幸的是,所有这些脚本都失败了ERROR：在sysinit完成之前无法运行syslog-ng.所以,我重新启动系统(现在实际上工作正常,因为我已经使init听取/ dev / initctl：我以root身份登录然后重新启动),重复上述步骤(除了重新安装/ dev / hda3为可写) )直到并包括将SIGUSR1发送到init的点.现在我试图让init恢复启动序列,但是以更温和的方式,通过重新读取/ etc / inittab文件：

init q

似乎没有发生任何事情.所以,我将调查/ etc / inittab,在那里我找到一个似乎称为sysinit的运行级别的条目.我承担风险并重新运行：

init sysinit

这次init抱怨使用消息.再次读取/ etc / inittab,我看到sysinit条目使用参数sysinit调用/ sbin / rc.所以,我决定尝试：

/ sbin / rc sysinit

现在系统重试启动一些服务并成功！不仅如此,当重新运行用于挂载/ proc,/ sys和/ dev的init脚本时,还会检查它们是否已经挂载(证明在代码中进行完整性检查和错误检查的价值是多么有价值在遇到异常情况时采取相应行动).对此感到高兴,我决定也为/ etc / inittab条目bootwait运行命令,因为那个命令缺少一个运行级别的字母或数字.

/ sbin / rc boot

同样,启动了许多init脚本,主要用于网络.没有报告任何意外错误,所以我很乐意重新尝试运行级别3：

init 3

一旦initscripts完成,机器启动,我可以以root身份登录(理论上,修复这个混乱的根本原因)！