Last week write access to my NVMe ssd running Qubes 4.3 was lost with data corruption (on the dom0 root volume) preventing boot. Installing Qubes on another NVMe ssd and proceeding to debug, I determined the data corruption was too pervasive. I successfully made disk images of my various private vol…

Just realized I didn’t define “crash”. I mean the system (dom0, qubes) suddenly lose the ability to write to the disk, the mount ends up R/O with a ton of kernel errors from the filesystem (ext4) not being able to write caches to disk etc. I’ll get log outputs as soon as I can.

Managed to retrieve some logs. Let me know if you need any other data. [ 10.254255] EXT4-fs (nvme0n1p2): mounted filesystem 7a9df742-797c-4415-9d12-69c38fedd286 r/w with ordered data mode. Quota mode: none. [ 10.755462] usbcore: registered new interface driver snd-usb-audio [ 71.369646] devic…

Yes, and in my case the only path forward for me was to ditch the LVM filesystem altogether and to reinstall on top of BTRFS instead. I tried installing with the default LVM filesystem option four times, on top of brand-new Samsung SSD’s, and there was no joy each time. Each time I was unable to res…

This was also possibly related to this same problem. https://forum.qubes-os.org/t/q-4-3-backup-restore-process-running-out-of-space-but-where-why/42344

Oops, I was coming to the same conclusion thinking about this over night. It might be possible I ran into an actual bug (or hardware fault) on my first SSD, then ran out of space without realizing it while recovering data on the second, smaller SSD. Or perhaps I ran into the same issue on both. Goin…

2 different NVMe Drives crash, Possible Qubes/Xen bug

User Support

rustybird July 19, 2026, 11:19am 4

Doesn’t look like a hardware error, just LVM running out of space in the pool hosting the dom0 filesystem. Not unlike this recent post: