On 10/22/13 9:59 AM, Bruno Friedmann wrote:
On Tuesday 22 October 2013 15.40:58 Raymond Wooninck wrote:
Hi,
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. Absolutely.
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 initrd) There's also the 1.1 version, where in branding we can put a lock icon 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.
Exactly.
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 change.
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? -Jeff -- Jeff Mahoney SUSE Labs