fix efistub bootloader to use backslashes

[h8d13]

As seen in wiki example:
https://wiki.archlinux.org/title/EFI_boot_stub#efibootmgr

efibootmgr --create --disk /dev/sdX --part Y --label "Arch Linux" --loader /vmlinuz-linux \
--unicode 'root=block_device_identifier rw initrd=\initramfs-linux.img'

Was just wondering why EFIstub never worked to boot and found this :)

#1431 #2684

[codefiles]

This does not fix anything, see the note at the bottom of Unified Extensible Firmware Interface#efibootmgr.

Edit: The note is not applicable to kernel parameters.

[h8d13]

This does not fix anything, see the note at the bottom of Unified Extensible Firmware Interface#efibootmgr.

Right so try without the patch and then with it? I do not think you had the time to do so ? Are you actively testing changes ? Also did you look at linked issues ?

Like we have never seen firmware quirks, and shouldn't respect the actual specification of provided example (because explicit is better than implicit :) ?

The conversion works for --loader not --unicode that goes straight to the firmware as is (hence the 'content here'. Have a good rest of your sunday, Hade

[codefiles]

You are correct, the note I mentioned does not apply to the kernel parameters like initrd.

Relevant sections of the ArchWiki that support this change:

• https://wiki.archlinux.org/title/Kernel_parameters#Parameter_list
• https://wiki.archlinux.org/title/EFI_boot_stub#Booting_an_EFI_boot_stub

I have caught this before in the past but never submitted changes because I misunderstood the note. I also tested this same thing in the past but could not get it to work in my test environment.

[h8d13]

You can also also see it directly here: https://github.com/rhboot/efibootmgr/blob/main/src/efi.c#L330-L361
Which converts UTF-8 → UCS-2 directly https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#file-names

[codefiles]

Left some comments that are extremely minor. Good to be merged as is.

[codefiles]

I erroneously changed this with bc3b3a3. Here is the relevant line before that change:

archinstall/archinstall/lib/installer.py

Line 1096 in 332ec0d

f"initrd=\\initramfs-{kernel}.img",

That commit is from 2023 but #1431 is from 2022. The log from that issue shows version 2.5.0; backslashes were intact:

archinstall/archinstall/lib/installer.py

Line 979 in c75e6a1

kernel_parameters.append(f"initrd=\\initramfs-{kernel}.img")

In #2684 it was reported that it works when the ESP is /boot but not when it is /efi. In either of those cases this same line would get used in the kernel parameters, when not using UKI as they reported having done. The ISO given is 2024-09-01 so the code with the erroneous forward slashes would have been in use, eliminating that as a possible cause to the issue.

Also did you look at linked issues ?

I have seen them before but never determined the source of the issue.

Though I agree with this change, it can be ruled out as fixing the linked issues. If the EFI boot stub option was broken I would expect there would be more than these two old issues with no other users commenting on it.

[h8d13]

I can think of dozens of times I've told people to use Grub/Limine or systemd-boot because this one was flaky (when there are 2 reports here, means more on other forums regardless, bbs/reddit/etc, and even from me testing it several times, aside from people not reporting or who do not use efistub)

I like it (technically one less pkg lol), is why I was trying to fix it :D

Then I tried it on alpine and it worked flawlessly, so I was was wondering and just thought what if it's something to do with python formatting (and how its passed to the tool), and no worries, shit happens

Also nice UKI patch lore 👯

[codefiles]

Yes, I am very aware that other places exist that issues with archinstall get discussed but as I demonstrated the two linked issues would not be related to the changes here. That would mean 0 reports of this causing an issue here then not 2.

The standard for initrd is indisputably to use backslashes but using forward slashes causing breakage has not been demonstrated. I think it is likely most UEFI implementations accept forward slashes.

From one of your earlier comments:

Right so try without the patch and then with it?

I just tested and can boot with no problems when forward slashes are used in the initrd path. After booting /proc/cmdline contained the kerenel parameter initrd=/initramfs-linux.img with the starting forward slash. I tested the patch, and after booting /proc/cmdline contained the kernel parameter initrd=\initramfs-linux.img with the starting backslash.

Are you able to reproduce a failed boot when using forward slashes? It does not look like you have ever stated so directly.

[h8d13]

You are testing in VMs or weird hardware ?

Im not sure how being more correct can be worse than hoping the firmware implementation is well done for others' hardware.

A lot of these tools are known for quirks with firmware equivalent implementations or straight up not following specs. Like msi boards not booting without removable bootloader

I think it is likely most UEFI implementations accept forward slashes.

Emphasis on "most"

[codefiles]

You are testing in VMs or weird hardware ?

QEMU/KVM

Im not sure how being more correct can be worse than hoping the firmware implementation is well done for others' hardware.

It can't. I am in favor of merging the patch friend. If I had the ability to merge it, I would have already. I desire knowledge and that makes me want to see the evidence of a system that fails to boot when the initrd contains forward slashes. This does not mean I in anyway object to the patch in the absence of that evidence. The patch enforces the standard and that is enough reason to merge it.

A lot of these tools are known for quirks with firmware equivalent implementations or straight up not following specs. Like msi boards not booting without removable bootloader

Good point.