mjhjmtu

I have three Linuxes installed on a 2TB drive.
In addition I have two partitions carrying common data, plus three swap partitions.

Following a glitch of some kind and limited recovery only one option from the grb2 menu can successfully be booted, the remainder producing Kernel Panic.
I can change which one can become bootable by running rescatux and choosing a different one. The remainder then become unbootable!

How can I probe where the problem lies and how to fix it?

The job of the Linux bootloader, in general, is to get three things from the disk to RAM:

• the Linux kernel file


• the initrd/initramfs file (this can be optional)


• the boot options, which often specify the root filesystem.

As you have three Linux installations, you probably have three separate root filesystems: one fore each installation. Each installation may also have /boot as a separate filesystem, or as sub-directory of the root filesystem. Each of those will contain a GRUB2 bootloader configuration file that contains the correct boot settings for that specific version of Linux. Rescatux is probably just picking one installation and using its GRUB2 configuration file to re-write the GRUB into the disk's Master Boot Record (or onto the EFI System Partition, if you have UEFI in native mode, instead of legacy BIOS).

You should pick one of your Linuxes as the "primary" maintainer of the bootloader, as having multiple GRUB2 bootloaders on the same disk won't really work. Ideally that would be the newest Linux distribution you've installed, as it is the most likely to have the best filesystem type support built into its GRUB2.

Once you have the "primary" Linux distribution bootable, you should manually mount the filesystems of the other distributions and find their GRUB configuration files. Read them to find out where the other distributions have GRUB loading their kernel and initramfs files, and what boot options they use. You now have all the information you need to add the other distributions to the boot menu of your "primary" Linux installation. If the menu items are already there, you can now check them for incorrect paths, syntax errors or wrong boot options.

Once you manage to get the GRUB of your primary installation successfully booting the other Linux installations, you might consider uninstalling the GRUB packages from the non-primary installations. That way, you won't accidentally ovewrite the GRUB of the primary installation when installing updates to one of the non-primary ones.

The flipside of that is, unless you can figure out a way to have the newest kernel and initramfs files of the non-primary installations on non-changing filenames, you'll have to update the GRUB configuration of your primary installation manually each time you install a new kernel package on one of the non-primary installations.