[qubes-users] Failed to shutdown or suspend. Help

Hi, for more than two months, qubes-os has not completed the shutdown and has not entered into suspension. To turn it off, I must necessarily hold down the power button.

further details:

  1. after shutdown, at the end of the loading bar (which I didn’t remember being there) the computer remains on.

  2. The “sata operation mode” setting in the bios has been changed from Rapid to Ahci. Could it be the cause?

For me it is a very important problem, I do not find anything in the log files that allow me to understand and solve the problem.

Thanks to those who want to help me.

ioko8:

Hi, for more than two months, qubes-os has not completed the shutdown and
has not entered into suspension. To turn it off, I must necessarily hold
down the power button.

further details:
1. after shutdown, at the end of the loading bar (which I didn't remember
being there) the computer remains on.

2. The "sata operation mode" setting in the bios has been changed from
Rapid to Ahci. Could it be the cause?

For me it is a very important problem, I do not find anything in the log
files that allow me to understand and solve the problem.

Thanks to those who want to help me.

In a dom0 terminal, check sudo journalctl. Look for messages just before
your most recent bootup. Also check /var/log/xen/console/hypervisor.log*
for same.

thanks for your help awokd,

from the analysis on the logs made days ago, it seems that this is a bug on the new kernel version 4.19, in fact from the journalctl there is an error on the unmounting of the encrypted disk:
“dom0 systemd-cryptsetup [9169]: Failed to deactivate: Device or resource busy”
I think this could be the cause, also because I found several references on the internet.
Honestly, I don’t know if the disc is disassembled even with suspension.
It seems that some have also solved by putting acpi = force on the bootloader, but having no devices to do an alternative booting I am reluctant to change the bootloader options.
If I had a key combination to change boot options, as in all other linux distributions, I would certainly do a lot more testing. Like for example I don’t know why I have the iommu = no-igfx option since I use the integrated graphics of the intel cpu.

If it was really the fault of not unmounting the encrypted volume, what could I do …

other errors on the journalctl at the same time:

dom0 libvirtd [2776]: 2020-09-17 01: 56: 27.338 + 0000: 2802: error: virPCIDeviceReset: 1002: internal error: Unable to reset PCI device 0000: 00: 14.0: no FLR, PM reset or bus reset available

Sep 17 03:57:12 dom0 systemd-cryptsetup [9169]: Failed to deactivate: Device or resource busy
Sep 17 03:57:12 dom0 systemd [1]: systemd-cryptsetup @ luks \ x2d625d19ea \ x2d61d4 \ x2d408f \ x2daec8 \ x2d25f759724841.service: Control process exited, code = exited status = 1
Sep 17 03:57:12 dom0 systemd [1]: Stopped Cryptography Setup for luks-625d19ea-61d4-408f-aec8-25f759724841.
Sep 17 03:57:12 Sun0 kernel: kauditd_printk_skb: 40 callbacks suppressed
Sep 17 03:57:12 dom0 kernel: audit: type = 1130 audit (1600307832.579: 310): pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = systemd-cryptsetup @ luks \ x2d625d19ea \ x2d61d4 \ x2d408f \ x2daec8 \ x2d25f759724841 comm = “systemd” exe = “/ usr / lib / systemd / systemd” hostname =? addr =? terminal =? res = failed ’
Sep 17 03:57:12 dom0 audit [1]: SERVICE_START pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = systemd-cryptsetup @ luks \ x2d625d19ea \ x2d61d4 \ x2d408f \ x2daec897 "system comm = x224d41f “exe =” / usr / lib / systemd / systemd "hostname =? addr =? terminal =? res = failed ’
Sep 17 03:57:12 dom0 systemd [1]: systemd-cryptsetup @ luks \ x2d625d19ea \ x2d61d4 \ x2d408f \ x2daec8 \ x2d25f759724841.service: Unit entered failed state.
Sep 17 03:57:12 dom0 systemd [1]: systemd-cryptsetup @ luks \ x2d625d19ea \ x2d61d4 \ x2d408f \ x2daec8 \ x2d25f759724841.service: Failed with result ‘exit-code’.
Sep 17 03:57:12 sun0 systemd [1]: Reached target Unmount All Filesystems.
Sep 17 03:57:12 dom0 systemd [1]: Removed slice system-systemd \ x2dcryptsetup.slice.
Sep 17 03:57:12 sun0 systemd [1]: Reached target Shutdown.
Sep 17 03:57:12 sun0 systemd [1]: Reached target Final Step.
Sep 17 03:57:12 dom0 systemd [1]: Starting Power-Off …
Sep 17 03:57:12 sun0 systemd [1]: Shutting down.
Sep 17 03:57:12 dom0 systemd-shutdown [1]: Sending SIGTERM to remaining processes …
Sep 17 03:57:12 dom0 dmeventd [1586]: dmeventd detected break while being idle for 4 second (s), exiting.
Sep 17 03:57:12 sun0 dmeventd [1586]: dmeventd shutting down.
Sep 17 03:57:12 sun0 systemd-journald [1569]: Journal stopped

