[SOLVED] Please Consider Schooling Me in Grub2

enorbet · 09-16-2021, 11:07 AM

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 loop

in, 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/nvme1n1p4

boots 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.

colorpurple21859 · 09-16-2021, 12:18 PM

grub-install installs grub boot code in MBR or or grubx64.efi on efi partition Usually only ran during install or grub package upgrade. On an efi system, some distros grub looks for the grub.cfg on the efi partition(that may point to a /boot/grub/grub.cfg), while others only points to /boot/grub/grub.cfg

update-grub/"grub-mkconfig -o /boot/grub/grub.cfg" creates grub.cfg. Usually ran with kernel upgrades

configuration files for grub.cfg:
/
etc/default/grub: sets default menu, disable/enable os prober/ video resolution, uuid enable/disable
/etc/grub.d/ scripts that are ran to produce the grub.cfg based on what is in /etc/default/grub
The scripts are ran in order of number, 40_custom is used for custom menu entries, The scripts can be disabled/enabled with chmod -x/+x

after editing configuration files need to update-grub/grub-mkconfig for changes to take place.

From what I have observed, with mutlibooting if another system has it's own separate boot partition, grub usually doesn't pick it up.

Grub customizer puts the files in /etc/grub.d in a backup folder in grub.d inserts it's own files, not sure what grub customizer does with the /etc/default/grub

enorbet · 09-16-2021, 01:07 PM

Thanks colorpurple21859 that helps some but I know most of that stuff. For example I know how to disable OS-Prober but I'm uncertain at how to get "foreign" systems in the menu list AFTER OS-Prober is no longer in play. The UUID situation is a major issue for me. I hate using them. They just aren't immediately recognizable and there is some variation on where and how that information is stored so that conflicts can and do occur. Maybe that "else" operand can deal with that but I'm not sure how yet. I'd rather just eliminate the conflict by using /dev/sdfoo. I already have a working Grub2 from SuSe but some entries boot and others can't even find the kernel even if they are in the exact same location as the one that does boot.

1st order of business - How do I create a menuitem entry that will guaranteed find the drive/partition and kernel as reliably as LILO and to a lessser degree, rEFInd does does? At least LILO gives me meaningful error messages.

enorbet · 09-16-2021, 02:20 PM

