Qube unresponsive due to sourcing un-existing file

I messed up trying to sync my dotfiles and got one of my qubes sourcing an unexisting file in their .zshenv file. More specifically, rustup had added the following line to my ~/.zshenv file:

. "$HOME/.cargo/env"

and I blindly have qvm-move 'd that same .zshenv file to another qube which doesn’t have any file as $HOME/.cargo/env. Now that qube doesn’t pull up a terminal, I also cannot remove that .zshenv file from dom0:

(dom0) $ qvm-run --pass-io mydebian 'rm ~/.config/zsh/.zshenv'
/usr/lib/qubes/qubes-rpc-multiplexer: 28: .: cannot open /home/user/.cargo/env: No such file

I am practically locked out of my mydebian qube. Luckily I had it backed-up 2 days ago. However, I also don’t want to miss out on 2 days’ worth of changes in that qube.

Is there a way I can (somehow) reach into that qube and remove the problematic file so that I can finally pull up a terminal in it? Or am I doomed to having to have to restore from my backup?

You can mount the image and edit the file, How to mount LVM image

You can also try and revert fs of the qube to previous revision, Revert volume

1 Like

Would that be my 2-day-old backup file in an external HDD?

It’s a little optimistic to assume anyone but yourself can answer that question.

I was trying to ask whether the “previos revision” is stored locally on qubes os, or it is implicitly meaning my manual backups—but I guess the linked doc answers that. I am reading now.

Unless you turn off revisions, you get two snapshots of the FS

With Qubes, it is possible to revert one of a VM’s storage volumes to a previous state using the automatic snapshot that is normally saved every time a VM is shutdown. (Note that this is a different, lower level activity than the Backup, Restoration, and Migration process.)

In Qubes, when you create a new VM, it’s volumes are stored in one of the system’s Storage Pools. On pool creation, a revisions_to_keep default value is set for the entire pool. (For a pool creation example, see Storing app qubes on Secondary Drives.) Thereafter, each volume associated with a VM that is stored in this pool inherits the pool default revisions_to_keep.

I just checked that it reports:

revisions_to_keep   0
Available revisions (for revert): none

I don’t remember turning off revisions. That qube is an off-shoot of debian-11-minimal. Are revisions turned off by default for the minimal ones?

I think it’s controlled by the storage pool, not the template.

Then you need to mount the image and edit the file.

Yeah, I am looking at it.

# Example: /dev/qubes_dom0/vm-debian-9-tmp-root
[user@dom0]$ dev=$(basename $(readlink /dev/YOUR_LVM_VG/YOUR_LVM_IMAGE))

What exactly should I write in place of YOUR_LVM_VG and YOUR_LVM_IMAGE placeholders?

YOUR_LVM_VG ?= qubes_dom0
YOUR_LVM_IMAGE ?= vm-mydebian-private

I think /dev/mapper/vm-mydebian-private is the default

this worked. thanks

Alternatively, you could use qvm-run -u root to execute command as different user (to avoid sourcing user’s configs).


Ah you’re right! I will keep this in mind for the next time.