Being able to indicate the location of the airootfs.sfs file without having to provide the UUID of the partition

tell the kernel by parameter where the airootfs.sfs file resides

How?

The boot loader and kernel+udev address the block devices in an entirely different way. While mkarchiso uses a GRUB (🤮) specific feature to search for a specific file (/boot/grub/YYYY-mm-dd-HH-MM-SS-00.uuid) and pass the UUID of the volume it's on to the kernel, it still relies on a UUID.

An alternative would be getting rid of the separate rootfs image and place it all in the initramfs image.

How?

I do not know. I am no expert in these matters. But I understand that it is possible when it is done in other systems, for example Puppy Linux boots without any UUID being specified.

I think Debian's initramfs implements searching all volumes for the rootfs image.

added hinthelp-wanted label

Why would you need to search any drive for the root file system image?

Take a look at my branch anyway.

The initramfs needs know where the root file system image is since it needs to mount it. If the boot loader doesn't tell it (via archisodevice) then it needs to search for it in some way.

The initramfs gets the ISO UUID where the root file system resides from the GRUB kernel parameters in GRUB configuration file in all my branches.

The ISO UUID is written in configuration files at build time so no mistakes can be made about which drive to load. When the root file system image is an encrypted one, the UUID is instead given to encrypt hook, while /dev/mapper/root is given to archiso hook as stable archisodevice value.

I don't see a single good reason to have the bootloader "guess" anything, in particular the root file system image location (and its signatures).

To load root file system image from a set of alternatives is not having the bootloader randomly guess which drive contains the correct root file system, so either integrity checks on kernel and initramfs have to be included in GRUB directly or the kernel has to be copied over an encrypted space so that the even if the UUID is the same, the bootloader won't be able to open the partition with using user's provided "secret".

I didn't notice the "recent" mess-up in grub-embed.cfg for uefi systems because on my branches I have been selecting the correct drive using security-sorted UUID search of build-time encrypted external partitions (booting images from eventually present unencrypted volumes with signatures on the above mentioned encrypted partitions or from secondary drives on public builds) since last year.

The idea is to avoid hardcoding the UUIDs. This is what "file system transposition" is all about, you simply copy the ISO contents to a FAT formatted USB flash and it simply works for UEFI booting.

The is no reason not to have hardcoded UUIDs without "file system transposition": the guessing mechanism can be used as fallback when drives corresponding to hardcoded UUIDs are not available.

The security vulnerability introduced by guessing the root file system drive can be partially avoided by hardcoding root file system image checksums in the bootloader config file embedded in the bootloader binary and verify integrity at runtime before loading the kernel.

With code implemented to do that you can also check kernel and initramfs integrity at the same time. I want to stress code code to that with minimal effort is on my branch since last year probably.

I still think guessing the drives for the root file system is a bad choice in the general direction of maximizing total I/O by accessing install media images from multiple available sources or easing install media access.

One doesn't want to read the data from any device providing correct data, one wants data from a specific drive only, so more data should be gathered to estabilish if the selected drive is the same from which the boot loader has been loaded.

more data should be gathered to estabilish if the selected drive is the same from which the boot loader has been loaded.

The existence of the /boot/grub/YYYY-mm-dd-HH-MM-SS-00.uuid file is proof enough. If the need ever arises we can make the file name even more unique.

This is madness.

I will add a mandatory checksum on loaded artifacts to my code just the same.

I will be sure to use the same vulnerability you are keeping open to let ISOs produced by my fork auto-close the hole whenever they find a vulnerable but legit install medium.