999 兄，能不能帮我理顺一下 Live 上面的安装

jiangtao9999

initrd 每次安装新内核都需要重新生成。因为 initrd 里面有当前内核的驱动模块。
如果不需要这部分驱动模块，那其实 initrd 就可以取消的。

haulm

原帖由 huizige 于 2012-6-6 02:06 发表
我建议更新一下INITRD文件,init文件写成动态的,解释引导参数装载磁盘,这样不用每次安装都需要重现生成.

对不起，我这次看懂你写的意思了……，initrd 有对系统安装位置的信息，具体我也没有解压过 initrd 研究其构成。
在生成 initrd 前，必需保证你的 fstab 是正确的，否则生成的 initrd 文件是不能正确引导系统的。
所以 Live 在生成目标系统的 initrd 时的指令需要 chroot 运行。

huizige

我拆解过好几个的initrd,好像光盘上用的initrd文件是跟磁盘上的一样的文件。
对于几个不同系统的initrd我说一下各自特点

magiclinux的initrd,应该是用mkinitrd生成的,,挂载的分区直接写到了initrd,连dev设备也是通过脚本进行装载。

ubuntu大体过程是先把proc,sys,dev先挂到内存,然后挂接驱动设备,用udev管理设备,接着解释内核参数,获得磁盘名称,再做一些对挂载磁盘做初始化,把日志文件拷贝到目标磁盘,最后挂载系统分区chroot,由于内核启动后只能由initrd执行chroot,init根据内核参数导入不同的文件脚本函数完成不同的启动过程。

fc15已经开始使用systemd,所以分析fc的initrd也相当有必要,不过大部分也跟utuntu的差不多,也是用udev管理设备,只是代码风格不一样,导入变量和函数的文件较少。

slax就比较另类,initrd使用busybox的mdev装载dev目录的设备,转到aufs的根目录后再使用udev管理。

cdlinux的就更加迷惑人了,initrd文件使用squashfs的格式,启动后必须先加载aufs后才可以做设备文件的加载,否则报只读文件系统,启动后没有chroot,直接在aufs做root，没有提供运行级别，只是在启动时判断内存容量启动图形还是控制台。

通过拆解这些initrd文件发现可以直接使用内核参数控制initrd的启动过程，如果说设备驱动问题，现在流行发行版的initrd文件容量如此之大，几乎是把所有模块都塞进initrd镜像了，只是需要通过udev进行管理就可以了。

haulm

现有的 Live 就是使用 slax 的脚本，的确是由 mdev 再转 udev，而且对 udev 版本有要求，但是如果安装后的系统还是由 mdev 转 udev 我就不理解了。我对 udev 的升级是否必要也有很多疑惑，因为 udev 的高版本甚至影响到一些 dbus 应用权限方面问题，妨碍我对普通用户的提权，影响到 Live 脚本的正常系统启动。
magic 的dev设备也是通过脚本进行装载，所以我制做安装时就不要考虑 dev 设备的建设，系统启动时全部自动建好了。

jiangtao9999

initrd 里面 mdev 足以，用它也不过就是生成一下设备文件。
Live 的核心就在于 initrd 里面的启动脚本，这里你不可能做一个全功能的系统根目录，所以mdev 够轻便够用就行了。
启动到了 Live 系统的 root 重新启动 udev 和 initrd 里面的 mdev 不影响的。

initrd 必须配合一个适合需要功能的 busybox 。楼主你要是有空，先去尝试做一个 busybox 的 initrd 救援系统吧。

haulm

没那个必要，这种系统我有一个完整的 pdf 教程，并且我根据它已经做过了几次。不过这次做 Live 安装收获不少，因为我现在实现 Magic 系统救缓是心中有数了，只用一个内核外加 busybox 再加上 unsquash，8M 大小的 Linux 环境完全可以引导和安装 Magiclinux。
至于 Magic 完整的启动过程我仍不是很了解。

jiangtao9999

mgc 的启动：
/sbin/init -> initab -> /etc/rc.d/rc.sysinit -> inittab -> /etc/rc.d/rc （运行级当作参数传递给这个脚本，这个脚本去启动对应运行级的 service ) -> inittab -> 启动 tty -> 启动 X 。
把 systemVinit 的 inittab 看明白你就全能明白。

如果有足够好的编程能力，自己写脚本替代 rc.sysinit 和 rc 两个脚本就能实现很多想要的功能。

jiangtao9999

Gentoo 的 openrc 就是替代 rc 脚本而不是整体替代 systemVinit 。

huizige

我建议服务守护程序提升到sydtemd，编写规则也不复杂。

initrd如果有足够空间能用上支持数组的bash应该可以提高启动速度，如果一些设备信息反复通过程序获得会拖延启动时间，如果使用数组，把获得的信息转成数组，在循环调取数组获得信息时是读取内存中的数据，这样可以提高脚本的执行速度。

haulm

你能为 mgc 打包一个并让它完整工作么，如果只是提建议，很难到位的。

haulm

原帖由 huizige 于 2012-6-9 00:30 发表
我建议服务守护程序提升到sydtemd，编写规则也不复杂。

initrd如果有足够空间能用上支持数组的bash应该可以提高启动速度，如果一些设备信息反复通过程序获得会拖延启动时间，如果使用数组，把获得的信息转成数组，在循环调取 ...

MGC3 已经是 systemd 了，只是我对新事物接受速度更慢。

huizige

我只在BLFS上建立了完整的安装脚本，对于RPM打包我不了解，需要熟悉一下RPM打包的规则。如果MGC运行环境完善我会给MGC打包systemd。

haulm

原帖由 huizige 于 2012-6-20 02:53 发表
我只在BLFS上建立了完整的安装脚本，对于RPM打包我不了解，需要熟悉一下RPM打包的规则。如果MGC运行环境完善我会给MGC打包systemd。

MGC运行环境完善 是啥意思？systemd 涉及东西太多，各种服务组件需要重新打包，mgc3 这个月底或者再迟一些会有一个带 kde4 的测试版本，不过可能还是内部版本。

sejishikong

原帖由 huizige 于 2012-6-20 02:53 发表
我只在BLFS上建立了完整的安装脚本，对于RPM打包我不了解，需要熟悉一下RPM打包的规则。如果MGC运行环境完善我会给MGC打包systemd。

systemd这种包，不会需要另打的。不过如果出来以后能修改完善，我是十分欢迎的。

huizige

去年我想把我自己的项目移到MGC上调试，结果尝试了好几个MGC的版本，安装后没法进桌面。其他FC、乌班图根本看不上眼。打包遇到最麻烦的是不同源码包的版本匹配问题，桌面环境没稳定前去优化启动怕是白忙活一场，自己的项目比MGC2.5完一点决定的，到现在还难产。