Wireless broke again (R4-rc3 following current-testing)

[jpouellet]

Qubes OS version:

R4-rc3 following current-testing

Affected TemplateVMs:

Clean clone of fedora-26 with nothing additional added, and all updates from default-enabled repos applied.

---

Steps to reproduce the behavior:

With my hardware:

[user@sys-net ~]$ lspci | grep -i wireless
00:05.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)

And this running in dom0 (latest from dom0-current-testing):

[user@dom0 ~]$ uname -a
Linux dom0 4.14.13-1.pvops.qubes.x86_64 #1 SMP Sat Jan 13 04:05:03 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

[user@dom0 ~]$ xl dmesg | head -2
 Xen 4.8.2-11.fc25
(XEN) Xen version 4.8.2 (user@) (gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)) debug=n  Tue Nov 28 13:05:52 UTC 2017

[user@dom0 ~]$ rpm -qa | grep -E '^(qubes|xen|kernel)'
qubes-desktop-linux-manager-4.0.6-1.fc25.noarch
qubes-release-notes-4.0-0.4.noarch
xen-4.8.2-11.fc25.x86_64
qubes-desktop-linux-common-4.0.8-1.2.fc25.noarch
qubes-pdf-converter-dom0-2.1.3-1.fc25.x86_64
kernel-4.14.13-1.pvops.qubes.x86_64
qubes-core-dom0-linux-kernel-install-4.0.10-1.fc25.x86_64
qubes-mgmt-salt-dom0-virtual-machines-4.0.9-1.fc25.noarch
qubes-mgmt-salt-base-overrides-4.0.1-1.fc25.noarch
kernel-4.9.56-21.pvops.qubes.x86_64
qubes-db-dom0-4.0.5-1.fc25.x86_64
qubes-template-whonix-gw-4.0.0-201710200209.noarch
qubes-mgmt-salt-4.0.6-1.fc25.noarch
qubes-gui-dom0-4.0.6-1.fc25.x86_64
qubes-utils-4.0.15-1.fc25.x86_64
qubes-dbus-1.0.4-1.fc25.noarch
qubes-template-fedora-26-minimal-4.0.0-201711210705.noarch
qubes-template-fedora-25-minimal-4.0.0-201710192146.noarch
xen-libs-4.8.2-11.fc25.x86_64
xen-runtime-4.8.2-11.fc25.x86_64
qubes-libvchan-xen-4.0.0-1.fc25.x86_64
kernel-headers-4.13.16-100.fc25.x86_64
qubes-mgmt-salt-dom0-qvm-4.0.6-1.fc25.noarch
qubes-db-4.0.5-1.fc25.x86_64
qubes-usb-proxy-dom0-1.0.14-1.fc25.noarch
qubes-mgmt-salt-base-topd-4.0.0-1.fc25.noarch
qubes-mgmt-salt-base-4.0.2-1.fc25.noarch
qubes-template-whonix-ws-4.0.0-201710200214.noarch
qubes-input-proxy-1.0.10-1.fc25.x86_64
qubes-img-converter-dom0-1.2.4-1.fc25.x86_64
qubes-gui-dom0-debuginfo-4.0.6-1.fc25.x86_64
qubes-core-admin-client-4.0.13-0.1.fc25.noarch
qubes-core-dom0-linux-4.0.10-1.fc25.x86_64
qubes-release-4.0-0.4.noarch
xen-licenses-4.8.2-11.fc25.x86_64
xen-hypervisor-4.8.2-11.fc25.x86_64
qubes-menus-4.0.8-1.2.fc25.noarch
qubes-utils-libs-4.0.15-1.fc25.x86_64
kernel-qubes-vm-4.14.13-1.pvops.qubes.x86_64
qubes-manager-4.0.11-1.fc25.x86_64
qubes-anaconda-addon-4.0.4-1.fc25.noarch
qubes-mgmt-salt-base-config-4.0.0-1.fc25.noarch
kernel-qubes-vm-4.9.56-21.pvops.qubes.x86_64
qubes-mgmt-salt-dom0-4.0.6-1.fc25.noarch
qubes-mgmt-salt-admin-tools-4.0.6-1.fc25.noarch
qubes-core-dom0-4.0.18-1.fc25.x86_64
qubes-mgmt-salt-base-overrides-libs-4.0.1-1.fc25.noarch
qubes-core-dom0-linux-debuginfo-4.0.10-1.fc25.x86_64
qubes-mgmt-salt-dom0-update-4.0.3-1.fc25.noarch
qubes-gpg-split-dom0-2.0.27-1.fc25.x86_64
xen-hvm-stubdom-linux-1.0.7-1.fc25.x86_64
qubes-core-dom0-vaio-fixes-1.6.1-1.8.fc25.x86_64
qubes-template-fedora-26-4.0.0-201710191822.noarch
xen-hvm-4.8.2-11.fc25.x86_64
qubes-artwork-4.0.0-2.fc25.noarch
qubes-db-libs-4.0.5-1.fc25.x86_64
qubes-mgmt-salt-config-4.0.6-1.fc25.noarch

