Intel Atom D2550 fails to boot HAOS 12.4

[this-user]

Describe the issue you are experiencing

My issue is that my newly installed HAOS refuses to boot despite having followed the instructions exactly, including having created a new UEFI boot entry. Despite the entry in question being selected, the system fails to launch the bootloader and instead returns an error message: Reboot and Select proper Boot device or Insert Boot Media in selected Boot device and press a key.

There is no option to even disable UEFI boot, and there is no Secure Boot or any other option that could be responsible that I haven't tried changing.

It seems this is related to the issue with 64-bit system that, for some reason, only support 32-bit UEFI. I have found a number of references to that issue as well as a few comments that this is supposed to work in more recent HAOS versions, yet it does not for this specific machine.

One thing that I have noticed when either booting Arch Linux from USB stick or installing a recent Debian version on the machine is that they seem to be using the GRUB IA32 EFI (grubia32.efi) executable whereas HAOS only offers the bootx64.efi.

So my question is whether the bootx64.efi is supposed to also support 32-bit mode or whether the 32-bit one is perhaps missing? I couldn't find an image that contains a 32-bit version. The grub2.mk file from the Buildroot project contains a reference to a bootia32.efi file at least for the i386 build. Perhaps that file could be included in the x64 build? Then it should be a simple matter of just adding a UEFI boot entry that points to that file.

Any pointers would be appreciated.

What operating system image do you use?

generic-x86-64 (Generic UEFI capable x86-64 systems)

What version of Home Assistant Operating System is installed?

12.4

Did the problem occur after upgrading the Operating System?

No

Hardware details

• Intel Atom D2550 (Cedarview)
• Intel NM10 Chipset

# uname -m
x86_64

# cat /sys/firmware/efi/fw_platform_size
32

Steps to reproduce the issue

1. Write HAOS image to disk as per the installation instructions
2. Create UEFI boot entry via efibootmgr
3. Attempt to boot system by deliberately selecting the new 'HAOS' entry

Anything in the Supervisor logs that might be useful for us?

There is no log

Anything in the Host logs that might be useful for us?

There is no log

System information

No response

Additional information

No response

[sairon]

Upstream GRUB 2.12 ssue with the NM10 platform where it fails to load Linux kernel is only fixed in 13.0.rc1+, see #3305

Please try the latest dev and if that doesn't work, enter GRUB's command line and run smbios --type 4 --get-qword 8 there, it should return a number that identifies that CPU and can be added to the exclusions list. But if I recall correctly D2550 has the same ID that's already patched.

[this-user]

Thanks for getting back to me. Installing 13.0.rc2 works, although I don't think it's the same upstream GRUB issue, because the system never even got to the point where the EFI executable was started.

However, 13.rc2 does include the bootia32.efi that was missing from the 12 series. If I add a boot entry pointing to that one, the system starts just fine. If I try using the bootx64.efi, I get the exact same issue as before. So I don't think its the GRUB kernel issue, but just the fact that there was no support for 32-bit UEFI in the previous versions. Perhaps a note could be added to the documentation about manually setting up the bootia32.efi?

[sairon]

Oh, sorry, I saw NM10 and immediately jumped to conclusions. Anyway, I think there's something else wrong. First, bootia32.efi is present in the boot partition of 12.4 as well - in fact, it's in all HAOS versions since #1819. Second, you shouldn't need to add UEFI entries using efibootmgr at all (I wonder how you did it though - booted another live distro?). All you need to do normally is to write the image to the boot drive and that should be it.

I might have an idea what is the issue though. As I said, it's not needed (or even desired) to add UEFI boot entry when installing HAOS. This is because the GRUB binary is in the default path of the EFI boot partition (aka "removable" GRUB install). And it also happened to me when I was debugging the GRUB issue on NM10 that the EFI list contained a non-existing path to the bootloader - then the boot failed with exactly the same message as for you. Weirdly, I couldn't clear it even with a CMOS reset - I had to boot a live USB with some other distro and remove all the UEFI entries manually. Then I was able to boot just fine.

