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

2020-09-18 Thread vin cen zo
>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

2020-09-17 Thread 'awokd' via qubes-users
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

2020-09-17 Thread vin cen zo
 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

2020-09-17 Thread 'awokd' via qubes-users
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

2020-09-14 Thread 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.

-- 
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.