Not had that much time to fiddle thus far, after discovering this thread. All I did re OS update was establish a successful mirror to my main HA installation, then asked it to update the OS via the web interface from another computer, in the normal way. Of course, I also manually intercepted the reboot, in order to choose the HA disk boot option in the bios. Otherwise it would have booted to my current default (Windows). I wonder if changing the default to the HA disk might have some effect - that is something else to try. However, while playing with the various possibilities (“to USB or not to USB”), I did re-flash the disk with the latest generic x86-64 image. Hence it’s all up to date at the moment and I await the next OS upgrade before trying again.
Have also seen the post about choosing slot B etc. Don’t know what the implications of that are or how to try it - my boot only shows the ‘slots’ option on screen for less than a second before starting up, presumably would have to press some keys PDQ to intercept it. I’ll try that as one possible solution at next OS update and will report back here, unless someone else solves it in the meantime!
Thanks a lot for this thread.
I do not have any knowledge of linux or HA and with your help i’ve managed to install HA for the first time and its up and running on my old laptop!
The easiest way for me to follow was the description of @carloshurtadom
The only problem i have on this moment is updating to HAOS 9.5
In HA GUI it says to update to 9.5, im clicking on it and it goes updating… then HA (on my old laptop) restarts and is showing OS version: Home Assistant OS 9.4
Thanks @sandman-125, I tried slot B in Grub boot menu after running the update and now HA says OS version 9.5
Anyone knowing why this happens and how to eliminate this?
Thanks in advance.
this is what i’ve found at Reddit (https://www.reddit.com/r/homeassistant/comments/v675kc/make_ha_boot_the_latest_os_by_default/): “I think it probably means the OP updated from 7.6 to 8.1. The OS is updated via an A/B update mechanism so 1. the new OS can install while the old OS is still running, and 2. the old OS is still there as a backup in case something goes wrong with the new OS. It seems from the OP’s experience that a power cut is treated as “something goes wrong” for this purpose”
@Richard28 I would assume that it is by design that it runs the updated version to slot B but I’m not sure. I didn’t worry too much about it so I just set it to boot to slot B by default from Grub boot menu. You should be able to do this by editing the file efi/boot/grub.cfg in hassos-boot partition.
By default the first line in that grub.cfg is set default=99
Just edit that to be as below (and save the changes):
set default="1"
Then in the Grub boot menu it will select slot B by default.
Hello,
Thanks for your help. I managed to install Homeassistant on my old computer. But I have a problem. I have no problems with the network cable, but it cannot find my wifi adapter. Can you help with this issue?
(sorry for my bad english i use translation)
I had the same problem, when I upgraded Home Assistant OS from 9.5 to 10, my system stayed on 9.5 until I made change in efi/boot/grub.cfg (set defuaul=99 to set default=1) and now I am on Home Assistant OS 10.
But I have another problem. Before I move to slot B I have this under about:
Home Assistant 2023.4.6
Supervisor 2023.04.0
Operating System 9.5
Frontend 20230411.1 - latest
And all other stuff are working.
only error I had under repair: AppArmor issues - unsuported system
After I moved to slot B In CLI I see that I am on HA OS 10, but under about I have only this:
Home Assistant 2023.4.6
Frontend 20230411.1 - latest
I lose abiliti to shutdown/restart my system, backup doesn’t work, no addons tab,…
error in cli: /dev/sda1 can't open blockdev
Then I try to move back to slot A, but nothing happened in CLI I can see HA OS 9.5.
I lose ability to restart/shutdown, backup, no addons tab, …
Can anyone explain how HA OS upgrade script work?
It is possible to customize it for non-uefi bios machines?
when ha os is up and runing i ran command: ha os update from cli
when update complete ha os goes to restart
when pc starts I first boot to some linux and mount sda1 with command: mount /dev/sda1 /mnt
then I edit /efi/boot/grub.cfg with command nano /mnt/efi/boot/grub.cfg end I changed default=99 to default=1 to get more time to select slot b
then umount mounted sda1 with command umount /mnt type reboot to restart pc
on system boot select slot b and wait system to complete
I am now on latest version of ha os with all stuff working.
Home Assistant 2023.4.6
Supervisor 2023.04.0
Operating System 10.0
Frontend 20230411.1 - latest
Error in cli si still presented: /dev/sda1 can’t open blockdev
After that do not try to boot from slot a, if you try that you are back on begining!!!
In future will bi great if someone figure out how to automate this process, so that people with old computers and non-uefi bios update ha os without unnecessary difficulty.
Hi, I just installed the latest version of Home Assistant following your guide and replacing the 9th with the 10th version.
It was excellent and I would like to thank you, and the previous contributors very much
Yeah, it works, but it seems that subsequent HAOS updates are not working. So I reverted back to VM. Maybe that would (or already is) fixed, but not sure.
The reason HA does not boot to the latest version after an update is because the OS writes to the /efi/boot/grubenv file to update the environment, but the default location for load_env and save_env (used in the grub.cfg file) is /boot/grub/grubenv. Setting default to 1 in grub.cfg will work, however, it bypasses HA’s failover method. (HA always has two versions installed at a time, one in SLOT A and one in SLOT B. If one version fails to boot after 3 tries, it will attempt to boot the other version). To fix this while retaining the failover functionality, you can simply tell grub to use the same file by editing the /efi/boot/grub.cfg file, changing the line that says
load_env
to
load_env --file (hd0,gpt1)/efi/boot/grubenv
and the line that says
save_env A_TRY A_OK B_TRY B_OK ORDER MACHINE_ID
to
save_env --file (hd0,gpt1)/efi/boot/grubenv A_TRY A_OK B_TRY B_OK ORDER MACHINE_ID
I followed the same steps that @carloshurtadom posted here and then changed those two lines in /efi/boot/grub.cfg.
@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.
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 env to load_env --file (hd0,gpt1)/efi/boot/grubenv
change save_env A_TRY A_OK B_TRY B_OK ORDER MACHINE_ID to save_env --file (hd0,gpt1)/efi/boot/grubenv A_TRY A_OK B_TRY B_OK ORDER MACHINE_ID
