Raspberry Pi 5 + Argon V5 + NVMe + Home Assistant: troubleshooting NVMe I/O errors and a stable workaround

Hardware
1

Raspberry Pi 5 + Argon V5 + NVMe + Home Assistant: troubleshooting NVMe I/O errors and a stable workaround

I recently spent quite a bit of time debugging a Raspberry Pi 5 setup using an Argon V5 case, NVMe storage, Zigbee, and Home Assistant.

The final result is stable, but the path there exposed a few useful failure markers that may help anyone running into similar issues.

Hardware / setup

  • Raspberry Pi 5
  • Official Raspberry Pi 27 W USB-C PSU
  • Argon V5 case with NVMe support and Zigbee module
  • Kingston NV3 1 TB NVMe (SNV3S1000G)
  • Home Assistant OS 18.2
  • Home Assistant Core 2026.8.0

The NVMe was initially flashed directly with HAOS using an external USB NVMe enclosure.

Initial symptoms

HAOS would sometimes boot, sometimes fail during boot, and sometimes run briefly before storage errors started appearing.

Typical kernel errors included:

Buffer I/O error on dev nvme0n1p5

nvme0n1: I/O Cmd(0x1) ... I/O Error

followed by large amounts of:

could not locate request for tag 0xffff

Once the NVMe errors started, filesystem errors followed naturally:

EXT4-fs error (device nvme0n1p8):
__ext4_find_entry:... reading directory lblock 0

and on HAOS system partitions:

erofs (device nvme0n1p5): readahead error ...

Eventually even shutdown could fail because HAOS was no longer able to read some of its own files.

At first this looked like:

  • bad NVMe
  • bad PCIe ribbon cable/contact
  • insufficient PSU
  • filesystem corruption
  • PCIe Gen 3 instability
  • or an HAOS-specific issue

1. Check the physical PCIe connection

The Argon PCIe ribbon cable is easy to insert slightly incorrectly while still looking mechanically secure.

I removed and reseated the ribbon carefully.

This is worth doing before anything else, but in my case the HAOS errors remained.

2. Boot Raspberry Pi OS from microSD

I installed Raspberry Pi OS Lite 64-bit on a microSD and booted from it while leaving the NVMe connected.

This gave me a known-good Linux environment independent of HAOS.

First checks:

lsblk -o NAME,SIZE,MODEL,FSTYPE,MOUNTPOINTS

The NVMe was detected correctly:

KINGSTON SNV3S1000G

Then:

dmesg | grep -Ei 'nvme|pcie|i/o error|timeout|reset'

No NVMe errors appeared.

3. Update the Raspberry Pi EEPROM / bootloader

The Pi bootloader was slightly behind:

CURRENT: 11 May 2026
LATEST:  26 May 2026

I updated it with:

sudo rpi-eeprom-update -a
sudo reboot

After reboot:

sudo rpi-eeprom-update

showed:

BOOTLOADER: up to date
CURRENT: Tue 26 May 2026
LATEST:  Tue 26 May 2026

4. Verify PCIe link speed

I wanted to rule out a forced PCIe Gen 3 configuration.

On Raspberry Pi OS:

grep -nE 'pcie|pciex1' /boot/firmware/config.txt

No Gen 3 override was present.

Then:

sudo lspci -vv -s 0001:01:00.0 | grep -E 'LnkCap|LnkSta'

Result:

LnkCap: Speed 16GT/s, Width x4
LnkSta: Speed 5 GT/s (downgraded), Width x1 (downgraded)

So the link was operating at:

PCIe Gen 2 x1

which is exactly what I wanted for stability testing.

The HAOS boot partition also contained no pciex1_gen=3 setting. It only had ASPM disabled:

pcie_aspm=off
dtparam=pciex1_aspm=off

5. Stress-test the NVMe under Raspberry Pi OS

This was the key comparison.

With the NVMe unmounted:

sudo dd if=/dev/nvme0n1 of=/dev/null bs=16M status=progress

The disk sustained roughly:

~472 MB/s

for tens of GB, then well beyond 100 GB, with:

sudo dmesg -w

showing no:

I/O error
timeout
reset controller
could not locate request for tag
PCIe Bus Error

This strongly suggested that:

  • the SSD itself was functional
  • the PCIe link could sustain heavy reads
  • the ribbon cable was at least capable of stable operation
  • the PSU was not obviously the problem

6. Repair filesystem damage left by the previous crashes

The HAOS partitions had suffered from unclean shutdowns and I/O failures.

For example, mounting the HAOS FAT boot partition showed:

FAT-fs (nvme0n1p1):
Volume was not properly unmounted.
Some data may be corrupt.
Please run fsck.

The writable HAOS partitions were:

  • nvme0n1p1 — hassos-boot, VFAT
  • nvme0n1p7 — hassos-overlay, ext4
  • nvme0n1p8 — HA data, ext4

I checked them from Raspberry Pi OS.

Boot partition:

sudo fsck.fat -a /dev/nvme0n1p1

This automatically removed the dirty bit.

Overlay:

sudo fsck.ext4 -f /dev/nvme0n1p7

No errors.

Data partition:

sudo fsck.ext4 -f /dev/nvme0n1p8

This initially found and fixed two:

free blocks count wrong

errors.

A second fsck completed cleanly.

I did not try to repair the EROFS partitions, since those are read-only HAOS system images and the EROFS messages were a consequence of lower-level NVMe read failures.

7. Re-test HAOS

After:

  • carefully reseating the PCIe ribbon
  • updating the EEPROM
  • confirming PCIe Gen 2 x1
  • stress-testing the SSD successfully under Raspberry Pi OS
  • repairing the writable HAOS filesystems

I booted HAOS 18.2 again without touching the hardware.

HAOS reached the console, but shortly afterwards the same errors returned:

could not locate request for tag 0xffff

followed by:

nvme0n1: I/O Cmd(...) ... I/O Error

and then EXT4 / EROFS failures.

At that point I stopped treating this as a normal SSD or cable failure.

The important A/B comparison was:

Same Raspberry Pi
Same Argon board
Same ribbon cable
Same Kingston NV3
Same PCIe Gen 2 x1 link

Raspberry Pi OS:
sustained NVMe reads at ~472 MB/s, no kernel errors

HAOS 18.2:
NVMe I/O failures shortly after boot

8. Final workaround: Raspberry Pi OS + Docker + Home Assistant Container

Instead of continuing to fight HAOS, I decided to keep Raspberry Pi OS Lite on the microSD and use the NVMe as application/data storage.

I wiped the HAOS partition layout and created one ext4 partition:

sudo wipefs -a /dev/nvme0n1

sudo parted /dev/nvme0n1 --script mklabel gpt
sudo parted /dev/nvme0n1 --script mkpart primary ext4 0% 100%

sudo mkfs.ext4 -L data /dev/nvme0n1p1

Mounted it under:

/srv

and added it to /etc/fstab using its UUID.

For example:

UUID=$(blkid -s UUID -o value /dev/nvme0n1p1) \
&& echo "UUID=$UUID /srv ext4 defaults,noatime 0 2" \
| sudo tee -a /etc/fstab

Then I installed Docker Engine and configured:

{
  "data-root": "/srv/docker"
}

in:

/etc/docker/daemon.json

Home Assistant Container now runs with its config stored on the NVMe.

Example Compose configuration:

services:
  homeassistant:
    container_name: homeassistant
    image: ghcr.io/home-assistant/home-assistant:stable
    volumes:
      - /srv/homeassistant/config:/config
      - /etc/localtime:/etc/localtime:ro
      - /run/dbus:/run/dbus:ro
    restart: unless-stopped
    privileged: true
    network_mode: host

This has been stable for hours with Home Assistant actively reading and writing to the NVMe.

A current kernel check shows no NVMe I/O failures:

dmesg | grep -Ei 'nvme|i/o error|timeout|reset|tag 0xffff|ext4'

9. Argon V5 USB / Zigbee gotcha

There was another completely separate issue worth documenting.

Initially:

  • the Raspberry Pi’s native USB ports worked
  • the USB ports exposed by the Argon board did not
  • the Argon Zigbee coordinator did not appear
  • /dev/serial/by-id/ did not exist

Installing the official Argon V5 scripts fixed this:

curl https://download.argon40.com/argon1v5.sh | bash
sudo reboot

After installation, /boot/firmware/config.txt contained:

otg_mode=1
dtoverlay=dwc2,dr_mode=host
usb_max_current_enable=1

After reboot:

lsusb

showed:

1a86:8091 QinHeng Electronics USB HUB
10c4:ea60 Silicon Labs CP210x UART Bridge

and:

ls -l /dev/serial/by-id/

returned:

usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_... -> ../../ttyUSB0

So if the Argon USB ports and Zigbee module appear completely dead under Raspberry Pi OS, do not immediately assume a hardware fault: the Argon setup scripts may simply not have been installed yet.

Current result

The final setup is:

