seems like my Pi5 will collect some dust until this stabilises…
Raspberry Pi
Original heatsink
PoE HAT
Pimorone nvme BASE “HAT”
I saw video’s of having to manually change configuration to get the Pi5 to boot off of the NVME drive, do we know if they are working on making it possible to boot off of nvme drives in HA. ?
I have RPi5 8Gb with Pimoroni NVME Base + SSD Samsung 980 500Gb connected through NVME (not USB)
I’ve spent several days trying to make HA works on this setup with huge number of fails.
Short story:
The main issue was with Raspberry Pi Imager - it makes not bootable image on SSD or SD Card. Once I’ve used Balena Etcher - HA starts to boot from the SSD (or SD, I tried both).
Long story:
I have old RPi3 with 1Gb RAM and experienced some troubles with Sonoff Zigbee 3.0 USB dongle when Zigbee2MQTT addon going to reset preiodically. I think because of out of RAM memory and freeze during swap activated watchdog to reset the addon. So, I decided to move to more powerfull HW. I’ve made an HA backup with all addons switched Off option for “Start on boot”, because I saw a topic with the issue specifically with RPi5 and HAOS 11.4 related on this.
I’ve flashed Rasperry OS lite via Raspberry Pi imager on SD card and made a first boot of RPi5 - all worked well.
I’ve changed
sudo rpi-eeprom-config --edit
by adding PCIE_PROBE=1 and changing boot order to NVMe SSD by BOOT_ORDER=0xf416
after that I’ve flashed haos_rpi5-64-11.4.img.xz on SSD and rebooted RPi5 without SD card with expectation to see the installation screen over http, but nothing happened. I’ve tried different releases like 11.3.rc1, 11.3., 11.4.rc1 with the same result (no boot). I always have used Raspberry PI imager for it, because it provides possibility to set WiFi settings and other useful options.
But when I flashed Raspberry OS on the SSD (or SD card) - it boots and works well, without any problems.
During the investigation I’ve updated eeprom
sudo nano /etc/default/rpi-eeprom-update
change the FIRMWARE_RELEASE_STATUS from “default” to “latest”
sudo apt update
sudo apt full-upgrade
sudo reboot
sudo rpi-eeprom-update
This should report at least firmware 2023-12-06 or higher.
It didn’t change anything, but good to have latest version.
So, finally I’ve used Balena Etcher to flash HAOS 11.4 image on SSD and it started to boot, showed installation screen in web browser and I used the backup to restore all my HA configuration.
The addons Mosquitto broker and Zigbee2MQTT started automatically, even with Start On Boot switched Off, I’ve just switched them On and made a full reboot.
I tried to full, quick and power disconnection reboot - without any problems. It booting every time now without any problems.
I hope it helps to other readers of this forum.
yeah I used ha network to manually set the SSID and restart, all good now! thank you
Hi, I have recently changed from Pi4 to Pi5 HA 11.4 on an USB Nvme and it works when connected to the USB2.0 port on the PI5. But if I connect it to the USB3.0 port on the pi5, it looks like its booting up, but is getting stuck. Is Usb3.0 not supported in HA?
As a quick test, I grabbed a SSK NVME to USB3 adapter from my drawer. It has a Samsung 1TB 970 EVO drive in it. I plugged it into my Windows 11 PC, and used the Raspberry Pi Imager tool to load the latest haos_rpi5-64-11.4.img.xz on that drive.
I then shutdown my RPi 5, removed power, removed the microSD flash memory card I have been using for testing, plugged in the SSK NVME-to-USB drive to a RPi 5 USB3 port, and plugged the USB-C power back in. The RPi 5 booted right up and is running HAOS 11.4 without any obvious issues.
Perhaps your existing NVME to USB adapter is not quite compatible? Just a guess.
it was working fine on PI4, and is also working with the Raspi OS.
Adapter is this one
SSK Aluminium M.2 NVME SATA SSD Gehäuseadapter, USB 3.2 Gen 2 (10 Gbit/s) auf PCI-E NGFF M-Key/(B+M) Key Solid State Drive Externes Gehäuse unterstützt UASP Trim für NVME/SATA SSDs 2242/ 2260/2280
but thanks for testing.
br
mike
Tested again, it was a faulty cable. working fine now.
thanks
I had same experience .
Tried install Pi 5 with 32Gb of SD card and after few reboots the SD becomes unresponsive .
Replaced the SD with new one which acted the same .
Few of the integrations did not work after restoring the DB .
Tried installing the HA as a container on a native Rpi image ( Linux raspberrypi 6.1.0-rpi7-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24) aarch64) and got into memory allocation issues .
09:07:06] INFO: Home Assistant Core finish process exit code 1
[09:07:06] INFO: Home Assistant Core service shutdown
s6-rc: info: service legacy-services successfully started
s6-rc: info: service legacy-services: stopping
[09:07:07] INFO: Home Assistant Core finish process exit code 256
[09:07:07] INFO: Home Assistant Core finish process received signal 15
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
services-up: info: copying legacy longrun home-assistant (no readiness notification)
: Unsupported system page size
: Unsupported system page size
: Unsupported system page size
Fatal Python error: _PyRuntimeState_Init: memory allocation failed
Python runtime state: unknown
From my POV there is still work to be done to make it usable .
been testing it for a few days now in rpi5, so far no issues or errors showed up…
My RPi 5 has been running HASO 11.4 for a while now. I have rebooted it multiple times, updated HA Core a few times, and even accidentally unplugged it today. In all cases, it has come back without any issues. The real test, IMHO, will come when we upgrade to HAOS 11.5.
I definitely did experience the reboot instability on HAOS 11.3. I won’t call the issue completely resolved until I can complete a few more upgrades of HAOS greater than 11.4.
I share the same experience. Running smooth for over two weeks.
I am still running a Christmas dev Version on my RasPi5 with no problems and several reboots , but I haven’t dared to do an update yet, because I’ve always ended up in the boot loop before. That seems to have been solved now ( many thanks to @agners and @sairon) and I’m eagerly waiting for HAOS 11.5 to give it another try.
is everyone booting off an SD card? I’ve tried 11.4 image off an nvme and I’m not having much luck.
are there any ticks to this?
I have a RPi 5 booting off of a USB 3 connected NVME drive. No issues and I did not do anything special to the RPi 5 in order to enable this functionality. Prior to running it off of the USB-NVME drive, I did boot it originally off of a microSD card. The first OS I tried was the official Raspberry Pi OS for the RPI 5. Later, I used the HAOS 11.3 development and release candidate images. Not sure if running any of these operating systems did anything to the RPi 5’s EEPROM settings to allow it to boot from a USB attached NVME drive or not?
I have not tried to boot it using a PCIexpress to NVME adapter, as I do not have one of those, yet…
yeah this is the unit I’m trying to use… I can load the image onto it fine from the same pi5 booting off the SD card, I have also run the tool to change boot order, but maybe that has only got USB over the new PCIe option.
it start after a restart or shut down, any issues with yours?
I am having the same issue - I am using a different HAT, but same connection.
Looks like we should be able to upgrade the Yellow with a CM5, pending support from the HASS team:
What we can confirm though is that the Compute Module 5 will share the same dual connectors as the Compute Module 4
Retaining the dual connector should mean that boards designed around the CM4 should work with the CM5. The assumption being that the 55 x 40 MM form factor remains the same.