What sort of controller does your USB to NVMe adapter use? Or if you can’t find that on the box, what’s the model of the adapter?
It’s starting to sound a lot like a UAS issue, given it works on USB 2.
1 Like
Thanks for the response and thanks for your help.
The “unpowered” adapter is a “dongle” style like one of these USB-NVMe
The powered one is a Geekworm X872/3 like this one Geekworm powered Adapter
The dongle one uses the JMS583 chip that is supposed to work. I can’t find the chip on the geekworm one. But Both of these things will boot vanilla Raspbian (Pi OS) with a NVMe drive (I have tried different bands of NVMe drives too, Samsung Pro, Samsung EVO and Western Digital. ALL boot Raspbian (Pi OS) NONE boot HASSio.
Funny thing about the USB2 boot… Seems that you only get one boot, on the next boot it fails. Super odd… it seems that HASSio writes something to the drive that corrupts it for the next boot.
Not sure if this is a HASSio issue or a HASSio update issue. As per your directions I flashed V5.5 to the drive. Once it booted on the USB2 port it upgraded to 5.12 and then it was a dead (again).
Willing to try for a 10th or 11th time.
I’m going to flash V5.5 (again) not let the update happen and see if I get more than one boot…
Update, I can confirm, as others have posted, the USB2 boot thing is a “one shot deal” during the first boot HASS downloads a bunch of stuff and seems to reconfigure the 8 SSD partitions so that as soon as you power down it will not come back.
Oh and I took apart my Geekworm adapter and it is also drive by a JMS583 chip.
So my understanding is, there is no issue for you using the Argon One M.2 case with M.2 SSD with USB3 . But there is issue with NVME SSD with the case?
Not just the Argon case… any NVMe drive and adapter/case will not work… I hope the HA developers fix this bug soon.
Update SUCCESS!
And this is still weird. Turns out the the JMS583 Boards that enable NVMe drives to talk to the Pi (or other USB 3 devices) have a firmware built in. Also turns out that HASSio is rather picky about this firmware. Pi OS is less so (or at leas Pi OS has been patched to not have this issue)
Once I updated the firmware of both the powered and non-power JMS583 NVMe -> USB adapters I was able to successfully boot HASSio to a Wester Digital Blue 1T NVMe drive! I have not tried the faster EVO and PRO drives but the “Blue” drive was the one that I was planning to run HA on.
If you want to flash the firmware on your JMS583 based adapter… Use the 2.0.9 version here:
Down Load 2.0.9 firmware patch
Thanks for all of your help!
1 Like
But why you are using a NVMe drive for this task? I don‘t think it will have any advantage over a SATA SSD attached to a Pi 4.
Mostly because I got the drive for free… And it nets a more “compact” Pi system. Which fits perfectly in a 3D printed case… Yes it is over kill over the SATA Drive.
I’ve been using the new m.2 case with Hassos stable on a WD Blue SSD and have run into a few issues after what I thought was a trouble free first week. I’ve been running Frigate and six cameras which meant pushing the RPi4 quite a lot, I overclocked to 2000 and average CPU use was 70-80%. To use Frigate I needed a Google Coral TPU plugged into the other USB3. This worked fine till the other day when it locked up as soon as I ran Frigate. Lots of homeassistant kernel: sd 0:0:0:0: [sda] tag#19 uas_zap_pending 0 uas-tag 4 inflight: CMD in the logs. After a lot of trial and error I’ve finally got it back stable again but with the TPU in a USB2 slot, which has hit my inference speeds.
The reason I bought the M.2 case is I like the all in one form factor so I don’t really want to add a USB hub, so now looking around for another option like a hack for more power or less power hungry SSD. Reading the spec the 250gb WD blue is max peak 4350mW/1318mA @3.3v. I’ve only looked at the green and they dont list the max peak only the average which is 2200mw, same as the blue. Not sure I’m going to find a more efficient SSD.
Other questions I have is I read some about using dev Hassos on older posts, is USB boot now working on stable or should I switch to dev?
I enabled the dtparam=sd_poll_once=on but now my activity LED is off permanently, is that normal?
What sort of speeds are people seeing when running hdparm -tT /dev/sda? I’m getting:
# hdparm -tT /dev/sda
/dev/sda:
Timing buffer-cache reads: 1108 MB in 0.51 seconds = 2223656 kB/s
Timing buffered disk reads: 1114 MB in 3.00 seconds = 380023 kB/s
Something isn’t right there as the spec is quoted as max 550 MB/s!!
EDIT: Just to add, I’m still seeing this in the log when HD activity ramps up,
homeassistant kernel: usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
from what I read on an old github post this could be down to power issues so it seems as though even on it’s own in the USB3 bus SSD isn’t working perfectly.
I don’t think you will reach this speed with the Pi 4.
I am using here HassOS 5.12 64bit to boot with an M.2 WD Green without any problem.
Yes, I didn’t realise the buffer-cache is not the read speed. 380MB/s is sounding about right.
I’m guessing you don’t have anything else connected to the USB?
Whenever I start Frigate I can see this in the log regardless of which USB the TPU is connected to:
homeassistant kernel: usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
homeassistant kernel: usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
homeassistant kernel: usb 1-1.3: device firmware changed
homeassistant kernel: usb 1-1.3: USB disconnect, device number 3
homeassistant 9e0c0b43ef56[414]: 21-03-11 14:53:35 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.REMOVE usb hardware /dev/bus/usb/001/003
homeassistant hassos-supervisor[876]: 21-03-11 14:53:35 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.REMOVE usb hardware /dev/bus/usb/001/003
homeassistant kernel: usb 1-1.3: new high-speed USB device number 4 using xhci_hcd
homeassistant kernel: usb 1-1.3: New USB device found, idVendor=18d1, idProduct=9302, bcdDevice= 1.00
homeassistant kernel: usb 1-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
homeassistant 9e0c0b43ef56[414]: 21-03-11 14:53:38 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD usb hardware /dev/bus/usb/001/004
homeassistant hassos-supervisor[876]: 21-03-11 14:53:38 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD usb hardware /dev/bus/usb/001/004
I’m not sure if that’s normal, it looks to me as if it’s losing connection, maybe due to power?
I just bought this case for a RPI4 that I will be using to replace my current RPI3 as my Home Assistant hub.
I am currently using a MariaDB on a Synology for storing all data from HASSIO, but my idea is to have a DB running locally on the RPI4 together with an M.2 SSD.
My first concern is the power requirements for such setup. Will the official RPI4 power source with 3.0A be enough?
And regarding the SSD, I guess that a 250GB or 500GB SSD will be more than enough for the purpose. Do you recommend any particular brand/model?
Yes, that is correct!
The ConBee II Stick for ZigBee is connected to a Pi Zero with an USB extension cable because the Home Assistant Pi 4 is on a not so good position.
The Argon One M.2 case having discount in my region now… still thinking should i migrate to SSD or not as ot seems it still has stability issue…hmmmm
This is the only thread where I read about stability problems with SSD. All other places and my Home Assistant too don’t have problems with stability.
Mostly problems with SSD are the USB 3-SATA controllers that are used, which not work correctly with the Pi 4 at USB 3. Other problems are the power adapters which deliver too low voltage.
Yeah. I was worried on the USB3 issue as this case is using the USB3 port with the SSD. Afraid it will interfere my CC2531, although my CC2531 has a USB extension with it.
This stick is USB 2, I think, so you can use an USB 2 port.
1 Like
Just placed the order for Argon One M2 case. Hopefully all good during setup.
I think there is an issue with power and booting the RPi from SSD. From what I’ve read the RPi can only supply a max of 1.5A over all the USB ports. The Max Average operating power of my SSD is 667mA so in theory it should be enough however with a Google Coral USB connected as well this is having problems. The max current for that is 900mA so if both operate at peak it’s over the 1.5A.
I’m back to booting off SD card now and just using the M.2 drive as storage, I’m still seeing some uas_eh_abort_handler in the log. I will have to look for a SSD that uses less than 667mA, if it exists.
But this seems to be more a problem of the controller which has UAS problems with the Pi 4.