Hi, On 1/12/21 5:55 PM, Michel Alexandre Salim wrote: > Hi, > > Thanks for the thorough reply, Hans! One question inline > > On Tue, 2021-01-05 at 12:31 +0100, Hans de Goede wrote: >> Hi, >> >> On 12/30/20 11:52 PM, Neal Gompa wrote: >>> On Wed, Dec 30, 2020 at 5:48 PM Marius Schwarz < >>> fedora...@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. >> > > `boot_success` needs to be cleared per boot though, right? So that if > the user session timer doesn't set it back (so we assume the boot > failed), the next boot shows the GRUB menu. > > Where does this happen? I'm under the impression this happened in the > GRUB execution environment, which is problematic if that environment is > on a filesystem GRUB can't write to.
Correct this happens in the grub execution environment. > Apologies for seeing this late, it would be nice to get this > information going into tomorrow's FESCo meeting since Javier's proposal > has a -1 that is partly due to concern over breaking the hidden menu > functionality -- https://pagure.io/fesco/issue/2543 So I've read Neal's comment there and what he describes really is a special corner case, but yes it is possible for people to have created the special setup he describes and yes in that case moving grubenv to /boot will break the hidden-menu functionality. I'm not sure if this warrants a -1 to the proposal though, I believe documenting this + some workaround for it should be sufficient. But as mentioned in the fesco issue this has more to do with the fact that storing the grubenv in a filesystem-file is a bad idea in general. As discussed in detail here: https://pagure.io/fedora-workstation/issue/206 we really should be moving away from that. As discussed there Suse already has grub-patches to instead store the grubenv in an part of the btrfs filesystem header which is reserved for bootloader use. As @javierm says in the linked fedora-workstation issue, that is also the long term plan for Fedora, but we really want to discuss and develop a solution for this with/at grub-upstream so that we don't end up with conflicting solutions between distributions which stomp all over each-others data. Regards, Hans _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
