I am on Qubes 4.1.1. I pressed Ctrl+Alt+F9 on my keyboard and my screen went black. In order I pressed:
Ctrl+Alt+F9
I am having trouble remembering if I pressed Ctrl+Alt+F7, but all I remember is that when I did, my screen was already black after pressing Ctrl+Alt+F9
Ctrl+Alt+F10
Ctrl+Alt+F11
Ctrl+Alt+F12
Ctrl+Alt+Home
Ctrl+Alt+End
Ctrl+Alt+Insert
Ctrl+Alt+Delete
My computer restarted after pressing Ctrl+Alt+Delete, then I turned off my computer by pressing the power button for a few seconds.
I turned my computer back on and logged in to my computer as usual, except I was bought to a terminal. It said that my dom root was missing. It also said 2 other things were missing, which I don’t recall.
I restarted my computer again after that, but this time everything went back to normal. This time I wasn’t bought to the terminal. Instead, my computer is back to normal as if nothing happened. I want to know why this happened.
Is this a risk? Is it possible that my computer may be compromised, somehow? By some 0-day vulnerability even, that was waiting for me to press Ctrl+Alt+F9 or any other button combination I pressed? Is that even possible? I just want to know why this happened or what caused all of this to occur and knowing what each button press did.
All I did was the above, I have never let dom 0 connect to the internet since I started running Qubes OS on my computer. I downloaded Qubes from the official website, doing as the instructions said for a secure installation.
This is a standard behavior in Linux distributions. You could press Ctrl+Alt+F1 to return back to your graphical shell or Ctrl+Alt+F2-F6 to switch to a TTY.
This is useful if, for instance, on a classic Linux distribution the graphical shell crashed and one needed to restart the display server.
Are you able to reproduce this and provide us the exact messages?
@aronowski No, I am not comfortable with trying to reproduce this as I do not want to risk losing everything on my computer. I would prefer it if anyone more experienced with the Qubes operating system can help find out if this is normal or not, using the information I provided to try to reproduce it themselves, and suggest what I should do next.
As @aronowski has told you “I pressed Ctrl+Alt+F9 on my keyboard and my
screen went black” is absolutely normal behaviour, although why you
went through that list of commands is not explained.
Your computer is running different consoles - the GUI is on tty1.
When you are in the desktop, you can switch to another tty by pressing
“Ctrl+Alt+FNUMKEY”
You pressed Ctrl+Alt+F9 - that takes you to tty9.
There is nothing listening on tty9 so you got a blank screen.
If you had pressed Ctrl+Alt+F2 you would have seen tty2 where there is a
console login.
When you are already on a console tty you can switch to another by
pressing Alt+FNUMKEY
The GUI is listening on F1 so you can get back to it from a console tty
by pressing Alt+F1
Ctrl+Alt+Del is a standard combo to trigger reboot in systemd
SO this is all standard behaviour.
Since you aren’t able to say what these mysterious messages were, there’s
little more to be said.
What should you do next? Learn not to arbitrarily mash away on the
keyboard.
@aronowski@unman I tried to reproduce what happened, now knowing exactly what the buttons do and why. I was unable to.
It’s possible these were the messages:
/dev/mapper/qubes_dom0-root does not exist
/dev/qubes_dom0/root does not exist
/dev/qubes_dom0/swap does not exist
I must have been taken to the emergency dracut shell. Why did Qubes say they did not exist only for them to exist next boot when I did not do anything except reboot?
Ok, let’s say you find out why did Qubes said that. For what that info can be used in the future for you? How many times this will happen again? How would you know that exactly thee same thing happened. Even when it happens, wouldn’t you already have a solution? So…?
When computers are, many decades ago I stopped to use words IF and WHY, but instead rather WHEN and HOW respectively. Became immensely more efficient.
@enmus Your post is inappropriate considering the simple question I asked.
I asked my question to understand what happened and why Qubes did that.
You could respond with an explanation or share resources that would help me understand better, which would be appreciated like the other responses above, which are appropriate answers.
I’m trying to help you, and sorry for English is not my first language. You ask someone to explain something that happened, while even you not being able to reproduce the cause of it. So, instead your why, I’m asking, how exactly would you expect someone to know the answer and what is the value of it to the community?
Even when I’m wrong about not knowing the answer, I still think it’s wrong approach, and it’s not personal but rather general, if you read my previous post because…
such an approach is like going forward with my butt ahead: I don’t know IF I’ll crash on something, because my head is looking back where I’m coming from to check WHY the crash might or did happen.
And I could swear this is the main reason for having bugs in software at all, which means once again it wasn’t personal, but please apologize anyway.
Because the answer is either one out of two things:
If /dev/mapper/qubes_dom0-root does not exist, /dev/qubes_dom0/root does not exist, /dev/qubes_dom0/swap does not exist and suddenly reappears, and if it’s supposed to be impossible for the system to do that, then that means my system is compromised and switched with another dom0-root, root and swap.
If /dev/mapper/qubes_dom0-root does not exist, /dev/qubes_dom0/root does not exist, /dev/qubes_dom0/swap does not exist and suddenly reappears, and is normal for the Qubes system, then my system is not compromised and this is just Qubes doing what it was programmed to do. I would also like to know how Qubes can even replace /dev/mapper/qubes_dom0-root, /dev/qubes_dom0/root, and /dev/qubes_dom0/swap, because if they were said to be missing, then how were they replaced? If not, then I would like to know if Qubes just said they were “missing” when they actually weren’t and why it would do that.
I just need a person experienced with Qubes to tell me which answer it is, 1 or 2?
You probably know for that to happen either someone has to have physical access to your computer, or there’s some very serious Xen bug not yet discovered. So, no one of us can answer to this, obviously (yet).
There could be tens of tens reasons this to happen, starting from faulty hardware. And I could bet (and probably you too) that Qubes is not programmed to do this.
Now, that I find the proper question it could be answered.
Wrong. they were missing as you claimed, so: “when they were missing”
I honestly doubt a question put in such a way can be properly answered.
Qubes is not supposed to replace /dev/mapper/qubes_dom0-root, /dev/qubes_dom0/root, /dev/qubes_dom0/swap if they are missing? Are you sure? Because my system is back to normal, so I want to know why it said that in the first place. So there has to be a reason why they didn’t “exist” then started to exist again after.
I got an answer for what the button combinations did. That does not explain the second question I asked.
If Qubes is not programmed to replace /dev/mapper/qubes_dom0-root, /dev/qubes_dom0/root, and /dev/qubes_dom0/swap which were said to not exist, then why is my system back to normal? If they truly didn’t exist, my system should have stayed the way it was. So I ask, does Qubes fix this within the system itself? That would explain why my system returned back to normal, given it’s not some advanced threat.
I understand now that Ctrl+Alt+Delete is a combo to trigger a reboot in systemd.
I was bought to the emergency dracut shell. The messages:
/dev/mapper/qubes_dom0-root does not exist
/dev/qubes_dom0/root does not exist
/dev/qubes_dom0/swap does not exist
The question I want to answer now is: why did /dev/mapper/qubes_dom0-root, /dev/qubes_dom0/root, and /dev/qubes_dom0/swap not exist for one reboot, only for them to exist next reboot and let me use my system? If they truly did not exist, my system should not have went back to normal as it is now.