img引Linux的绝对路径,Red Hat Enterprist Linux 5 启动引导Trouble Shooting不完全

文件:Red Hat Enterprist Linux 5 启动引导troubleshooting实验笔记.pdf

大小:812KB

下载:

Red Hat Enterprist Linux 5 启动引导Trouble

Shooting不完全实验笔记

前言：

看有些哥们很头痛这个，所以整理个笔记方便大家。

由于绝大部分内容是自己总结的，所以以下内容并不保证绝对的正确性与权威性。

版权：

GPL v3：

Name ：Yunlin

Fang ( Alin Fang )

MSN：

G Talk：

27 Aug, 2008

正文：

电脑的生命过程：

这就把jerrywjl的帖子抄过来吧：

Linux系统启动过程大致按照如下步骤进行(这是一个简述)：

第一阶段：BIOS启动引导阶段；在该过程中实现硬件的初始化以及查找启动介质；从MBR中装载启动引导管理器(GRUB)并运行该启动引导管理

第二阶段：GRUB启动引导阶段；装载stage1装载stage1.5装载stage2读取/boot/grub.conf文件并显示启动菜单；装载所选的kernel和initrd文件到内存中

第三阶段：内核阶段：运行内核启动参数；解压initrd文件并挂载initd文件系统，装载必须的驱动；挂载根文件系统

第四阶段：Sys

V init初始化阶段：启动/sbin/init程序；运行rc.sysinit脚本，设置系统环境，启动swap分区，检查和挂载文件系统；读取/etc/inittab文件，运行在/et/rc.d/rc.d中定义的不同运行级别的服务初始化脚本；打开字符终端1-6号控制台/打开图形显示管理的7号控制台

OK，到这里抄袭结束。

首先，BIOS坏掉的话，不干Linux的事情。

其次，硬件坏掉，也不干Linux的事情。

那么我总结了几个Linux在启动时可能出现的trouble的地方。

第一阶段：

MBR里面的引导管理器(IPL,

Initial Program Loader)grub损坏。

第二阶段：

stage1.5, stage2损坏。

找不到grub.conf

找不到kernel

第三阶段：

找不到initrd.img

fstab分区挂载失败

第四阶段：

inittab初始化脚本失败

服务进程错误(内容太多，不在讨论范围-__-||)

TrobuleShooting预科班：如何进修复模式

TrobuleShooting有很多时候需要在修复模式下对系统进行修复。

这里给初学Linux的哥们说下进修复模式的方法。

把安装光盘放入光驱，重启电脑，选择从光驱启动。输入liunx

rescue回车。即可进入修复模式。

Choose a Language：选择语言

Keyboard Type：选择键盘布局

Setup Networking：是否启用网络支持

Rescue：选择用何种方式挂在硬盘分区，有“继续(读写)”，“只读(有个P用……)”

，“跳过”三项。一般我们选"Continue”。

然后告诉你，修复模式下，把硬盘的/分区挂到了/mnt/sysimage下，把/boot挂到了/mnt/sysimage/boot下。

这个就是进入修复模式了。

TrobuleShooting预科班：如何猜测硬盘的分区结构以及作用

进入修复模式。

SH-3.2# chroot /mnt/sysimage

SH-3.2# df

根据df和fdisk就可以推测出硬盘的分区结构以及作用了。

TrobuleShooting预科班：GRUB

stage1-stage2的过程

对症下药：

屏幕一片黑，无法看到grub界面——MBR里面的grub损坏

修复：

方法1：

进入修复模式。

SH-3.2# chroot /mnt/sysimage

#> grub

grub> root hd(0,0)

grub> setup (hd0)

如果修复成功，grub会提示你success了。

注意：

此方法修复grub依赖于/boot/grub/grub.conf，如果grub.conf不存在，则需手工创建一个。创建方法请参考下文。

用此方法修复grub是把/boot/grub下的stage镜像安装到硬盘上的特定位置上。所以使用此法修复grub仅限于是硬盘上的stage1(在MBR里)以及stage1.5，修复依赖于/boot/grub下的stage1,

stage1.5, stage2镜像。如果这几个镜像也遭到破坏，则此法无效。

方法2：

进入修复模式。

SH-3.2# chroot /mnt/sysimage

