Qube OS doesn't shutdown properly

Hello,

I’ve been using Qubes OS for 1 week and i’m having a problem shutting down my computer. I use the classic procedure of going to the taskbar menu and clicking on “shutdown”. The screen goes black with a white stripe at the bottom, but the PC continues to run. I have to keep pressing the on/off button on my computer for it to shutdown.

here’s my configuration :

Brand: MSI
Model: MS-7978

CPU: Intel(R) Core™ i5-6600 CPU @ 3.30GHz
Chipset: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [8086:191f] (rev 07)
Graphics: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1) (prog-if 00 [VGA controller])

RAM: 24522 Mb

QubesOS version: R4.2.3
BIOS: B.C0
Kernel: 6.6.48-1
Xen: unknown

Does anyone have any leads ?

Thanks.

This solution might help, see the final post:

Thanks,

I had seen this topic but I have no idea what the tpm in question is. I’ll keep looking.

The TPM is a chip on your computer that helps protect against physical attacks. As I understand it, moving to 1.2 would require reflashing the firmware but I’m not 100% sure because I’ve never had to deal with this personally. Reflashing can be a dangerous process if you don’t know what you’re doing. If there’s a computer repair shop you trust nearby they might be able to help you.

But before going through all that trouble you can check your current TPM version by opening the Qubes menu, clicking on the gear icon (final icon in the left column) and opening “Qubes Global Config” from the “Qubes Tools” submenu (I tried to take a screenshot but pressing prtscr on my keyboard causes the menu to disappear :slightly_frowning_face:). Unde the “This Device” tab (near the bottom-left of the window) there will be a “Qubes OS Security Report” section where your TPM version will be listed.

Thanks for your answers.

I found the options concerning TPM in my bios.

I’ve already tweaked it but i didn’t take notes on what i did noob that i am.

I did find the menu you’re talking about in Qubes OS and the TPM field says : Device not found. Probably because the “Security Device Support” option in my bios is now set to “Disabled”.

I’ll have to investigate further to find out which option does what, and then maybe i’ll know if the problem really related to TPM.

You can press Esc key at this screen:

It should show you the shutdown log and you can check where is it stuck at.
If you still won’t see the log then maybe you’ll have to remove rhgb quiet and add plymouth.enable=0 kernel command line options in GRUB to show the log.

I’ve tried pressing the Esc key but nothing happens.

I’ve managed to get some logs from dom0 juste after booting, but I don’t think there’s any information there that’s relevant to this problem. But i may be mistaking.

I’ll try to apply your changes in the Grub when I’ve figured out how to do it :-).

This seems to be the Xen log, there is no relevant info there.
Check the dom0 log using journalctl command.

I’ve tested it and the kernel command line options should show you the shutdown log.

Hi again.

Thank you for spending time with me.

I think I’ve found the logs :

There do seem to be some errors towards the end.

I imagine that the following line corresponds to the moment when I press the on/off button on my PC to turn it off.
oct. 21 23:27:02 dom0 systemd-logind[2739]: System is powering down.

This could be related:

qubesd[2981]: socket.send() raised exception.

System shutdown hang · Issue #1581 · QubesOS/qubes-issues · GitHub

But I’m not sure.
Set the kernel command line options and try to shutdown with them to see the shutdown log, maybe you’ll see the relevant log because after this line:

 oct. 21 23:27:02 dom0 systemd-logind[2739]: System is powering down.

The log is not written to the disk anymore but you should be able to see it on the screen.

I made the changes in the grub conf file.
I can see the logs when QubesOS is shut down.
However, I only have one line concerning the shutdown:

[168.379633] audit: type=1131 audit(1729882470.077:364): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump00-5720-0 comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’emd-update-utmp

If a can trust Mistral AI, this line says that it’s all fine lol.

Edit : the computer finally stopped while I was copying and writing my reply…
I’m going to reset the grub conf file to its original state and run another test.

There seems to be a crash somewhere but you need to check the log before and after this line to know what crashed.

Try to shutdown all the qubes before powering down the system and see if it’ll hang or not.

I find this in the log from journalctl :