thank

vin cen zo:

Forgot to respond to your other question in the previous email- I don't
think SATA controller going to ACPI would cause the shutdown problem,
but it could be a quick test to change it back to RAID mode and see. Put
back on ACPI if it doesn't help.

It seems that some have also solved by putting acpi = force on the
bootloader, but having no devices to do an alternative booting I am
reluctant to change the bootloader options.

No USB port? Should be able to boot into Rescue mode from the Qubes
installer, or from some other live CD on a USB drive. This would let you
edit bootloader options more safely. Trying acpi=force is a good idea.

If I had a key combination to change boot options, as in all other linux
distributions, I would certainly do a lot more testing. Like for example I
don't know why I have the iommu = no-igfx option since I use the integrated
graphics of the intel cpu.

Intel integrated graphics don't play well with iommu, so that boot
option disables it.

If it was really the fault of not unmounting the encrypted volume, what
could I do ..

I don't think that's it, because it continues on through to this point:

Sep 17 03:57:12 sun0 systemd [1]: Reached target Unmount All Filesystems.
Sep 17 03:57:12 dom0 systemd [1]: Removed slice system-systemd \
x2dcryptsetup.slice.
Sep 17 03:57:12 sun0 systemd [1]: Reached target Shutdown.
Sep 17 03:57:12 sun0 systemd [1]: Reached target Final Step.
Sep 17 03:57:12 dom0 systemd [1]: Starting Power-Off ...
Sep 17 03:57:12 sun0 systemd [1]: Shutting down.
Sep 17 03:57:12 dom0 systemd-shutdown [1]: Sending SIGTERM to remaining
processes ...
Sep 17 03:57:12 dom0 dmeventd [1586]: dmeventd detected break while being
idle for 4 second (s), exiting.
Sep 17 03:57:12 sun0 dmeventd [1586]: dmeventd shutting down.
Sep 17 03:57:12 sun0 systemd-journald [1569]: Journal stopped

And journal stops cleanly at this point so it looks like dom0 is
shutting down successfully. This points to a Xen issue. How about
messages in those hypervisor.log* files? Might not be any messages if
filesystems are already unmounted by the time it encounters a problem.

test to change it back to RAID mode and see. Put back on ACPI if it doesn’t help.

I tried to set up rapid (rst raid) but nothing has changed

Trying acpi = force is a good idea.

tried, but it didn’t help.

Actually this problem arose before this summer when I had to change the cpu fan and on the next restart I had the bios reset. This was in conjunction with the kernel version upgrade.
In fact I had to put ahci settings back on sata-operetion-mode and reselect the efi boot file.

for suspension is essential, the last step will be reinstallation.

Thanks for your ever present help.

sudo cat /proc/cmdline
root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-625d19ea-61d4-408f-aec8-25f759724841 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 rhgb quiet acpi=force rd.qubes.hide_all_usb plymouth.ignore-serial-consoles rd.qubes.hide_pci=02:00.0 modprobe=xen-pciback.passthrough=1 xen-pciback.permissive xen-pciback.hide=(02:00.0)

sudo efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0001,0002,0000,0003,0004
Boot0000* xen HD(1,GPT,3a4fdaa2-0a2c-4783-ba2a-59a408c24c1c,0x800,0x64000)/File(\EFI\QUBES\XEN.EFI)
Boot0001* P0: Samsung SSD 850 PRO 256GB BBS(16,0x0)AMBO
Boot0002* Atheros Boot Agent BBS(20,0x0)AMBO
Boot0003* UEFI: Network Card PciRoot(0x0)/Pci(0x1c,0x5)/Pci(0x0,0x0)/MAC(e0db55a2173f,0)/IPv4(0.0.0.0:0<->0.0.0.0:0,0,0)AMBO
Boot0004* UEFI: Network Card PciRoot(0x0)/Pci(0x1c,0x5)/Pci(0x0,0x0)/MAC(e0db55a2173f,0)/IPv6([::]:<->[::]:,0,0)AMBO
[k8@dom0 0000:02:00.0]$

sudo cat /proc/acpi/wakeup
Device S-state Status Sysfs node
P0P1 S4 *disabled
USB1 S3 *disabled
USB2 S3 *disabled
USB3 S3 *disabled
USB4 S3 *disabled
USB5 S3 *disabled
USB6 S3 *disabled
USB7 S3 *disabled
RP01 S4 *disabled pci:0000:00:1c.0
PXSX S4 *disabled
RP02 S4 *disabled
PXSX S4 *disabled
RP03 S4 *disabled
PXSX S4 *disabled
RP04 S4 *disabled pci:0000:00:1c.3
PXSX S4 *disabled pci:0000:07:00.0
RP05 S0 *disabled
PXSX S4 *disabled
RP06 S4 *disabled pci:0000:00:1c.5
PXSX S4 *disabled pci:0000:09:00.0
RP07 S4 *disabled
PXSX S4 *disabled
RP08 S4 *disabled
PXSX S4 *disabled
PEG0 S4 *disabled pci:0000:00:01.0
PEGP S4 *disabled pci:0000:02:00.0
PEGA S4 *disabled
PEG1 S4 *disabled
PEG2 S4 *disabled
PEG3 S4 *disabled
XHC S4 *disabled pci:0000:00:14.0
HDEF S4 *disabled pci:0000:00:1b.0
EHC2 S0 *disabled pci:0000:00:1a.0
EHC1 S0 *disabled pci:0000:00:1d.0
LID0 S3 *enabled platform:PNP0C0D:00

sudo dmesg |grep -2i acpi
[ 0.000000] Linux version 4.19.142-1.pvops.qubes.x86_64 (user@build-fedora4) (gcc version 6.4.1 20170727 (Red Hat 6.4.1-1) (GCC)) #1 SMP Sat Aug 29 19:54:26 UTC 2020
[ 0.000000] Command line: root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-625d19ea-61d4-408f-aec8-25f759724841 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 rhgb quiet acpi=force rd.qubes.hide_all_usb plymouth.ignore-serial-consoles rd.qubes.hide_pci=02:00.0 modprobe=xen-pciback.passthrough=1 xen-pciback.permissive xen-pciback.hide=(02:00.0)
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: ‘x87 floating point registers’
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: ‘SSE registers’

