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?
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.