and sys-net with:

[user@dom0 ~]$ qvm-prefs sys-net virt_mode
hvm

[user@sys-net ~]$ uname -a
Linux sys-net 4.14.13-1.pvops.qubes.x86_64 #1 SMP Sat Jan 13 04:05:03 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

[user@sys-net ~]$ rpm -qa | grep ^qubes
qubes-core-agent-passwordless-root-4.0.13-1.fc26.x86_64
qubes-core-agent-4.0.13-1.fc26.x86_64
qubes-db-vm-4.0.5-1.fc26.x86_64
qubes-core-agent-systemd-4.0.13-1.fc26.x86_64
qubes-vm-dependencies-4.0.0-1.fc26.noarch
qubes-vm-recommended-4.0.0-1.fc26.noarch
qubes-db-libs-4.0.5-1.fc26.x86_64
qubes-utils-4.0.13-1.fc26.x86_64
qubes-mgmt-salt-vm-connector-4.0.6-1.fc26.noarch
qubes-kernel-vm-support-4.0.13-1.fc26.x86_64
qubes-utils-libs-4.0.13-1.fc26.x86_64
qubes-img-converter-1.2.4-1.fc26.x86_64
qubes-core-agent-networking-4.0.13-1.fc26.x86_64
qubes-core-agent-network-manager-4.0.13-1.fc26.x86_64
qubes-gpg-split-2.0.27-1.fc26.x86_64
qubes-usb-proxy-1.0.12-1.fc26.noarch
qubes-db-4.0.5-1.fc26.x86_64
qubes-libvchan-xen-4.0.0-1.fc26.x86_64
qubes-pdf-converter-2.1.2-1.fc26.x86_64
qubes-core-agent-nautilus-4.0.13-1.fc26.x86_64
qubes-core-agent-dom0-updates-4.0.13-1.fc26.x86_64
qubes-gui-agent-4.0.7-1.fc26.x86_64
qubes-core-agent-qrexec-4.0.13-1.fc26.x86_64
qubes-input-proxy-sender-1.0.10-1.fc26.x86_64

Expected behavior:

sys-net to come back on resume and wireless to "just work".

Wireless came back up on suspend/resume ~100% of the time before whatever update just broke it.

Actual behavior:

sys-net hangs reliably after every resume

[user@dom0 ~]$ sudo xl console -t pv sys-net | sed -E 's/([0-9a-f]{2}:){5}[0-9a-f]{2}/[mac redacted]/'
...
[  OK  ] Mounted FUSE Control File System.
[  OK  ] Started Builds and install new kernel modules through DKMS.
[  OK  ] Reached target Multi-User System.
         Starting Update UTMP about System Runlevel Changes...
[  OK  ] Started Update UTMP about System Runlevel Changes.

Fedora 26 (Twenty Six)
Kernel 4.14.13-1.pvops.qubes.x86_64 on an x86_64 (hvc0)