And I'm also quite certain that all NM10 boards need the GRUB 2.12 patch to use the legacy load - however, I forgot that 12.3+ also contained a revert that addressed it as well.

[this-user]

The bootia32.efi is definitely not present in the version that I wrote to the disk:

# find /mnt/boot
/mnt/boot/
/mnt/boot/EFI
/mnt/boot/EFI/BOOT
/mnt/boot/EFI/grub.cfg
/mnt/boot/EFI/grubenv-A
/mnt/boot/EFI/grubenv-B
/mnt/boot/EFI/bootx64.efi
/mnt/boot/EFI/grubenv
/mnt/boot/cmdlline.txt

The file I used is the haos_generic-x86-64-12.4.img.xz that I downloaded directly from the GH release page last week.

$ md5sum haos_generic-x86-64-12.4.img.xz 
2b8080370c7f34ce13373500395e8c74  haos_generic-x86-64-12.4.img.xz

Second, you shouldn't need to add UEFI entries using efibootmgr at all (I wonder how you did it though - booted another live distro?).

Yes, I was using an Arch Linux ISO to boot from a USB stick and was then using dd to write the HAOS image to the disk of the actual system. Since that one did boot correctly in UEFI mode, I was able to use the efibootmgr to create the entry. Arch is using a patched 2.12-2 GRUB BTW that worked perfectly fine on that machine. Debian Bookworm, using a 2.06 GRUB also has no issues.

As for having to create the EFI entry manually, it might be the case that 13.rc2 didn't start correctly despite having the bootia32.efi present, because the HAOS entry was still pointing to the bootx64.efi. I haven't actually tried what would happen if I deleted all the entries first. But shouldn't it normally automatically look for the bootia32.efi if the specified loader doesn't exist/cannot be started? Although, maybe the fallback mode only works for the 64-bit executable, but not the 32-bit one, or it just stops searching if it has already found a 64-bit one even if it doesn't work? It also might be the case that the BIOS on the machine in question is not particularly well implemented. It's a bit of an off-brand machine of questionable quality anyway.

[sairon]

There's definitely something strange on your side:

$ md5sum haos_generic-x86-64-12.4.img.xz 
2b8080370c7f34ce13373500395e8c74  haos_generic-x86-64-12.4.img.xz
$ unxz haos_generic-x86-64-12.4.img.xz 
$ mkdir /tmp/haos
$ sudo mount -o loop,offset=1048576 haos_generic-x86-64-12.4.img /tmp/haos
$ find /tmp/haos/
/tmp/haos/
/tmp/haos/EFI
/tmp/haos/EFI/BOOT
/tmp/haos/EFI/BOOT/grubenv-B
/tmp/haos/EFI/BOOT/bootx64.efi
/tmp/haos/EFI/BOOT/grub.cfg
/tmp/haos/EFI/BOOT/bootia32.efi
/tmp/haos/EFI/BOOT/grubenv-A
/tmp/haos/cmdline.txt

But shouldn't it normally automatically look for the bootia32.efi if the specified loader doesn't exist/cannot be started?

It's not what I saw on D525MW - with non-existing UEFI entries, it just ignored the fallback GRUB binary on the SATA drive.

[this-user]

That is very strange indeed. I just tried the same process with that very image in a VM with an empty disk, and the 32-bit EFI executable does show up there. Maybe I did use a different image on the initial attempt, I had been trying different things to get it working.

In any case, the 13 series works, but as you have pointed out, the bootia32.efi isn't being used automatically. So I suppose that is something you have to add manually with these machines.

[sairon]

In any case, the 13 series works, but as you have pointed out, the bootia32.efi isn't being used automatically. So I suppose that is something you have to add manually with these machines.

Can't tell, one thing is for sure that the UEFI BIOS implementation isn't the best. I would prefer not to invest any more time into this platform than I already did. With its massive inefficiency (D525MW board sits around ~20W in idle with performance far lower than RPi 3), the sustainability of its usage is questionable IMHO.