Re: [qubes-users] Failed to shutdown or suspend. Help
>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: Timeout: 0 seconds BootOrder: 0001,0002,,0003,0004 Boot* xen HD(1,GPT,3a4fdaa2-0a2c-4783-ba2a-59a408c24c1c,0x800,0x64000)/File(\EFI\QUBES\XEN.EFI) Boot0001* P0: Samsung SSD 850 PRO 256GBBBS(16,,0x0)AMBO Boot0002* Atheros Boot AgentBBS(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 :02:00.0]$ sudo cat /proc/acpi/wakeup DeviceS-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::00:1c.0 PXSX S4*disabled RP02 S4*disabled PXSX S4*disabled RP03 S4*disabled PXSX S4*disabled RP04 S4*disabled pci::00:1c.3 PXSX S4*disabled pci::07:00.0 RP05 S0*disabled PXSX S4*disabled RP06 S4*disabled pci::00:1c.5 PXSX S4*disabled pci::09:00.0 RP07 S4*disabled PXSX S4*disabled RP08 S4*disabled PXSX S4*disabled PEG0 S4*disabled pci::00:01.0 PEGP S4*disabled pci::02:00.0 PEGA S4*disabled PEG1 S4*disabled PEG2 S4*disabled PEG3 S4*disabled XHC S4*disabled pci::00:14.0 HDEF S4*disabled pci::00:1b.0 EHC2 S0*disabled pci::00:1a.0 EHC1 S0*disabled pci::00:1d.0 *LID0 S3*enabled platform:PNP0C0D:00* sudo dmesg |grep -2i acpi [0.00] 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.00] 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.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] 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+: 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+: 1946: error : virPCIDeviceReset:1002 : internal error: Unable to reset PCI device :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
Re: [qubes-users] Failed to shutdown or suspend. Help
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. -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ee99ebd4-84ff-2469-d053-fc95ec96e683%40danwin1210.me.
Re: [qubes-users] Failed to shutdown or suspend. Help
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 + : 2802: error: virPCIDeviceReset: 1002: internal error: Unable to reset PCI device : 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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/917e250c-dde8-4b78-a902-2a4c859ad1bcn%40googlegroups.com.
Re: [qubes-users] Failed to shutdown or suspend. Help
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. -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/73756763-0bdb-a148-136a-710af12070e0%40danwin1210.me.
[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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3ef5daa0-cdc5-4a17-8342-da4710497e95o%40googlegroups.com.