Qubes OS does not reboot

[qubist]

Hi,

Ever since installing Qubes OS I have been unable to reboot it (even right at the end of the installation). What happens when I initiate a reboot is: the computer starts to shutdown and at the end of the process the monitor says there is no DPMI signal. There is no reboot and no power off. The computer remains in some unresponsive powered on state and the only way to restart it is to power it down by pressing the power button for 5 seconds and then power it on again. I was hoping that an update would fix it but unfortunately it doesn’t. Shutdown and suspend work fine.

To make sure it is not a hardware issue I booted the machine with a Live openSUSE system and reboot works fine with it.

I looked at the final lines of dom0’s journal:

systemd[1]: systemd-reboot.service: Succeeded.
systemd[1]: Finished Reboot.
systemd[1]: Reached target Reboot.
systemd[1]: Shutting down.
audit: BPF prog-id=0 op=UNLOAD
audit: BPF prog-id=0 op=UNLOAD
systemd-shutdown[1]: Syncing filesystems and block devices.
systemd-shutdown[1]: Syncing SIGTERM to remaining processes...
systemd-journald[923]: Journal stopped
-- Reboot --

How can I diagnose and fix this issue, please?

[HPOA909]

Did you remove the ext4 during the disk clensing process?

[qubist]

No idea what you are talking about.
What is that disk clensing process?

[HPOA909]

During the installation process, did you accidentally removed the ext4 during the disk wipeout session?

[alzer89]

@qubist, that’s very peculiar. I have encountered a similar thing on Qubes 4.0 on a 2010 MacBook Air.

Any chance of getting some into about your hardware and kernel version that you’re running? That will help narrow it down to the OS, systemd, the kernel, or the BIOS.

If I had to guess without knowing your hardware, I would imagine that a “hacky” fix would be to introduce a kernel reboot (reboot -f) added as a systemd service after the reboot service was successfully completed might force a power cycle and reboot your machine.

If that’s the case, I will take you through the steps to write a systemd service file to do just that.

[qubist]

During the installation process, did you accidentally removed the ext4 during the disk wipeout session?

The whole drive was formatted and managed by the installation itself. I am new to Qubes OS, so I did not use any custom or expert installation mode.

Any chance of getting some into about your hardware and kernel version that you’re running? That will help narrow it down to the OS, systemd, the kernel, or the BIOS.

That’s a NitroPC with 64 GiB of RAM and a 1TB Samsung 970 Pro NVMe drive.
I installed Qubes OS 4.1.0 and updated everything. The kernel version is 5.15.52-1.fc32 and systemd is 245.9-1.fc32.

I tested reboot -f in tty2 but the result is the same overall. The small difference is that the “shutdown” is almost instant (I don’t see any console messages at all) and after I power off and boot the system myself, I don’t see the journal messages mentioned initially. The last lines shown in the log say:

su[6797]: pam_unix(su-l:session): session opened for user root by user(uid=0)
audit[6797]: USER_START pid=6797 uid=0 auid=1000 ses=4 msg='op=PAM:session open grantors=pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask,pam_xauth acct="root" exe="/usr/bin/su" hostname=dom0 addr=? terminal=tty2 res=success'
-- Reboot --

[alzer89]

@HPOA909, yeah, what you said about “removing the ext4” is a little unclear what you mean exactly. Is there any chance you could clarify what you mean?

Do you mean:

• zeroing out the drive before installation?
  • That shouldn’t make a difference. The Qubes OS standard installer won’t zero out the drive, because that would shorten the lifespan of an SSD
• removing the ext4 label from the partition when formatting the drive?
  • That also should be done automatically when you install, unless you try something complex like dual-booting
• something else?
  • Please explain. Happy to explore any suggestions

—-

I’ve never been lucky enough to get my hands on a NitroPC to play around with it, so I can’t say for certain that “skipping a step” in the installation wouldn’t interact with NitroKey’s BIOS.

It’s highly unlikely, to be honest, but I don’t want to just “saying anything without any evidence”, because that doesn’t really help anyone….

—-

@qubist, the fact that you’re able to read system logs tells me that you’re fairly familiar with Linux, which is good, because we can skip the long paragraphs I normally have to write (thank you!)

Maybe it might be worth contacting NitroKey and asking them what’s going on. It’s possible that you might have a small hardware defect (unlikely, but possible, and it can’t hurt contacting them just to confirm ).

The other possibility is that it might be worth seeing what the latest kernel build does when you try to reboot it.

If you’re comfortable with running a Qubes OS-patched Linux kernel 5.18.9 or newer in your dom0 (there isn’t really any reason why, but you never know, some people might not want to…), then type this command into a dom0 terminal:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing kernel-latest kernel-latest-qubes-vm

That will download RPM packages for kernel version 5.18.14 (I think we’re at that version now….) as a don0 and another package for the same version as an AppVM kernel.

(You can select your kernel at boot with GRUB like you’re probably familiar with, and select the AppVM kernel in the Qube Settings, too. And of course, you can also purge them from your system later if you wish…)

If that doesn’t solve it, well, maybe adding an extra systemd service at the very end to power cycle your machine might work (I’ll write that up in a minute so you can just copy and paste. It’s not something that’s easy to type up without sitting down at a proper keyboard😋)

Your other option is to “live with it”. But i don’t feel that’s a valid solution, and I wouldn’t want you to do that!

[HPOA909]

I cannot explain too much for you, but the way that many people cannot understand these pro words as they didn’t know about computer as they did in the 1990s. I will pin these pros for the explanation. Also, any new evidence?

@Sven Maybe you can help me to explain to this user

[alzer89]

@HPOA909

I cannot explain too much for you

I really hope you can clarify, because we’re trying to help @qubist…

@HPOA909

the way that many people cannot understand these pro words as they didn’t know about computer as they did in the 1990s

Yes, I understand this, and this definitely drives me crazy at the best of times.

But @qubist appears to be well-versed in Linux, and I most definitely am, and we are both having trouble figuring out what you mean.

I’m definitely not saying that you don’t know what you’re talking about. You may very well have given the correct solution to @qubist’s problem. But any solution isn’t very useful if it can’t be understood…

So what do you actually mean when you say:

@HPOA909

During the installation process, did you accidentally removed the ext4 during the disk wipeout session?

[HPOA909]

QubesOS freeze, crash and reboots

Have you tried CTRL + ALT + F4 to open the xTerm and come back with CTRL + ALT + F1 ?

[qubist]

@HPOA909 what is the relation between the current topic and the link you give? I hope you can clarify as I am definitely not experiencing any crashes, freezes or reboots. Especially reboots

Re. that disk clensing you mentioned earlier, I wonder how this can be related too. As I said, I am using Automatic installation mode (I have re-installed multiple times already). From the very beginning it has been the way I do it. This means that even when the NVMe drive was brand new (out of the box) the installation itself manages the process of partitioning, formatting and everything else involved in the Automatic installation mode. The only “clensing” that I do when reinstalling is to “Delete all” to free the whole drive for the purpose of installation.

[qubist]

More info:

I am experiencing the inability to reboot even during the installation itself. Even in the very first step of the installation process (language selection), if I simply click Quit and confirm, the system does not reboot and does not shutdown. It just goes into that same unresponsive powered on state which needs manual power off/on.

I wonder if the specifics of the hardware may require certain kernel boot time parameter(s) or anything along these lines, as it does not look related to file systems at all.

What do you guys think?

[alzer89]

@qubist

I wonder if the specifics of the hardware may require certain kernel boot time parameter(s) or anything along these lines, as it does not look related to file systems at all.

No, it has nothing to do with filesystems at all, unles systemd is stuck unmounting them. But that systemd service should be on a 3-minute timer, and should lazily unmount it if the timer expires, anyway. You said your machine is able to shut down properly, so I’d be surprised if that was the case…

---

@qubist There is potentially one way to get your system to reboot, but it’s a little “hacky”, and not very elegant

Step 1: Open a dom0 terminal and become root

sudo su -

Step 2: Create a text file at /usr/local/bin/force-reboot.sh. If you don’t have a preference for which text editor you use, just type this in:

vim /usr/local/bin/force-reboot.sh

Step 3: Type the following verbatim into the text file:

#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

DISCLAIMER: This is the equivalent of “pulling the plug” and having the kernel force a power cycle. This will not “gracefully” power down your computer (sync and unmount your drives, save your work, etc.), so if you decide to type this into a terminal, it’s probably not a good idea to have anything open when you do…

Step 4: Make sure /usr/local/bin/force-reboot.sh is executable:

chmod _+x /usr/local/bin/force-reboot.sh

Step 5: Type in the following command (unless you want to find the file and type it in manually):

echo "ExecStop=/usr/local/bin/force-reboot.sh" >> /usr/lib/systemd/system/systemd-journald.service

This tells systemd to run this script when the systemd-journal stops.

Step 6: Test a reboot:

reboot

[rustybird]

@qubist

I wonder if the specifics of the hardware may require certain kernel boot time parameter(s) or anything along these lines, as it does not look related to file systems at all.

Try the reboot=acpi Xen (not kernel) parameter:

Don't use EFI_RUNTIME_SERVICES->Reboot

[qubist]

@alzer89 thanks for this but I really don’t want to “pull the plug”. I hope to have a graceful way to reboot.

@rustybird you say not kernel but Xen parameter. This is the first time I am using Xen. How/where should I set that Xen parameter?

[rustybird]

@qubist

How/where should I set that Xen parameter?

Inside the GRUB_CMDLINE_XEN_DEFAULT variable in /etc/default/grub. Then regenerate grub.cfg; for EFI boot that would be:

sudo grub2-mkconfig -o /boot/efi/EFI/qubes/grub.cfg

After the next start, you can verify it’s being used:

xl info xen_commandline

[alzer89]

@qubist

thanks for this but I really don’t want to “pull the plug”. I hope to have a graceful way to reboot.

I 100% agree, and hopefully you don’t have to use this. @rustybird’s solution should work nicely.

You’ll have to forgive me. I’m not used to buying “mainstream” hardware that likes to play nice with me…

[qubist]

@rustybird - this works! Thank you!
@alzer89 - thank you too

[fsflover]

@qubist

@rustybird - this works! Thank you!

You could mark the reply as “Solution” to help other users with the same problem.

[qubist]

Marked.
Thanks.