New Installation on Linux KVM fails to boot with an 'unsupported' error

[rtstarliper (Tim)]

I am attempting to install the current hassos on a KVM virtual machine, however I keep getting dropped to the EFI shell instead of booting.

I followed the steps here, then looked through several related posts - including ones marked as resolved. I also searched for KVM UEFI issues and came across this YouTube video that, although the virtualization platform is Proxmox vs. KVM and the OS is different, seemed to match my situation. I looked and the entry in the EFI configuration pointing to the efi file for hassos was missing. I added that entry, and it is the first boot entry. I still get dropped to the EFI shell:

I caught a brief glimpse of a message before this screen, but was unable to see it. I managed to get a screenshot of it:

The error seems to indicate the hassos efi boot file (bootaa64.efi) is not supported - which is why I think this might be more an HA issue than an KVM EFI issue. Of course, I could be wrong.

If I exit from the EFI shell, I get the EFI configuration screen, just as shown in the video I linked above. Adding a boot option, I see the hassos-boot disk as the only one available:

with the only path being EFI/BOOT/, and two options under that:

Grubenv is not a boot loader, so that is not a viable option - leaving the only option the bootaa64.efi file - which is unsupported.

On the KVM side, I did as I saw in this thread here and checked the configuration for the virtual machine (see the last two entries in the thread).

   <os firmware='efi'>
    <type arch='x86_64' machine='pc-i440fx-10.0'>hvm</type>
    <firmware>
      <feature enabled='no' name='enrolled-keys'/>
      <feature enabled='no' name='secure-boot'/>
    </firmware>
    <loader readonly='yes' type='pflash' format='raw'>/usr/share/OVMF/OVMF_CODE_4M.fd</loader>
    <nvram template='/usr/share/OVMF/OVMF_VARS_4M.fd' templateFormat='raw' format='raw'>/var/lib/libvirt/qemu/nvram/xxxxxxxx_VARS.fd</nvram>
    <boot dev='hd'/>
  </os>

I am not using the default hassos name, I am using a different VM name, which I obfuscated here.

It seems as though KVM/OVMF is finding the boot file, it just doesn’t seem to like it - hence the ‘unsupported’ error.

What have I overlooked or what am I missing here? I really do not want to have to set up a separate box for this - the idea of it being a VM in the first place is to take advantage of the server and rack. Purchasing a new server is well out of the budget for now anyway (I need something with redundant power supplies and rack-mountable for this use case).

[Frank_Beetz]

So your OS is Linux - and you are trying to install via virtual-manager or virtual-install?

If you are doing it via virt-manager, than I believe the instruction listed in your link are no longer up to date.
I had to leave out Steps 7-9 to make it happen.

[wmaker (Tommy Long)]

I haven’t done this in a while, but just glancing at some things… your XML file looks correct to me, but wondering the bootaa64.efi would probably be for an ARM. Are your running this on an ARM?

[rtstarliper (Tim)]

So your OS is Linux - and you are trying to install via virtual-manager or virtual-install?

If you are doing it via virt-manager, than I believe the instruction listed in your link are no longer up to date.
I had to leave out Steps 7-9 to make it happen.

I am using virt-manager. I will look into it further when I am back in the station - I am only there one day a week at the moment, and have not installed virt-manager at home so I can get there remotely (at least, not on the working home pc )

I will see what happens skipping that part of the machine setup.

Thanks!

[rtstarliper (Tim)]

I haven’t done this in a while, but just glancing at some things… your XML file looks correct to me, but wondering the bootaa64.efi would probably be for an ARM. Are your running this on an ARM?

Nope. This is an x64 system. I never gave the bootaa64.efi name a thought as to possibly being ARM instead, but I can see that as a possibility (assuming ARM can support an EFI boot). That is as it came in the downloaded KVM image from the link on the page I referenced. I wonder if it is possible that something is wrong with the image. This would certainly explain the unsupported message. An ARM image would certainly not be supported on an x64.

If what Frank_Beetz suggested with leaving out some steps doesn't work, I will see about downloading the Virtualbox image and converting it.

