Keyboard and mouse frozen, cannot log in, I don't think it's sys-usb though

User Support
1

OK, it looks like I hosed myself with sys-usb, right?

Maybe not.

I have grub available in my boot.

As I understand it, if I have grub, i shouldn’t be able to decrypt the disk without first killing sys-usb.

Yet I CAN decrypt; I can enter my pass phrase. The keyboard and mouse freeze before the login.

Using the grub menu, I was told I should be able to edit the boot commands and do this:
" At the GRUB screen, hit ‘e’, then remove rd.qubes.hide_all_usb , then boot"

however this phrase appeared NOWHERE in my grub screen.

So I figured I had done something else to myself. (Especially since I had managed to boot with my sys-usb before.) I had attempted to rename sys-net and sys-firewall and had reset all the “defaults” I could find, and figured that had somehow burned me.

OK, now it gets totally wonky.

I tried rescue mode off my installation thumbdrive, but no matter what, it wouldn’t find my installation. I can’t say I’m terribly surprised; I had to create the thumb drive from a special beta-test version of Qubes in order to recognize my Nvme SDD at all; and perhaps the rescue part of it didn’t get the updates necessary to be able to see it.

I tried multiple times; I’m pretty sure I’m typing the LUKS password correctly.

So finally I took the next (and possibly fatal) step. There is an “ordinary” 2.5 inch SDD in the box, totally unused. I decided to install Qubes into it, and try to use that to recover the qubes etc from the old install.

I did do a no-frills install, but in doing so I appear to have wiped out the bootablility of the NVme SDD. I didn’t realize this at the time.

I was able to mount the entire old directory tree with this:

cryptsetup luksOpen /dev/mydevice mount_point

which I found here: After disk decryption, the screen shuts down and the computer reboots - #2 by opybsu , but was unable to figure out how to get my qubes off the old system. In fact I can’t figure out what he says he DID do after than…nvm2 is installed but doesn’t appear to be a command, vgchange doesn’t exist and sudo apt can’t find it.

Anyway, once I get all these things mounted with cryptsetup, how do I copy my qubes off that old system?

Failing that I’ll have to recreate the qube to go to some backups that are about four or five days old (and hope dom0 is among them.

2

  1. You can restore your EFI boot record by running this command from your Qubes ISO rescue terminal or from new Qubes on 2.5" SSD:
    Assuming /dev/nvme0n1 is your old Qubes drive and EFI partition number on this disk is 1.
    efibootmgr -v -c -u -L QubesOS -l /EFI/qubes/grubx64.efi -d /dev/nvme0n1 -p 1

  2. You can try to boot your old Qubes with qubes.skip_autostart option:

  1. I think you have a problem with vgchange in new Qubes if you try to mount it in dom0 since it’ll have the same default volume name qubes_dom0.
1 Like
3

In the case of the old dom0, I’d just want to get at some files on it. I don’t want to bring it over in toto.

Most of the qubes on that old system have totally different names, actually, and I could bring them over to the new one.

That assumes I cannot restore it with the other hints you have given me. But, somehow, the new install took a dump on me just now; I can;t even reinstall to that SSD, I had to swap it out. That’s in progress now.

(Yeah, I’m having a really bad day!)

It is, by the way the 20220305 installation ISO I’m using. But I suspect the rescue on it cannot see my mvne, just like the regular 4.1 ISO couldn’t.)

4

You can try to rescue your old Qubes by fixing boot record and trying to boot with qubes.skip_autostart, maybe your keyboard and mouse will work.

If you don’t want to try to restore old Qubes and just want to get some files from old Qubes and then reinstall the system then you need to attach your old Qubes LVM partition on nvme drive in new Qubes to some qube and mount your old dom0 root in this qube:

# Decrypt Qubes disk
sudo cryptsetup luksOpen /dev/xvdi qubes_dom0
# Activate decrypted LVM
sudo vgchange -ay
# Check to see if your LVM volumes are there
sudo lvs
# or
ls /dev/mapper
# If your LVM volumes are present and then you can mount Qubes dom0 root and copy files from there
mount /dev/mapper/qubes_dom0-root /mnt
5

I’m going to try to fix the old one first. (Plan A)

If I cannot, the commands you just gave will be critical reconstructing it. The files I’m talking about are scripts to create template vms, inspired largely by @sven and his minimal templates project. With those, I should be able to do a 90-95 percent reconstruction of what I had before…but again, that’s plan B.

EDIT: I’m in. Was able to reboot the nvme; renamed sys-net and sys-firewall back the way they were, deleted the one policy file I had added to point to the new name…and I disabled (for now) sys-usb even though I thought it was blameless.

Those were sufficient.

As I think back on everything, I think the Rescuer or something else on the 20200305 ISO might be what trashed the boot areas. Because the first SSD also became unbootable at one point, and I had to grab another one and install onto IT to finish this process.

1 Like