Hi,
Just for info. at this time.. Details on request.
Alternative multiboot setup. Overview.
There are a few minor potential "gotchas" with a traditional multiboot setup.
It's possible for a Grub module mismatch to occur i.e the initial Grub start is from one Grub version, with the target boot actually starting from another Grub version.
Yes, I'll agree it's rare and not likely to cause any particular problems.
A more serious problem which can and does occur is this. If a particular installation on a multibooted system has a kernel upgrade, the other installations local 'grub.cfg's won't reflect the changes until each of the local 'update-grub' has been run. Under these conditions, a particular installation may not boot if the recorded kernel version doesn't actually exist.
I agree this is not a major problem, if you are aware of the cause. It's more of a minor 'niggle' which requires each installed system to be booted and the local 'grub.cfg' updated.
Another "minor niggle" is if you wish to remove a particular installation. If this installation has 'lead Grub', then the system won't boot.
I use the following method on every multiboot system and external multiboot device that I use.
Grub is installed to the ESP partition. A hand crafted 'grub.cfg' then points to each installation as required. Every installation is fully standard and is installed and updated normally. The important thing is that each installation is totally independant of any of the others. If one system is removed, you only need to edit the initial 'grub.cfg' to suit. I keep a 'template' menuentry here, for ease of use. No system has 'lead grub'. Full initial control is provided by the 'ESP's 'grub.cfg'.
Typical initial 'grub.cfg' extract:
Code:
# menuentry "Template" {
# search --set=root --fs-uuid UUID-HERE
# set prefix=($root)/boot/grub
# configfile $prefix/grub.cfg }
menuentry "Ubuntu Cinnamon" {
search --set=root --fs-uuid 7caee267-2eb7-462a-bcab-498fd987bde5
set prefix=($root)/boot/grub
configfile $prefix/grub.cfg }
menuentry "Mint-Mate" {
search --set=root --fs-uuid ca7d8cc7-4b53-439c-ade8-4bb714eaab8c
set prefix=($root)/boot/grub
configfile $prefix/grub.cfg }
menuentry "OpenSuse" {
search --set=root --fs-uuid 77b16df4-9741-4da1-b8ee-a02047e32426
set prefix=($root)/boot/grub2
configfile $prefix/grub.cfg }
menuentry "Devuan" {
search --set=root --fs-uuid d6f677d0-b5fd-4194-8ecc-2586a949421d
set prefix=($root)/boot/grub
configfile $prefix/grub.cfg }
All you need for each entry is the UUID of the relevant filesystem (from 'blkid') and the location of the local 'grub.cfg'.
You can boot an installation that doesn't use Grub by calling the kernel & initrd directly if desired.
On powerup, this ESP based 'grub.cfg' is run first every time. Control is then passed to the selected installation's 'grub.cfg' which starts the system perfectly normally.
If you are using this method on an external device, you can call the external drive ESP's 'grub.cfg' by using your "boot override", direct Bios boot selection or from the EFI shell.
Full details on any of this on request.
B.
