Hassio on Armbian

Try the following link:

Did the job for me.

If you are running Armbian with Docker powered kernel (3.14 or up) try:

  1. apt update && apt -y upgrade
  2. armbian-config -> software -> softy -> Home Assistant

Source: https://github.com/armbian/config/blob/master/debian-software#L832-L846

1 Like

Good stuff…so its HassOS? Right?


HassOS? Right?


HassOS? Really? Isn’t it Hassio? I’m confused!

Could some one clarify? Thank’s!

At least in the armbian-config under software -> softy there is written hassio like you can see in this screenshot:

sweet :clown_face:

EDIT: The armbian install script above should also work on any other debian os independently from the hardware. You could try this:

1. wget https://raw.githubusercontent.com/armbian/config/master/debian-software
2. chmod 755 debian-software
3. sudo ./debian-software

A test proofed me wrong.

When you try to install it you will get asked for the machine type.


In my case I use a allwinner H3 soc based orange pi pc and this type is not listed.

How could I proceed? Can I proceed? Am I lost? :woozy_face:

Is hassio supported now in armbian? I have a beelink x2 with armbian and would like to run Hass.io in it!

1 Like

qemuarm? :thinking:

Armbian is straight debian. Debian is the support OS for a supervised install. Any reason Armbian shows up as an unsupported OS?

cat /etc/os-release
PRETTY_NAME=“Armbian 21.02.2 Buster”
NAME=“Debian GNU/Linux”
VERSION=“10 (buster)”

1 Like

Exactly my question, can the installation be fixed somehow to be supported?
I have re-installed mine to bullseye variant but still displays unsupported.

same question. something wrong with the boot with groub? no luck.

:arrow_right: architecture/adr/0014-home-assistant-supervised.md at 73be016a4c933adc649a7b257da1aa2f1a070744 · home-assistant/architecture · GitHub

Supported Operating System, System dependencies and versions

  • Debian Linux Debian 11 aka Bullseye (no derivatives)

Only if you convince the devs to add armbian as a ‘officially’ supported system (quite the opposite was part of this architecture issue 126)

I expect that everything works - correct? If you are not bothered by this two letters more (un) in front of the term supported you should be fine :wink:

same answers as above. :arrow_up_small:

Actually a bummer because armbian ships with very good defaults for sbc’s which running with simple flash (like sd cards/emmc’s/usb sticks/…) and can prolong the live of storage significantly compared to a supervised install on a “vanilla” debian without tweaking and even easily outperform haOS in terms of the expected write amplification (higher amplification = killing flash cells faster) :do_not_litter:

Beyond the very good defaults you mention, armbian is one of the few bullseye installation distribution that works correctly across a large set of arm based SBCs. The bullseye installation distribution that comes straight from Debian only supports limited arm based SBCs. If you’re working in the x86_ world where the Debian release works on most every motherboard and CPU, this mandate makes sense. Sadly the arm world hasn’t made it to the same place. While I know people run HA on x86_ it really isn’t the optimal platform for a controller based system such as HA. I’ve pointed out this bullseye distribution in other posts, which actually gets a supported rating based on the HA checks. I was informed it wasn’t supported because of the OS level tweaks included in the installation. A few of the tweaks have to be implemented as scripts that run every time on OS boot. Bullseye will does not continuously run on most arm SBCs without SBC specific tweaks. I use the odrioid N2+ which is one of the best SCBs available today if your building an HA system. The Debian bullseye release doesn’t work on this great platform. The second release I mention does. It just feels to me that there is some confusion as to what it means to be a bullseye distribution in the arm world. Hopefully the dev team is fully aware of what is required to run bullseye in the arm world.

I started my HA journey more than 5 years ago with a $10 SBC back in 2017. It was a orange pi one - obviously super charged with armbian :rocket:

Today Yesterday I made the mistake moving my x86-64 install from supervised to (c)HAOS :exploding_head:

I don’t think there is actually. The docs state quite clear:

Debian Linux Debian 11 aka Bullseye (no derivatives)

Only the above-listed version of Debian Linux is supported for running this installation method.

beside also these sentence are in the document:

We only accept bug reports for issues that have been reproduced on a freshly installed, fully updated Debian with no additional packages.

So that should mean armbian isn’t “officially” supported while at the same time probably has full technical support solely because it’s so very close to a “vanilla” debian. I never experienced any problems running pip or supervised ha install on armbian.

Sadly I don’t think they are much aware of all the odds. Specially choosing ext4 for HAOS with the default (commit) flush interval of 5 seconds (relic from the spinning hard disk age) for the filesystem is nothing more than sd-card killer :frowning_face:

My problem with the conversation is that the statement

Debian Linux Debian 11 aka Bullseye (no derivatives)

makes little sense in the arm world. The Debian organization doesn’t provide the kernel, they provide the packages that load on top of the boot loader and the kernel. They do have a boot load and kernel they include with their installation image/script but Debian didn’t build them and sadly they only support a few arm boards. If I use 100% packages provided through Debian repos, and only modify things to make the boot loader/kernel work on the hardware, is that not still Debian? I believe in the arm world it qualifies as a no derivative Debian. If you use orange pi SBC then you know that Armbian is the primary distribution for those boards. The Debian released boot loader/kernel will not run on those boards. I still have orange pi one and pc that I use in my full house audio system. Thank god for the true arm based Debian distributions like Armbian and the other I mentioned that look to work on a larger subset of arm boards. If the HA team need to restrict what is viewed as supported then the best way to support the community would be to pick a release that works on the arm platforms best suited to be an HA controller. The HA dev team should engage the guy that supports this bullseye release, as it works on RPI4, Odroid N2(+) and multiple others. It has an integrate script for installing HA. They could add him to their team, putting themself in a position to optimally support their arm community. Obviously just an opinion, but an opinion support by a significant background in the embedded computing/security software world. I know the ship has sailed but I keep hoping it might pull back into port for some retrofits.

I think exactly this was the idea behind the “Architecture Decision Record 14” (see issue 126 for the discussion). :page_with_curl:

One also can’t forget that the initial idea was to deprecate the supervised install all at ones. :put_litter_in_its_place:

The very good thing at this point - even when running a supervised ha install on top of armbian and it shows the state “unsupported” it is very likely that still 100% of the things will exactly work like expected. :muscle:

I was using an HA supervised install at the point they released the deprecated message. I had initially started with HASSOS but it had limitations that prevented me from building some of the features I desired. The main issue was the Cellular backup communication path and GPIO support. At that point they supported the odroid N2 platform as a target. Thankfully they got enough push back to put that on hold. It’s exactly that previous decision to deprecate supervised installs that leaves me wanting for a better decision on what release is viewed as supported. In general I could care less about an OS release, but if it a decision kills my smart house installation and relegates my hardware to the trash pile then that will be a sad day.

change PRETTY_NAME=“Armbian 21.02.2 Buster”
to PRETTY_NAME=“Debian GNU/Linux 11 (bullseye)” would solved some problems. check it out.

Nice solution. I actually moved from Armbian and now use a different packaging of Debian I documented here. I had issue with Armbian when first moving to bullseye, which caused me to look out alternate solution.