Click on ‘learn more’ to see the reason. Could be apparmor is not enabled, or something with networkmanager, or your docker settings.
thanks man… I just realize that I’m modifying my docker daemon for proxy socket which probably remove the current setup. Its fixed and working now.
Took the plunge and did the OS-upgrade to ‘Bullseye’ on a RPI4 4GB. All went well so far.
Worth to mention for users upgrading from Debian 10 installed by using @kanga_who’s former instructions:
If you see the following error message after “apt update”:
The value 'buster' is invalid for APT::Default-Release as such a release is not available in the sources
Run:
sed -i 's/buster/bullseye/' /etc/apt/apt.conf
Also note for those who have set:
sudo apt-mark hold linux-image-arm64
due to the boot problems with the latest official kernel on Debian 10 on a RPI4,
Run:
apt-mark unhold linux-image-arm64
before running “apt upgrade”
Addendum (09/09/21):
$ apt --fix-broken install (<- just because of coming from Buster?)
$ cd /usr/local/src
$ wget https://github.com/home-assistant/os-agent/releases/download/1.1.1/os-agent_1.1.1_linux_aarch64.deb
$ dpkg -i os-agent_1.1.1_linux_aarch64.deb
$ systemctl reboot
5 Likes
BTW which version is AgentOS need to be installed for RPI 4? So far getting aarch64 but my supervised did not continue and it keeps crashing.
Or maybe someone has an idea?
That is on my Pi 4 running 64bit Debian
Raspberry Pi 4 running Debian 11, AgentOS aarch64, Installed Supervised raspberrypi-64.
Supervised running however it keep on crashing with this error log
[services.d] starting services
[services.d] done.
[13:55:59] INFO: Starting local supervisor watchdog...
21-09-08 13:56:01 INFO (MainThread) [__main__] Initializing Supervisor setup
21-09-08 13:56:01 INFO (MainThread) [supervisor.bootstrap] Initializing Supervisor Sentry
Traceback (most recent call last):
File "/usr/local/lib/python3.9/runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/local/lib/python3.9/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/usr/src/supervisor/supervisor/__main__.py", line 41, in <module>
coresys = loop.run_until_complete(bootstrap.initialize_coresys())
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
return future.result()
File "/usr/src/supervisor/supervisor/bootstrap.py", line 97, in initialize_coresys
coresys.machine_id = MACHINE_ID.read_text().strip()
File "/usr/local/lib/python3.9/pathlib.py", line 1256, in read_text
with self.open(mode='r', encoding=encoding, errors=errors) as f:
File "/usr/local/lib/python3.9/pathlib.py", line 1242, in open
return io.open(self, mode, buffering, encoding, errors, newline,
IsADirectoryError: [Errno 21] Is a directory: '/etc/machine-id'
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
Unsure what happen.
Debian 11 Bullseye
Docker version 20.10.8
Python 3.9.2
maybe this ?
Did you set these ?
Environment variables
There are a few environment variables that you have to add in order to make the Supervisor work properly with newer versions of the Supervisor. These variables have to be added to the run command for the Supervisor container, on most installations this is a script called from a service file.
SUPERVISOR_SHARE- The path to the directory for the Supervisor data files, typically/usr/share/hassio.SUPERVISOR_NAME- The name of the supervisor container, typicallyhassio_supervisorSUPERVISOR_MACHINE- The machine you are using. For a list of machine types, have a look here
I’m not sure, since the step follows. I see that my docker somehow did run with error after rebooting the machine. So maybe some apps install making it unstable. Debian 11 did make changes in the kernel, so I believe not the HA but another thing.
Mine updated from 4.19 to 5.10 on amd64. Yes an upgrade will change the kernel. They will be significant.
What does uname -a tell you?
The machine already being format so I miss this one. Anyway will try to find out why and let you guys know (this is my test machine for RPI4)
I pretty much followed @francisp’s instructions for the RPI4 but just added:
sed -i 's/buster/bullseye/' /etc/apt/apt.conf
before:
apt update
and:
apt-mark unhold linux-image-arm64
before:
apt upgrade
Nothing else, no fiddling with AgentOS or any other (config-)file.
After a host reboot HA, but also Mosquitto, Samba, Portainer, Broadlink Manager etc. (Docker images, not Add-ons) came all back up nicely. And so did the Add-ons and all installed/activated integrations.
As simple as that and took me less than 30 minutes.
Looks to me like you have configured your installation to death… 
Its showing this
Linux 5.10.0-8-arm64 #1 SMP Debian 5.10.46-4 (2021-08-03) aarch64 GNU/Linux
However, the error messages show that /etc/machine-id is a directory and not a file like it suppose to be. That is why my supervisor keeps on crashing. Is this a bug on the supervisor-install script?
I run a .sh script so I can assure you that it’s being done correctly.
BTW I used bash installer.sh --machine raspberrypi4-64
Is there anything in that directory? If not, I suggest you delete it.
Are there some files inside /etc/machine-id?
Check with:
ls -la /etc/machine-id
Otherwise, if empty, just rename the directory:
mv /etc/machine-id /etc/machine-id.bak
then restart the RPI4 and try again.
Here is where machine-id is located on a RPI4. In fact that directory IS empty:
Why would you restart it? This isn’t windows.
it’s a directory where is supposed to be a file. They’re supposed to be some random numbers. Restarting the RPI crash docker and typing docker ps show nothing unless you type docker ps -a
LOL! Because it seems to have been taken part already in the process thus somehow involved in the failure. Restart because we want to make sure the dir isn’t there in place the whole process.
This is what happen to docker
root@kedoyaha:/etc# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
root@kedoyaha:/etc# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ca77c48b366e homeassistant/aarch64-hassio-supervisor "/init" 2 seconds ago Created hassio_supervisor
df241d978714 portainer/portainer-ce "/portainer" 52 minutes ago Exited (2) 25 minutes ago 8000/tcp, 0.0.0.0:9000->9000/tcp, :::9000->9000/tcp portainer
When I do docker ps show nothing but if I put docker ps -a it show my container.
Portainer is now cant be called from port 9000 and suppose to be running, before reboot I can access it. So there are something being done by the supervisor scripts that break docker. The system keep on making machine-id directory.
This is not happening on VM only on RPI4
Take a look at the link I’ve send before on how to handle machine-id correctly.