@trevormcclellan If your suggested solution removes the need to manually change the boot slot after each HAOS version update then that’s perfect and I will give it a try.
I’m hoping it will remove the need to manually change the boot slot after an update. That is still to be determined. I only started digging into the source code when 10.4 came out since I ran into the same issue, so I haven’t been able to test yet with a new update. I can confirm, however, that the failover functionality appears to be working. My OK counters increase immediately and if I shut the laptop off before it fully boots 3 times, it boots into the previous version. Previously, the OK counters were always 0 as you said. This is on an old BIOS-based Dell Latitude E6500.
@trevormcclellan You’re right and my interpretation about needing the UEFI was not correct. I tested your solution and the counters started working. Thanks!
As you said, it remains to be seen if this removes the need to manually change the boot slot but I’m quite sure it will.
1 Like
I just updated to 10.5 and can now confirm that the boot slot does not need to be manually changed.
1 Like
Thank you for the solution, Can you please explain how should I edit the .cfg file?
Should I use Debian Live?
Please be patient, I’m not an expert for sure! 
Yeah, Debian Live should work, or any Live OS. I just used Ubuntu because I already had it on a flash drive. I’ll combine the instructions from others above that I used.
Edit the grub.cfg file
vi mnt/efi/boot/grub.cfg(open in editor of your choice)- change
load envtoload_env --file (hd0,gpt1)/efi/boot/grubenv - change
save_env A_TRY A_OK B_TRY B_OK ORDER MACHINE_IDtosave_env --file (hd0,gpt1)/efi/boot/grubenv A_TRY A_OK B_TRY B_OK ORDER MACHINE_ID - save and quit
8 Likes
This worked perfectly for me! Thanks so much for the detailed steps!
This. Worked. Perfectly.
However, I did go back and implement @blind-oracle 's implementation … but it worked like a charm. Thanks!
Hi, im a little new to linux, may i know what disk partitions did you create.
Thx
Why is it so hard to install HAOS? I mean… I can install ubuntu desktop with no issues and its all working, but installing a lightweight HAOS doesnt work? Someone have been sleeping in class when making this user frendly…
It’s not. It is actually pretty trivial assuming one uses a supported hardware platform.
Sure, that makes sense. Ubuntu is developed to run on a wide range of Desktop and Servers, as that is its target platform.
HAOS works great on the hardware it is designed for and tested on. It clearly states that a UEFI BIOS is required to install on x86 platforms. This thread is about users who are trying to install it on systems that do not support UEFI. Thus, the added complexity in trying to make it work.
1 Like
I know this post is a little old. I’m new to HA and just now trying to get started. Using a PC without UEFI I was able to follow these instructions almost exactly except I used Ubuntu to get to a terminal window. I even opened a Mozilla window so I could copy and paste the code after I kept making typos. I can get HA running and it sees some devices already on my network. I will keep going to learn more.
My question now is this: With this method, I am unable to update HA to a newer version through the web interface. It says it is updating, but restarts with the same version. I tried loading 10.1 instead and tried to update to 10.5 with no luck. Will I just need to manually update by re-installing HA using this same method and restoring a backup database? Or am I missing something?
Thanks. Dale
Everything worked great until 11.2 update, don’t know what happend. I start the update, after rebooting the update notification is still on and no update has been installed. Any ideas?
@drhalleron and @fortunenick :
I had the same issue and had to quickly move the cursor at boot to use slot B in the grub menu to actually boot into the new version.
I found the changes to /mnt/EFI/BOOT/grub.cfg were gone and I had to add “--file (hd0,gpt1)/efi/boot/grubenv” again to load_env and save_env.
Maybe the file was overwritten by one of the updates.
Has someone found a more permanent solution?
2 Likes
So I just completed this task and thought I would share my experience in 2023 as the posts I got all seem outdated, mostly focussed on ver 9.3, the current version of HASSOS is 11.2.
Why I did this?
- I have an old laptop, Acer ONE Intel Atom N450, it was probably built somewhere in 2010 way before UEFI was mainstream. Unfortunately it is a core part of the HASSOS installation.
- I only have a 250GB drive, and the image file requires a 1TB drive (Disk application complains)
- I have been running a “supervised” installation for the last 3 years and have fallen behind on the maintenance (monthly updates of OS, and supervisor and core and add-ins) to the point that everything was becoming a mess. I highly recommend you DO NOT follow this path…
Assumptions:
You have already installed a version of linux on the machine which is bootable - you can find this process all over. (There are other shortcuts here like only installing a boot partition and GRUB, you only need GRUB to boot the machine, you dont really need a full linux install)
Step 1:
Boot into a linux distro with flash drive. Any distro, they are very much the same (for this task - please dont hate me). I used Linux Mint 20 XFCE, the GUI runs better on older hardware. On the official X86 installation they explain how to use Ubuntu.
Note: May have to change your BIOS setup to allow flash drive to boot before hard drive.
Step 2:
Download the latest version of the disk image. It is available as point 5 under METHOD 1 on official website: X86 installation.
Step 4:
Unzip (xz) the image with: xz -d -c img_file_name.img.xz
You will be left with a disk image file. Note: the zipped file is around 400MB but after unzipping, it is about 7GB.
Note: Flashdrives are notoriously slow, you could mount your hard drive and extract there. Google it, in short create a directory under your /mnt folder, call it whatever you want. I used my drive partition, so mkdir /mnt/sda7 then mount /dev/sda7 /mnt/sda7.
Step 5:
Mount the img file: losetup --find --partscan img_file_name.img
This will now (hopefully) mount 8 partitions. First is the “boot” partition, the next 4 are kernel and OS “pairs” (an A & B version for fallback). The next is a “Bootstate” and then an “overlay” for configs and a “data” for add-ons and other storage. Partitions are detailed here. PS: Mine only mounted 4 partitions: kernel, OS, overlay and data.
Note: In the link above they state that the alternate 2 “boot” partitions are empty on a first install. I manually mounted partition 1 to get access to the EFI boot partition.
Step 6:
You now have to create partitions on your local drive to mirror the above. Running: “df -h” is helpful to see the required sizes of the partitions. I used the “Disk” tool in Mint (also available in most distros) which is a nice GUI interface to disk partitioning. I then resized my existing Linux partitions to open up space for the new partitions I need. I created a 25MB partition for my kernel(FAT), and a 250MB partition for my OS(FAT), a 500MB partition for overlay (NB to label this correctly as HASSOS-OVERLAY), and a 15GB partition for my data (NB to label this correctly as HASSOS-DATA).
Note: You will notice I did not create the “A & B” setup, perhaps I will in future need to come update this post…this is what I needed to get up and running. Technically, you should be creating the additional 2 partitions which will probably be an issue when I upgrade.
Step 7:
Copying data to your partitions: I tried using dd command to write the partitions using the mounted volumes as input but that did not work well, and I had 2 corrupted drives (squashFS issues). I therefore just recursively copied (with permissions) the data from the mounted partitions (above) to the new partitions. using: cp -pdRx /media/mint/DISK/* /media/mint/KERNEL/. - just an example, my kernel drive (with the bzImage file was mounted as DISK, the OS was mounted as DISK1, overlay and data as per above by label mounted as HASOS-OVERLAY and HASSOS-DATA).
If you have gotten this far, you are well on your way 
Step 8:
Configuring the boot file: Technically, you just need to hand the BIOS the kernel image, and the rest should just run. I opened the grub.cfg file from the HASSOS image mounted BOOT partition located in EFI/boot/grub/grub.cfg and copied everything after the first 2 lines (which were setting default and timeout) into my existing grub.cfg file located in /boot/grub/grub.cfg at the end of the file.
Step 9:
Making it boot: This was the most complex bit that took me time to figure out. The way drives are labelled and named depends on the architecture and bootloader version being used. The boot config in step 8 is pretty straight forward. There is an “A” and a “B” option, and then 2 “recovery” versions of same. The trick was in selecting the right drive and partition for the kernel (bzImage) and then identifying the root partition correctly so the kernel can handover to the OS. What worked in the end was to reboot, then hit “c” for command line when the GRUB menu came up. There I could run “ls” to see how my drives are being labelled. I had to change (HD0, GPT1) to (AHCI0,msdos7). The “root=” is defined by UUID (unique hardware reference to the partition) but this gave me a “Waiting on root” message and hanged for hours even after updating the UUID to the one matching the new partition. I replaced it with “root=/dev/hda7” (7th partition on the first hard drive), which worked!
Step 10 (extra):
If you had started like me with a previous basically unusable install, and had made backups using Google drive, you will find your backups on your Google drive. They are basically zipped files of the configs of apps and even the full homeassistant config. You can restore these files if you feel comfortable…I unzipped them and took out the files I needed to config my new installation as clean as possible.
1 Like
This worked like a dream. There appears to be one issue, though. On OS update, it appears that the EFI/BOOT/grub.cfg is overwritten.
My BOOT_ORDER was set to B A. I applied this fix, and it worked, booting to Slot B. After an OS update, it started booting to Slot A. I thought that everything was working as it should. Then, in the next update, it kept booting to Slot A. I inspected the EFI/BOOT/grub.cfg and the updates were gone.
1 Like
Yeah, that’s because the image contains the grub.cfg file. So it will overwrite it each update. To avoid this you can point your grub to use a different file like “grub_custom.cfg”. Of course copy the grub.cfg contents there and modify them. I am using this and it works. The downside is that if anything changes in the grub.cfg your custom one will not reflect that, but it shouldn’t change too much anyway.
1 Like
Makes sense.
My understanding of Grub isn’t extensive, but looking at the config, I’m unsure why manually specifying the env locations works. They’re not in “custom” locations.
Since we are pointing boot/grub/grub.cfg to the efi grub.cfg… is the load/save_env looking at the env in /boot/grub? If so, why isn’t that being updated accordingly?
As I’m thinking about it. I manually edited the /boot/grub/ env files and the changes were not recognized. So it’s almost like the env isn’t loaded unless directly pointed to. And since it doesn’t load it… it will always use the default BOOT_ORDER of A B
I take it that it’s not possible to do this from within HA using the terminal interface?
I’m trying to do this remotely and have limited tools and even more limited knowledge of how to use these tools.
hello. we don’t have that much technical knowledge. can you please explain in a video?