Congrats to the Debian release team on the
new release
of Debian 7.0 (wheezy)!
Leading up to the release, a meme making the rounds on Planet Debian has
been to play a #newinwheezy game,
calling out some of the many new packages in 7.0 that may be interesting
to users. While upstart as a package is
nothing new in wheezy, the jump to upstart 1.6.1 from 0.6.6 is quite a
substantial change. It does bring with it a new package,
mountall, which by itself
isn't terribly interesting because it just provides an upstart-ish
replacement for some core scripts from the initscripts package
(essentially, /etc/rcS.d/*mount*). Where things get interesting (and,
typically, controversial) is the way in which mountall leverages
plymouth to achieve this.
What is plymouth?
There is a great deal of misunderstanding around plymouth, a fact I was
reminded of again while working to get a modern version of upstart into
wheezy. When Ubuntu first started requiring plymouth as an essential
component of the boot infrastructure, there was a lot of outrage from users,
particularly from Ubuntu Server users, who believed this was an attempt to
force pretty splash screen graphics down their throats. Nothing could be
further from the truth.
Plymouth provides a splash screen, but that's not what plymouth is. What
plymouth is, is a boot-time I/O multiplexer. And why, you ask, would
upstart - or mountall, whose job is just to get the filesystem mounted at
boot - need a boot-time I/O multiplexer?
Why use plymouth?
The simple answer is that, like everything else in a truly event-driven
boot system, filesystem mounting is handled in parallel - with no defined
order. If a filesystem is missing or fails an fsck, mountall may need to
interact with the user to decide how to handle it. And if there's more than
one missing or broken filesystem, and these are all being found in parallel,
there needs to be a way to associate each answer from the user to the
corresponding question from mountall, to avoid crossed signals... and lost
data.
One possible way to handle this would be for mountall to serialize the
fsck's / mounts. But this is a pretty unsatisfactory answer; all other
things (that is, boot reliability) being equal, admins would prefer
their systems to boot as fast as possible, so that they can get back to
being useful to users. So we reject the idea of solving the problem of
serializing prompts by making mountall serialize all its filesystem
checks.
Another option would be to have mountall prompt directly on the console,
doing its own serialization of the prompts (even though successful mounts /
fscks continue to be run in parallel). This, too, is not desirable in the
general case, both because some users actually would like to have pretty
splash screens at boot time, and this would be incompatible with direct
console prompting; and because mountall is not the only piece of software
that need to prompt at boot time (see also: cryptsetup).
Plymouth: not just a pretty face
Enter plymouth, which provides the framework for serializing requests to the
user while booting. It can provide a graphical boot splash, yes; ironically,
even its own homepage
suggests that this is its purpose. But it can also provide a text-only
console interface, which is what you get automatically when booting without a
splash boot argument, or even handle I/O over a serial console.
Which is why, contrary to the initial intuitions of the s390 porters upon
seeing this package, plymouth is available for all of Debian's Linux
architectures in wheezy, s390 and s390x included, providing a consistent
architecture for boot-time I/O for systems that need it - which is any
machine using a modern boot system, such as upstart or systemd.
Room for improvement
Now, having a coherent architecture for your boot I/O is one thing; having
a bug-free splash screen is another. The experience of plymouth in Ubuntu
has certainly not been bug-free, with plymouth making significant demands of
the kernel video layer. Recently, the binary video driver packages in Ubuntu
have started to blacklist the framebuffer kernel driver entirely due to
stability concerns, making plymouth splash screens a non-starter for users of
these drivers and regressing the boot experience.
One solution for this would be to have plymouth offload the video handling
complexity to something more reliable and better tested. Plymouth does
already have an X backend, but we don't use that in Ubuntu because even if
we do have an X server, it normally starts much later than when we would want
to display the splash screen. With Mir on the
horizon for Ubuntu, however, and its clean separation between system and
session compositors, it's possible that using a Mir backend - that can
continue running even after the greeter has started, unlike the current
situation where plymouth has to cede the console to the display manager when
it starts - will become an appealing option.
This, too, is not without its downsides. Needing to load plymouth when using
crypted root filesystems already makes for a bloated initramfs; adding a
system compositor to the initramfs won't make it any better, and introduces
further questions about how to hand off between initramfs and root fs.
Keeping your system compositor running from the initramfs post-boot isn't
really ideal, particularly for low-memory systems; whereas killing the system
compositor and restarting it will make it harder to provide a flicker-free
experience. But for all that, it does have its architectural appeal, as it
lets us use plymouth as long as we need to after boot. As the concept of
static runlevels becomes increasingly obsolete in the face of dynamic
systems, we need to design for the world where the distinction between
"booting" and "booted" doesn't mean what it once did.
Read more
Latest Official Posts