oct. 25 21:21:37 dom0 systemd[1]: lightdm.service: Processes still around after final SIGKILL. Entering failed mode.
oct. 25 21:21:37 dom0 systemd[1]: lightdm.service: Failed with result ‘timeout’.
oct. 25 21:21:37 dom0 systemd[1]: lightdm.service: Unit process 11191 (Xorg) remains running after unit stopped.
oct. 25 21:21:37 dom0 systemd[1]: Stopped lightdm.service - Light Display Manager.
oct. 25 21:21:37 dom0 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg=‘unit=lightdm comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=failed’
oct. 25 21:21:37 dom0 kernel: audit: type=1131 audit(1729884097.536:502): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=‘unit=lightdm comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=failed’
oct. 25 21:21:37 dom0 systemd[1]: lightdm.service: Triggering OnFailure= dependencies.
oct. 25 21:21:37 dom0 systemd[1]: Requested transaction contradicts existing jobs: Transaction for plymouth-quit.service/start is destructive (systemd-modules-load.service has ‘stop’ job queued, but ‘start’ is included in transaction).
oct. 25 21:21:37 dom0 systemd[1]: lightdm.service: Failed to enqueue OnFailure= job, ignoring: Transaction for plymouth-quit.service/start is destructive (systemd-modules-load.service has ‘stop’ job queued, but ‘start’ is included in transaction).
oct. 25 21:21:37 dom0 systemd[1]: lightdm.service: Consumed 1min 1.364s CPU time.
oct. 25 21:21:37 dom0 systemd[1]: plymouth-poweroff.service - Show Plymouth Power Off Screen was skipped because of a failed condition check (ConditionKernelCommandLine=!plymouth.enable=0).
oct. 25 21:21:37 dom0 systemd[1]: Starting plymouth-switch-root-initramfs.service - Tell Plymouth To Jump To initramfs…
oct. 25 21:21:37 dom0 systemd[1]: Stopping systemd-user-sessions.service - Permit User Sessions…
oct. 25 21:21:37 dom0 systemd[1]: Finished plymouth-switch-root-initramfs.service - Tell Plymouth To Jump To initramfs.

Maybe it’s related.

I try a shutdown of all qubes before extinction and look at the logs.

There’s too much I don’t understand, it’s starting to exhaust me. I’m going to give up soon :slight_smile:

Post the log before this message as well to know what happened with Xorg/lightdm:

oct. 25 21:21:37 dom0 systemd[1]: lightdm.service: Processes still around after final SIGKILL. Entering failed mode.

Probably you have some issue with NVIDIA driver.

There the full log before :

oct. 25 21:21:37 dom0 systemd[1]: lightdm.service: Processes still around after final SIGKILL. Entering failed mode.

i found this with journalctl -u lightdm -ex :

oct. 25 21:21:37 dom0 systemd[1]: lightdm.service: Triggering OnFailure= dependencies.
oct. 25 21:21:37 dom0 systemd[1]: Requested transaction contradicts existing jobs: Transaction for plymouth-quit.service/start is destructive (systemd-modules-load.service has ‘stop’ job queued, but ‘start’ is included in transaction).
oct. 25 21:21:37 dom0 systemd[1]: lightdm.service: Failed to enqueue OnFailure= job, ignoring: Transaction for plymouth-quit.service/start is destructive (systemd-modules-load.service has ‘stop’ job queued, but ‘start’ is included in transaction).

It seems i have some issues concerning Xorg who remains running and some dependencies.

Qubes os stops after 7min after requesting power-off.

Edit : i tried sudo dnf update xorg-x11-server-Xorg

Qubes OS Repository For Dom0
Dependencies resolved.
Nothing to do.
Done!

Nothing change

Research into the problem of dependencies :
sudo systemctl list-dependencies lightdm

Is this a log of the Qubes OS shutdown when you manually shutdown all qubes including sys-* qubes before shutting down the Qubes OS?
Because I see in the log the messages indicating that the sys-* qubes are still running:

oct. 25 21:21:02 dom0 qrexec[14069]: qubes.WindowIconUpdater+: sys-whonix -> @adminvm: allowed to dom0
oct. 25 21:21:02 dom0 qrexec[14070]: qubes.WindowIconUpdater+: sys-firewall -> @adminvm: allowed to dom0
oct. 25 21:21:02 dom0 qrexec[14086]: qubes.WindowIconUpdater+: sys-net -> @adminvm: allowed to dom0
oct. 25 21:21:02 dom0 qrexec[14088]: qubes.WindowIconUpdater+: sys-usb -> @adminvm: allowed to dom0

Um, I don’t think I’d stopped the qubes manually there. I’m starting to get mixed up in what I’ve done. I’m starting from scratch log-wise.

I just stopped all qubes except :

  • Dom0
  • sys-usb because otherwise I lose the use of the mouse and keyboard.

Here are the logs:

Searching for the term “Entering failed mode”, we see on the previous line that there are only “sys-usb”

oct. 26 16:30:02 dom0 qrexec[20886]: qubes.WindowIconUpdater+: sys-usb → @adminvm: allowed to dom0
oct. 26 16:31:07 dom0 systemd[1]: lightdm.service: State ‘final-sigterm’ timed out. Killing.
oct. 26 16:31:07 dom0 systemd[1]: lightdm.service: Killing process 20627 (Xorg) with signal SIGKILL.
oct. 26 16:32:02 dom0 qrexec[21363]: qubes.WindowIconUpdater+: sys-usb → @adminvm: allowed to dom0

On a positive note, I’m learning to be more precise in my commands with: journalctl --since “2024-10-26 16:27:00” > logs_20241026.txt

If you think you need something more specific, don’t hesitate to ask. I’ll try to be less messy. I’ll have to make a cleaner post again, I’ve made a mess here.