Supervised on Debian Bullseye, dpkg -i homeassistant-supervised.deb fails

Installation
#1

In Installing Home Assistant Supervised on Debian 11 I am in step 3.1 so I have successfully pulled the .deb file to my Nano Pi (and all steps before, of course) but when executing dpkg -i homeassistant-supervised.deb it fails. So I pulled the logfile and just pasting error lines with the line before it - please advise if there is a better was to paste the logfile.

Mär 16 11:29:24 NanoPi-R5S NetworkManager[1141]: <info>  [1678966164.6969] manager: (lo): new Generic device (/org/freedesktop/NetworkManager/Devices/1)
Mär 16 11:29:24 NanoPi-R5S kernel: overlayfs: filesystem on '/var/lib/docker/check-overlayfs-support2524542272/upper' not supported as upperdir

░░ The unit docker.service has entered the 'failed' state with result 'exit-code'.
Mär 16 11:29:24 NanoPi-R5S systemd[1]: Failed to start Docker Application Container Engine.
░░ Subject: A start job for unit docker.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support

Mär 16 11:29:27 NanoPi-R5S dockerd[1245]: time="2023-03-16T11:29:27.060926096Z" level=info msg="[graphdriver] trying configured driver: overlay2"
Mär 16 11:29:27 NanoPi-R5S kernel: overlayfs: filesystem on '/var/lib/docker/check-overlayfs-support397184888/upper' not supported as upperdir

░░ The unit docker.service has entered the 'failed' state with result 'exit-code'.
Mär 16 11:29:27 NanoPi-R5S systemd[1]: Failed to start Docker Application Container Engine.
░░ Subject: A start job for unit docker.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support

Mär 16 11:29:29 NanoPi-R5S dockerd[1254]: time="2023-03-16T11:29:29.313741281Z" level=info msg="[core] [Channel #1] Channel Connectivity change to SHUTDOWN" module=grpc
Mär 16 11:29:29 NanoPi-R5S kernel: overlayfs: filesystem on '/var/lib/docker/check-overlayfs-support119520660/upper' not supported as upperdir

What could I try next?

#2

Reading Use the OverlayFS storage driver
it seems that the Package refers to a different structure in the Container Layer, correct?

#3

Overlayfs2 only supports xfs and ext4 as backing FS

image
image802×227 18.7 KB

Would you use a different one on /var/lib/docker/?

#4

very good point, I can and will check that. To be honest I did not check the FS as I simply flashed the eMMC with the provided image.

#5

Seems to be ext4

image
image1280×960 364 KB

#6

Well, the underlying FS might be ext4, but root is actually mounted through overlayFS (not the docker overlayfs2), hence your issue.

image

Don’t ask me why, it’s baked in the image for your NanoPi :wink:

1 Like
#7

Could I change this? My only idea would be to change this in the etc/fstab but presumably this is not the correct level as this defines the underlying level which is correct?

#8

Answering the “why is it in the NanoPi image” asks more like “why is it not allowed?”

Wondering why it is built in my NanoPi image, I went through Initram-FS and OverlayFS definitions and found out that this is essential to minimize write-access to the SD card which is essential for SD-card life. So for my research so far it does make a lot of sense to use OverlayFS for an OS that is running on a SBC.

Now if I get it right the Docker tries to set up its own OverlayFS2 which requires a native FS like XFS or ext4. Now is this an issue with Docker as such or with Home Assistant? as the currently used Debian Bullseye seems to be incompatible, would it make more sense to use some distro that is better for Docker? I used Debian Bullseye Core because it was recommended, but would use something else if it fits better.

Other idea: Throw in an NVME SSD, format to EXT4 and do a “native” Debian install - would this be better?

#9

Just found this one How to Install Docker on Debian - FriendlyELEC WiKi and working my way through it. So it seems that there could be a way - just thinking about the best way to realize it.

#10

Well, unless mistaken, overlayfs is rather used to “emulate” a RW filesystem over an actually RO root. It’s notably used by openwrt to create a FS over router firmware.
I don’t think it reduces the wear and tear on an SD card in any way, and I am pretty sure RPI doesn’t use it out-of-the-box (although it’s been awhile)

image

The “the “factory reset” function relies on OverlayFS” note on the page you mention makes more sense. It would allow to keep the initial installation pristine, allowing a quick rollback to “factory”, while any change you do on the FS actually happen on the overlay.

If you can, creating an additional partition, as indicated in the page, is probably the best middle-ground.

#11

As all my attempts to get rid of OverlayFS is not working, I am now going the other way round and using different Debian installations and re-doing the Supervised install.

As more and more people switch from Raspi to Rockchip-based boards it would be really great to have native HAOS support for all the NanoPi, RockPi etc. out there.

#12

See my Answer in this Post