rEFInd / Discussion / General Discussion: Can lowercase boot in loader path affect rEFInd behavior?

This is a continuation of some other topic[1], but I wanted to make it a separate issue since it's really an interesting one.

First of wall, I have the following partitions on my multiboot pendrive (which actually is an SD card plugged into an external SD card reader):

# lsblk /dev/sdb
NAME    SIZE FSTYPE  TYPE LABEL                       MOUNTPOINT UUID
sdb    28.9G         disk
├─sdb1  100M vfat    part SD_ESP                                 AD3E-8645
├─sdb2    3G iso9660 part Ubuntu 18.04.4 LTS amd64               2020-02-03-18-40-13-00
├─sdb3    3G iso9660 part Ubuntu 19.10 amd64                     2019-10-17-12-53-34-00
├─sdb4    3G iso9660 part d-live 10.3.0 gn amd64                 2020-02-08-12-48-50-00
├─sdb5    3G iso9660 part d-live 10.3.0 ma amd64                 2020-02-08-12-47-49-00
├─sdb6    3G iso9660 part Linux Mint 19.2 MATE 64-bit            2019-07-29-12-12-10-00
├─sdb7    3G ext4    part                                        6ad21575-730b-424e-8bcf-7ce691ffcbfa
├─sdb8 1000M iso9660 part GParted-live                           2020-01-21-00-31-03-00
└─sdb9 1000M iso9660 part 20200302-eoan-amd64                    2020-03-02-14-27-53-00