SH-3.2# grub-install /dev/sda

如果似乎成功，会如此提示你：

注意：

此方法修复grub依赖于/boot/grub/grub.conf，如果grub.conf不存在，则需手工创建一个。创建方法请参考下文。

此方法不依赖于grub.conf，当/boot/grub下文件都找到破坏，亦可用次命令修复。但不修复grub.conf。

grub警告：Error

15: File not found——找不到kernel或者initrd.img

Stage1.5报错。

修复：

路线1：

在grub界面，在要加载的内核选项处按进入编辑模式，再在带检查的各栏按，利用补全功能，

确定kernel以及initrd.img文件是否存在，

确定指定kernel所在磁盘分区的root参数是否写对，

就拿上面截图来说，最容易出问题的地方有：

第一行root

(hd0,0)

这里的root指定的是内核所在分区，不是根文件系统所在的分区。

这里不用/dev/sdxn这样的格式来标识硬盘分区。而是直接用hd(n,m)这样的格式来标识硬盘。

N表示第几块硬盘,m表示是第几个分区。这里m不管是逻辑分区还是主分区。全部按照从0向后的顺序递增。

比如：

hd(0,2)表示第一块硬盘上的第三个分区。

hd(1)表示第二块硬盘。

第二行kernel

/vmlinuz的位置。

一个是要检查内核位置是否是以/boot所在分区为根的绝对路径。比如如果你是单独把/boot划出来当作一个分区，那么如果你如果内核在以linux的根分区为准的绝对路径是/boot/vmlinuz的话，那么你以/boot分区

为根，则要写/vmlinuz

initrd.img亦如上。

一个是要确定

且判断导致Error

15错误是因为grub.conf里的配置内核模块的参数是否写错，尤其是文件名写错，则改正之。并按或者再次进入安全模式，进入可用系统后修改/boot/grub/grub.conf参数。

利用自动补全功能检查/boot/grub/grub.conf配置是否正确。

如果发现内核丢失，则走路线2。

如果发现initrd.img镜像丢失，则走路线2或者路线3。

路线2：

进入修复模式，

挂载安装盘，强制重装内核。

SH-3.2# chroot /mnt/sysimage

SH-3.2# mount -o loop -t iso9660 /dev/sdc /media

SH-3.2# cd /media/Server

SH-3.2# rpm -ivh --force kernel-2.6.18-92.el5.i686.rpm

SH-3.2# reboot

路线3：

进入修复模式，重新生成镜像文件。

SH-3.2# chroot /mnt/sysimage

SH-3.2# mkinitrd initrd- 2.6.18-92.el5.img `uname -r`

SH-3.2# reboot

为什么走路线2强装内核也可以呢？因为在RHEL5里面安装kernel的RPM包，安装脚本会帮你执行mkinitrd这个步骤。

Grub> 直接进入grub

shell界面——找不到grub.conf文件

重装grub？

No。

有些配置文件是rpm自带的。在安装rpm时会自动生成。

但是，有些配置文件是根据你机器配置事实生成的。这种配置文件就不一定能靠重装相关的包来修复。

怎么办？自己手动重写。

修复：

进入修复模式。

SH-3.2# chroot /mnt/sysimage

SH-3.2# echo /boot/vmlinuz-2.6.18-92.el5 >>

/boot/grub/grub.conf

SH-3.2# echo /boot/initrd-2.6.18-92.img >>

/boot/grub/grub.conf

SH-3.2# vim /boot/grub/grub.conf

title Red Hat Enterprise Linux 5 update 2

root (hd0,0)

kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/sda3

initrd / initrd-2.6.18-92.img

重启。

grub警告：Error

15——stage1.5报错，极有可能是stage2，stage1.5加载stage2失败。

Stage1.5报错。

修复：

进入修复模式。

Grub-install ?

不一定能成功。

grub-install的安装必须依赖grub.conf这个配置。如果这个配置不存在，grub是install不了的。

所以你要现确认/boot/grub下的grub.conf是否存在。

如果不存在，参照上面修复grub.conf的做法。

修复grub之后，执行重装grub即可。请参见之前修复grub的方法。

注意：

初始状态的stage1并不会去读取/boot/grub/下的stage1.5和stage2。位于MBR的stage1会去读取硬盘某个位置的stage1.5，然后直接引导内核。

