event based initramfs

[James Hunt]

On 16/05/12 19:09, Phillip Susi wrote:
> 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.
Sounds like both systems are performing initialisation to me. And as we
know, there is symmetry between what happens in the initramfs and what
then has to happen again in the main system. By using Upstart, we get
one tool to do that job without duplication of code.

>> - 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?
Upstart provides a "udev bridge" that allows arbitrary jobs to react to
udev events without having to install udev rules in one of the 3 udev
locations (although I guess that's really potentially 5 if you include
the initramfs locations (but exclude /run)). For the cases where you
aren't modifying devices, it makes working with udev much simpler.

The whole point is that modern Linux systems are highly dynamic in
nature. Polling is not required for most operations so why do it?
Upstart was designed from the outset to operate in such a dynamic
environment so it makes a lot of sense to take advantage of Upstarts
ample abilities to make the initramfs less opaque, more efficient and
more maintainable.

> 
>> 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.
? The initramfs performs numerous individual mounts including:

root filesystem
/proc
/sys
/dev
/dev/pts
/run

The code for mountall is admittedly more complex than simply calling
'mount', but it has the following advantages:

- it actually performs error checking (unlike the initramfs mount code).
- it provides user feedback on the operations via Plymouth.
- it runs fsck and provides feedback to the user via Plymouth.
- it supports delays and timeouts.
- it emits Upstart events allowing jobs to react to mount changes.

>> 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?
There is an ongoing associated overhead in maintaining patches where we
diverge from upstreams.

  They normally go
> to /usr/local and we move them to /usr with a configure switch.  Moving
> to / instead should be trivial.
That's not actually what we're talking about here - the upstreams are
moving tooling currently in / to /usr. We might be able to work around
this, but it sounds like it will become increasingly difficult to do so.

>> - 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.
True, but it with the advent of state-based re-exec support, Upstart
will be able to manage these daemons at a job level, tracking their
associated processes for the entire system lifetime. So, for example, if
udevd dies horribly in the initramfs, Upstart can restart it resulting
in a more reliable boot experience.

> What sort of "smarts" do you have in mind?
Wait and see :-)

Kind regards,

James.
--
James Hunt
____________________________________
http://upstart.ubuntu.com/cookbook
http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf