HAOS support for the APU devices (PC Engines apu2 system boards) would be really great.
These devices have enough power, but doesn’t have a graphic card and I think no UEFI (coreboot) support, so the generic x86_64 image doesn’t work out.
Support for x86_64 devices without graphics, but with serial and legacy BIOS would be great.
I managed to boot home-assistant OS from coreboot + grub on an old Thinkpad lx201 with this. It just doesn’t do it automatically yet. Anyhow, this demonstrates that UEFI isn’t strictly required; probably just support for booting from GPT partitioned disks and somehow doing it automatically. I think having the APU boot from a USB drive which only loads Grub with the configuration for home-assistant OS might work.
Here’s my grub.cfg:
set root=(ahci0,gpt1)
configfile (ahci0,gpt1)/efi/boot/grub.cfg
That’s all.
FYI for those who might wander here with same question - I managed to boot latest at time of writing HAOS (9.4) on APU2 using @nilux advice quite easily:
dd the HAOS image to APU’s internal SSD (or from where you boot it), /dev/sda in my case/dev/sda1 (EFI boot partition) to /mnt
grub-install --boot-directory=/mnt/boot --force /dev/sdaThen just create a /mnt/boot/grub/grub.cfg with the following content:
set root=(hd0,gpt1)
configfile (hd0,gpt1)/efi/boot/grub.cfg
/mnt, take bootable USB out and rebootDo you think it also possible to run HA supervised on an APU2 board? that would be an interesting usecase to me. I’m currently running PfSense on a APU2 board, and there is a second unused slot in the case. The 8 Gb RAM is a real nice to have for some additional containers
I also would like to run HA on apu2c4. Any suggestion?
Tanks!
Read the thread above.
Nice. Further to this, to install grub and avoid the (potentially unreliable) use of blocklists, add a bios-boot partition (type 0xEF02) before the first partition. The ‘–force’ option is no longer required anymore as the grub image now has a proper home.
After writing the HAOS image, I used gdisk to create another partition (numbered mine 99) from sector 34 to 2047, of type ‘EF02’. Write the partition table, saying ‘Y’ to move the backup partition table elsewhere.
Continue from above, mounting /dev/sda1 to /mnt, etc.
One further thing I did was to add console=ttyS0,115200 to the end of the default_cmdline var in the existing HAOS grub.cfg (/mnt/efi/boot/grub.cfg).
Then unmount, reboot and watch the boot process over serial (which on first boot, expands partition(s) to disk size, etc.)
Done on an APU1c4 with HAOS 10.4.
I did this. It worked great. However, it doesn’t take upgrades to the OS. I did this with 10.4 and spent a few weeks trying to figure out why 10.5 was not persisting after reboot and I finally came to the conclusion that it won’t work because of the way this was installed on the APU. The upgrade does go to SLOT B, and if you interrupt the boot (after an update), and manually pick SLOT B, it will boot to 10.5. However, on a reboot, it will go back to the original SLOT A which is 10.4. I had gotten some help over on github but no solution to fix this (or make it persist). HAOS 10.4 to 10.5 shows successful, reboots, stays on 10.4, suggests 10.5 upgrade · Issue #2766 · home-assistant/operating-system · GitHub
From what I read in this thread so far, it seems that HASS expects an EFI-capable system that uses something like efibootmgr to select the boot slot.
The APU2 uses Coreboot, and as far as I can tell UEFI is not really supported unless you want to hack your own custom firmware.
@GR0DZ1LLA did you make any progress since your last post?
@nilux with your config, can you update the HomeAssistant version somehow? Does it happen automatically, and if not, what steps do you take to switch the boot slot?
(Another option to install HomeAsssistant would be the manual installation of the supervisor on an existing Debian system. However, I don’t know what the implications for system updates would be.)
I have officially left the APU and gone to a NUC. It was a kludge to deal with. HA requires so much time and effort that I have to simplify my life where I can, and this was on small win. My advice is to not use the APU at all. With cheap chinese NUCs being $85, it’s not work the effort.
So, I wanted to do this as well. Raspberry Pi was a bit slow, and the apu2 (4 GB model) came free since I moved from OPNsense to Unify.
I’ve decided to build go the custom firmware route since that seemed to be the easiest solution on the HASS side.
Followed these instructions from GitHub and edited the cmdline.txt file on the hassos-boot partition to console=ttyS0,115200. After that, everything seems to work like a charm. I’m still waiting for the restore to finish, but I don’t see what could go wrong from here.
Upgrading HA works just fine, but upgrading the OS requires manually selecting Boot B on reboot if that’s where the next version was installed. For some reason it always defaults to A. By the way this is on a Thinkpad X201 with coreboot + grub. I assume it is the same on APU.
Hello,
for the SATA on APU you have to use the same config of the grub.cfg?
Thanks!
set root=(hd0,gpt1)
configfile (hd0,gpt1)/efi/boot/grub.cfg
If you have just one drive then that is probably hd0, so yes. You can use the grub command line (rescue console) to list devices and partitions. See some online guide on how to do that.
Thanks it is working now
yo[quote=“nilux, post:13, topic:449610, full:true”]
Upgrading HA works just fine, but upgrading the OS requires manually selecting Boot B on reboot if that’s where the next version was installed. For some reason it always defaults to A. By the way this is on a Thinkpad X201 with coreboot + grub. I assume it is the same on APU.
[/quote]
Only on the next reboot? Or on every boot after the upgrade on HA OS?
Thanks!