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

On Tue, 22 Oct 2013 18:55, Raymond Wooninck 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

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

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

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

Andreas Schwab wrote:

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.

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

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

On Wed, 23 Oct 2013 10:03:42 +0200 Philipp Wagner 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