FYI: update-grub / grub-mkconfig somewhat "broken"

[Bret Busby]

On 14/2/21 11:06 pm, Robert Heller wrote:
> For what it is worth:
> 
> The default setup for grub-mkconfig is somewhat "broken". It poorly handles
> the case where there is a shared /boot file system shared by two or more Linux
> distros. I have two systems that can dual boot Ubuntu 18.04 (4.15.0-* kernels)
> and CentOS 6.10 (2.6.32-* kernels). The default behaviour will include the
> options to boot with a 2.6.32 kernel with the Ubuntu root file system (this
> really won't work!)
> 
> I have managed to hack things (hacked 10_linux to skip centos kernels) to not
> do this and created a grub-mkconfig helper script specificly for the CentOS
> 6.10 kernels (it is hardwired for my systems). I also had to disable
> os-prober, since it was just not doing anything good, including trying to set
> up booting a VM as a bare metal O/S (!).  Hopefully, apt-get dist-upgrade will
> behave and not screw up my settings or overwrite my hacked 10_linux script.
> 
> I don't know if this is a bug or if my setup is just unique -- somehow I don't
> really believe that -- I don't really believe that *I* invented the idea of a
> separate /boot file system and multi-booting different Linux distros with a
> shared /boot file system. A separate /boot file system is actually necessary
> with LILO and grub 1.x when using LVM. I'm guessing with grub 2.x, you don't
> need to do that (no it is not worth the effort to change how my disks are
> partitioned).
> 
> Also I found an interesting passage in the grub manual:
> 
> " grub-mkconfig does have some limitations. While adding extra custom menu
> entries to the end of the list can be done by editing '/etc/grub.d/40_custom'
> or creating '/boot/grub/custom.cfg', changing the order of menu entries or
> changing their titles may require making complex changes to shell scripts
> stored in '/etc/grub.d/'. This may be improved in the future. In the
> meantime, those who feel that it would be easier to write 'grub.cfg'
> directly are encouraged to do so (see Chapter 5 [Booting], page 15, and
> Section 6.3 [Shell-like scripting], page 25), and to disable any system
> provided by their distribution to automatically run grub-mkconfig."
> 
> So it seems that even the grub devs don't full trust grub-mkconfig...
> 
> 

I do not know whether this applies to your scenario, but, on one of my 
systems, I have both 20.10 and 16.04.x of UbuntuMATE installed, with the 
system being originally a MS Win 8 system (it still has MS Win 8 
installed, but that is unusable, as I forgot the password for MS Win 8, 
and it was too difficult to use MS Win 8, anyway), and GRUB lets me 
select whichever of the two UbuntuMATE versions to boot, without any 
problem, and, that has applied, when the 20.10 was previous version 
numbers, going back to 18.04.

On that computer, I had previously had three or four different version 
numbers of UbuntuMATE installed, and, had no problems selecting and 
booting into the different version numbers.

I currently have that system running 20.10, as, whilst I prefer 16.04, I 
believe that EOL for 16.04, is due to occur in two months time, and so I 
thought it better to get used to running the stuff on that system, in 
20.10, before 16.04 EOL.

-- 
Bret Busby
Armadale
West Australia
(UTC+0800)
..............