近观 Magic Linux 操作系统启动过程

KDE

http://blog.sina.com.cn/u/53f570ed010003ho

npcomet

     [code:1]系统启动称为 boot，为什么叫靴子？因为启动过程就象提起纤细的靴子带随即整个大头皮靴就会跟着被提起来一样。Magic Linux 遵循标准 SysV Init 规范，启动的大致过程是这样的：

首先，BIOS 进行开机自检，然后按照设定顺序搜索相应存储设备上的主引导记录(MBR)区，如果 grub 等引导管理器的引导信息被安装到了 MBR，BIOS 会执行其中的代码，找到引导管理器并启动它，至此 BIOS 已将引导权交给引导管理器。

引导管理器(例如：ntldr、grub、lilo、syslinux)根据配置文件(例如：linux 下常见的 /boot/grub/menu.lst，它是指向 /boot/grub/grub.conf 的符号链接，而 windows 则是 c:\boot.ini)找到根目录、内核(vmlinuz)、初始化内存盘映象(initrd.img)，然后启动内核，内核头部一段未压缩的代码会将内核自身解压缩进内存，接着初始化内存盘映象也被读进内存(如果有的话)，至此引导管理器已将引导权交给内核。

接着内核主体代码的一部分会完成硬件环境的探测，配置相应的驱动，内核完成启动后，会解压缩初始化内存盘，并把它挂载为根文件系统，随后运行这个小文件系统里的启动脚本，完成一些特殊任务，例如启动时显示炫耀画面(bootsplash)、加载真实文件系统所在设备的硬件驱动模块(例如 RAID/SCSI支持，前提是这些驱动没有直接编译进内核，而是以模块形式存放于真实的文件系统里，而这个真实的文件系统恰好位于没有被内核默认支持的存储设备上)以及其它重要模块等等，然后卸载初始化内存盘，并根据引导管理器传递过来的真实根目录的位置，使用新加载的初始化内存盘里的额外驱动以及必要的配置信息识别出真实根文件系统存放的设备，以只读方式加载真实根文件系统，并探测是否有一些重要目录和文件(例如：/sbin/init、 /etc/fstab)，如果根文件系统加载出错，就会报告：内核惊恐，找不到 init。如果根文件系统顺利加载，则运行常规开机文件系统检查[对哪些设备上的文件系统进行检查，取决于/etc/fstab 配置文件里每行配置语句里最后的一个字段，那是一个数字，除了根文件系统是 1(强制)，其它均为 0(不检测) 或者 2(总是检测)]，根据/etc/fstab 配置文件里指定的文件系统自动启动相应文件系统专用的 fsck工具扫描文件系统，遇到问题通常会自动修正错误，然后再以可读写方式重新挂载真实根文件系统，接着搜索并执行 /sbin/init 可执行程序(也可以是脚本)，这样 init 成为系统里第一个进程，至此内核已将引导权交给 init 进程。

init 会搜索并运行启动脚本，通常是 /etc/rc.d/rc.sysinit，然后根据  /etc/inittab 里指定的启动级别，运行 /etc/rc.d/rc1.d 到 /etc/rc.d/rc5.d 中相应级别的某一个目录里的服务启停脚本，加载后台服务(守护进程)并进入相应的运行级，启动登陆会话，要求输入用户帐户信息。

如果是第五运行级，就会启动 xwindows，然后启动 xdm、kdm 或者 gdm，输入帐户信息，登陆后进入桌面环境，接着一些预配置的自启动程序会被执行(例如音量控制、剪贴板管理、即时通讯程序)，至此完成启动。

Q：既然“初始化内存盘映象(initrd.img)包含的驱动没有直接编译进内核，而是以模块形式存放于真实的文件系统里，而这个真实的文件系统恰好位于没有被内核默认支持的存储设备上”那么这个 initrd.img 最初是如何创建的呢？
A：原来它是由安装程序安装完系统软件包之后，根据真实的硬件环境创建的，因此就不难理解为什么 initrd 文件不能在不同机器间通用的道理了。[/code:1]
转一下

wkt

初始化内存盘映象(initrd.img)包含的驱动没有直接编译进内核，而是以模块形式存放于真实的文件系统里，而这个真实的文件系统恰好位于没有被内核默认支持的存储设备上

这有点不明白！
如果模块在initrd.img里那么，真实文件系统里的模块就没有意思了
如果模块存放在真实的文件系统里，那么内核如何加载
'位于没有被内核默认支持的存储设备上'的模块以支持'没有被内核默认支持的存储设备'。
我有点糊涂了，版主帮我一下啊？

wdts

KDE兄,能不能给个2.1的ISO出来..我急需,我的2.0升级过KDE,不成功,我想直接安装2.1,找了两三个月了,就是没有找到,.

jiangtao9999

2.1 根本就没出呢