Nuts! I'm already up against Grub's rebel ways in naming conventions for drives/partitions...specifically if Grub2 sees NVME drives as just (hd#,#) or some other specific nomenclature.

teckk · 09-16-2021, 03:08 PM

How about this.
https://wiki.archlinux.org/title/GRUB

colorpurple21859 · 09-16-2021, 03:17 PM

Grub doesn't use sda mmc nvme for drives/partitions, it uses (hd#,#) for spinning, usb, mmc, nvme drives. (cd#) is optical drives. Grub2 counts drives from zero, partitions from 1 in the format (hd0,2) is drive 1 partition 2, (hd2,5) is drive 3 partition partition 3.

Code:

set root=(hd1,3)

sets drive 2 partition 3 grub looks in to load the kernel and initrd specified by the linux line and initrd line.

The "root=/dev/sdb3" "root=UUID=<some long number> is an option that is passed to the kernel on the linux line so the kernel knows where to look for the file system

For what ever reason, I don't know why, there is a search function that follows the "set root=" that will change the "set root=" . I have seen where the search function has caused problems setting the root partition.

mrmazda · 09-17-2021, 12:23 AM

Try reading these threads addressing your interest, keying on custom.cfg:
https://www.linuxquestions.org/quest...nd-4175679796/
https://www.linuxquestions.org/quest...8/#post6219712
https://www.linuxquestions.org/quest...nu-4175700376/
https://www.linuxquestions.org/quest...ut-4175694318/
https://www.linuxquestions.org/quest...tu-4175693330/
https://www.linuxquestions.org/quest...fi-4175692306/

They're the first 6 hits from a search for string custom.cfg by user mrmazda:
https://www.linuxquestions.org/quest...rchid=11961745
There is surely more to be found in those other than the first 6.

Some background and a few procedural details:

My primary OS is openSUSE
I have more than 2 dozen multiboot PCs averaging well in excess of 12 installed distros each
Most of these PCs have only one "disk", either SSD or HDD or NVME
My only virtual machines are PC DOS hosted on OS/2 or one of its derivatives
Three PCs use RAID1, while none use LVM, and except for BTRFS on one laptop, all / filesystems are EXT3 or 4
All partitioning is done independently of any OS installer, never during any OS installation, always with only one partitioning tool that logs its activity, which I use for OS/partition inventory
On MBR systems, with very few exceptions limited to *buntu, all still boot via openSUSE's very friendly Grub Legacy with Gfxboot
On UEFI systems, except for a Mac, which uses openSUSE Leap's Grub2-efi, all are booting from custom.cfg hosted by openSUSE Tumbleweed
On UEFI systems, the ESP partition is mounted to /boot/efi/ only if openSUSE Tumbleweed is the booted OS
Windows 10 is installed on a select few MBR PCs only, and very infrequently used

petelq · 09-17-2021, 04:42 AM

If you set a label for the partitions you can set up refind to look for the vmlinuz and initrd syslinks using partition labels instead of UUIDs.
Check the refind.conf file in /EFI/refind. That way you don't have to reset every time you update the kernel.

pan64 · 09-17-2021, 04:47 AM

I guess you can create a VM and try [almost?] everything what you want inside.

hazel · 09-17-2021, 06:47 AM

Why not just use elilo if you don't trust refind? Personally I wouldn't touch grub with a bargepole.

smallpond · 09-17-2021, 08:20 AM

Quote:

I also very much dislike employing UUID for disk/partition identification.

You don't have to use either UUID or the variable sdaX forms. Use e2label or btrfs to set a LABEL on your partitions, and boot and mount that way.

In /etc/default/grub:

Code:

GRUB_DISABLE_LINUX_UUID=true
GRUB_ENABLE_LINUX_LABEL=true

Then change commandline to root=LABEL=myroot

I mount and umount my backup drive by LABEL=backup so I never have to worry about getting the right volume.

lovemeslk · 09-17-2021, 12:41 PM

Code:

menuentry 'Slackware 15.0 x86_64 (post 15.0 -current) (on /dev/nvme0n1p2)' --class slackware --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-3f76a8a7-795c-42f3-b1ba-d273265c2e05' {
	insmod part_gpt
	insmod ext2
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root  3f76a8a7-795c-42f3-b1ba-d273265c2e05
	else
	  search --no-floppy --fs-uuid --set=root 3f76a8a7-795c-42f3-b1ba-d273265c2e05
	fi
	linux /boot/vmlinuz-generic root=/dev/nvme0n1p2 ro vga=792 init 4
	initrd	/boot/initrd.gz
}
submenu 'Advanced options for Slackware 15.0 x86_64 (post 15.0 -current) (on /dev/nvme0n1p2)' $menuentry_id_option 'osprober-gnulinux-advanced-3f76a8a7-795c-42f3-b1ba-d273265c2e05' {
	menuentry 'Slackware 15.0 x86_64 (post 15.0 -current) (on /dev/nvme0n1p2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-generic-5.10.8--3f76a8a7-795c-42f3-b1ba-d273265c2e05' {
		insmod part_gpt
		insmod ext2
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root  3f76a8a7-795c-42f3-b1ba-d273265c2e05
		else
		  search --no-floppy --fs-uuid --set=root 3f76a8a7-795c-42f3-b1ba-d273265c2e05
		fi
		linux /boot/vmlinuz-generic-5.14.5 root=/dev/nvme0n1p2
	}
	menuentry 'Slackware 15.0 x86_64 (post 15.0 -current) (on /dev/nvme0n1p2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-huge-5.14.5--3f76a8a7-795c-42f3-b1ba-d273265c2e05' {
		insmod part_gpt
		insmod ext2
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root  3f76a8a7-795c-42f3-b1ba-d273265c2e05
		else
		  search --no-floppy --fs-uuid --set=root 3f76a8a7-795c-42f3-b1ba-d273265c2e05
		fi
		linux /boot/vmlinuz-huge-5.14.5 root=/dev/nvme0n1p2
	}
}

sample of my grub I manually keep it up. Only time I remap grub2 is adding new hard-drive.
or reformat a partition. Some time i don't to that I just use the blkid
Plus I use it to boot live cdroms and puppy Linux

enorbet · 09-17-2021, 01:37 PM

Wow a lot of posts to respond to. Thanks. I'll try to address each one. I thought I had it licked this morning, well.. did for awhile (more on that further down) but not by getting Grub2 to do my bidding. I am some impressed that Grub continues to work at least with what actually works. I still have yet to work out how to satisfy Grubs diabolical complexity and syntax to be able to designate a kernel and it's location and have Grub find and use it. This is likely complicated even more by having at least 6 systems on 5 drives on this Main box.

My problems actually began with two projects on one day. I upgraded my BIOS/UEFI image, loaded optimized defaults, and manually edited what I wanted and after noticing that one of my ESP partitions that I had created as 1GB in size, although working nicely for many months, showed up as only 500MB recognized. That was confirmed on the important issue of it's Free Space, which is very cramped with so many bootable systems. After backing up ESP and using GDisk to resize to 500MB and restoring "/boot/efi", rEFInd launched but only showed a blank white screen with the rEFInd logo and zero bootable systems. Over time I finally got an error message saying rEFInd could not scale an icon.

Once I figured rEFInd should be able to handle those icons just like it did before I checked BIOS/UEFI settings and one of the settings I'd missed was specifically designating PCIe as the first and preferred GPU (I turn off IGPU). After that rEFInd worked as before! Hallelujah, right?

Not quite. There was a newer UEFI image and I was hoping for support for PCIe v4, and thinking the GPU setting was the culprit, I flashed UEFI again to the newer one, and rEFInd stopped working again. Setting GPU to PCIe did not fix it.

So TLDR, there are issues with elilo and multibooting that make it a low priority. I'm still having problems directing Grub2 and why it can't find one kernel while it can another in the same location escapes me so far making Grub2 a less desirable tradeoff just to avoid FAT32 ESP limitations. That said there are a lot of links posted here so I will spend some time trying to gain control over Grub2. However if I can find whatever BIOS/UEFI setting returned function I think it behooves me to try to find that first before I explore Grub2 further.

Addendum: I'm actually pleased I flashed the latest BIOS image, despite getting bitten where the Sun don't shine, yet again, because it has new functions, most notably detailed and deeper NVME control. I will try to answer each individually but I'm likely to be all day today getting rEFInd back to have a decent base to work from. Thanks again to each and every respondent.

enorbet · 09-17-2021, 03:24 PM

Quote:

Originally Posted by petelq

If you set a label for the partitions you can set up refind to look for the vmlinuz and initrd syslinks using partition labels instead of UUIDs.
Check the refind.conf file in /EFI/refind. That way you don't have to reset every time you update the kernel.

Thank you but I'm almost never having a problem getting rEFInd to find the kernels and I ALWAYS assign Labels to ALL Partitions from old habit. It prevents a lot of mistakes. Also I'm VERY familiar with refind.conf as I prefer to turn off scanning and just declare what I want.

My main problems with rEFInd are

1) Major - Apparently some BIOS setting affects rEFInd's function to display graphics and I don't yet know what it is. I thought it was specifying NO IGPU and Load PCIe first , but while that may be part of the solution it isn't all of it. Oddly enough rEFInd doesn't always display an error message but when it does it complains about scaling icons reporting numbers that make little sense.

For example, one such message about an icon that I placed in the icons folder was...

Code:

  Warning: Unable to scale icon IBM.png from 1953459968 x 2037672306 to 128 x 128

I literally scaled that icon myself to 128x128 in GIMP after that message and still got the same error. I tried deleting the icon and replacing it with a default icon in refind.conf and STILL got the error. There is apparently some BIOS graphics support that toggles and if rEFInd doesn't have it, it stalls. Whatever setting this is has zero effect on any running system. I've benchmarked graphic performance and always monitor power and temperature of GPU and CPU and zero effect... excepting rEFInd.

2) Minor - My Main is Slackware and because I'm still using a 14.2 install but testing with several Current/v15.0-Alpha (which updates a LOT) with differing update schedules, I have several self-made icons to differentiate and every time I try to restore rEFInd it rewrites the icons folder, naturally without my custom icons. FAT32 apparently can't protect it in it's ESP format and that may even be how an install of Mageia on a completely different hard drive managed to bork rEFInd from the jump. For size and safety, I'd dearly love to dump FAT32.

enorbet · 09-17-2021, 03:32 PM

Actually, after spending an hour or so depending on what does work in Grub2, and suffering from Fat32 and Graphics issues in rEFInd, I'm changing horses in midstream and leaning toward learning Grub2 better.

Current problems I'm having with Grub2 (and thank you guys for definitively stating that Grub2 sees all drives with the (hd0,1) format with no special term fro NVME but I still am confused about drive order. In other systems and even on GParted within OpenSuSe, NVME drives are first in line BUT check this out....

