Please Consider Schooling Me in Grub2
by enorbet from LinuxQuestions.org on (#5PM8T)
I;m asking for help, not because I lazily avoided docs, but because what I want from any bootloader, and especially one as complex as Grub2, is apparently unusual and I have yet to discover how to make it suit my needs.
I very much dislike OS-Prober. It matches up incorrect UUIDs with kernels that have no possibility of working on my multiboot boxen. This not only clutters the menu but makes it hit or miss in any recovery situation, and to some degree, in "normal" booting.
I also very much dislike employing UUID for disk/partition identification. I need human readable identities and /dev/sdfoo suits me just fine.
For those reasons alone I have preferred LILO for 2 decades, and really if it wasn't for one 8TB disk on my Main, I'd still use it - a very simple straightforward tool to do one job and do it well. Once I began down the rather offensive UEFI rabbit hole, being an inveterate multibooter, I turned to rEFInd. However rEFInd has been found to be vulnerable due to the whole Fat32 requirement for ESP/EFI partitions (can't always read /boot even when ext2, has no serious read-only protection, and the ESP variety is not adjustable or maintain-able through common tools like GParted, and most importantly, is vulnerable to some opsys installers. So, I am considering Grub2 which apparently eliminates the Fat32 requirements and limitations.
TLDR - I need to disable OS-Prober AND edit menuitem entries for specificity I can easily understand and adjust as needed.
Currently I have an alternate system of OpenSuSe 15.2 with the Grub bootloader and I cannot figure out why os-prober entries, edited with grub-customizer to match the UUIDs displayed with
Code: lsblk -f | grep -v loopin, as one example
Code: insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root c07638a9-9cab-4850-9ae1-345103c1278c
else
search --no-floppy --fs-uuid --set=root c07638a9-9cab-4850-9ae1-345103c1278c
fi
linuxefi /vmlinuz-5.12.12 root=/dev/nvme1n1p4boots systems on one drive yet the corresponding entries fail to even find the kernel on those others.
Is this a problem from efibootmgr embedding old UUIDs? Does the "else search UUID=foo" line allow checking more than one UUID to find the root and kernel? Is it possible to read .efi files (like BOOTX86.efi or refind_x64.efi) to eliminate the no longer useful remnants or are we expected to just cull and reinstall en masse?
I just want a persistent EFI Bootloader with human readable and edit-able menu list. Any ideas or recommendations most welcome.
I very much dislike OS-Prober. It matches up incorrect UUIDs with kernels that have no possibility of working on my multiboot boxen. This not only clutters the menu but makes it hit or miss in any recovery situation, and to some degree, in "normal" booting.
I also very much dislike employing UUID for disk/partition identification. I need human readable identities and /dev/sdfoo suits me just fine.
For those reasons alone I have preferred LILO for 2 decades, and really if it wasn't for one 8TB disk on my Main, I'd still use it - a very simple straightforward tool to do one job and do it well. Once I began down the rather offensive UEFI rabbit hole, being an inveterate multibooter, I turned to rEFInd. However rEFInd has been found to be vulnerable due to the whole Fat32 requirement for ESP/EFI partitions (can't always read /boot even when ext2, has no serious read-only protection, and the ESP variety is not adjustable or maintain-able through common tools like GParted, and most importantly, is vulnerable to some opsys installers. So, I am considering Grub2 which apparently eliminates the Fat32 requirements and limitations.
TLDR - I need to disable OS-Prober AND edit menuitem entries for specificity I can easily understand and adjust as needed.
Currently I have an alternate system of OpenSuSe 15.2 with the Grub bootloader and I cannot figure out why os-prober entries, edited with grub-customizer to match the UUIDs displayed with
Code: lsblk -f | grep -v loopin, as one example
Code: insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root c07638a9-9cab-4850-9ae1-345103c1278c
else
search --no-floppy --fs-uuid --set=root c07638a9-9cab-4850-9ae1-345103c1278c
fi
linuxefi /vmlinuz-5.12.12 root=/dev/nvme1n1p4boots systems on one drive yet the corresponding entries fail to even find the kernel on those others.
Is this a problem from efibootmgr embedding old UUIDs? Does the "else search UUID=foo" line allow checking more than one UUID to find the root and kernel? Is it possible to read .efi files (like BOOTX86.efi or refind_x64.efi) to eliminate the no longer useful remnants or are we expected to just cull and reinstall en masse?
I just want a persistent EFI Bootloader with human readable and edit-able menu list. Any ideas or recommendations most welcome.