operating-system: Unsupported system - Systemd-Resolved issues on a fresh OdroidM1 install

With #2578 and #2633 there are now two fixes for this issue. They will be part of the next 10.4 release. The latest dev version 11.0.dev20230705 already has the first fix (see https://os-builds.home-assistant.io/).

Okay, I will upload those later today.

Hi Angers,

Running the new version for a while now.

Works like a charm! Thanks for putting in the effort!

Meanwhile I’ve proven that the entropy pool is the problem indeed. On the problematic board I can see that the entropy pool as reported by the kernel starts around ~50 and grows very slowly:

watch -n 1 cat /proc/sys/kernel/random/entropy_avail

On the working board the entropy pool ramps up much quicker. It still takes about 5-10s to reach 256. At 256 the service dbus-broker.service then launches successful.

Currently it is not clear to me why that is the case. The kernel adds various identifiers (e.g. of SD cards and USB devices) to the entropy pool via add_device_randomness. It could be that the SD card’s identifier used doesn’t/does not provide as much entropy. However, this is a rather wild guess.

In any case, I am currently working on integrating a driver for the hardware random number generator. With that there will be enough entropy available very quickly, which seems to solve the boot problem.

It might also be sensible to improve the service ordering: In particular, udisks2.service should depend on the dbus.socket. However, it seems that the socket and the dbus-broker.service are not directly linked, so this alone won’t resolve the issue.

I was wondering why dbus-broker requires randomness. It seem that the XML library libexpat is at fault. I am not entirly sure why quality entropy is need for an XML parser, but it seems the library really insists on it (see https://github.com/libexpat/libexpat/blob/R_2_5_0/expat/lib/xmlparse.c#L128).

@lukassadovsky thanks for the full log, that helped me, I think I see the problem now:

Jun 17 19:11:04 homeassistant udisksd[256]: udisks daemon version 2.9.2 starting
...
Jun 17 19:12:34 homeassistant systemd[1]: udisks2.service: start operation timed out. Terminating.
Jun 17 19:12:34 homeassistant udisksd[256]: udisks daemon version 2.9.2 exiting
Jun 17 19:12:34 homeassistant systemd[1]: udisks2.service: Failed with result 'timeout'.
...
Jun 17 19:12:36 homeassistant systemd[1]: haos-swapfile.service: Deactivated successfully.

It seems that udisks2 service gets started really early, and then times out because creation of the Swapfile takes much longer than anticipated. With that I should be able to reproduce the problem and fix it so that it won’t happen in the future.

Tried again on fresh install on completely different network on different place and network provider. Still the same issue. Is there any other somewhat easy way how to set up hassio on M1? I dont feel like going with Debian 10 and docker. Do not have that much skill with linux and do not have time to learn it right now.

New update; Another fresh install; this time without recovering a backup. After two rebooted until now it appears to work just fine.

Problem described in my earlier comment is probably due to multiple partitions on the data disk. Feel free to ignore 😉

I’m gonna put it to the test in the upcoming days. It’s looking promising!

I’ve tried the nightly build. On initial boot this was successfull. I’ve recovered my backup, which also worked.

Unfortunatly, now after 2’nd reboot, its stuck on "Waiting for the Home Assistant CLI to be ready… So no easy loggin/debugging now right?

Hi, same here. For now i am running on RPI4 with SSD boot.

On M1, fresh install, SD card only this: Log here: home-assistant_2023-06-12T18-24-35.454Z.log

And the result of the command journalctl -b 0 -u systemd-resolved.service:

It has been like this for a while. For me this install is acting up. Terminal addon not starting, Settings - addons not working.