The boot process

One of the things that is obvious, between the mailing lists and the comments to my previous post is that there are quite different expectations of what the boot process involves — which is to be expected, since in Gentoo the boot process, like many other things, is totally customized on a per-user basis.

As Greg and William said before, the whole point of supporting (or not) a split /usr approach is not something that is tied that much to udev itself, but more a matter of what is involved in the boot process at all. Reimar pointed out that in the comments to the other post, and I guess that’s the one thing that right now we have to consider a bit more thoroughly. So let’s see if I can analyse it a bit more closely.

Let me put a foreword here. The one problem that is the biggest regarding udev and split /usr is that, while it’s still possible to select whether to search for rules in the rootfs or /usr, it didn’t, and maybe doesn’t, search both paths at the same time. That is probably the only thing that I count as a total non-sense, and it’s breaking for break sake. And it realistically is one of the things that made many Gentoo users upset with Lennart and Kay: the migration of rules is easy for binary distributions – you just rebuild all the packages installing in the old path – but it’s a pain in the neck for Gentoo users; and the cost of searching both paths is unlikely to be noticeable.

So what do we consider as part of the boot? Well, as I said in the other post, if you expect to be able to log in without /usr, you’re probably out of luck, if you use PAM — while the modules are still available on the rootfs, many of them require libraries in /usr — ConsoleKit, Kerberos, PKCS#11, … This is also one of the reasons why I’m skeptical about just teaching Portage to move dependencies to the rootfs: it’ll probably move a good deal of libraries to the rootfs, especially for a desktop, which will in turn make the “lightweight rootfs” option moot.

Another reason why I don’t think that the automatic move is going to solve the problem, is that while it’s possible to teach Portage to move the libraries, it’s impossible to teach it to move plugins, or the datafiles that those libraries use. More about that in the next paragraphs.

So let’s drop the login issue: we don’t expect to be able to log in the system without /usr so it’s not an option. The next thing that is going to be a problem is coldplugging (I’ll consider hotplugging during boot as hotplugging but it might actually be more complex). The idea of coldplugging is that you want to start a given piece of software if, at boot, you find a given device connected. As an example you might want to start pcscd if a smartcard reader (be it a CCID one or another driver) is found, or ekeyd if an EntropyKey is connected, without the user having added them to the runlevels manually.

What’s the problem with this then? Well, the coldplugged services might require /usr for both the service and the libraries, which means you can’t run them without /usr — the udev-postmount service was, if I recall correctly, created just to deal with that, with udev actually keeping a score of which rules failed to execute, and re-executing them after /usr was mounted, but it relied on udev’s own handling of re-execution of rules, which I forgot if it still exists or not. If not, then that’s a big deal, but not something I want to care about to be honest. An easy way out of this is to say that coldplugging is not supported if your coldplugged services are needing /usr and you have it split, but it’s still quite hacky.

This blog post was supposed to be a bit longer, and provide among other things a visual representation of the boot-time service dependencies. It turns out now that I left it open for a whole week without being able to complete it as I intended. In particular, the graphical representation is messy because there are so many involved services, that on my laptop it’s seriously unreadable. I’ve been using the representation as a debug method to improve on my service files though, and I’ll write about that. It’s going to enter OpenRC’s git soon.

This said, this “half” post is good enough to read as it is. I’ll write more about it later on.

6 thoughts on “The boot process

  1. “The one problem that is the biggest regarding udev and split /usr is that, while it’s still possible to select whether to search for rules in the rootfs or /usr, it didn’t, and maybe doesn’t, search both paths at the same time. That is probably the only thing that I count as a total non-sense, and it’s breaking for break sake. And it realistically is one of the things that made many Gentoo users upset with Lennart and Kay: the migration of rules is easy for binary distributions – you just rebuild all the packages installing in the old path – but it’s a pain in the neck for Gentoo users; and the cost of searching both paths is unlikely to be noticeable.”Ahem, the path didn’t change upstream at all. On upstream udev the rules files are installed to $rootprefix=/, and they always were. On systems such as Fedora where /lib is now a symlink to /usr $prefix and $rootprefix are now identical, which effectively means that either /usr/lib and and /lib are fine now to access the rules files by. However, gentoo decided to go a very different way with udev, and just moved udev from / to /usr without making /lib a symlink to /usr/lib. That of course breaks a lot of things, and is probably at the core of all the confusion the Gentoo folks have about udev. But that’s a purely Gentoo-specific issue, caused by a Gentoo-specific decision of what to do with /usr in udev.To clarify this under the focus of compatibility: some distros chose to stay with the classic layout, and hence (obviously) are compatible with the old way. Other distros such as Fedora chose to make /lib, /bin, /sbin symlinks to /usr/{lib,bin,sbin}. Both these approaches retain perfect compatibility with the old layout. However, Gentoo moved udev from / to /usr, without creating any symlinks and hence deliberately broke compatibility at no benefit.I wished the Gentoo folks would ack that this all is a Gentoo-made issue inherent to their own packaging, instead of pouring complaints and blame on upstream all the time. Thank you.Lennarthappy new year

    Like

  2. @Lennart:Someone did explain this to me on our ml, and I intend to fix it when udev-197 is released to put everything back in /lib/udev.I will need to coordinate it with our systemd maintainer, so that is why I want to wait for the next release to happen to take care of it.

    Like

  3. @Lennart:I do understand that keeping separate /usr without an initramfs is not broken by udev, but the biggest udev-specific complaint I’ve heard is about the removal of the trigger for retrying rules that did not run successfully when udev was started. In the old days, gentoo had a separate init script which would run after /usr was mounted and issue “udevadm trigger –type=failed” to re-run all of the rules which had failed during the initial udevadm trigger after udev was started, before /usr was mounted.

    Like

  4. What’s so hard about sticking to the stated upstream requirement, which is simply that local drives need to be mounted before udev starts? If you keep that in mind, it’s perfectly simple (in the overall scheme of things) to start udev after localmount, when the user tells you to.They can do that without an initramfs, if they never needed an initramfs before. ie rootfs is not on lvm/encrypted/raid, and they have the drivers built-in to get through localmount (and don’t need eg a bluetooth keyboard to boot.) Including when /usr and most other partitions are split, with some on lvm, as was recommended in the lvm guide for some years.That way no patches are needed, the postmount service is not needed, and the discipline of demarcating which libs and binaries are needed for boot is maintained, which helps everyone, including people using an initramfs.

    Like

  5. Isn’t ‘systemd’ is to booting what “pulseaudio’ is to audio?Another words, both are utterly useless, redundant make things unusable, AND server no other purpose other than the aforementioned.Quick, linux needs 20 more pulseauidios, OpenAL, ALSA, JACK ect isn’t enough.

    Like

  6. @LennartI don’t see how systemd introducing a new layout requirement (the symlinks) makes it Gentoo’s “fault” for breakage. With the FHS in mind this doesn’t make sense, but I know you don’t care about that, or POSIX; but with regard to the “Linux Standard” its a case of continually rewriting the standard to fit new methods of implementation as opposed to actually having a standard.Not aiming for a “no, YOU!” response, but seriously…I’ve slowly come of the opinion that while agile/continuous/extreme/cyclic/iterative/[insert methodology buzzword-to-be] techniques are swell when it comes to userland executables and most services, it certainly seems that boot subsystems and filesystem schematics fall into the same category as data schema development: processes that benefit greatly from a “big design up front” method.(This last statement, hopefully, doesn’t incite too much flaming.)

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s