I am a beginner to Qubes and Linux.
I created a Sys-USB and locked myself out. I am running Qubes on a NUC set up, without any PS/2 port.
I don’t think I have legacy boot. I see commands that I can press prior to the screen requesting a login, but it won’t register any inputs.
Any idea how to proceed?
I see you have already found this thread and the advice given there is sound. There are many ways for you to obtain a “LiveCD” … which means a CD or USB stick with a live Linux system you could boot into. A friend or colleague could create one for you or maybe you can by a Linux magazine … they often have such media attached to them.
Thanks. I saw the other documentation on how to create a LiveCD and used Rufus to create it according to the documentation.
When I plug in the USB, the system does not recognize it and it just skips to the screen requiring the password.
qubes.skip_autostart is the answer you seek
@alzer89 I understand his trouble to be much earlier: actually getting the computer to boot from the LiveCD system.
@rapidtest … did you press F10 and select the media when booting?
Thanks. F10 worked. Was able to select my Live USB.
Now I enter the GMU GRUB version 2.04 menu.
With several options:
Troubleshooting - verbose boot and Install Qubes
-Rescue a Qubes OS system
I could also press c for a command line
Simply add kernel parameter, on grub menu press e to edit, then add
qubes.skip_autostart in line that has
rhgb quiet, in the same line if there’s
rd.qubes.hide_all_usb delete that, then f10 to boot with this parameter.
Thank you!!! This solved it
Would the following two functions recreate the sys usb and allow keyboard to work
sudo qubesctl state.sls qvm.usb-keyboard
EDIT - Removed because it was posted in the wrong thread. My apologies for the confusion.
Yes, @Sven is right. to enter the BIOS.
@rapidtest, there isn’t really any need to do this.
What I would recommend is:
In dom0 add the following line to the file
sys-usb dom0 allow
$anyvm $anyvm deny
This means that you are telling dom0 to automatically accept keystrokes from anything that presents itself as a keyboard on any of your USB buses (including “rubber duckies”, or any other device that you plug in and tells your machine that it has keyboard functionality).
(It’s important that you fully understand what this means, and the secondary consequences of this, to prevent unnecessary avoidable self-pwnage)
After you do this, your sys-usb should function properly.
As long as sys-usb start on boot, you should be fine.
No actually it’s right thing to do to run qvm.usb-keyboard, what he don’t need is, removing current sys-usb vm.
it’s delete the
rd.qubes.hide_all_usb from grub config, and add qubes.inputkeyboard policy, then regenerate grub config. He still locked out from entering disk encryption because sys-usb not yet started.
Correct. @51lieal is right. I forgot the
rd.qubes.hide_all_usb grub kernel parameter. I knew I forgot something…
This will help many to revive broken qubes systems as I have wasted days and weeks of my time trying to revive my systems many times and nothing worked. I created sys-usb and got locked out few times. None of those instructions found in the internet worked as they may be outdated.
My system: Qubes OS 4.1.1
PC with no PS/2 mouse capability
Make a bootable USB stick of 4.1.1 for a different computer or from a friend. You can download the iso file and use Rufus tool to make that.
Boot it and enter Troubleshooting and rescue mode.
In rescue mode press 1 and it will say your system is not linux and press Enter will give you a shell. (Directly pressing 3 may also work)
Run lvdisplay command to see all the logical volumes present. (my disk is not encrypted and I can see all of them. If you have encrypted disk you may go through further steps to decrypt it 1st)
All the logical drives seem to be ‘Inactive’ and they cannot be mounted now.
Run vgchange -ay qubes_dom0 to Activate those (please check the _ or - in qubes_dom0 on the lvdisplay, forgot the actual one)
Run lvscan will show them as ‘Active’ now
Run mkdir /mnt/root
Run mount /dev/qubes_dom0/root /mnt/root
Run vi /mnt/root/etc/qubes-rpc/policies/qubes.InputKeyboard and add ‘sys-usb dom0 allow’ as the first line without the quotes
Run vi /mnt/root/etc/qubes-rpc/policies/qubes.InputMouse and add ‘sys-usb dom0 allow’ as the first line without the quotes
Open the file /etc/default/grub and find the line GRUB_CMDLINE_LINUX and remove rd.qubes.hide_all_usb in that line if present
Run grub2-mkconfig -o /mnt/root/etc/boot/grub2/grub.cfg
Item 13 and 14 may not be necessary but I did it.
Now, if you have encrypted disk you may use the following to decrypt the disk 1st and then follow the steps:
grub.cfg in 14 come from?
/mnt/root/etc/default/grub in 13?
grub2-mkconfig have effect?
Hey thank you for this instruction but I messed up a lot worst. I run my qubes on external SSD and now I am not able to even boot the system after I messed up the sys_usb
One thing that helps…provided of course you remember to do it, and sometimes I do not, is to go into the sys-usb settings and turn OFF start on system boot before starting to monkey with it. That way if you are forced to reboot at least sys-usb won’t cause a problem on restart.
Another, somewhat contradictory one is to have a cron job that (re) starts sys-usb every minute. If your difficulty stems from shutting down sys-usb by mistake or stupidity, this will solve that.
However, you should disable the cron job before monkeying with sys-usb too, or it will start sys-usb very shortly after you log in, just after you thought you were home free because you could type your password after a reboot.
The two tips probably shouldn’t be used at the same time!
Instead of a cronjob,
at could be used to schedule a
qvm-kill sys-usb in a dozen minutes, just in case.
Yes that’s another way to do it.
My cron job actually starts sys-usb just in case it accidentally gets killed (which is my favorite way to be burned by it, when I’m not actively tinkering with sys-usb).
I was dealing with two cases in my response. I realize now that wasn’t clear so I’ll give it another go. The cases are:
Just a routine day with gubes, and you accidentally shut down sys-usb. You’re frozen, but the cron job restarts it and unfreezes you without you having to reboot. In this case you WANT sys-usb to run, but it’s not running.
You do something stupid to sys-usb and now it won’t work properly, but is running and freezing you out. That’s the opposite problem; you want sys-usb NOT to run. The problem here is that just killing it never solves the problem; dom0 doesn’t resume control of keyboard and mouse (a deliberate design decision for security reasons), In that case, you pretty much have to reboot and make sure qubes doesn’t start sys-usb. Yes, there’s something you can do in the boot menu to prevent it. But, it’s easier if you just disable the startup on boot for sys-usb as a precaution–and also remove the cron job since it will fire up sys-usb for you within a minute of logging in (and there will be crying by the crashed bicycle as in the meme).
Your at scheduling of qvm-kill will stop sys-usb…but where do you go from there? Unless you did something else I am unaware of, doing so won’t re-activate your keyboard and mouse.