如果机器上的grub是经过修复的，比如用grub-install或者进入grub然后setup过。那么就不一样了。此时stage会去引导/boot/grub下的stage2。

Kernel panic——原因有N多。

Kernel panic的原因太多了。主要是你要看是在系统运行的哪个阶段kernel喊痛了。

比如说这个阶段。

Switchroot: mount failed: No such file or

directory

Kernel panic – not syncing: Attempted to kill init!

内核挂root载分区失败。

常见的原因有root分区遭到破坏，或者内核不能正确定位root分区。

如果是root分区遭到破坏，那么这个不在我们讨论的范围之内。

如果是内核不能正确定位root分区，则我们可以尝试修复之。

通常情况下内核如何定位root分区呢？一般是通过grub在引导起内核的时候，给内核指定root分区的位置。

大家看这个grub配置：

default=0

timeout=5

splashimage=(hd0,4)/grub/splash.xpm.gz

hiddenmenu

password --md5 $1$YfEwIjnz$cCLdMBF3FDn1iww9fSMp/.

title Red Hat Enterprise Linux Client (2.6.18-92.el5)

root (hd0,4)

kernel /vmlinuz-2.6.18-92.el5 ro root=LABEL=/

rhgb quiet

initrd /initrd-2.6.18-92.el5.img

一般情况下，grub引导一个linux内核，有这几行参数：

title

title指定了要引导的内核的title。顾名思义。

root

这个root并不是根分区的意思。这里是指定了内核所在的文件系统的位置。此root非彼root。

Kernel

这里指定了要加载的内核以及加载内核的参数。

initrd

这里指定了要加载的initrd.img模块。

从这个思路走，我们检查grub.conf。

修复：

进入修复模式。

SH-3.2# chroot /mnt/sysimage

SH-3.2# df -h

SH-3.2# fdisk -l

确定根分区在硬盘上的位置。

SH-3.2# vim /boot/grub/grub/conf

检查kernel选项参数。

核对root参数是否正确。

这里发现本应指向linux根分区的kernel选项的root参数指向了/boot分区，kernel在/boot分区找不到/目录该有的东西，所以就kernel

panic了。

改正。

重启。

OK，到此说的trouble都是在linux内核完全加载完毕之前。现在开始将linux内核加载之后的trouble。

X下打开虚拟终端出现警告：There

was an error creating the child process for the terminal

ssh到此机器，连接成功，输入用户名，输入密码，并无提示密码错误，并不断开连接，终端无反应——原因：由于作者水平有限，很难解释清楚。只知道己有可能的诱因。

RHEL5里面，虚拟终端pts是依赖于设备devpts的。如果devpts未挂载，则pts虚拟终端是起不来的。

修复：

检查devpts是否被挂载

[root@server1 ~]# mount

/dev/sda3 on / type ext3 (rw)

proc on /proc type proc (rw)

sysfs on /sys type sysfs (rw)

/dev/sda1 on /boot type ext3 (rw)

tmpfs on /dev/shm type tmpfs (rw)

none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

/dev/hdc on /misc/cd type iso9660 (ro,nosuid,nodev)

发现devpts没有给挂载

[root@server1 ~]# vim /etc/fstab

编辑挂载选项：

LABEL=/ / ext3 defaults

1 1

LABEL=/boot /boot ext3 defaults

1 2

tmpfs /dev/shm tmpfs defaults

0 0

devpts /dev/pts

devpts gid=5,mode=620 0 0

sysfs /sys sysfs defaults

0 0

proc /proc proc defaults

0 0

LABEL=SWAP-sda2 swap swap defaults

0 0

~

gid=5是什么意思？

[root@server1 ~]# head -n 6 /etc/group

root:x:0:root

bin:x:1:root,bin,daemon

daemon:x:2:root,bin,daemon

sys:x:3:root,bin,adm

adm:x:4:root,adm,daemon

tty:x:5:

[root@server1 ~]#

明白了吧？

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

OK，到此位置。由于种种原因，更多的加载kernel之后的Trouble

Shooting，我就不多说了。但是要记住，由于这个时候Linux已经开始启动，关联的东西更加错综复杂，从此开始的Trouble

Shooting也更加的凶险与有趣。