Hi, On 12/30/20 11:52 PM, Neal Gompa wrote: > On Wed, Dec 30, 2020 at 5:48 PM Marius Schwarz <fedoradev@xxxxxxxxxxxx> 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 _______________________________________________ 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
