With 64bit HA runs better then ever before!
I also mention this in my install steps some posts before
Hilarious - booted first time - thanks!
Hello all
Initially I though it will be easy task, but…
I have Pi4 8GB. upgraded its firmware to recent one (Sept 3rd). Succeeded to boot from SSD with HassOS v5.2 image burned on it.
Unfortunately, it refuse to boot up again after toggling power off and on.
This is the last thing which is displayed before Pi repeatedly restarts on its own
BTW is it possible to ssh to hassos with no containers/supervisor running? All guides point to ssh addon which is pointless without supervisor
with regards
I think I found the root cause of failing boot after reboot, but not double checked it. I don’t know is it expected behaviour or issue I should report on github.
Initially I started testing ssd boot at place where there is no wired connectivity available. I thought I can temporally use wifi. Unfortunatelly I failed connecting hassos with my wifi network.
Anyway, the first boot gave access to hassos but none containers got up bacause it required network connection (to download docker images I suppose).
Failing in the midfle of first boot process likely caused some damage to the system.
Anyway, when I connected my RPi do LAN, whole process went flawless. It boots from usb2 as well as usb3 without quirks.
Interesting thing, connecting the ssd to usb3 under Raspbian causes increased cpu load and makes keyboard/mouse both connected to usb2 not responding. Under HassOS I see no such problems with the keyboard.
For reference:
RPI 4 8GB
SSD Samsung V300 connected through some SATA-USB3 cable
Sorry to jump in here. This seems to be the best thread on this.
Im trying to get HA on a new RPi4 2gb-64bit.
It appears the usb(SSD) booting was just added not to long ago, but I’ve yet to get mine working. Can anyone point me in the newest install option?
I can confirm with Vlad’s instructions that this is working on Raspberry pi 4 8GB when previously it was not. The big thing I think everyone is hitting a wall at is the bootloaders being up to date and not being able to go backwards on the version. I had to download the July version of the bootloader on the 16th.
- I had to go to the following URL: https://github.com/raspberrypi/rpi-eeprom/releases
- Look for the eeprom listed: rpi-boot-eeprom-recovery-2020-07-16-vl805-000138a1-STABLE
- Extract the files from the zip and winscp or SCP transfer the files into the /home/pi directory.
- Run the following command to revert the eeprom to July 16th. Please note you must be in the same directory in where you put the files via SCP. sudo rpi-eeprom-update -d -f ./pieeprom-new.bin
- sudo reboot the system and wait for it to boot up and shut it down and replace the MicroSD card with the SSD in the USB 3.0 Port.
Please note as well, now that I started to think about this. You can use wget to receive the files into the /home/pi directory and unzip it from there.
I have been able to boot my Rpi4 HA installation (installation described here) from a USB flash drive for sometime. Originally I needed to use a SD card for the boot process but with the FW update this card is no longer needed
Recently I installed HA ( This version as well as This version) on a flash drive. Neither of these versions would boot using the same Rpi4 as above.
Is there another step I have to do to get either of these versions to boot? Bear in mind I do have the Rpi4 booting this version without issue.
Update the bootloader as described above and then apply version 5.2 64bit
1 Like
Worked like a charm.
Well… Not really.
While I can boot without issues and everything within HA appears to be working I do have an issue with Supervisor. After a refresh or reboot, Supervisor tells me there is an update. I am runnin 115.2 and it want me to update to 114.3. If I click the Update button I am toast, The PI will no longer boot from that USB. I tried recreating this install several times and even without any integrations, addons or any other changes to the new installation, all I need to do is refresh or reboot and I get this:
1 Like
what about to ignore this update? just don’t click it.
BTW what’s wrong with boot loader from 3rd August? I can see above that 16th July is suggested while newer version is available
operating system wait until the final version 5.x does not update anything until then. The supervisor updates himself and the Home assistant can be updated to newer versions that will be.
I have a newer bootloader 31.7 and I have no problem with v 5.2 64 bit
It’s not a Supervisor, it’s OS update. Just ignore it.
This may come back to bite me, but I toasted an SD card a while back and decided to move two rpi4’s over to SSD’s. I wanted cheap but not straight off the boat cheap, and I didn’t need much storage because I’m just running home assistant and other little stuff. I picked up two startech cables but couldn’t find a good drive. Everything was either bigger than I needed or too expensive.
After a bunch of googling, I found this drive. I’ve had no problems booting both raspberry pi OS and home assistant OS from these drives, and they’re cheaper than an equivalent SD card. Amazon reviews seen pretty good and my own speed tests showed the drive was quicker than many higher prices drives. Just wanted to share.
1 Like
It works with the latest beta release of homeassistant os 5.2 for me, but the initial boot (preparing homeassistant os) took several hours. After the setup it took half an hour for an reboot. Anybody else experiencing this issue? In this state it is unusable 
Had to switch back to microsd
in my case ssd was very slow on usb3 (even causing mouse/keyboard not working under raspbian). USB2 provides light speed.
Likely to be the USB to SATA adapter or the SSD itself, I’ve set up 5 new HassOS 5.2 systems in the last week and both the initial HassOS setup and reboot are super quick compared to MicroSD cards. Also prepared all RPI4’s by doing a full upgrade of RaspberryPi OS first to get the official September 2020 bootloader version.
I wouldn’t blame adapter directly since those works flawlessly with other hw/os.it might be rather incompatibility with RPi.