On 10/22/13 9:59 AM, Bruno Friedmann wrote:
On Tuesday 22 October 2013 15.40:58 Raymond Wooninck
Based on the recent changes for Dracut and making it replace mkinitrd, also
has some consequences for Plymouth.
Using Dracut at the moment would generate a smaller initrd file, then
utilizing mkinitrd. Main reason for this is not that Dracut is so much
smarter, but more that only partial Plymouth support is provided.
The initrd that Dracut generated does not include the Pango libraries/modules
and Font that is required to present the user with a question or comments
during the boot process. In most cases this is never used, but for those users
that utilize encrypted disks, this would be a major issue.
This particular combination has been always a hot
topic in the past and I
would like to resolve it in the best way possible. As far as I can see, we
have the following possibilities:
1) Drop the ask-for-password stuff from
Plymouth, which would allow us to
drop the additional library requirements. This would mean that the password
for encrypted disks is validated before plymouth starts (all within the
There's also the 1.1 version, where in branding we can put a lock
and why not another small buble containing the important information (like only us kmap)
We also have to check the transition between grub2(or bootloader) and plymouth.
Having grub2 full-hd, then a 80x40 text console for password and full-hd plymouth would
be really ugly. Would be nice to kept a nice transition effect.
2) Drop plymouth from initrd and start plymouth from disk after password,
etc have been required. This would then be the task for systemd, which already
has this support.
Would be perfect, also for encrypted server where you mainly
doesn't need fancy boot graphics.
I think this is the worst of the three options. Everyone else is trying
to go for a completely seamless boot process where you don't notice
transitions between states. This would be a regression.
3) Try to establish a checking mechanism that implements option 2 for
particular kernels/encrypted root/swap disks. For the other users there is no
could be tricky, a particular needed partition could be encrypted and
other not ..
It might be enough to key off of whether the system will eventually
start up graphics. Then it could be determined whether we want to use
Plymouth at all during the entire boot process.
> Option 2 would be easy to implement. For the
others I don't know and I might
> have to rely on others to support me.
It seems like there's an option 4 missing here: Add the required
functionality. Is the lack of those libraries in the initrd on purpose
or has someone not added the functionality to Dracut yet? I'm all for
unifying on standard packages, but I don't want to see user experience
regressions in the process. I assume that Dracut will only include the
luks stuff if it's required for the root file system -- couldn't we key
off of that to determine whether to include the libraries for Plymouth?