sys-net login: [    9.856546] IPv6: ADDRCONF(NETDEV_UP): wls5: link is not ready
[    9.884954] wls5: authenticate with [mac redacted]
[    9.895016] wls5: send auth to [mac redacted] (try 1/3)
[    9.921158] wls5: authenticated
[    9.922032] wls5: associate with [mac redacted] (try 1/3)
[    9.948214] wls5: RX AssocResp from [mac redacted] (capab=0x511 status=0 aid=5)
[    9.951849] wls5: associated
[    9.972218] IPv6: ADDRCONF(NETDEV_CHANGE): wls5: link becomes ready
[   14.618444] vif vif-22-0 vif22.0: Guest Rx ready
[   14.618472] IPv6: ADDRCONF(NETDEV_CHANGE): vif22.0: link becomes ready
[10947.354623] wls5: deauthenticating from [mac redacted] by local choice (Reason: 3=DEAUTH_LEAVING)
[10947.368301] wls5: failed to remove key (1, [mac redacted]) from hardware (-22)
[10947.368673] wls5: failed to remove key (2, [mac redacted]) from hardware (-22)
[10947.522368] Freezing user space processes ... (elapsed 0.003 seconds) done.
[10947.525601] OOM killer disabled.
[10947.525609] Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
[11009.638279] clocksource: timekeeping watchdog on CPU1: Marking clocksource 'tsc' as unstable because the skew is too large:
[11009.638331] clocksource:                       'xen' wd_now: 17b759a9d78c wd_last: 17b71387bd55 mask: ffffffffffffffff
[11009.638367] clocksource:                       'tsc' cs_now: fffffd0e64f7caa0 cs_last: 1c2084c499d6 mask: ffffffffffffffff
[11009.638402] tsc: Marking TSC unstable due to clocksource watchdog

General notes:

I have also always had (and needed):

[user@sys-net ~]$ cat /rw/config/suspend-module-blacklist 
iwlmvm
iwlwifi

for the interface to come back up reliably, but the whole VM has not hung before, I just got the exact failure mode described in https://www.qubes-os.org/doc/wireless-troubleshooting/ (which I wrote)

[mirrorway]

I have a similar issue in 4.0rc2 tracking current-testing, but atheros wifi (so usually no blacklisting needed).

sys-net hangs on resume.

Short-term workaround: restart sys-net.
Long-term workaround: downgrade sys-net kernel from 4.14.13 to 4.9.56,

[mirrorway]

I have a similar issue in 4.0rc2 tracking current-testing, but atheros wifi (so usually no blacklisting needed).

sys-net hangs on resume.

Short-term workaround: restart sys-net.
Long-term workaround: downgrade sys-net kernel from 4.14.13 to 4.9.56,

[marmarek]

Does it work if you unload the module manually before the suspend? Do you see any errors in dom0 journalctl, especially related to qubesd or qubes-suspend services?

[marmarek]

Does it work if you unload the module manually before the suspend? Do you see any errors in dom0 journalctl, especially related to qubesd or qubes-suspend services?

[marmarek]

Ok, I can reproduce the problem.

[marmarek]

Ok, I can reproduce the problem.

[marmarek]

For me, detaching drivers from all PCI devices (besides those qemu emulated) fixes the problem.
I'll patch the script to do that automatically, as it looks like most hardware/drivers require it. Lets not force each user to list drivers manually...

[marmarek]

For me, detaching drivers from all PCI devices (besides those qemu emulated) fixes the problem.
I'll patch the script to do that automatically, as it looks like most hardware/drivers require it. Lets not force each user to list drivers manually...

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 testing repository for the CentOS centos7 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 testing repository for the CentOS centos7 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.18-1+deb8u1 has been pushed to the r4.0 testing repository for the Debian jessie template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing jessie-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.18-1+deb8u1 has been pushed to the r4.0 testing repository for the Debian jessie template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing jessie-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.18-1+deb9u1 has been pushed to the r4.0 testing repository for the Debian stretch template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.18-1+deb9u1 has been pushed to the r4.0 testing repository for the Debian stretch template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.18-1.fc24 has been pushed to the r4.0 testing repository for the Fedora fc24 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.18-1.fc24 has been pushed to the r4.0 testing repository for the Fedora fc24 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.18-1.fc25 has been pushed to the r4.0 testing repository for the Fedora fc25 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.18-1.fc25 has been pushed to the r4.0 testing repository for the Fedora fc25 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.18-1.fc26 has been pushed to the r4.0 testing repository for the Fedora fc26 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.18-1.fc26 has been pushed to the r4.0 testing repository for the Fedora fc26 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[hyperfekt]

Am I correct in the assumption that this should be fixed with qubes-core-agent 4.0.20?
Asking because I have that installed, but still have the exact same problem (same hardware).
Could you confirm, @jpouellet ?

PS: versions:

[user@unknownb88a60933807 ~]$ dnf list installed "qubes-core-agent*"
Installed Packages
qubes-core-agent.x86_64                   4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing
qubes-core-agent-dom0-updates.x86_64      4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing
qubes-core-agent-nautilus.x86_64          4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing
qubes-core-agent-network-manager.x86_64   4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing
qubes-core-agent-networking.x86_64        4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing
qubes-core-agent-passwordless-root.x86_64 4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing
qubes-core-agent-qrexec.x86_64            4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing
qubes-core-agent-systemd.x86_64           4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing

