Hi, On 3/4/21 11:45 PM, Adam Williamson wrote: > On Thu, 2021-03-04 at 22:40 +0100, Hans de Goede wrote: >> >>> Starting from a minimal install with plymouth omitted, adding just >>> plymouth itself pulls in 3 packages (plymouth, plymouth-core-libs, >>> plymouth-scripts) with an installed size of 621K. Adding plymouth- >>> system-theme pulls in 32 packages with an installed size of 24M. So >>> putting plymouth-system-theme in @core would substantially inflate the >>> size of @core in terms of both number of packages and overall installed >>> size. Removing plymouth from @core would not save a lot in terms of >>> packages or space. >>> >>> So, I guess the question here is, what do we do? >>> >>> 1) Remove plymouth from @core >>> 2) Add plymouth-system-theme to @core >>> 3) Make Hans/Ray/someone fix the plymouth bug >> >> 1) clearly gets my vote, not just because I don't have time to work on 3) >> but also because to me it seems like the right thing to do. Plymouth is >> a boot splash, its goal is to make the boot look pretty / hide all the >> scary log messages in use-cases where we want this. The text fallback >> splash is not pretty. In general if it shows instead of the graphical >> splash the fact that the text fallback shows is considered a bug. > > Well, you could still argue it's prettier than a wall-o-text boot. And > it *does* hide the wall-o-text. > >> So either the server spin wants a pretty boot and then they should fix the >> bug of the text splash showing by installing plymouth-system-theme, or the >> server spin does not want a pretty boot and then there should be no >> plymouth at all. > > What if we want something arguably-prettier than wall-o-text, but don't > want an extra 32 packages and 24M of storage used up? Systemd has you covered here, you can tell it to not log any startup status or to only log errors by specifying systemd.show_status=no or systemd.show_status=auto on the kernel commandline. Note I'm not claiming there is no bug in plymouth (1) here, but I also believe that dropping plymouth completely from e.g. the server-spin is the right thing to do. And that has the nice side effect of significant lowering the priority of the plymouth bug. Which I must admit does make the chance of me actually looking into the plymouth bug a lot smaller. Regards, Hans 1) There have been a lot of tty/console code changes in the kernel recently to deal with a bunch of security issues. I would not be surprised if one of those turns out to be the root cause. This makes me wonder how hard it would be for you to try and reproduce this with the latest F34 rootfs + a kernel from when openQA did not hit this yet ? _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
