help-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRUB2 Behavior Question


From: John Little
Subject: Re: GRUB2 Behavior Question
Date: Fri, 27 Mar 2020 16:56:44 +1300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 27/03/2020 03.33, Matt Sickler wrote:
> ... a semi-embedded system ...
Gosh, I've no experience with anything like that.

> linux-root ... is actually a subvolume...
The linux root being a subvolume is normal for Ubuntu.  I use subvolumes
to have many installs in one btrfs.

> @    A symlink to the subvolume we want to boot into

It's never occurred to me that subvolumes could be symlinked to, or that
the fstab entries could refer to symlinks.  I tried it out and neither
gave any trouble, except that by the time I logged in, the symlinks had
been resolved by linux (I mention that because when grub-install is run
it won't know about the symlinks).  Cool, IMO.

> ...how grub actually executes at boot... (in the MBR or somewhere)...

Yes. That depends on whether the system uses UEFI or the old BIOS/MBR.
(You might tell us that.)

grub-install writes a pointer to grub's "second" stage.  Briefly,
with UEFI the location is written into the grubx64.efi image in the EFI
system partition (or it least it was last time I looked). With
BIOS/MBR it's written into the core.img that lives in the "MBR gap",
between the MBR and the first partition.  It's written as a grub
partition and a directory.

My opinion is even more that you should consider a manual, simple,
grub.cfg.  Otherwise I'd expect some grub update to break the boot
sooner or later.  The grub script machinery generating grub.cfg seems
oriented towards desktop and laptop use.

If that's too far off the beaten track, I suggest picking one install to
control grub and uninstalling grub from the others (or blocking it from
running there).  It's quite normal for grub in one install to boot
another, as long as that controlling install will always be there.

With UEFI it would be easy to copy or rename the .efi files to get
control that way.  (The EFI system partition is FAT32 so no symlinks.)
With BIOS/MBR, conceivably a script could backup and restore the
core.img with dd, and people used to do that, but there be dragons.

Also, you might consider using the "vmlinuz" and "initrd.img" symlinks.
In your debians they might still be in the linux root directory, that is
/vmlinuz and /initrd.img, but when Ubuntu went to linux 5 last year they
moved into /boot.  APT maintains them to always point to the latest
kernel.

HTH,
--
Regards, John Little



reply via email to

[Prev in Thread] Current Thread [Next in Thread]