A bit panicked right now because all of my backups are in this external hdd drive and I don’t want to lose all of them. Please help.
So basically what happened is that, while my LUKs-encrypted external hdd was plugged in, attached to, and mounted & unlocked in one of my qubes, I accidentally shut down sys-usb.
Once I realized what I did, I immediately started sys-usb up again and tried attaching the external hdd back to the qube it was attached to earlier. When I did that, there was an error message, I think it said that the device was already attached? Or at least something like that. Then I unmounted the attached drive from within the gnome file manager.
I know I know, what I did was stupid and rash. I’m not sure if I made things a lot worse. What do I do now?
Edit:
Okay, I didn’t do anything more but I got another message saying “Unable to unmount volume: Timeout was reached”
Not sure if I understand correctly yout setup. This is how I understand it:
Your external drive is connected to a USB controller attached to sys-usb.
The block device is attached to some other VM (using qvm-block or something like that).
In the other VM, the block device is mounted.
When you shut down, the sys-usb in this setup, the effect should be similar to power outage. You might have lost something that was being saved or some uncommited data, but modern filesystem should recover from it. Especially if you run fsck.
Aside of that, you might have some temporary issues. Unless there is some unstored data you want to save, I’d perform reboot of the VM where you use the block device, or even reboot your system.
The way I attached it was by using the “Qubes Devices” icon, found in the task bar on top-right of the screen. The external drive was attached from sys-usb to one of my work qubes using that gui icon. If that’s what you meant, then you’re correct. Also to clarify, the drive was unlocked, with a password(Remember that it’s a luks encrypted ext4 drive), at the time I accidentally shut down sys-usb.
But anyways, how should I proceed? The external drive still appears to be attached to the work qube, according to the context menu that appears when I click the “Qubes Devices” icon. I haven’t done anything since my original post, besides closing the message that said
Should I just unattach it using the “Qubes Devices” icon, physically unplug the external drive, and restart the work qube?
I decided to just go ahead and try to reboot the qube as you said but I ran into errors when trying to shut it down. What I did was:
Detach the external hdd from the work qube using the “Qubes Devices” gui icon.
Then I physically disconnect the external hdd from the computer
Then I try to shutdown the work qube
I’m stuck at the third step. When I try to shut it down, an error notification on the top-right of the screen pops up and says:
“Qube work failed to shut down: internal error: Failed to shutdown domain ‘6’ with libxenlight”
And dom0 also gets a pop-up error message:
“The following error occurred while attempting to shut down qube work: Got empty response from qubesd. See journalctl in dom0 for details.”
I checked the log using “journalctl -r” and below is the section where the error happens.
Nov 25 14:01:27 dom0 qubesd[2938]: libvirt.libvirtError: internal error: Failed to shutdown domain '6' with libxenlight
Nov 25 14:01:27 dom0 qubesd[2938]: if ret == -1: raise libvirtError ('virDomainShutdown() failed', dom=self)
Nov 25 14:01:27 dom0 qubesd[2938]: File "/usr/lib64/python3.8/site-packages/libvirt.py", line 2672, in shutdown
Nov 25 14:01:27 dom0 qubesd[2938]: return attr(*args, **kwargs)
Nov 25 14:01:27 dom0 qubesd[2938]: File "/usr/lib/python3.8/site-packages/qubes/app.py", line 103, in wrapper
Nov 25 14:01:27 dom0 qubesd[2938]: self.libvirt_domain.shutdown()
Nov 25 14:01:27 dom0 qubesd[2938]: File "/usr/lib/python3.8/site-packages/qubes/vm/qubesvm.py", line 1354, in shutdown
Nov 25 14:01:27 dom0 qubesd[2938]: await self.dest.shutdown(force=force, wait=wait)
Nov 25 14:01:27 dom0 qubesd[2938]: File "/usr/lib/python3.8/site-packages/qubes/api/admin.py", line 901, in vm_shutdown
Nov 25 14:01:27 dom0 qubesd[2938]: response = await self.mgmt.execute(
Nov 25 14:01:27 dom0 qubesd[2938]: File "/usr/lib/python3.8/site-packages/qubes/api/__init__.py", line 288, in respond
Nov 25 14:01:27 dom0 qubesd[2938]: Traceback (most recent call last):
Nov 25 14:01:27 dom0 qubesd[2938]: unhandled exception while calling src=b'dom0' meth=b'admin.vm.Shutdown' dest=b'work' arg=b'' len(untrusted_payload)=0
Nov 25 14:01:27 dom0 libvirtd[1939]: internal error: Failed to shutdown domain '6' with libxenlight
I would just exit all the apps in all the qube and maybe run sync command in qubes you cannot shut down. (I don’t think running sync is necessary, but just to be sure…) Then, I would reboot whole Qubes OS. (The shutdown might take longer than usual, as it might hang until some timeout is reached.)
Or you can try to terminate qui-devices, qubes-qube-manager and qui-domains and check if everything is ok now. When this happens to me, it’s usually is about (device, manager and domains) gui interface(s) not been properly refreshed.
I did a whole system reboot and now the external drive connects to the work qube just fine. Also ran fsck and no problems were found.
Thank you so much for your help. I really thought the whole drive/filesystem would’ve been screwed up by sys-usb being shut down in the middle of it being unlocked/unencrypted.
I thought there was some way like that, but didn’t know it exactly, so that reboot would be faster than elaborating. But for the next time, this can be a viable option.
Generally, modern filesystems are usually ready for that. You might lose some data being written, you might lose some recently written data (usually up to 1 minute ago), as they might not have been written, but I wouldn’t expect broader filesystem corruption, unless you use some funky options/tools (disabled journaling, data=write back, eatmydata) that optimize performance at cost of data safety I those scenario. And even is such odd cases, I’d rather expect individual files (incl. whole tables/databases) to be affected.
And if whole FS was corrupted, I’d expect different symptoms. Qubes device manager (or qvm-block) doesn’t care about the FS. So I was pretty sure it was some inconsistent state (that can be solved by reboot) rather than damaged FS.