Raspberry Pi 5
├── microSD
│   └── Raspberry Pi OS Lite
│
├── Argon V5
│   ├── PCIe NVMe
│   ├── USB hub
│   └── Zigbee coordinator
│
└── NVMe 1 TB mounted at /srv
    ├── Docker data
    ├── Home Assistant config/data
    └── future NAS / services / backups

Home Assistant Container is currently controlling:

  • Zigbee lights via ZHA
  • Somfy / TaHoma shutters
  • Viessmann ViCare boiler
  • MCZ pellet stove through HACS
  • temperature sensors and other automation inputs

The system is stable and the NVMe continues to behave normally under Raspberry Pi OS.

Main takeaway

If you see this combination on Raspberry Pi 5 + NVMe:

could not locate request for tag 0xffff
nvme0n1: I/O Cmd(...) ... I/O Error
EXT4-fs errors
EROFS readahead errors

do not immediately conclude that the SSD is dead.

Booting Raspberry Pi OS from microSD and stress-testing the same NVMe is a very useful discriminator.

If the NVMe survives sustained reads under Pi OS but consistently fails under HAOS with the same physical setup, testing a Raspberry Pi OS + Home Assistant Container architecture may save a lot of time.

It also gives you a regular Linux host, which can be useful if you want to run other Docker services, NAS storage, reverse proxies, VPNs, monitoring, or small self-hosted applications alongside Home Assistant.

2

My first thought is is that able to keep up with all the added hardware? It is designed with margins to run the PI, might need more margins to run everything else.

3

Couldn’t you have simply used the move data disk option in HAOS?

4

This was indeed my main concern. First time I ran the whole hardware, was with a cheap power supply, and it just didn’t work. I also read somewhere that my choice of nvme wasn’t particularly good (or even not supported officially). With my current setup though, it holds very well and doesn’t crash. I also better have a “real” linux and run docker on it. I’m more used to such infrastructure.
It would be interesting to test a bigger PSU though. Now, docker run on the nvme, and the OS on the SD card. I’m fine with it.

5

Indeed I could do that, but I wasn’t very attached to anything on my previous setup, so I decided to format everything to prevent potential issues from a shaky install.

6

Refresh my failing memory: Wasn’t there another thread here about the Argon case that found the problem was hardware, and the closest to a ‘fix’ was to move the adapter cable from USB3.0 to USB2.0?

RF Interference if I recall. The workaround slowed down the system and allowed the continual overworked data error correcting algorithms do do their work, occasionally overflowing if overloaded, hence data loss at random times. Alternative was to look for alternative hardware, avoiding Argon solutions.

A vendor keen to offload obsolete faulty stock at whatever price they could find easy targets to part with their money? No product recall?

The reams of messages in respect of this, gradually narrowing the problem, has confused many LLMs that are throwing up outdated solutions. Is this one of those?

Your proposed solution probably has the worst of both worlds: SD Card, plus SSD, and a suspect interface.

7

Interesting. USB 3 could indeed explain some issues with radio interference, but I don’t really see how that would directly relate to the NVMe I/O errors, since the drive is connected over PCIe x1.

That said, I understand why the Argon hardware itself could still be considered suspicious from a signal-integrity point of view. My goal here is mainly to see whether I can make this exact hardware combination work reliably. I personally haven’t experienced any radio issues.

For now, the setup is running well. My “solution” is obviously more of a workaround for this specific hardware than a definitive fix. I’ve had this hardware for almost a year now, and this is the first setup I’ve found that has been stable so far.

My original post was simply formatted with the help of an LLM from all the tests, errors and workarounds I went through.

Thanks to your comment, I ended up reading these threads:

Some people reported that switching to PCIe Gen 3 actually improved stability, which is something I hadn’t even considered. I had deliberately made sure I was running Gen 2 because I assumed that would be the safer option.

I know that running the OS from SD and keeping the data on NVMe is not an ideal long-term architecture. For now, my methodology is to leave it running for a couple of months and monitor things like NVMe media errors, kernel I/O errors and resets. That should at least give me more information and help isolate whether the interface itself is actually unstable over time.

I don’t know yet whether this is the best approach, but replacing the Argon NVMe interface altogether would of course be the more definitive solution. :slightly_smiling_face:

Thanks for the help, appreciate !

Update: I found an Argon support response stating that the Kingston NV3 (SNV3S) is not considered compatible with the Raspberry Pi 5 PCIe interface, while the older NV2 is on their tested compatibility list. This may explain why HAOS exposed repeated NVMe I/O errors even though Raspberry Pi OS currently runs the same drive without errors (kernel, drivers, aspm / power managment / host memory buffer size, …). I’m keeping the current setup under observation.