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

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 SUSE -- 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

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

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

On Wed, 23 Oct 2013 01:40, Jan Engelhardt 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

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

Per Jessen 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

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

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