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 <
>> 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.
>
`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