[opensuse-factory] Going forward with Plymouth (based on dracut changes)
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. 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) 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. 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. 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. However I would like to have your opinion on the right way forward. Thanks Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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.
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.
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 ..
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.
However I would like to have your opinion on the right way forward. done
-- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
On Tuesday 22 October 2013 12:16:50 Jeff Mahoney wrote:
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?
The required functionality can be easily added to Dracut and it would just to take maybe 5 minutes to do so. However I wanted to take the opportunity to validate if this is still the preferred option as that we had quite some complaints about the size of the initrd, etc. Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 22 octobre 2013 à 18:55 +0200, Raymond Wooninck a écrit :
On Tuesday 22 October 2013 12:16:50 Jeff Mahoney wrote:
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?
The required functionality can be easily added to Dracut and it would just to take maybe 5 minutes to do so. However I wanted to take the opportunity to validate if this is still the preferred option as that we had quite some complaints about the size of the initrd, etc.
I don't know if it is still possible, but I remember it used to be possible to have different initrd/initramfs layered on top of another. This way, you could separate the splash part (plymouth + theme) from the main initrd (and also, not regenerate the main initrd when just the theme or plymouth is updated). I remember dracut author looked at it years ago but I don't know if it was discarded. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 22 Oct 2013 18:55, Raymond Wooninck <tittiatcoke@...> wrote:
On Tuesday 22 October 2013 12:16:50 Jeff Mahoney wrote:
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?
The required functionality can be easily added to Dracut and it would just to take maybe 5 minutes to do so. However I wanted to take the opportunity to validate if this is still the preferred option as that we had quite some complaints about the size of the initrd, etc.
Raymond
Separate from the install-system / live-system initrd, what NEEDS to be in the initrd / initramfs phase? Can we make a renewed definition, to get a smaller standard? As it is, mkinitrd runs every kernel update at least, would it that bad to run it during system install / update once? For most, the host-specific (-H) option would bring a reduction. Otherwise, Question: If we tamper with this stuff anyway, please, can we add an option for: non-graphic / text-only boot? Getting rid off Plymouth / other graphic boot things gets harder every new distro release. Maybe call it "Text-only (Server)" boot. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 22/10/13 14:08, Yamaban escribió:
Separate from the install-system / live-system initrd, what NEEDS to be in the initrd / initramfs phase?
Can we make a renewed definition, to get a smaller standard?
As it is, mkinitrd runs every kernel update at least, would it that bad to run it during system install / update once?
For most, the host-specific (-H) option would bring a reduction.
Otherwise, Question:
If we tamper with this stuff anyway, please, can we add an option for: non-graphic / text-only boot?
This option already exist.. theme is called "text". Getting rid off Plymouth / other graphic
boot things gets harder every new distro release.
huh ? it is a simple as removing plymouth or booting with plymouth.enable=0 -- "If debugging is the process of removing bugs, then programming must be the process of putting them in." - Edsger Dijkstra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2013-10-22 19:08, Yamaban wrote:
As it is, mkinitrd runs every kernel update at least, would it that bad to run it during system install / update once?
Kernel updates potentially bring in new modules, and you want thse new modules in the initrd, therefore, on kernel update, the %post scriptlets will generate the particular initrd that needs to be regenerated. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 22/10/13 20:40, Jan Engelhardt escribió:
On Tuesday 2013-10-22 19:08, Yamaban wrote:
As it is, mkinitrd runs every kernel update at least, would it that bad to run it during system install / update once?
Kernel updates potentially bring in new modules, and you want thse new modules in the initrd, therefore, on kernel update, the %post scriptlets will generate the particular initrd that needs to be regenerated.
I guess he wants it to run %postrans .. unfortunately that wont work... -- "If debugging is the process of removing bugs, then programming must be the process of putting them in." - Edsger Dijkstra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Tue, 22 Oct 2013 21:05:36 -0300 Cristian Rodríguez <crrodriguez@opensuse.org> пишет:
El 22/10/13 20:40, Jan Engelhardt escribió:
On Tuesday 2013-10-22 19:08, Yamaban wrote:
As it is, mkinitrd runs every kernel update at least, would it that bad to run it during system install / update once?
Kernel updates potentially bring in new modules, and you want thse new modules in the initrd, therefore, on kernel update, the %post scriptlets will generate the particular initrd that needs to be regenerated.
I guess he wants it to run %postrans .. unfortunately that wont work...
Why? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 22/10/13 23:29, Andrey Borzenkov escribió:
Why?
Because zypp does not use transactions, it installs packages one by one.. -- "Judging by their response, the meanest thing you can do to people on the Internet is to give them really good software for free". - Anil Dash -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 23 octobre 2013 à 00:28 -0300, Cristian Rodríguez a écrit :
El 22/10/13 23:29, Andrey Borzenkov escribió:
Why?
Because zypp does not use transactions, it installs packages one by one..
And it runs %posttrans after that.. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 23 Oct 2013 01:40, Jan Engelhardt <jengelh@...> wrote:
On Tuesday 2013-10-22 19:08, Yamaban wrote:
As it is, mkinitrd runs every kernel update at least, would it that bad to run it during system install / update once?
Kernel updates potentially bring in new modules, and you want thse new modules in the initrd, therefore, on kernel update, the %post scriptlets will generate the particular initrd that needs to be regenerated.
Not what I whated to point out, no, my point was: Instead of leaving the premade 'anyting and all' initrd, that is brought in during install, as final step for the installation / distro upgrade (meaning after the first batch of updates), check if the initrd is still the inital one, if yes call mkinitrd / dracut to build a smaller, host specific initrd. That can be done in background, with a nice value. Benefit: - smaller initrd, means faster load of initrd by kernel - less unused modules loaded (what isn't there can't bring errors) - 'felt' personalised system (it's made for ME, not for the masses) - made sure the 'theme' the user selects for boot menu is installed. It's a mix of measureable and just feeling. No extra work if initrd is build anyway (other than making sure to use host-specific mode for any call to mkinitrd / dracut). - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2013-10-23 08:31, Yamaban wrote:
Instead of leaving the premade 'anyting and all' initrd, that is brought in during install, as final step for the installation / distro upgrade (meaning after the first batch of updates), check if the initrd is still the inital one, if yes call mkinitrd / dracut to build a smaller, host specific initrd.
There is no initrd inside the kernel-* rpms; a host-specific one will always be created.
No extra work if initrd is build anyway (other than making sure to use host-specific mode for any call to mkinitrd / dracut). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 22/10/13 13:55, Raymond Wooninck escribió:
The required functionality can be easily added to Dracut and it would just to take maybe 5 minutes to do so. However I wanted to take the opportunity to validate if this is still the preferred option as that we had quite some complaints about the size of the initrd, etc.
The size of the "host only" initrd can be reduced significantly by using --xz instead of the default gzip compression..but then people may complain about compression speed -_-. -- "If debugging is the process of removing bugs, then programming must be the process of putting them in." - Edsger Dijkstra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
El 22/10/13 13:55, Raymond Wooninck escribió:
The required functionality can be easily added to Dracut and it would just to take maybe 5 minutes to do so. However I wanted to take the opportunity to validate if this is still the preferred option as that we had quite some complaints about the size of the initrd, etc.
The size of the "host only" initrd can be reduced significantly by using --xz instead of the default gzip compression..but then people may complain about compression speed -_-.
It's probably a reasonable trade-off, especially for large initrds. Even for relatively tiny initrds, using xz gives a decent saving: Compr Size Time gzip 5379419 10s xz 3936824 18s 8s extra runtime for a 1.4Mb reduction. -- Per Jessen, Zürich (16.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Per Jessen <per@computer.org> writes:
It's probably a reasonable trade-off, especially for large initrds. Even for relatively tiny initrds, using xz gives a decent saving:
Compr Size Time gzip 5379419 10s xz 3936824 18s
8s extra runtime
Which is about 80% more. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andreas Schwab wrote:
Per Jessen <per@computer.org> writes:
It's probably a reasonable trade-off, especially for large initrds. Even for relatively tiny initrds, using xz gives a decent saving:
Compr Size Time gzip 5379419 10s xz 3936824 18s
8s extra runtime
Which is about 80% more.
Yes, but still only 8 seconds. Not enough to make a cup of coffee. I rarely boot any machine, but for a desktop machine with a large initrd, it won't be many boots before it's paid off (in time saved loading), I would think. Philipp's point is probably more important though:
Those are compression times? What about the much more important decompression times at boot?
I haven't measured it - perhaps similar? -- Per Jessen, Zürich (16.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 23.10.2013 09:36, schrieb Per Jessen:
It's probably a reasonable trade-off, especially for large initrds. Even for relatively tiny initrds, using xz gives a decent saving:
Compr Size Time gzip 5379419 10s xz 3936824 18s
8s extra runtime for a 1.4Mb reduction.
Those are compression times? What about the much more important decompression times at boot? Philipp -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 23 Oct 2013 10:03:42 +0200 Philipp Wagner <lists@philipp-wagner.com> wrote:
.... Those are compression times? What about the much more important decompression times at boot?
Compression: opensuse.tar 179087360 It is about 170 MB of email messages, in other words mostly text. $ time xz -kz opensuse.tar real 1m20.960s user 1m20.477s sys 0m0.229s opensuse.tar.xz 18859460 (about 18 MB = 60% ) $ time bzip2 -zk9 opensuse.tar real 0m31.556s user 0m31.407s sys 0m0.121s opensuse.tar.bz2 23718197 (about 22.6 MB = 75.7% ) $ time gzip -9 opensuse.tar real 0m7.590s user 0m7.495s sys 0m0.091s opensuse.tar.gz 31332269 (about 30 MB = 100% ) Decompression: $ time xz -d opensuse.tar.xz real 0m2.626s user 0m2.377s sys 0m0.247s $ time bzip2 -d opensuse.tar.bz2 real 0m6.336s user 0m6.025s sys 0m0.302s $ time gzip -d opensuse.tar.gz real 0m1.226s user 0m1.023s sys 0m0.201s File size: xz > bzip2 > gzip Compression time: gzip > bzip2 > xz Decompression time: gzip > xz > bzip2 I was playing with compression ratio (0)1-9, but did not have time to sort results. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jeff Mahoney wrote:
On 10/22/13 9:59 AM, Bruno Friedmann wrote:
On Tuesday 22 October 2013 15.40:58 Raymond Wooninck wrote:
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.
This is the behavior we get in 13.1 btw due to plymouth failing to provide the passphrase for unknown reasons. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
The regression is caring so much about the stupid screen switching modes a couple times during boot that you let it screw up booting or make booting more fragile. Not opensuse but you should see my Vaio P running Lubuntu 13.10 these days. Between grub2 and plymouth It's worse these days than it ever was. It's laughable. The screen switches several times and most of those times the screen is either useless blank black, or a repeating scrambled graphics glitch pattern until the display manager finally comes on. It's like a ColecoVision game console with a dead cartridge. 1983 at it's best. Don't talk to me about regression. -- bkw -----Original Message----- From: "Ludwig Nussel" <ludwig.nussel@suse.de> Sent: Wednesday, October 23, 2013 7:21am To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] Going forward with Plymouth (based on dracut changes) Jeff Mahoney wrote:
On 10/22/13 9:59 AM, Bruno Friedmann wrote:
On Tuesday 22 October 2013 15.40:58 Raymond Wooninck wrote:
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.
This is the behavior we get in 13.1 btw due to plymouth failing to provide the passphrase for unknown reasons. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (14)
-
Andreas Schwab -
Andrey Borzenkov -
brian＠aljex.com -
Bruno Friedmann -
Cristian Rodríguez -
Frederic Crozat -
Jan Engelhardt -
Jeff Mahoney -
Ludwig Nussel -
Per Jessen -
Philipp Wagner -
Rajko -
Raymond Wooninck -
Yamaban