So I've filed a bug recently which may need wider discussion about the
resolution. The bug report is:
The problem is this. If plymouth is installed but no graphical theme is
installed/configured - which is currently the case for at least Server
and minimal installs - plymouth uses a 'fallback' text theme, which
Hans says is under-maintained. Since around Fedora-Rawhide-
20210122.n.0, openQA has been encountering an intermittent problem
where this theme does not clear properly when boot is complete and the
console login is shown, it looks like this:
It gets worse once you actually try and log in - bits of the grey
background get wiped and replaced with black in ugly patterns, this
both looks dumb and makes working around the bug in openQA by adding
more screenshots impractical (because the pattern of the background
just keeps changing). This bug does not seem to happen if a Plymouth
graphical theme is installed and configured, only if the fallback text
theme is used.
In the bug report, we did a bit of looking into what bits of Plymouth
are installed when. In comps, 'plymouth' itself is listed as
'mandatory' in @core. This seems to ultimately date back to
by Bill, which was in response to
https://bugzilla.redhat.com/show_bug.cgi?id=801087 (the bug number in
the commit is a typo). The commit claims "Add plymouth to core, to
match prior releases", but it was *not* in @core in "previous releases"
so far as I can tell; it may have been pulled into minimal installs via
dependencies (I can check an F16 minimal install later).
'plymouth-system-theme' - which installs the default graphical theme -
is in the 'base-x' group. So only package sets that include base-x will
install a graphical theme for Plymouth. This includes all major
desktops, but does *not* include at least Server or minimal installs
(and probably some other subsets I'm not thinking of). Anything that
includes @core but *not* @base-x will hit the broken configuration.
Obviously one option here is just to fix the bug in Plymouth, but Hans
suggested that we should fix it by not installing Plymouth in this
configuration - i.e. we should only ever install plymouth and plymouth-
system-theme or no plymouth at all.
If you don't have plymouth installed, you get a very old-school "wall
of text" boot process; if there are encrypted system partitions, you
get a plain text prompt for the encryption passphrase, with no keyboard
layout indicator (I'm not sure if the text theme indicates the keyboard
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
Opinions? :) Thanks!
IRC: adamw | Twitter: adamw_ha
I’m on the way to prepare some tutorials for our documentation and just stumbled across an Anaconda question.
The installation process is slightly different depending on which edition is started. For example, the default partitioning for Workstation is slightly different than for Server.
The question is, if I start the installation with Everything, for example, and change the installation source to Server on the Summary Screen, will I still use exactly the same Anaconda as if I had started the installation from the Server Edition? And is it save to do such a „switch"?
Or, where are the differences e.g in the default partitioning, in the edition specific variant of Anaconda or later when loading packages?
Or, where are the differences in handling the btrfs file system vs. LVM?
Or, where are the differences in handling DNS (systems-resolve in 33), in Anaconda F32 / F33 or in loaded packages and associated scripts?
Background: Providers of rental hardware or a data center offer e.g. the installation of Fedora by starting a VNC installation from Everything 33. On the Summery screen, you can then select another edition or even a completely different version, such as 34. Question is, do you get really the same?
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?
IRC: adamw | Twitter: adamw_ha
Again, for all of us lazy people, I'll briefly summarise today’s IRC discussions right here.
For greater details see meetbot
1. Status Reboot Server Working Group
We were finally able to decide on the memberships that we had inadvertently skipped at the last meeting.
This completes the new formation of the Fedora Server Working Group. I updated the wiki page so the list over there is now up to date. If I got anything wrong, please let me know.
2. Introduce Dusty Mabe from Cloud Group
We had a longer discussion about various possible joint initiatives and projects that could be of benefit to both groups. Two subjects in particular met with consensus:
- most VPSes now use cloud as their server image, therefore both should be coordinated with each other
- a joint venture could increase quality and visibility of documentation
Agreed: It needs a general proposal on a mailing list that everyone can read and discuss. Then it can go to the groups and get discussed and voted on. Due to time constraints, this could start at the beginning of April.
3. The following items are not discussed in this meeting: Fedora 34 beta, PRD, Documentaiton updates. Postponed to the next meeting
Next meeting: March 17, 2021 18:00 UTC