Whenever I put the laptop to sleep, while the partition from a USB block device is still attached to an AppVM, when the laptop resumes that partition is no longer working in the AppVM. The previous /dev/xvdX node is still there, but it doesn’t work to re-mount it.
Until recently, what I’ve been doing was to keep re-attaching the partition using qvm-block (then mounting it again in the AppVM) every time after waking the laptop from sleep. Is this the normal workflow for everyone?
However, since multiple /dev/xvdX nodes keep pilling up while doing this, eventually it runs out and I have to restart the AppVM, before I can attach partitions again. One way around this is to unmount and unattach the partition, before putting the laptop to sleep. But this gets tedious, especially when I also need to close any programs running in the AppVM that are currently accessing the partition.
To makes this process a little more streamlined, I recently tried to automate the mounting part, using an /etc/fstab entry and the x-systemd.automount option: Automounting an attached USB partition in debian 12 minimal - #8 by fb2043. However, I put the laptop to sleep without unmounting the partition (as I always used to) and when I resumed the laptop, the partition (ext4) became corrupted: all the files were gone (it was bad enough that utilities like fsck couldn’t fix it using the superblock backups; photorec could recover the files, but testdisk couldn’t recover the directory structure). I’m not sure if it’s related to the systemd automounting configuration, or just a shitty coincidence.
Anyway, I decided to ask what other people are doing about this, in case there are ways which are tested and definitely don’t lead to data loss.
This x-systemd.automount works only during boot or when run manually.
There is another option - automount that mounts partition when you access it and unmount after some idle time not using it. media-usbdata01.automount when you have already media-usbdata01.mount done:
[Unit]
Description="/etc/systemd/system/media-usbdata01.automount" unit to automount "/media/usbdata01" on demand
[Automount]
Where=/media/usbdata01
TimeoutIdleSec=5
[Install]
WantedBy=multi-user.target
If you add it to bind-dirs then you must add to rc.local:
If you do it in template, then you need enable it (only once):
sudo systemctl enable media-usbdata01.automount
You don’t need to start or enable media-usbdata01.mount (you souldn’t, as it will mount immediately without any automation), it just need to be in /etc/systemd/system/.
After that, when you connect usb that have media-usbdata01.mount unit in systemd (not enabled and not running), and go to /media/usbdata01 then systemd will mount that mount point.
After 5s (TimeoutIdleSec) of being outside of that mount point it will be unmounted. And if you go there again it will be mounted again.
It might not work with .automount unit from x-systemd.automount as it might have different name every start (dunno that, just guesing, don’t have that to test).
For the data loss, if the disk is used a lot, and if it is a spinning hdd, can it be a problem of the write buffer that is not flushed?
Normally I do not expect such problems, but maybe your device tells lies…
Yes! There is also a possibility in hdparm/sdparm, I think, to set write caching for some disks . It is even lower level than the kernel, but I am not sure all USB-disk controllers pass it correctly (a memory… quite long ago… it was cheap hardware).
The drive that got corrupted was a basic USB thumbdrive
It also works for automatically mounting the partition whenever it’s attached to the AppVM.
Unmounting will fail with the error target is busy if the partition is in use; for example, it will fail even if there is a shell running at that path. So before putting the laptop to sleep, it would be necessary to manually close all programs that are accessing that partition, in order for the timeout to trigger. Furthermore, it wouldn’t avoid the issue where the device nodes at /dev/xvdX are pilling up when re-attaching the partition. So unfortunately this doesn’t solve many of the problems I’ve mentioned.
No. With my approach, until it’s busy it would not unmount.
Tested it with:
x=false; until $x; do ls /media/usbdata01/; done
As long as it worked it wouldn’t unmount.
When I stopped it with <CTRL-C> then partition was unmounted.
With .automount created from fstab there’s nothing about it:
### Editing /etc/systemd/system/media-usbdata01.automount.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file
### Edits below this comment will be discarded
### /run/systemd/generator/media-usbdata01.automount
# # Automatically generated by systemd-fstab-generator
#
# [Unit]
# SourcePath=/etc/fstab
# Documentation=man:fstab(5) man:systemd-fstab-generator(8)
#
# [Automount]
# Where=/media/usbdata01
So again, tested method for auto mount on access and auto unmount after no use. /etc/systemd/system/media-usbdata01.mount:
[Unit]
Description="/etc/systemd/system/media-usbdata01.mount` unit to mount UUID ExFAT partition to "/media/usbdata01" mount point
After=local-fs.target
[Mount]
What=/dev/disk/by-uuid/XXXX-XXXX #put here UUID of partition to mount
Where=/media/usbdata01
Type=exfat
Options=defaults,uid=1000,gid=1000,sync,iocharset=utf8,errors=remount-ro,nodev,nosuid
[Install]
WantedBy=multi-user.target
/etc/systemd/system/media-usbdata01.automount:
[Unit]
Description="/etc/systemd/system/media-usbdata01.automount" unit to automount "/media/usbdata01" on demand
[Automount]
Where=/media/usbdata01
TimeoutIdleSec=5
[Install]
WantedBy=multi-user.target
The reattachment problem sounds a little like the usb key is not restored immediately on resume.
I really don’t know where I would start searching for the cause… selective suspend, kernel module unload-reload in sys-usb, indirect attachment (i.e. on a secondary hub), strict reset or lack of strict-reset. Probably there are others with more idea than me.
The corruption is another question.
I’ve had a similar-sounding bad experience with a total failure of ext4 on a “consumer” key. I think I did not take any steps to minimise metadata updates, and it was just worn out. I guessed that the firmware misbehaved when no writable blocks were left.
OTOH, some folk seem to happily use USB keys as their main system disk. Maybe they take more care than me - noatime is one recommended mount option, I forget what else.
As for usb as main system experience ask unraid users. They’re pounding devs with hdd/ssd boot option. On their forum, tumb rule is to make several copies of boot usb, because they live like 3-4 months and need to be trashed.
Are you suggesting that for other QubesOS users, when they put the laptop to sleep with a USB drive attached and mounted in an AppVM, the mounted partition remains accessible after resuming from sleep? That would be weird, because this was never the case for me on 2 different laptops and with many different USB drives. So far I’ve assumed my problem was just related to Implement facilities for handling unexpected physical removal of block devices · Issue #1082 · QubesOS/qubes-issues · GitHub.
Don’t take it as 100% sure.
My memory is that it used to work like that for my USB backups… but I stopped using standby years ago (other problems + laziness). I did have some automount setup, but I’m fairly certain there was not constant need to reattach as a new device after standby.