Hi,
On 12/30/20 11:52 PM, Neal Gompa wrote:
On Wed, Dec 30, 2020 at 5:48 PM Marius Schwarz
<fedoradev(a)cloud-foo.de> wrote:
>
> Am 30.12.20 um 22:14 schrieb Michel Alexandre Salim:
>> - a separate partition for storing GRUB config, no matter what
>> architecture, is probably the ideal solution
> Not always. In VMs you would reduce the amount of partitions to ease up
> things. The main problem with Vms is, that you have LTS based linux
> distros on the host systems which can't mount the vm guest, if the guest
> uses newer filesystems. If you then use BTRFS on the boot partition or
> store grub configs in partionheaders, you can't access those from the
> guest making it impossible to change the bootconfig, if it fails for
> some stupid reasons like older pygrub ( xen ) boot loaders, which can't
> handle the kernel images compression/format. Happend last with Xenserver
> and Kernel 5.9.
>
> For this, i.E. me, choose to store the boot config on / so we have just
> one partition with ext4, which can easily mounted on the host, as ext4
> can be handled by the older LTS systems on the host.
>
> As Fedora is a good server os, if the ui parts have been removed ;), it
> should be taken into any consideration, that it may not be a bare metal
> installation you make plans for. It still needs to run in good old
> stable setups ;)
>
The issues Michel is referring to do not apply to Fedora Server using
Btrfs, because outside of Workstation, currently no variant of Fedora
has cross-layer integration with the bootloader.
I do not think that that is entirely true, well it depends on if anaconda
also sets the menu_auto_hide=1 variable for other variants. The grub hidden
boot menu stuff:
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
https://hansdegoede.livejournal.com/19081.html
Should mostly work, assuming they at least use a systemd user-session.
The boot menu being hidden or not depends on the boot_success grubenv
variable, which gets set by a systemd-timer in the systemd-user session
of non-system (aka normal) users if the user-session has lasted at least
2 minutes.
And since Fedora 33, the integration to force the boot-menu to be shown
is using the standard systemd DBUS APIs for this, so that e.g. :
systemctl reboot -boot-loader-menu=60
To cause the menu to show next boot with a timeout of 60 seconds works now,
except for a selinux bug which will hopefully be resolved soon:
https://bugzilla.redhat.com/show_bug.cgi?id=1856399
So other desktop-environments / spins / variants could also integrate
more closely with the hidden-boot-menu stuff, which is a pre-requisite
for getting a fully flicker free boot.
I would be happy to answer any questions people may have about this, but
I'm afraid I do not have the time to actively help with this (outside of
answering questions).
As for writing docs, the FAQ on my blog answers all end-user questions
that I know about. But yes we could use some more docs to help other
variants integrate better with this. If someone wants to start a wiki
page based on the Change + FAQ pages and then extend that as closer
integration is added to other variants, go for it. Feel free to take
all the text I wrote on this and put it under any FOSS license of your
choice.
That is, Fedora KDE does not currently have integration at the
desktop
level to trigger different GRUB states like GNOME will in Workstation.
If the KDE folks want to work on this, I'm happy to provide assistance,
see above.
Cockpit in Fedora Server Edition also lacks this ability.
I think that on servers just always showing the boot menu is fine and
some even find this desirable.
Most of this is due to missing documentation to actually *implement*
the capability in other variants. But the side effect is that the
concern we have is pretty much exclusive to Fedora Workstation.
See above, I admit this is not that well documented. But I have always
answered questions on this from various people, including other distros
who have implemented this from scratch themselves. So the info is
available in a way. And if someone can turn my emails into docs for this
then that would be even better.
Regards,
Hans