Speaking of converting, I did try converting from the qcow2 format to a raw img format. No change in behavior (didn't really expect there to be, but the other VMs I have on this box are all using the raw .img format - so why not).

Thanks for the response. I will check on this when I get in tomorrow morning and see what happens!

[slh]

This is most likely a configuration problem on your side, rather than an issue with haos itself. I see two (slightly orthogonal issues) are primary potential issues here:

• UEFI wants persistent nvram state (variables, boot entries, etc.), kvm can (but doesn't need to) emulate this by keeping these in an emulated pflash (~a file on your disk, just like the emulated drive container, but independent from that). If you re-use an OS definition, this virtual nvram will remain persistent (including outdated/ wrong boot entries).
• according to your paste, there seems to be a mismatch between the host arch (presumably x86_64) and the VM (image-) arch (apparently ARM64/ AARCH), so check what kind of image (architecture) you actually downloaded

I see potential for either of these here, e.g. the "HASSOS" entry doesn't come out of nowhere, someone (~you) will have to have manually created it (it's not the removable media path fallback) using efibootmgr and might have mistyped the filename there - on the other hand you might have downloaded the ARM64 disk image instead of a x86_64 one.

I would suggest to start over from scratch again, not taking shortcuts by reusing old VM definitions. Generic x86-64 - Home Assistant should give you all the details necessary.

[rtstarliper (Tim)]

UEFI wants persistent nvram state (variables, boot entries, etc.), kvm can (but doesn't need to) emulate this by keeping these in an emulated pflash (~a file on your disk, just like the emulated drive container, but independent from that). If you re-use an OS definition, this virtual nvram will remain persistent (including outdated/ wrong boot entries).

I have this set up for this VM, but it is not a default configuration. The only time I reuse a definition is when I am building a new server that is run on Debian 13. I have a 'golden' Debian 13 base image that I will copy over. In the case HASSOS, I downloaded the KVM file from the HA website, that is a VM disk image in qcow2 format. This is from the Linux-specific instructions. All configurations are from scratch for this VM, following those instructions.

according to your paste, there seems to be a mismatch between the host arch (presumably x86_64) and the VM (image-) arch (apparently ARM64/ AARCH), so check what kind of image (architecture) you actually downloaded

This is where I suspect the issue lies. Like I mentioned, I am using the KVM image I downloaded from the Linux instructions on the HA website, and used without modification. This means that if the efi image is not correct, then it is incorrect in the qcow2 file linked in the Linux installation instructions on the Home Assistant site.

I tried eliminating the steps indicated by @Frank_Beetz, with no change in behavior. My next target is the EFI file. I am going to pull down the qcow2 image and mount it in another system where I can actually look at it. If the same efi file is there (I suspect it will be), then I am going to pull down the Virtual Box image and do the same. If it has a different efi file, then I will see about using that one (the efi file, not Virtual Box - I am not a fan of Virtual Box).

[rtstarliper (Tim)]

Here's something interesting. I downloaded using the same link as I used previously, however this time the image is different - name and size. Size is not really a surprise. Name - it's a significantly different name.

rtstarliper@wmss6:~/Downloads$ ls | grep qcow2
-rw-rw-r--  1 rtstarliper rtstarliper  386782172 May  3 08:11 haos_generic-aarch64-17.2.qcow2.xz
-rw-rw-r--  1 rtstarliper rtstarliper  555120812 May 10 08:44 haos_ova-17.3.qcow2.xz
rtstarliper@wmss6:~/Downloads$

I pulled down the vdi file as well. Same base name as the qcow2 from today. I unpacked both files and mounted the efi partition. The efi file is the same for both - and not the same as in the file downloaded using the same link last week.

Today's qcow2 file:

rtstarliper@wmss6:/media/rtstarliper/hassosq/EFI/BOOT$ ls
total 734
drwxr-xr-x 2 root root   2048 May  6 04:51 .
drwxr-xr-x 3 root root   2048 May  6 04:51 ..
-rwxr-xr-x 1 root root 741376 May  6 04:51 bootx64.efi
-rwxr-xr-x 1 root root   2236 May  6 04:51 grub.cfg
-rwxr-xr-x 1 root root   1024 May  6 04:51 grubenv
rtstarliper@wmss6:/media/rtstarliper/hassosq/EFI/BOOT$

Last week's qcow2 file:

rtstarliper@wmss6:/media/rtstarliper/hassosq2/EFI/BOOT$ ls
total 802
drwxr-xr-x 2 root root   2048 Apr  7 07:20 .
drwxr-xr-x 3 root root   2048 Apr  7 07:20 ..
-rwxr-xr-x 1 root root 811008 Apr  7 07:20 bootaa64.efi
-rwxr-xr-x 1 root root   2216 Apr  7 07:20 grub.cfg
-rwxr-xr-x 1 root root   1024 Apr  7 07:20 grubenv
rtstarliper@wmss6:/media/rtstarliper/hassosq2/EFI/BOOT$

And, for completeness, the vdi file from today:

rtstarliper@wmss6:/media/rtstarliper/hassosv/EFI/BOOT$ ls
total 734
drwxr-xr-x 2 root root   2048 May  6 04:51 .
drwxr-xr-x 3 root root   2048 May  6 04:51 ..
-rwxr-xr-x 1 root root 741376 May  6 04:51 bootx64.efi
-rwxr-xr-x 1 root root   2236 May  6 04:51 grub.cfg
-rwxr-xr-x 1 root root   1024 May  6 04:51 grubenv
rtstarliper@wmss6:/media/rtstarliper/hassosv/EFI/BOOT$

My quess is the link may have been pointing to the incorrect file - I used the same link today that I did last week. Time to move files around and see what happens.

[Frank_Beetz]

I hear what you are saying about VirtualBox - I ditched that one also on my Windows machine for VMware about 5 years ago.

But while the KVM approach on Linux resulted in a working VM that ran my HA quite nicely, I was faced with networking issues which I couldn't solve at the time.

In my desperation I turned towards VB and lo and behold it has done the job very reliably for the last month or so.

So if you run out of ideas - give VB another chance?

[slh]

I am running haos under (plain) kvm on linux just fine, it works. You obviously can't use the aarch image and need the x86_64 one.

[rtstarliper (Tim)]

I need to run multiple virtual machines, and this is one of the things I encountered with VB. I didn't want to have to run the virtualization under a user, and run an instance for each machine. At work, I had a management platform that was only available as a virtualbox image (or as a turnkey box from the vendor that I couldn't get management to spend the $$$ for). The network for KVM has been nailed down long ago - when I first built this KVM host. I created a number of bridge interfaces, one for each subnet/vlan that one of the machines will need. Sine I was virtualizing some machines that were previously bare metal, the firewall rule and routing were already in place on the network. I just had to build the VM in KVM and away I went.

The KVM host is dedicated to hosting virtual machines, so I didn't have to be concerned about other things on it.

[rtstarliper (Tim)]

See my message above. The file downloaded today is different than the one downloaded last week - using the same link from the same page. I suspect something was messed up with that link on the site, and was fixed when an updated image was posted.

[slh]

I've seen that, however I haven't really heard about any results with the correct image (there's no point even trying the aarch image on an x86_64 host).

A wrong image download usually hints at a layer 8 problem, though.

[rtstarliper (Tim)]

Had there been multiple options other than VirtualBox or KVM, I would agree - however there were no other options. The image that is currently there is correct and boots. Now to do the rest of the configuration.

[rtstarliper (Tim)]

Solved by downloading the KVM image again, using the same link as a week ago but this time the file was different.

The issue was the efi boot file - it was for ARM, not x86_64. The image downloaded this morning has the correct efi boot file, and the image boots properly.

Thanks for the help!

[slh]

Not only the efi executable, literally everything - it was just an image for the wrong architecture.

[rtstarliper (Tim)]

Likely. I didn't compare the filesystems to see what differences there were, I just looked at the EFI partition - didn't even mount the others.

Wanted to mention previously - I am well aware of the layer 8 problem. Encountered it many times over my career. Too many times....