journalctl -b -3|grep -i error
Sep 17 12:17:56 dom0 kernel: RAS: Correctable Errors collector initialized.
Sep 17 12:18:18 dom0 kernel: platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
Sep 17 12:18:23 dom0 libvirtd[1915]: 2020-09-17 10:18:23.083+0000: 1961: error : virConnectOpenInternal:1118 : no connection driver available for qemu:///system
Sep 17 12:18:25 dom0 libvirtd[1915]: 2020-09-17 10:18:25.778+0000: 1946: error : virPCIDeviceReset:1002 : internal error: Unable to reset PCI device 0000:00:14.0: no FLR, PM reset or bus reset available
Sep 17 12:19:17 dom0 lightdm[3167]: Could not chown user data directory /var/lib/lightdm-data/k8: Error creating directory /var/lib/lightdm-data/k8: File exists
Sep 17 23:30:44 dom0 qubes.WindowIconUpdater-sys-firewall[3502]: xcffib.ConnectionException: xcb connection errors because of socket, pipe and other stream errors.
Sep 17 23:30:44 dom0 qubes.WindowIconUpdater-sys-firewall[3502]: xcffib.ConnectionException: xcb connection errors because of socket, pipe and other stream errors.
Sep 17 23:30:44 dom0 qubes.WindowIconUpdater-sys-net[3512]: xcffib.ConnectionException: xcb connection errors because of socket, pipe and other stream errors.
Sep 17 23:30:44 dom0 qubes.WindowIconUpdater-sys-net[3512]: xcffib.ConnectionException: xcb connection errors because of socket, pipe and other stream errors.
Sep 17 23:30:44 dom0 qubes.WindowIconUpdater-deby[3815]: xcffib.ConnectionException: xcb connection errors because of socket, pipe and other stream errors.
Sep 17 23:30:44 dom0 qubes.WindowIconUpdater-deby[3815]: xcffib.ConnectionException: xcb connection errors because of socket, pipe and other stream errors.
Sep 17 23:30:58 dom0 libvirtd[1915]: 2020-09-17 21:30:58.376+0000: 6590: error : virPCIDeviceReset:1002 : internal error: Unable to reset PCI device 0000:00:14.0: no FLR, PM reset or bus reset available

sudo journalctl -b -3|grep -i failed
Sep 17 12:17:56 dom0 kernel: tsc: Fast TSC calibration failed
Sep 17 12:17:56 dom0 kernel: PM-Timer failed consistency check (0xffffff) - aborting.
Sep 17 12:18:18 dom0 kernel: platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
Sep 17 12:18:18 dom0 kernel: cfg80211: failed to load regulatory.db
Sep 17 12:19:11 dom0 audit[3232]: USER_AUTH pid=3232 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:authentication grantors=? acct=“k8” exe=“/usr/sbin/lightdm” hostname=? addr=? terminal=:0 res=failed’
Sep 17 12:19:11 dom0 kernel: audit: type=1100 audit(1600337951.456:129): pid=3232 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:authentication grantors=? acct=“k8” exe=“/usr/sbin/lightdm” hostname=? addr=? terminal=:0 res=failed’
Sep 17 12:19:13 dom0 audit[3232]: USER_LOGIN pid=3232 uid=0 auid=4294967295 ses=4294967295 msg=‘op=login acct=“k8” exe=“/usr/sbin/lightdm” hostname=dom0 addr=? terminal=/dev/tty1 res=failed’
Sep 17 12:19:13 dom0 kernel: audit: type=1112 audit(1600337953.492:130): pid=3232 uid=0 auid=4294967295 ses=4294967295 msg=‘op=login acct=“k8” exe=“/usr/sbin/lightdm” hostname=dom0 addr=? terminal=/dev/tty1 res=failed’
Sep 17 12:19:21 dom0 qui-updates[3445]: gdk_window_thaw_toplevel_updates: assertion ‘window->update_and_descendants_freeze_count > 0’ failed
Sep 17 23:31:09 dom0 lvmetad[766]: Failed to accept connection errno 11.
Sep 17 23:31:14 dom0 systemd-cryptsetup[7614]: Failed to deactivate: Device or resource busy
Sep 17 23:31:14 dom0 kernel: audit: type=1130 audit(1600378274.172:331): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=‘unit=systemd-cryptsetup@luks\x2d625d19ea\x2d61d4\x2d408f\x2daec8\x2d25f759724841 comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=failed’
Sep 17 23:31:14 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg=‘unit=systemd-cryptsetup@luks\x2d625d19ea\x2d61d4\x2d408f\x2daec8\x2d25f759724841 comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=failed’
Sep 17 23:31:14 dom0 systemd[1]: systemd-cryptsetup@luks\x2d625d19ea\x2d61d4\x2d408f\x2daec8\x2d25f759724841.service: Unit entered failed state.
Sep 17 23:31:14 dom0 systemd[1]: systemd-cryptsetup@luks\x2d625d19ea\x2d61d4\x2d408f\x2daec8\x2d25f759724841.service: Failed with result ‘exit-code’.