operating-system: Unable to boot after upgrade to 11.0 on ODROID-M1
Describe the issue you are experiencing
There are multiple reports of this issue, please read here.
I
What operating system image do you use?
odroid-m1 (Hardkernel ODROID-M1)
What version of Home Assistant Operating System is installed?
11.0
Did you upgrade the Operating System.
Yes
Steps to reproduce the issue
- Have 10.5 installed, M1 using dedicated SSD for data.
- Upgrade to 11.0 using HASS UI
- The system will come up, with root filesystem mounted as read-only and HASS data partition not mounted at all. If you log in via system prompt (hass-cli is not working because containerd is waiting for filesystem mount) you can mount data directory manually, after that homeassistant starts, but with old OS.
If you reboot the system you would have to repeat mount procedure again.
I looked at the journalctl logs and the only error i foudn that “hass filesystem mount by label” job times out and restarts.
BUT this may not mean anything since this is boot of old hass version (upgrade failed at some point).
When ui comes up it asks you to upgdate to 11.0 version again.
It would be nice to know how to fix hass from this half-broken state.
Anything in the Supervisor logs that might be useful for us?
I cannot generate logs because upgrade did not complete and it now runs in semi-broken state.
Anything in the Host logs that might be useful for us?
I looked at journalctl and it says it "times out" while executing mout hass by label job, and then it reports that dependency is broken. But this can be an artifact of incomplete upgrade, i cannot find logs of upgrade anywhere.
System information
Odroid M1, SD card, dedicated data disk (ssd). upgrade from 10.5 to 11.0 using Hass Web UI.
Additional information
No response
About this issue
- Original URL
- State: closed
- Created 9 months ago
- Reactions: 8
- Comments: 30 (6 by maintainers)
Commits related to this issue
- ODROID-M1: Fix environment read from SD card (#2822) Make sure the environment can be read and written to SD card as well. This makes sure that first boot detection works properly too when booting fr... — committed to agners/operating-system by agners 8 months ago
- ODROID-M1: Fix environment read from SD card (#2822) (#2856) Make sure the environment can be read and written to SD card as well. This makes sure that first boot detection works properly too when ... — committed to home-assistant/operating-system by agners 8 months ago
- Fix first boot detection on SD boot (per #2822) — committed to darkxst/ha-operating-system by darkxst 8 months ago
- Fix first boot detection on SD boot (per #2822) — committed to darkxst/ha-operating-system by darkxst 8 months ago
This will be addressed with HAOS 11.1. You can test it already by updating to 11.1.rc1 on the beta channel.
I’m having this issue too, OS installed on SD Card and data on NVMe. Everything was working perfectly in 10.5, but as soon as I installed 11.0 it didn’t even come back from the mandatory reboot. Now every time I reboot I have to do
e2label /dev/nvme0n1p1 hassos-data
andsystemctl start hassos-supervisor
. So I guess my headless setup just turned into a headache.Incase it helps anyone else, here are the (unoptimized) steps I took to fix my install. I highly suspect there are some unnecessary steps in here but this fixed mine so I can’t easily go back and try to shorted them. Normally my setup is headless so I had to hook up a keyboard, monitor, and ethernet:
root
mount /dev/nvme0n1p1 /mnt/data
login
/dev/nvme0n1p1 hassos-data
andsystemctl restartstart hassos-supervisor
os update
to install HASSOS 11.1reboot
After the reboot everything worked like a charm.
Tested the HAOS 11.1.rc1, I can confirm that it fixed the issue and upgraded successfully on ODROID-M1 with SSD on nvme.
Before the upgrade to 11.1.rc1, when I tried to upgrade to 11.0, after each reboot I had to change label
After the upgrade
No, the md5sum looks right for the new boot.scr.
Yes it had a label: hassos-data-dis. Finally, I could solve this issue with:
e2label /dev/sda1 hassos-data
Was your disk renamed before to the disabled label? If yes, you probably have to manually rename it back.
Or try the latest Beta with the fixes, maybe this works better for you.
Edit: Ah, if you replaced it and then upgraded, it think the boot.scr was simply replaced with the bugged one from 11.0.
@cryptoluks that would be a possible work around, I should be able to create such a script.
Are you using an SD card?