operating-system
operating-system copied to clipboard
home-assistant
Fail to boot after Upgrade to 10.0 - rpi4 SSD
:information_source: :information_source: :information_source: If you are affected, please state which exact USB to S-ATA/M.2 adapter you are using (make/brand and PID/VID if possible). If you useRaspberry Pi CM4 with a directly attached NVMe, please do not write here but in https://github.com/home-assistant/operating-system/issues/2479 instead. Thank you!
Describe the issue you are experiencing
I have the argon40 case so I'm running my rpi4 from the external SSD (USB-connected).
Failed to boot after upgrading OS to 10.0. Problem was temporarily solved by downgrading back to OS 9.5
Currently running core 4.0.
Similar to #
What operating system image do you use?
rpi4 (Raspberry Pi 4/400 32-bit OS)
What version of Home Assistant Operating System is installed?
10.0
Did you upgrade the Operating System.
Yes
Steps to reproduce the issue
- Upgrade to 10.0
...
Anything in the Supervisor logs that might be useful for us?
No
Anything in the Host logs that might be useful for us?
No
System information
System Information
| version | core-2023.4.0 |
|---|---|
| installation_type | Home Assistant OS |
| dev | false |
| hassio | true |
| docker | true |
| user | root |
| virtualenv | false |
| python_version | 3.10.10 |
| os_name | Linux |
| os_version | 5.15.84-v7l |
| arch | armv7l |
| timezone | Europe/Copenhagen |
| config_dir | /config |
Home Assistant Community Store
| GitHub API | ok |
|---|---|
| GitHub Content | ok |
| GitHub Web | ok |
| GitHub API Calls Remaining | 4854 |
| Installed Version | 1.31.0 |
| Stage | running |
| Available Repositories | 1266 |
| Downloaded Repositories | 19 |
Home Assistant Cloud
| logged_in | true |
|---|---|
| subscription_expiration | August 10, 2023 at 2:00 AM |
| relayer_connected | true |
| relayer_region | eu-central-1 |
| remote_enabled | true |
| remote_connected | true |
| alexa_enabled | false |
| google_enabled | true |
| remote_server | eu-central-1-12.ui.nabu.casa |
| can_reach_cert_server | ok |
| can_reach_cloud_auth | ok |
| can_reach_cloud | ok |
Home Assistant Supervisor
| host_os | Home Assistant OS 9.5 |
|---|---|
| update_channel | stable |
| supervisor_version | supervisor-2023.04.0 |
| agent_version | 1.4.1 |
| docker_version | 20.10.22 |
| disk_total | 234.0 GB |
| disk_used | 9.4 GB |
| healthy | true |
| supported | true |
| board | rpi4 |
| supervisor_api | ok |
| version_api | ok |
| installed_addons | Home Assistant Google Drive Backup (0.110.3), Terminal & SSH (9.6.1), File editor (5.5.0), Mosquitto broker (6.2.0), Check Home Assistant configuration (3.11.0), Grafana (8.2.1), InfluxDB (4.6.0), Node-RED (13.5.2), Spotify Connect (0.12.3), Samba share (10.0.0), Zigbee2MQTT (1.30.3-1), ESPHome (2023.3.0), VLC (0.1.3), ArgonOne Active Cooling (29c), Shortumation (v0.7.6) |
Dashboards
| dashboards | 1 |
|---|---|
| resources | 17 |
| views | 9 |
| mode | storage |
Recorder
| oldest_recorder_run | April 5, 2023 at 9:47 PM |
|---|---|
| current_recorder_run | April 19, 2023 at 12:06 AM |
| estimated_db_size | 432.94 MiB |
| database_engine | sqlite |
| database_version | 3.38.5 |
Spotify
| api_endpoint_reachable | ok |
|---|
Additional information
No response
I had the same issue. I had to flash my SSD back to 9.5. Thankfully I have a backup of HA from the 17th of April.
I had this issue repeatedly from 8.3 to 9. It was fixed with a pi bios update. I had a work around that I did to get it to restart. I would shutdown my pi, unplug my ssd, have the boot fail and then plug the ssd back in and restart again. I have not seen this on any of the 10 rcs. 10.0 failed to boot for me as well but the workaround worked.
I had this same issue, and backing out to 9.5 was also the solution for me.
same here, will downgrade to 9.5 today.
10.05.2023 I have now downgraded and have access to more information. I'm using an Kingston SSD on USB. Here the hardware information
DEVLINKS: >- /dev/disk/by-diskseq/28 /dev/disk/by-id/ata-KINGSTON_SVP200S37A60G_50026B722A02B736 /dev/disk/by-id/usb-KINGSTON_SVP200S37A60G_26A1EE83E421-0:0 /dev/disk/by-id/wwn-0x50026b722a02b736 /dev/disk/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:2:1.0-scsi-0:0:0:0 DEVNAME: /dev/sda DEVPATH: >- /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda DEVTYPE: disk DISKSEQ: '28' ID_ATA: '1' ID_ATA_DOWNLOAD_MICROCODE: '1' ID_ATA_FEATURE_SET_APM: '1' ID_ATA_FEATURE_SET_APM_CURRENT_VALUE: '254' ID_ATA_FEATURE_SET_APM_ENABLED: '1' ID_ATA_FEATURE_SET_HPA: '1' ID_ATA_FEATURE_SET_HPA_ENABLED: '1' ID_ATA_FEATURE_SET_PM: '1' ID_ATA_FEATURE_SET_PM_ENABLED: '1' ID_ATA_FEATURE_SET_PUIS: '1' ID_ATA_FEATURE_SET_PUIS_ENABLED: '0' ID_ATA_FEATURE_SET_SECURITY: '1' ID_ATA_FEATURE_SET_SECURITY_ENABLED: '0' ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN: '2' ID_ATA_FEATURE_SET_SMART: '1' ID_ATA_FEATURE_SET_SMART_ENABLED: '1' ID_ATA_ROTATION_RATE_RPM: '0' ID_ATA_SATA: '1' ID_ATA_SATA_SIGNAL_RATE_GEN1: '1' ID_ATA_SATA_SIGNAL_RATE_GEN2: '1' ID_ATA_WRITE_CACHE: '1' ID_ATA_WRITE_CACHE_ENABLED: '1' ID_BUS: ata ID_MODEL: KINGSTON_SVP200S37A60G ID_MODEL_ENC: >- KINGSTON\x20SVP200S37A60G\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 ID_PART_TABLE_TYPE: gpt ID_PART_TABLE_UUID: de078dc3-a9a9-3d14-452f-8e0957752743 ID_PATH: platform-fd500000.pcie-pci-0000:01:00.0-usb-0:2:1.0-scsi-0:0:0:0 ID_PATH_TAG: platform-fd500000_pcie-pci-0000_01_00_0-usb-0_2_1_0-scsi-0_0_0_0 ID_REVISION: 502ABBF0 ID_SERIAL: KINGSTON_SVP200S37A60G_50026B722A02B736 ID_SERIAL_SHORT: 50026B722A02B736 ID_TYPE: disk ID_USB_DRIVER: uas ID_USB_INSTANCE: '0:0' ID_USB_INTERFACES: ':080650:080662:' ID_USB_INTERFACE_NUM: '00' ID_USB_MODEL: SVP200S37A60G ID_USB_MODEL_ENC: \x20SVP200S37A60G\x20\x20 ID_USB_MODEL_ID: '1153' ID_USB_REVISION: '0' ID_USB_SERIAL: KINGSTON_SVP200S37A60G_26A1EE83E421-0:0 ID_USB_SERIAL_SHORT: 26A1EE83E421 ID_USB_TYPE: disk ID_USB_VENDOR: KINGSTON ID_USB_VENDOR_ENC: KINGSTON ID_USB_VENDOR_ID: 174c ID_WWN: '0x50026b722a02b736' ID_WWN_WITH_EXTENSION: '0x50026b722a02b736' MAJOR: '8' MINOR: '0' SUBSYSTEM: block TAGS: ':systemd:' USEC_INITIALIZED: '3499828'
I encountered the same problem, and reverting to version 9.5 also resolved it for me.
Failed to boot after upgrading OS to 10.0.
How does this exactly manifest?
- Which leds to light up?
- Does removing and repluggin power helps?
- Anything shown on the HDMI screen?
From what I understand the Aragon One case has an internal ASMedia USB 3.0 to S-ATA adapter, from what I can tell with USB ID 174c:55aa? Can you double check if that is indeed true by running lsusb in the console (use login to get shell access).
With OS 10 we've updated to the lastest firmware from the Raspberry Pi folks (1.20230405) as well as their latest 6.1 based kernel release (tag 1.20230405 as well). This likely is the culprit of this issue.
This is essentially another variation of "boot from USB" issue on Rasberry Pi. As I've stated numerous times before, USB boot on Raspberry Pi is unfortunately notoriously unstable. I recommend booting from SD card, and use the SSD as data disk.
Same symptoms here. RPI 4 CM4 with HA installed on native NVME (Boot & Data). I am not using any USB adapter, the system is only installed on the NVME. I can ping the device but it doesn't start any services.
What a scramble ...
This issue seems to be related: https://github.com/home-assistant/operating-system/issues/2478
Perhaps there is a lower level issue with usb in general.
@agners here are my symptoms:
I'm using RPI CM4 with eMMC on Waveshare board with NVMe. eMMC is unused due to known issues with NVMe, however after upgrade OS doesn't boot at all. If connected, screen is blank, and as I understand it all ends on U-Boot. Am I getting it right?
- PI EEPROM is configured to boot from NVMe, and successfully does that by passing control to U-Boot (which was updated as a part of HAOS - #2234)
- U-Boot fails to detect the NVMe for some reason (
Device 0: unknown device?) and tries to boot via network (PXE) - HAOS is not even booted
...................................................................
U-Boot 2023.01 (Apr 17 2023 - 11:52:08 +0000)
DRAM: 512 MiB (effective 3.4 GiB)
RPI Compute Module 4 (0xc03141)
Core: 208 devices, 16 uclasses, devicetree: board
MMC: mmcnr@7e300000: 1, mmc@7e340000: 0
Loading Environment from nowhere... OK
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
No working controllers found
switch to partitions #0, OK
mmc0(part 0) is current device
** No partition table - mmc 0 **
Couldn't find partition mmc 0:1
Card did not respond to voltage select! : -110
MMC Device 2 not found
no mmc device at slot 2
Device 0: unknown device
starting USB...
No working controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
No working controllers found
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
missing environment variable: pxeuuid
Retrieving file: pxelinux.cfg/01-e4-5f-01-b8-d2-51
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/00000000
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/0000000
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/000000
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/00000
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/0000
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/000
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/00
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/0
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/default-arm-bcm283x
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/default-arm
ethernet@7d580000 Waiting for PHY auto negotiation to complete....
Also shared here: https://github.com/home-assistant/operating-system/issues/1887#issuecomment-1513719758
And one later UART messages until the prompt:
U-Boot 2023.01 (Apr 17 2023 - 11:52:08 +0000)
DRAM: 512 MiB (effective 3.4 GiB)
RPI Compute Module 4 (0xc03141)
Core: 208 devices, 16 uclasses, devicetree: board
MMC: mmcnr@7e300000: 1, mmc@7e340000: 0
Loading Environment from nowhere... OK
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
No working controllers found
switch to partitions #0, OK
mmc0(part 0) is current device
** No partition table - mmc 0 **
Couldn't find partition mmc 0:1
Card did not respond to voltage select! : -110
MMC Device 2 not found
no mmc device at slot 2
Device 0: unknown device
starting USB...
No working controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
No working controllers found
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
missing environment variable: pxeuuid
Retrieving file: pxelinux.cfg/01-e4-5f-01-b8-d2-51
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/00000000
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/0000000
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/000000
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/00000
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/0000
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/000
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/00
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/0
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/default-arm-bcm283x
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/default-arm
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Retrieving file: pxelinux.cfg/default
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
Config file not found
starting USB...
No working controllers found
ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
bcmgenet: PHY startup failed: -110
HAOS>
In the same issue with an Argon M.2 booting from USB SSD for more than a year now with no issues. Today upgraded to 10.0 and can't boot. Similar errors and prompt with no keyboard or network access. It just sits there HAOS>.
Any idea how to downgrade to 9.x in that state? All I can think of is to copy SSD -> SDCARD, boot from SDCARD, downgrade, then copy SDCARD -> SSD.
In the same issue with an Argon M.2 booting from USB SSD for more than a year now with no issues. Today upgraded to 10.0 and can't boot. Similar errors and prompt with no keyboard or network access. It just sits there HAOS>.
Any idea how to downgrade to 9.x in that state? All I can think of is to copy SSD -> SDCARD, boot from SDCARD, downgrade, then copy SDCARD -> SSD.
Do you have a backup? I assume you also boot from the SSD (no microSD present). If so, download the backup to another machine. Use a male to male USB (or a female to male and the argon male to male usb bridge) to connect the SSD to that machine. Write a fresh install with OS 9.5 to the SSD using rpi imager. Put the SSD back and boot. Wait until the rpi appears at <<IP>> :8123 and choose 'restore from backup'. Upload it, then wait again and that should be it.
If you wanted to convert to a data disk set up from a boot from USB (SSD, no microSD), how would one go about this?
From what I understand the Aragon One case has an internal ASMedia USB 3.0 to S-ATA adapter, from what I can tell with USB ID 174c:55aa? Can you double check if that is indeed true by running lsusb in the console (use login to get shell access). With OS 10 we've updated to the lastest firmware from the Raspberry Pi folks (1.20230405) as well as their latest 6.1 based kernel release (tag 1.20230405 as well). This likely is the culprit of this issue. This is essentially another variation of "boot from USB" issue on Rasberry Pi. As I've stated numerous times before, USB boot on Raspberry Pi is unfortunately notoriously unstable. I recommend booting from SD card, and use the SSD as data disk.
Hi, i have the same issue, booting from SSD, rpi4 and since the 10.0, booting is impossible.
I have backups on my side but what i wanna do is to update the firmware of the rpi and try to boot again. Do you think it's the best thing to try ?
If this manipulation does not work, i can flash my SSD back to 9.5 and restore backups, but, is there any chances that the firmware upgrade previously done will end with a fail on SSD boot, whatever the HA OS version i use ? I'm a bit worried about this ...
Thanks in advance :)
I have basically the same Setup - RPi 4, Booting from SSD with USB 3.0 Adapter (idVendor:174c, idProduct:225c, so Quirk neccesary), updating from 9.5 - and fortunatly didn't have any Issues.
I remember i updated the RPis Firmware 2-3 Month ago. My Bet for those RPis not booting would be its either because of an incompatibility with an older Firmware, or incompatibility with the USB-Adaptor.
@dafunkydan How did you do this update ? I read somewhere that the firmware is updated with the HAOS update.
Are you talking about an EEPROM update ? If yes, how did you do this operation ?
Thx
Everyone which has a problem with booting from SSD connected via USB, please share your exact adapter (make/brand and PID/VID if possible).
I am testing USB 3.0 to S-ATA adapters regularly here, these two work with HAOS 10.0:
Bus 004 Device 088: ID 2537:1068 Norelsys NS1068/NS1068X SATA Bridge Controller
Bus 004 Device 089: ID 14b0:0206 StarTech.com Ltd. ASMT105x
Folks which use Raspberry Pi CM4 with a directly attached NVMe, please do not write here but in #2479 instead.
I don't know if it's worthy of sharing but I do NOT have a problem with this adapter ( fully boot from USB no micro SD installed):
UGREEN USB C Hard Drive Enclosure, USB 3.1 Gen 2 Type C to 2.5 inch SATA SSD HDD, External Hard Drive Case Adapter Housing for 9.5mm 7mm SATA I II III, PS4, UASP High Speed Data Transfer, Up to 6TB https://a.co/d/i4XwYI5
My upgrading was a bit different, I was on 9.5 then I updated to 10.0 rc2 (during beta) then 10.0. No issues here.
However I would like to change to the data disc method to prevent future issues hence I asked this question.
If you wanted to convert to a data disk set up from a boot from USB (SSD, no microSD), how would one go about this?
The best way to do this is creating a full backup and start with an installation on the SD-card from scratch. Depending on your backup size, you can either upload it at onboarding time (before creating a login) and then enable the data disk feature, or alternatively you can create a user, enable the data disk feature and then upload the backup and restore it.
I have this one : https://www.amazon.fr/gp/product/B00XLAZODE/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&th=1
Which differences between adaptators could cause this kind of issues ?
If you wanted to convert to a data disk set up from a boot from USB (SSD, no microSD), how would one go about this?
The best way to do this is creating a full backup and start with an installation on the SD-card from scratch. Depending on your backup size, you can either upload it at onboarding time (before creating a login) and then enable the data disk feature, or alternatively you can create a user, enable the data disk feature and then upload the backup and restore it.
thanks, @agners there will likely have to be a step in between to change the RPi to boot from MicroSD (and not USB anymore, basically the opposite of these instructions ) before installing the fresh HA install on MicroSD, but I'm going to try option A, with my 2.1GB database size and upload on onboarding time. The MicroSD will only suffer twice, where everything gets transferred to the MicroSD card, and then moved to data disk.
I don't know how well option b would work because the backup would not have a data disk feature...but I'm green on the subject.
I have this one : https://www.amazon.fr/gp/product/B00XLAZODE/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&th=1
I actually have also a StarTech.com model, but it seems they have multiple.
Which differences between adaptators could cause this kind of issues ?
Which exact chip is used. But also your environment (power supply, USB hub in between, which of the USB port is being used). The disk connected to the adapter can influence behavior. And then also the EEPROM firmware of your Raspberry Pi 4.
I don't know how well option b would work because the backup would not have a data disk feature...but I'm green on the subject.
The backup is really just all data zipped, you can restore it on any installation: With a backup it is safe to go from one platform to another (e.g. Raspberry Pi 4 to a Intel x86-64 based VM installation) or from an installation with or without data disk to another installation with the opposite data disk configuration.
Kingston 120GB A400 SATA 3 2.5" Internal SSD SA400S37/120G - HDD
Once I shut power off on the RPI and my hub and restored, it booted correctly.
@bschatzow
Once I shut power off on the RPI and my hub and restored, it booted correctly.
Glad it boots even with HAOS 10. I still believe that your situation has some randomness to it which is not related to software.
Haven't tried updating yet as some of these issues stopped me from doing it. Maybe I am a bit overcautious but on the other hand it might add additional information about a potential scenario too.
Anyway - within an Argon One M.2 SATA I have this hardware:
BUSNUM: '002'
DEVNAME: /dev/bus/usb/002/002
DEVNUM: '002'
DEVPATH: >-
/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-2
DEVTYPE: usb_device
DRIVER: usb
ID_BUS: usb
ID_FOR_SEAT: usb-platform-fd500000_pcie-pci-0000_01_00_0-usb-0_2
ID_MODEL: Forty
ID_MODEL_ENC: Forty
ID_MODEL_ID: 55aa
ID_PATH: platform-fd500000.pcie-pci-0000:01:00.0-usb-0:2
ID_PATH_TAG: platform-fd500000_pcie-pci-0000_01_00_0-usb-0_2
ID_REVISION: '0100'
ID_SERIAL: Argon_Forty_0000000000E3
ID_SERIAL_SHORT: '0000000000E3'
ID_USB_INTERFACES: ':080650:080662:'
ID_VENDOR: Argon
ID_VENDOR_ENC: Argon
ID_VENDOR_ID: 174c
MAJOR: '189'
MINOR: '129'
PRODUCT: 174c/55aa/100
SUBSYSTEM: usb
TAGS: ':seat:'
TYPE: 0/0/0
USEC_INITIALIZED: '3135809'
DEVLINKS: >-
/dev/disk/by-id/ata-Dogfish_SSD_128GB_KC20210507797
/dev/disk/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:2:1.0-scsi-0:0:0:0
DEVNAME: /dev/sda
DEVPATH: >-
/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda
DEVTYPE: disk
DISKSEQ: '28'
ID_ATA: '1'
ID_ATA_DOWNLOAD_MICROCODE: '1'
ID_ATA_FEATURE_SET_APM: '1'
ID_ATA_FEATURE_SET_APM_ENABLED: '0'
ID_ATA_FEATURE_SET_HPA: '1'
ID_ATA_FEATURE_SET_HPA_ENABLED: '1'
ID_ATA_FEATURE_SET_PM: '1'
ID_ATA_FEATURE_SET_PM_ENABLED: '1'
ID_ATA_FEATURE_SET_SECURITY: '1'
ID_ATA_FEATURE_SET_SECURITY_ENABLED: '0'
ID_ATA_FEATURE_SET_SECURITY_ENHANCED_ERASE_UNIT_MIN: '6'
ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN: '6'
ID_ATA_FEATURE_SET_SMART: '1'
ID_ATA_FEATURE_SET_SMART_ENABLED: '1'
ID_ATA_ROTATION_RATE_RPM: '0'
ID_ATA_SATA: '1'
ID_ATA_SATA_SIGNAL_RATE_GEN1: '1'
ID_ATA_SATA_SIGNAL_RATE_GEN2: '1'
ID_ATA_WRITE_CACHE: '1'
ID_ATA_WRITE_CACHE_ENABLED: '1'
ID_BUS: ata
ID_MODEL: Dogfish_SSD_128GB
ID_MODEL_ENC: >-
Dogfish\x20SSD\x20128GB\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
ID_PART_TABLE_TYPE: gpt
ID_PART_TABLE_UUID: cbfa3e27-943a-4893-94e0-466580889719
ID_PATH: platform-fd500000.pcie-pci-0000:01:00.0-usb-0:2:1.0-scsi-0:0:0:0
ID_PATH_TAG: platform-fd500000_pcie-pci-0000_01_00_0-usb-0_2_1_0-scsi-0_0_0_0
ID_REVISION: T1125A0
ID_SERIAL: Dogfish_SSD_128GB_KC20210507797
ID_SERIAL_SHORT: KC20210507797
ID_TYPE: disk
MAJOR: '8'
MINOR: '0'
SUBSYSTEM: block
TAGS: ':systemd:'
USEC_INITIALIZED: '3634258'
No USB hub and the original Pi power supply.
I'm using a JSAUX adapter ( idVendor=174c, idProduct=55aa, ASMedia). It failed after update to v10. Tried firmware update but had to restore to v9.5 to get hassio working again.
Not sure. I have had no boot issue after you fixed it around 9.0? I have installed all the rcs and releases and this is the first one that didn't boot.
I have a Pi CM4 with NVMe directly connected via PCIe (no USB adapter) and I have experienced the same boot issue when updating to 10.0
