Installing Home Assistant Supervised on a Raspberry Pi with Debian 11

Can’t run this command on a new install following the directions above. Need Sudo install first and this fails without the update. What needs to be done on a new install?

Where did you get 2021-03-04-raspios-buster-arm64 from? That seems to be the wrong image. For the Raspi 4 4GB you need the latest image from here which is:

The first thing you do after just having installed Debian is to go to the CLI and type:
apt install sudo -y

Only after that you initiate:
sudo apt-mark hold linux-image-arm64

After the two above steps you can run:
apt update && apt upgrade -y

Read the OP’s instructions carefully. This guide is not for RaspiOS but for HA Supervised on Debian 10 Buster.

I figured it out.

Looks like the install worked, the snapshot worked but I am having an issue trying to get Samba to work. Followed the linked samba directions and I get

 sudo service smbd restart

sudo: unable to resolve host rpi4-20210210: Name or service not known

Not sure where to fix this?

Hello, If I well understood, your instructions fix the issue of a RPi4 hanging after “random crng init done” message while booting from SSD (no microsd), for a new install.

But how to fix an already installed Rpi4/Debian/HA supervised on ssd and no more booting after Debian update without starting from scratch?


If you have already done the reboot after the kernel update to 5.5.10 and the RPI4 is stuck within the boot process now there is little that you can do left. Debian images are loading kernel and initramfs directly from RPI firmware without using a bootloader like i.e. Grub thus not providing any choice to boot from an older kernel.

I’m afraid you have to redo the whole OS installation from the start. Take care:
You must run

apt-mark hold linux-image-arm64

BEFORE running the first regular system update or else the installation is doomed again and the system will not start!

Nah that’s not needed @Tamsy

You can connect the USB drive to your computer and edit the boot.cfg file and change all 5.10 references to the 5.9 filenames (the 5.9 files should be in that directory as well)

[email protected]:/boot$ ls -ltrh
total 100M
drwxr-xr-x 4 root root  16K Jan  1  1970 firmware
-rw-r--r-- 1 root root  22M Dec 31 16:19 vmlinuz-5.9.0-0.bpo.5-arm64
-rw-r--r-- 1 root root 243K Dec 31 16:19 config-5.9.0-0.bpo.5-arm64
-rw-r--r-- 1 root root   83 Dec 31 16:19
-rw-r--r-- 1 root root  26M Mar 13 14:10 vmlinuz-5.10.0-0.bpo.4-arm64
-rw-r--r-- 1 root root 246K Mar 13 14:10 config-5.10.0-0.bpo.4-arm64
-rw-r--r-- 1 root root   83 Mar 13 14:10
-rw-r--r-- 1 root root  27M Mar 30 06:30 initrd.img-5.9.0-0.bpo.5-arm64
-rw-r--r-- 1 root root  26M Apr  4 04:16 initrd.img-5.10.0-0.bpo.4-arm64
[email protected]:/boot$ 

Nice to know that :slightly_smiling_face:

But where to find the file boot.cfg? I know this file from VMWARE only. On other modern Linuxes you can set boot options through /boot/grub(2)/grub.cfg but Grub is not available for Debian on arm64.

Thanks. Really hoping to save my current installation. Where can I find that file?

Did you make a snapshot before the failed system uppgrade? If yes you should be able to connect the SSD to your PC, browse into /usr/share/hassio/backup and copy your snapshots to your PC for easy recovery after the base install of your rpi4.

The boot folder should be auto-mounted and visible (on a windows machine that is, otherwise /boot)
Just connect the USB drive to a computer and you will see

Or you can run from cli:

sudo ls -la /boot

which brings up (where kernel 5.5.10 is not installed:

drwxr-xr-x  3 root root     4096 Apr  2 12:12 .
drwxr-xr-x 18 root root     4096 Feb 14  2019 ..
-rw-r--r--  1 root root       83 Dec 31 15:19
-rw-r--r--  1 root root   248519 Dec 31 15:19 config-5.9.0-0.bpo.5-arm64
drwxr-xr-x  2 root root    16384 Jan  1  1970 firmware
-rw-r--r--  1 root root 27915840 Apr  2 12:12 initrd.img-5.9.0-0.bpo.5-arm64
-rw-r--r--  1 root root 22656880 Dec 31 15:19 vmlinuz-5.9.0-0.bpo.5-arm64

but unfortunately no boot.cfg

Running as root (su - for all permissions over the system):
locate boot.cfg

delivers an empty result.

Ok sorry so it’s not in the boot folder. Been a couple of weeks when it happened to me and had to apply this fix.

Anyway just connect the USB disk to a computer. On a Windows computer there will be only partition mounted and that is where all the files boot files are (you don’t even get to see the Linux drive what you are seeing now).

boot.cfg obviously only exists on machines running vmware.

Running as superuser

locate boot.cfg

delivers an empty result.

Which means there is no boot.cfg for Debian 10 on arm64 (as I pointed this out before).

Unfortunately no up-to-date snapshot just before the system upgrade.
I’m not so familiar with Linux/Debian, but can’t believe the recommended system upgrade can make my whole home automation unusable and there is no way to recover/rollback without full reinstall. :sob:
There is no way to change the firmware or overwrite the wrong files manually?

This is why backups exist - to protect you against unknown issues, even moreso if you aren’t familiar with what you are doing.

Always make a backup before doing any updates.

1 Like

I’ve been saying a couple of times 'just connect the USB disk to a computer and you will see what I mean". The mount/boot drive is HIDDEN but if you mount it on windows computer you will only see that partition.

I hate repeating myself over and over. I’m not running a VM. I’m using RPI4 with debian installation according to this guide. That’s why I am in this topic and not in the VM topic (if there is any).

edit config.txt (sorry my bad. As I mentioned it was a couple of weeks ago when I did this and i even posted it back then).



1 Like

Thanks you very very much. You saved my day!
After recovering this way, there is something I should do to prevent re-upgrading of this configuration file?

@Koal4 Chill, no need to yell.

It’s a difference to advise somebody to “edit boot.cfg” but in fact you mean “edit conf.txt”, isn’t it? Your tune is quite irritating.

However, @unlikely, you’ll find that file inside /boot/firmware (not hidden at all) or as @Koal4 says if you connect your ssd to your windows machine “you will only see that partition” anyway.

Would you please be so kind to report back to the community whether this workaround works? May help others with the same problem.

Yes, run:

sudo apt-mark hold linux-image-arm64

This prevents updates to update the kernel for the time being.