Thumbdrive behavior--nested partitions question about core-admin/qubes-devices library

SteveC · June 17, 2026, 7:10pm

A thumbdrive, on initial plugin, will (usually) show two devices…sys-usb:sda and sys-usb:sda1; sda1 is a partition basically nested within sda.

Usually you want to attach sys-usb:sda1 to whatever VM is supposed to work with the thumb drive. Once you do this, though, the device menu will never, ever show sys-usb:sda again, even if you detach sys-usb:sda1. It is necessary to unplug the device and plug it back in again to get sda back.

Even in the core-admin qubes-devices library, sda appears to vanish completely.

There are situations I run into where I might want sda to come back (I might want to run gparted on the thumb drive, for instance; I have other cases specific to my setup). Is there some process I can follow in core-admin that will “reset” it as though I had unplugged and then reinserted the drive?

noskb · June 18, 2026, 4:55am

If you don’t want to physically plug or unplug the drive, you can achieve the same result by triggering a udev event in sys-usb:

sudo udevadm trigger --subsystem-match block --action remove /dev/sda
sudo udevadm trigger --subsystem-match block --action add /dev/sda

Some time ago, I wrote a workaround patch for core-admin that automatically performs such actions when a partition is detached from a qube, but I’ve lost it somewhere…

tanky0u · June 18, 2026, 6:22am

A thumbdrive, on initial plugin, will (usually) show two
devices…sys-usb:sda and sys-usb:sda1; sda1 is a partition basically
nested within sda.

Usually you want to attach sys-usb:sda1 to whatever VM is supposed to
work with the thumb drive.

I always attach sys-usb:sda to the VMs. Then, in the VM, I mount
/dev/xvdi1 partition. And then work with the thumbdrive storage in that
VM.

Once you do this, though, the device menu will never, ever show
sys-usb:sda again, even if you detach sys-usb:sda1. It is necessary to
unplug the device and plug it back in again to get sda back.

Yeah, I also observe something “screwed up” like that.

SteveC · June 18, 2026, 4:54pm

That’s certainly one approach! I was doing that for a while, but it was getting tedious having to remember to mount xvdi1 not xvdi in the qube, particularly when that was what I usually wanted to do. (I could have automated this eventually, but chose to do the automation earlier in the process.)

Many of my thumbdrives I actually just go ahead and format the whole thing as ext3 or ext4 and there’s no nesting. It takes some doing to get that to happen but it works in Linux once you do so. Of course, you won’t ever get the kiosk at OfficeDepot to read that thumbdrive…

I was trying to write something smart enough to handle either case directly. I can tell it to “ignore children” and it will mount sda. I can tell it to ignore parents and it will mount sda1 (and ask which one, if there is also an sda2, etc.) But I can’t do it if the system insists on taking whatever I do as a precedent and never shows me what I ignored ever again. In 4.2 it would lose the parent (if I mounted a child), but at least if I mounted the parent, it would still remember the children. 4.3 will now forget the children in the latter case too.

SteveC · June 18, 2026, 4:56pm

noskb:

If you don’t want to physically plug or unplug the drive, you can achieve the same result by triggering a udev event in sys-usb:
sudo udevadm trigger --subsystem-match block --action remove /dev/sda
sudo udevadm trigger --subsystem-match block --action add /dev/sda
Some time ago, I wrote a workaround patch for core-admin that automatically performs such actions when a partition is detached from a qube, but I’ve lost it somewhere…

I guess I would have to have dom0 (which is doing the coordination) tell sys-usb to do this–another complication but one I can manage. (I’m not about to try to patch core-admin…I don’t understand most of it!)

Thanks!

rustybird · June 19, 2026, 12:44pm

github.com/QubesOS/qubes-issues

The hidden block devices due to attachment are not restored after detachment

opened 11:26AM - 09 Nov 24 UTC

apparatius

C: Qubes GUI tools P: default needs diagnosis C: storage affects-4.2 affects-4.3

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) #…## Qubes OS release R4.2.3 ### Brief summary When block device e.g. /dev/sda has multiple partitions and you attach a single partition e.g. /dev/sda1 to another qube, then block device /dev/sda is removed from the list of block devices available for attachment. And the same is when whole block device e.g. /dev/sda is being attached to another qube, then all partitions of this block device e.g. /dev/sda1 are removed from the list of block devices available for attachment. I guess this is to prevent the attachment of the same device to multiple qubes. The problems that after you detach the attached block device, the block devices removed to prevent the attachment of the same device to multiple qubes won't be available for attachment anymore. If you run `partprobe` in the source qube to refresh the block device info after detachment, then it'll restore the missing block devices in the list of block devices available for attachment. Maybe related: https://github.com/QubesOS/qubes-issues/issues/4692 ### Steps to reproduce In disposable qube disp1234 run these commands: ``` dd if=/dev/zero of=/tmp/tst.img bs=1M count=128 dev=$(sudo losetup -f --show /tmp/tst.img) sudo sgdisk -n 0:0:+64MiB $dev sudo sgdisk -n 0:0: $dev sudo partprobe $dev ``` Check the available block devices in dom0: ``` [user@dom0 ~]$ qvm-block BACKEND:DEVID DESCRIPTION USED BY disp1234:loop0 /tmp/tst.img disp1234:loop0p1 () disp1234:loop0p2 () ``` Attach a single partition of the loop device as block device in dom0 to another disposable qube: ``` qvm-block attach disp4321 disp1234:loop0p1 ``` Check the available block devices in dom0: ``` [user@dom0 ~]$ qvm-block BACKEND:DEVID DESCRIPTION USED BY disp1234:loop0p1 () disp4321 (read-only=no, frontend-dev=xvdi) disp1234:loop0p2 () ``` Detach the block device: ``` qvm-block detach disp4321 disp1234:loop0p1 ``` Check the available block devices in dom0: ### Expected behavior ``` [user@dom0 ~]$ qvm-block BACKEND:DEVID DESCRIPTION USED BY disp1234:loop0 /tmp/tst.img disp1234:loop0p1 () disp1234:loop0p2 () ``` ### Actual behavior ``` [user@dom0 ~]$ qvm-block BACKEND:DEVID DESCRIPTION USED BY disp1234:loop0p1 () disp1234:loop0p2 () ```

SteveC · June 19, 2026, 7:20pm

noskb:

If you don’t want to physically plug or unplug the drive, you can achieve the same result by triggering a udev event in sys-usb:
sudo udevadm trigger --subsystem-match block --action remove /dev/sda
sudo udevadm trigger --subsystem-match block --action add /dev/sda
Some time ago, I wrote a workaround patch for core-admin that automatically performs such actions when a partition is detached from a qube, but I’ve lost it somewhere…

OK…I realized (belatedly) that those commands you gave are actually to be issued in dom0…no need for a qvm-run call or anything like that.

Unfortunately…the add does not work; it ONLY adds /dev/sda, not its children sda1 thru sda4.

noskb · June 20, 2026, 12:05am

I think that indicates an USB controller is connected to dom0.
Anyway, I wonder if there’s a difference in how udev handles things between dom0 and sys-usb? At least, it worked when I tested it on my sys-usb.

SteveC · June 20, 2026, 4:33am

Actually…I realized those commands actually DO need to be run on sys-usb. I should have come back here and said so. Running on dom0 seemed to “work” sort of because it was disconnecting an internal SSD, not the thumbdrive.

I essentially have no known barriers left to converting my desktop over to 4.3…other than the fact that I simply won’t have time to do so for the next two weeks.