# gdisk -l /dev/sdb
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 60506112 sectors, 28.9 GiB
Model: STORAGE DEVICE
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): B36B76F8-412C-4150-A476-312A656F71AB
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 60506078
Partitions will be aligned on 2048-sector boundaries
Total free space is 19341245 sectors (9.2 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          206847   100.0 MiB   EF00  sd_esp
   2          206848         6350847   2.9 GiB     8300  Ubuntu LTS
   3         6350848        12494847   2.9 GiB     8300  Ubuntu Latest
   4        12494848        18638847   2.9 GiB     8300  Debian Gnome
   5        18638848        24782847   2.9 GiB     8300  Debian Mate
   6        24782848        30926847   2.9 GiB     8300  Linux Mint
   7        30926848        37070847   2.9 GiB     8300
   8        37070848        39118847   1000.0 MiB  8300  Gparted
   9        39118848        41166847   1000.0 MiB  8300  Clonezilla

On the Debian mailing list, one guy suggested creating static entries for the ISOs. So I edited refind.conf and added:

scanfor manual

and added entries like the following ones for all the ISOs:

menuentry "Ubuntu LTS" {
    icon EFI/BOOT/icons/os_ubuntu.png
    volume 67F11057-F4C1-4504-82EC-B6EE2A558B9F
    loader   /EFI/BOOT/grubx64.efi
}

menuentry "Debian Gnome" {
    icon EFI/BOOT/icons/os_debian.png
    volume 3AE69E07-679F-486A-8F99-338013F9A4B9
    loader   /EFI/boot/grubx64.efi
}

the volume of each entry points to Partition unique GUI of each partition:

# sgdisk -i 2 /dev/sdb
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 67F11057-F4C1-4504-82EC-B6EE2A558B9F
...
Partition name: 'Ubuntu LTS'

Ubuntu LTS, Ubuntu Latest and Linux Mint work well when selected their entries.

The Debian images boot on their own (when they burned to the device instead of partition). In the above setup when either one of the Debian menu entry is chosen, the Clonezilla grub boot menu appears.

I thought maybe when I switch the entries in the rEFInd menu, so the Debian would go last, it will affect the behavior in some way, but it didn't. So I removed the Clonezilla entry from the menu and left only Ubuntu and Debian. After I selected Debian, Clonezilla boot screen showed up anyway...

I tested also what would happen if I removed the clonezilla partition altogether (without rewriting it, just remove the entry from the partition table via gdisk). When a Debian entry was selected in rEFInd, the GParted boot screen appeared...

So I removed the GParted partition as well, and checked again. Then Linux Mint boot screen appeared... It looks like, it goes in alphabetical order (C, G, L). What would be next, U for Ubuntu?

I checked, and removed the Linux Mint partition. In this moment when I had only 2x Ubuntu and 2x Debian partitions, the Debian Gnome booted... So Ubuntu doesn't seem to fit in this alphabetic pattern. But when I wanted to boot Debian Mint, the Debian Gnome was booted instead, probably because M is after G in the alphabet, so Debian Gnome is selected in either case...

To be sure, I removed the Debian Gnome partition and then Debian Mate booted when selected its entry in rEFInd.

At this point I thought maybe something is wrong with the Debian Gnome ISO file. So I recreated all the removed partitions except the Debian Gnome and checked. It looks like it's the same behavior as it was with Debian Gnome, but now Debian Mint is involved.

Playing with the different settings, I accidentally booted the GParted entry at some point. I didn't do this before because it was obvious to me that GParted boot screen means that GParted is to boot or that the Clonezilla boot screen means that Clonezilla will boot -- wheat else would be booted when you select "Boot GParted" or "Boot Clonezilla" in the Grub list? But it turned out that Debian was booted... So I selected GParted entry, and Debian booted -- that's weird...

So what would happen if I selected the Debian entry, which shows me GParted grub boot screen and chose to boot from the Grub list whatever is listed there? In this case, also Debian is booted...

So all the images (Debian Gnome, Debian Mint, Clonezilla and Gparted) are somewhat connected together -- selecting either one will boot ultimately Debian.

The interesting part is that each of the 4 ISOs individually works well. So If I added only one of the ISOs to the two Ubuntus and Linux Mint, it will boot well. But as soon as I add another ISO (one of the three left), then the problems begin.

The question is how the ISO driver works and finds what to load into memory? The volume entry in the each menuentry stanza is different. The only thing I can see that would affect whether the ISO boots properly is the lowercase boot in the path in the loader line. Every ISO, which uses capital BOOT, works. In the cases of lowercase boot, the ISOs don't boot or lead to this weird situation. All the 4 affected have lowercase boot.

I would probably check what would happen when I edited the ISO files and capitalize the BOOT, but I will check later.

So what do you think? Any thought on this.

The EFI driver for ISO-9660 that ships with rEFInd simply provides access to each ISO-9660 filesystem to the EFI, which identifies each one as a separate volume, similar to the way they're handled in MS-DOS or Windows. rEFInd can then access them. If they're showing up as unique volumes in rEFInd, then the ISO-9660 driver is almost certainly working correctly, at least in this respect. You can investigate this further in an EFI shell. Launch it and type a filesystem identifier (like fs0: or fs3:) to access that filesystem. You can then peruse the filesystem with commands like ls and cd to verify that they're correct, comparing what you see in the EFI to what you see in Linux or some other OS.

My suspicion is that the problem is in GRUB. Specifically, I suspect that GRUB in the problem distributions is not correctly identifying the follow-on boot location. This might happen if all the problem distributions are based on the same original source, as I believe they are. (I don't use the Clonezilla or GParted live CDs myself, but some Googling suggests they're both based on Debian.) If the GRUB on the ISO-9660 filesystem, as booted by rEFInd, only looks for the first Debian-like system it can find on a partition, or if it's identifying the follow-on location by something that's invariant between all your distributions (like a filesystem name that's identical between them all), then it'll get it wrong. You'd need to dig into the GRUB configurations of all the problem distributions to figure this out. I haven't attempted to dig that deep.

Can lowercase boot in loader path affect rEFInd behavior?

An EFI boot manager utility

Forums

Help

Can lowercase boot in loader path affect rEFInd behavior?

Can lowercase boot in loader path affect rEFInd behavior?

An EFI boot manager utility

Forums

Help

Can lowercase boot in loader path affect rEFInd behavior? document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

Can lowercase boot in loader path affect rEFInd behavior?