HAOS Install on X86 fails with Grub prompt


I tried to install HAOD on an oldish Intel NUC at the weekend, using the latest version from the site. I followed the instructions - fix bios to disable secure boot, make sure it’s UEFI. Boot with live Ubuntu on USB, download the ISO, copy to partition, reboot.

When it boots, I get a Grub error and a CLI. I can do LS I think to list partitions, but I didn’t manage to use the CLI to get through the problem.

I tried everything

  • I used a different live USB, and used DD to copy the ISO
  • I tried the previous RC2 ISO, in case the latest ISO is corrupt
  • I found the ubuntu CLI for efimgr, and tidied the boot order list

I spent 6 hours, and didn’t succeed. I learnt more than I wanted to about UEFI :slight_smile:

So… I believe the downloading and copying the ISO onto the partition installs
both a new partition table and a whole batch of compressed partitions - and
it puts Grub 2.12 in there too. When Grub boots, it tries to find something on one of the partitions, and this fails in my case, hence the CLI.

One thing that puzzles me is that after the copying the ISO, surely the new partitions should be visible in tools? Gparted couldn’t see it. The Ubuntu installer doesn’t see it. But fdisk does see the new partitions - and it immediately told me that there was some problem to fix. I got fdisk to fix it and … the grub problem was still there.

I found the problem on here that there’s a bug in recent grub that causes something a bit similar, but i see that’s been fixed / worked around in the lates
ISO - so that’s not it.

So, my questions

  1. Are we supposed to delete all partitions on the target disk and create one new one? Is there any other obvious step that I don’t know about? If we create
    a new partition to overwrite, should it be EXT4 or ?

  2. What exactly is happening when we copy the downloaded HAOS ISO - am I right that this is installing a partition table and 8 partitions and Grub?

  3. Why is all this new partitioning invisible to Ubuntu installer and Gparted?

  4. Is there any chance that what you’re doing is somehow a bit iffy - I saw a comment that your partition table is hybrid. Some version of fdisk off Ubuntu
    definitely thinks the partition table you’ve created is invalid…

  5. I couldn’t see SHA hashes for the HAOS downloads so I can double check

Help would be really appreciated - VirtualBox and USB are not really the best of friends, and I lose my SkyConnect. I’d much rather HA is installed on the PC -
but I need to do the install!


Martin Green


I seem to have got past this problem.

For those hitting this issue, the recognized method didn’t work for me. Specifically restoring the downloaded xz file using Disks in Ubuntu 22.04 resulted in a disk that didn’t have a recognised HAOS partition set.

What did work was downloading the same 12.3 image in Ubuntu 22.04 live, unpacking manually and using DD to write to the local SSD.

The key test here is to run a partition viewer - gparted, disks - after writing the SSD and checking that you have a whole bunch of HAOS partitions.

When using the documented method, I saw one unrecognized partition. When using DD I saw 8 - and that booted into HAOS.

Now… I can get back to actually trying HAOS out!!

More information for the sceptical.

  • Using HAOS latest, which I think is 12.3
  • Following the first documented generic method
  • Turn off secure boot, make sure bios is UEFI
  • Boot from Ubuntu live. Download 12.3 x86 xz image.
  • In Disks utility, choose ‘restore image’ to write the xz image to disk
  • Reboot. In my case, I get a Grub prompt.

Some notes

  1. The docs aren’t clear on what to do with existing partitions. I think you
    should actually delete them all, create one big one and restore to this. The
    screenshots in the docs show someone leaving an existing boot partition -
    can’t be right?

  2. The docs suggest the ‘restore partition’ feature in Disks will decompress
    the xy. It appears to do this, but I didn’t test manually decompressing. Obviously
    if we wrote the compressed image to disk, that would cause the problem.

  3. If I use the documented method, the disk still contains one partition which
    is unrecognizable - i tried gparted, fdisk - nothing thought there was anything
    useful there. Grub CLI only sees one unrecognized partition. It’s clear that restoring the partition using Disks failed in some way.

  4. I could not get balena Etcher to work at all on Ubuntu 22.04. I found three
    guides to get around issues, none of them fully worked. I tried manual install
    and added fuse. I tried a bash script. I tried the AppImage - fixed various
    things, still failed. Nightmare!

Another note…

I just did this all again on a new machine. I used my DD method, and it failed - I didn’t see the list of 8 partitions.

I checked again… I’d used DD to copy the downloaded image to a partition. I changed this to use DD to copy it to the actual device, and it worked.

Maybe this is also the trick in the DISKS tool - is there way to restore an image to the device, and I missed it and restored to a partition?

YES - so, it turns out I’m a muppet after all, and the whole saga is user error - I restored a partition image not a disk image.

Sorry :frowning: