I booted up, and everything was just fine, as normal. I plugged in a USB, and had the USB ported to a qube. But I clearly clicked the wrong thing to send to the qube.
I think I clicked either the drive Qubes is installed on or the one with Arch. Either way, I couldn’t seem to reverse what I’d done, so I thought a reboot would fix things.
It didn’t lol.
Now when I boot into Qubes, I type in my encryption password, and then it reboots the whole PC. My Arch, on the other hand, boots and works just fine.
I’ve also run fdisk and nothing seems amiss.
I don’t seem to have any luck booting into Advanced Qubes either.
Sometimes you can try other kernels installed with Qubes. I’ve had a kernel upgrade and it won’t work with that. Did you already do that when you tried advanced?
I don’t know how to solve this but are you able to see error messages or show logs for the people who know more than I do?
Is there somewhere in the directory that has any logs?
Is this a dual boot? Are you able to decrypt the Qubes partition while in Arch? (This is a really bad idea for security also, since if your Arch partition is hacked it could compromise the Qubes partition, but you may not have another option.)
I’m not sure what could cause this issue for you.
You can try to boot from some trusted OS (e.g. from some Live Linux OS or Qubes OS installer), decrypt your Qubes OS disk there and check the volumes filesystem for errors using fsck:
You can also try to boot with enabled logs output:
@Pacer, any chance you can give us more specific information?
You successfully booted into Qubes OS
You inserted a USB drive (containing what, exactly? Without giving away too much information, of course….Any executables? Anything you’ve asked sys-usb to do when a usb device is plugged in?)
You then attached this USB drive to a Qube (need more information, haha)
You then installed something (again, need a lot more information)
You then rebooted your computer, and now your Qubes OS install won’t get past the LUKS decryption stage in the initramfs
Fill in the blanks with what’s missing, and we’d be happy to help you get your machine working again.
it would also be good to know if your sys-USB had access to dom0 for some reason, since it makes it more likely the contents or firmware of the USB attacked dom0