[hyperfekt]

Am I correct in the assumption that this should be fixed with qubes-core-agent 4.0.20?
Asking because I have that installed, but still have the exact same problem (same hardware).
Could you confirm, @jpouellet ?

PS: versions:

[user@unknownb88a60933807 ~]$ dnf list installed "qubes-core-agent*"
Installed Packages
qubes-core-agent.x86_64                   4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing
qubes-core-agent-dom0-updates.x86_64      4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing
qubes-core-agent-nautilus.x86_64          4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing
qubes-core-agent-network-manager.x86_64   4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing
qubes-core-agent-networking.x86_64        4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing
qubes-core-agent-passwordless-root.x86_64 4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing
qubes-core-agent-qrexec.x86_64            4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing
qubes-core-agent-systemd.x86_64           4.0.20-1.fc26 @qubes-builder-vm-r4.0-current-testing

[andrewdavidwong]

Am I correct in the assumption that this should be fixed with qubes-core-agent 4.0.20?
Asking because I have that installed, but still have the exact same problem (same hardware).

Looks like core-agent-linux v4.0.18 was intended to fix this (QubesOS/updates-status#381). Reopening.

[andrewdavidwong]

Am I correct in the assumption that this should be fixed with qubes-core-agent 4.0.20?
Asking because I have that installed, but still have the exact same problem (same hardware).

Looks like core-agent-linux v4.0.18 was intended to fix this (QubesOS/updates-status#381). Reopening.

[marmarek]

Check with updated VM kernel (kernel-qubes-vm package in dom0, version 4.14.13-3).

[marmarek]

Check with updated VM kernel (kernel-qubes-vm package in dom0, version 4.14.13-3).

[hyperfekt]

I figured it out: Apparently, having iwlmvm and iwlwifi in the suspend-modules-blacklist is the problem. Without them (and a sys-net reboot), everything works fine. The upgrade instructions could note not to add those for R4, just in case people think it's still necessary.

[hyperfekt]

I figured it out: Apparently, having iwlmvm and iwlwifi in the suspend-modules-blacklist is the problem. Without them (and a sys-net reboot), everything works fine. The upgrade instructions could note not to add those for R4, just in case people think it's still necessary.

[andrewdavidwong]

I figured it out: Apparently, having iwlmvm and iwlwifi in the suspend-modules-blacklist is the problem. Without them (and a sys-net reboot), everything works fine. The upgrade instructions could note not to add those for R4, just in case people think it's still necessary.

I thought it was still necessary, though. See: QubesOS/qubes-doc#549.

[andrewdavidwong]

I figured it out: Apparently, having iwlmvm and iwlwifi in the suspend-modules-blacklist is the problem. Without them (and a sys-net reboot), everything works fine. The upgrade instructions could note not to add those for R4, just in case people think it's still necessary.

I thought it was still necessary, though. See: QubesOS/qubes-doc#549.

[hyperfekt]

I thought with QubesOS/qubes-core-agent-linux@cfbc953 that was solved - at least for me it is.

[hyperfekt]

I thought with QubesOS/qubes-core-agent-linux@cfbc953 that was solved - at least for me it is.

[andrewdavidwong]

I thought with QubesOS/qubes-core-agent-linux@cfbc953 that was solved - at least for me it is.

Wait, don't you mean the opposite? Above, you wrote:

I figured it out: Apparently, having iwlmvm and iwlwifi in the suspend-modules-blacklist is the problem. Without them (and a sys-net reboot), everything works fine.

But QubesOS/qubes-core-agent-linux@cfbc953 adds iwlmvm and iwlwifi to the suspend-modules-blacklist. If that commit adds them, which breaks things for you, and you have to remove them in order to fix things, then why does that commit solve anything for you?

[andrewdavidwong]

I thought with QubesOS/qubes-core-agent-linux@cfbc953 that was solved - at least for me it is.

Wait, don't you mean the opposite? Above, you wrote:

I figured it out: Apparently, having iwlmvm and iwlwifi in the suspend-modules-blacklist is the problem. Without them (and a sys-net reboot), everything works fine.

But QubesOS/qubes-core-agent-linux@cfbc953 adds iwlmvm and iwlwifi to the suspend-modules-blacklist. If that commit adds them, which breaks things for you, and you have to remove them in order to fix things, then why does that commit solve anything for you?

[hyperfekt]

I am not really an expert on how this works.
I know the following things, however:
With 3.2, I needed to add these modules keep the WiFi functioning after suspend.
With qubes-core-agent 4.0.20, adding these modules will hang sys-net after suspend. Not adding these still leaves WiFi after suspend functioning.
I know these files are not identical, since looking at it iwldvm is not contained (mind that the commit adds iwldvm instead of iwlwifi!).
I have 2 hypotheses, if you ask me:

1. The file in /rw/config and the one they are added to in the agent are in some kind of conflict.
2. Having iwlwifi in there is the culprit and only causes an issue with R4.0.

[hyperfekt]

I am not really an expert on how this works.
I know the following things, however:
With 3.2, I needed to add these modules keep the WiFi functioning after suspend.
With qubes-core-agent 4.0.20, adding these modules will hang sys-net after suspend. Not adding these still leaves WiFi after suspend functioning.
I know these files are not identical, since looking at it iwldvm is not contained (mind that the commit adds iwldvm instead of iwlwifi!).
I have 2 hypotheses, if you ask me:

1. The file in /rw/config and the one they are added to in the agent are in some kind of conflict.
2. Having iwlwifi in there is the culprit and only causes an issue with R4.0.

[andrewdavidwong]

I know these files are not identical, since looking at it iwldvm is not contained (mind that the commit adds iwldvm instead of iwlwifi!).

You're right; I missed that!

Having iwlwifi in there is the culprit and only causes an issue with R4.0.

In light of the above, this hypothesis makes sense to me now. I'm not an expert either. Perhaps @marmarek can clear things up?

[andrewdavidwong]

I know these files are not identical, since looking at it iwldvm is not contained (mind that the commit adds iwldvm instead of iwlwifi!).

You're right; I missed that!

Having iwlwifi in there is the culprit and only causes an issue with R4.0.

In light of the above, this hypothesis makes sense to me now. I'm not an expert either. Perhaps @marmarek can clear things up?

[marmarek]

Unloading iwldvm and iwlmvm using modprobe -r (instead of rmmod) also unloads iwlwifi. But maybe if iwldvm is listed twice it cause some problems. Try to launch a terminal in sys-net (or even better: use sudo xl console -t pv sys-net for that) and execute journalctl -f there before suspending the system. This way, even if sys-net will hang, you'll see log entries, especially if that script fails in any way.

[marmarek]

Unloading iwldvm and iwlmvm using modprobe -r (instead of rmmod) also unloads iwlwifi. But maybe if iwldvm is listed twice it cause some problems. Try to launch a terminal in sys-net (or even better: use sudo xl console -t pv sys-net for that) and execute journalctl -f there before suspending the system. This way, even if sys-net will hang, you'll see log entries, especially if that script fails in any way.

[hyperfekt]

The issue quite clearly is having iwlmvm in /rw/config/suspend-modules-blacklist, iwlwifi or iwldvm causes no issues.
Here is the log of sys-net suspend, I don't trust myself picking just the relevant parts out.
(Although I'm not entirely sure how important chasing this down is, considering it shouldn't be happening anymore anyhow.)

[hyperfekt]

The issue quite clearly is having iwlmvm in /rw/config/suspend-modules-blacklist, iwlwifi or iwldvm causes no issues.
Here is the log of sys-net suspend, I don't trust myself picking just the relevant parts out.
(Although I'm not entirely sure how important chasing this down is, considering it shouldn't be happening anymore anyhow.)

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.20-1+deb9u1 has been pushed to the r4.0 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.20-1+deb9u1 has been pushed to the r4.0 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-4.0.20-1.fc26) has been pushed to the r4.0 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-4.0.20-1.fc26) has been pushed to the r4.0 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 stable repository for the Fedora centos7 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 stable repository for the Fedora centos7 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[marmarek]

One more thing: apparently there is a problem with HVM suspend using kernel >= 4.11. This should be fixed in 4.14.13-3, so make sure it is set for sys-net and sys-usb. It should be the default one, if you install updates.

[marmarek]

One more thing: apparently there is a problem with HVM suspend using kernel >= 4.11. This should be fixed in 4.14.13-3, so make sure it is set for sys-net and sys-usb. It should be the default one, if you install updates.