Code:

 
localhost:/home/enorbet # lsblk -f | grep -v loop
NAME        FSTYPE LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                
├─sda1      ext2               9d849441-5366-4888-bfb8-527fb5107503                
├─sda2      ntfs   XP64PRO     13EBC1AA7A522B61                                    
├─sda3      ntfs   Win_7       6A380E7D380E4911                                    
├─sda4                                                                             
├─sda5      vfat   CRNT32-BOOT 0010-3CD2                                           
├─sda6      ext4   Current-32  0a09c0f9-74d7-476a-b7ae-d9aff5f8d3ea                
├─sda7      ext3   Slack1432   c6dbab74-939e-413d-861e-b918e96ac3df                
├─sda8      ext4   TEST2       1bfa0a68-2575-4bc4-9911-8baecec71cef                
├─sda9      ext4   Slack14264  464faeb1-198a-44a3-8db0-c0caf6638072                
├─sda10     ntfs   ntfs1       02824A3C3B6DC713                                    
├─sda11     swap               6fb16721-3860-44ab-9460-67ade71f8543                
└─sda12     ntfs   Games       3F0CA8A431E81D13                                    
sdb                                                                                
├─sdb1      ext4   BigBack     5720b39d-4af0-4a75-9742-ee55bdbbc6a3                
├─sdb2      ntfs   764         4C60783654C005AC                                    
├─sdb3      vfat               AB4E-5169                                           
├─sdb5      ntfs   PFTmp       04C4AEB1C4AEA480                                    
├─sdb6      ntfs   HUGE_NT     000C75FB0C75EBD2                                    
├─sdb7      ext3   HUGE_X      6a0ea32a-9943-4152-afaf-69f781d0be12                
├─sdb8      ntfs   MongoNT     01CA338A25A73920                                    
├─sdb9      ext4   NewSuSe     405c37ca-28d9-4577-94c3-77b61014a169   91.6G    30% /
└─sdb10     ext2   OldPopBoot  0b0254fd-0978-4a06-9d86-271cea50ec36                
sdc                                                                                
├─sdc1      vfat   ESP         12A5-C095                                           
├─sdc2      swap               1a0ba59c-a297-4498-93ad-042f4387b51e                
├─sdc3      ext2   Cnt1129Boot f1764ed7-f41e-420e-9f77-473115757878                
├─sdc4      ext4   NewExt4     76e3815c-774c-4a90-bf19-81f432a0dcf5                
├─sdc5      vfat   SUSEBOOT    D68B-CBEB                              14.9G     0% /boot/efi
├─sdc6      ext4   StoreExt4   ff9a84bc-2d56-442d-a0c6-2202d6ed6464                
├─sdc7      ntfs   StoreNT     6E42D81801FD82DC                                    
├─sdc8      ext4   Mageia-8    0d5e661c-1784-4433-9e6d-4a0bdc0e3229                
└─sdc9      ext4   NoNameExt4  266ae154-5e66-43df-b753-ec0fcf2f264e                
sdd                                                                                
├─sdd1      vfat   EFI         C4EA-647B                                           
├─sdd2      ntfs   NTFS        EE522BBE522B8B03                                    
├─sdd3      ntfs   Ext2        7E7A5AAD7A5A61C7                                    
├─sdd4      ntfs   N-Sys       1A3684143683EED7                                    
└─sdd5      ntfs   NTFS-Store  1245C88D1BA4C71F                                    
nvme0n1                                                                            
├─nvme0n1p1 vfat   NVMEEFI     CF7B-BD05                             403.7M    19% /mnt/NVME-0/boot/efi
├─nvme0n1p2 ext2   NvmeBoot    c07638a9-9cab-4850-9ae1-345103c1278c    1.4G    18% /mnt/NVME-0/boot
└─nvme0n1p3 ext4   NewSlack20  27b37a15-8879-490c-8082-6011bfafd848  292.3G    63% /mnt/NVME-0
nvme1n1                                                                            
├─nvme1n1p1 vfat               0C9D-F374                                           
├─nvme1n1p2                                                                        
├─nvme1n1p3 ntfs   Win-10      A0BCA3BFBCA38DFA                                    
├─nvme1n1p4 ext4   TestSlack   2c055feb-8a35-4a49-9da6-0291a79cdf39                
└─nvme1n1p5 jfs    JFS         793d4ddd-9901-449a-8ed4-03a1453a095a

Not only do NVME drives come AFTER mechanical drives, they even come after /dev/sdd which is a USB stick! So, my question is, will my drive designation in Grub2 fail, just from having a thumbrive or external drive connected?

NOTE: Because SuSe defaults to controlling Grub2 with Yast and uses the "search" functions for discovered kernels, the menu ONLY shows UUID and has no (hd0,1) entry to compare to in order to see how NVME drives are actually numbered.