On 5/16/2012 9:01 AM, James Hunt wrote:
The most obvious reason is that the initramfs has it's own init system (a big shell script). So, an Ubuntu system with an initramfs has two different init systems. By reducing this down to just Upstart, we get a simpler and hence more readily maintainable system that:
It has its own system because it isn't really an init system at all. The goal of upstart is to bring up and maintain the system. The goal of the initramfs is only to find the root filesystem.
- has the advantage of being event-based (but which of course can also run jobs effectively "serially" too if desired).
LUKS support in the initramfs is currently handled using calls to "sleep 0.1". Who chose this value? How did they decide upon this value? Why 0.1 seconds? Why not just wait until the device appears? By having an event-based system, we can adopt a saner approach where the system simply reacts to the udev event when the kernel generates it - no polling required.
Isn't this what udev is for? Event based handling of hardware. What do we need upstart for?
My non-LVM, non-RAID systems initramfs contains 16 calls to mount. By using mountall you end up with a single mountall.conf job that handles all that complexity.
I only see one call to mount. There is only one filesystem to mount, so where does 16 come from? mountall is somewhat complex because it needs to mount multiple filesystems, in the correct order. The initramfs just needs one.
A number of upstream projects are starting to move functionality from / to /usr (see [3]), hence we intend to support this model too.
If getting to mountall depends on a file in /usr, then that is an FHS violation and fundamentally incompatible with having /usr on its own filesystem. Having the initramfs have its own copy of mountall and its dependencies in order to mount /usr before the real mountall runs is a kludgy workaround. If you want to boot without an initramfs at all, this workaround won't help ( since the kernel only knows how to mount the root and it is expected to contain everything needed to mount /usr or other filesystems ), so the proper thing to do is make sure that dependencies of mountall go in /.
What does it matter where upstream installs to anyhow? They normally go to /usr/local and we move them to /usr with a configure switch. Moving to / instead should be trivial.
- By utilizing Upstart, we get a clean, fast framework for mounting the root FS. We should also be able to simplify the initramfs by removing duplicate code. - the initramfs spawns daemons (such as udevd) which can be better managed via upstart. - the current initramfs kills the daemons it starts requiring them to be restarted in the main system. This has caused a few race conditions and clearly disallows state passing between the two systems. By enhancing Upstart to support stateful re-exec [4] we get huge benefits as we can retain state on processes started in the initramfs and hence don't necessarily need to restart them. I don't know of any other system that is capable of this. - there is potential for extra "smarts" that cannot be achieved easily/cleanly with the current shell approach.
udev still will need restarted to transition to the real root so it gains access to the full set of udev rules and the initramfs can be freed.
What sort of "smarts" do you have in mind? -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
