Re: Inconsistency Grub Menu vs. /boot/grub/grub.cfg

[John Little]

address@hidden wrote:
> Inconsistency Grub Menu vs. /boot/grub/grub.cfg

It's likely they are different grub.cfg files.  You have many subvolumes
in your btrfs (as you seem to be running snapper, or a tool like it) and
they all have grub.cfg.  They may have been the same at some point but
those you've booted into and run update-grub (perhaps triggered by
something else, such as apt full-upgrade) will be different.  Note also 
the "rootflags=subvol=" phrase is missing on the posted grub.cfg, I 
don't know how important that is.

IMO the Debian scripts that generate grub.cfg do not work well with
btrfs when there's multiple bootable subvolumes.  They just haven't
caught up with what's possible with btrfs.  A mess becomes likely, with
the root subvolumes fighting over who controls the boot.

I use a hand-coded grub.cfg with UEFI, on a small @grub subvolume
independent of any install or snapshot.  To achieve this I mount the
btrfs root on /mnt/top, and run

    # btrfs su create /mnt/top/@grub
    # grub-install --boot-directory=/mnt/top/@grub/boot 
--efi-directory=/boot/efi

Then I edit the grub.cfg there to reduce it to about 100 lines.  I
presently have 5 subvolumes I can (and do) boot into.  The manual 
grub.cfg entries can be much simpler.  For example:

menuentry 'Kubuntu Disco' --class ubuntu --class gnu-linux --class gnu 
--class os {
  gfxmode $linux_gfx_mode
  set root='hd2,gpt2'
  search --no-floppy --set=root --label "main"
  linux /@_disco_u/vmlinuz root=LABEL=main ro address@hidden
  initrd /@_disco_u/initrd.img
}

(That uses the label I've set on the btrfs, much more readable than a
UUID, and uses the /vmlinuz and /initrd.img links that APT scripts keep
pointed to the latest kernel version.)  With the commands that simple it 
is feasible in one-off situations to type them at the grub prompt.

The grub scripts keep trying to overwrite my setup, and preventing this
has been discussed on this list; I'll repeat this discussion here for 
convenience.  The simple expedient of not mounting the EFI partition 
stops most of it, but not all.  So I copy the grub EFI executable, and 
set up a boot entry for it:

    # cd /boot/efi/EFI/ubuntu
    # cp grubx64.efi my.efi
    # efibootmgr -c -d /dev/sdc -l '\EFI\ubuntu\my.efi' -L mine

And so when grub disturbs the boot I can quickly fix it with efibootmgr.

For completeness, I'll mention /etc/fstab, and the need to adjust it to
make a subvolume boot properly.

I wonder about booting into a snapper (or whatever) snapshot like that; 
surely you risk breakage if snapper "cleans up" that snapshot, which it 
might do for several reasons.  I suggest snapshotting a snapshot you 
want to boot into, to a path outside of snapper.  If you then want to 
run snapper in that subvolume, you may need to create a snapshots 
subvolume for it, or it will fail to start.  I expect they'll fix that 
one day.
--
Regards, John Little