Qubesd broken after rebooting dom0, updated fedora 25

[0spinboson]

Qubes OS version (e.g., R3.2):

4.0rc1

Rebooted machine, got this. No extra repo enabled beyond dom0 current testing.
First time I updated dom0 since installing 4rc1

Expected behavior:

Updating dom0 doesn't kill qubes-manager

[0spinboson]

The list of packages available atm

[0spinboson]

The list of packages available atm

[marmarek]

Updates list look normal (upstream Fedora updates). Previous error means something gone wrong with qubesd - see logs: sudo journalctl -u qubesd.

[marmarek]

Updates list look normal (upstream Fedora updates). Previous error means something gone wrong with qubesd - see logs: sudo journalctl -u qubesd.

[0spinboson]

After reinstalling rc1 a second time (to get that list), I haven't run into this again (and didn't screenshot log before doing so).

[0spinboson]

After reinstalling rc1 a second time (to get that list), I haven't run into this again (and didn't screenshot log before doing so).

[0spinboson]

Seems I spoke to soon. Here you go.

[0spinboson]

Seems I spoke to soon. Here you go.

[marmarek]

Is this right after update? What version of qubes-core-dom0 package do you have?

[marmarek]

Is this right after update? What version of qubes-core-dom0 package do you have?

[0spinboson]

4.0.4. I haven't done anything weird in dom0, just update it and update VMs (which also took some effort, because of weird issues with getting f25 to act as netVM. Works some times, but at other times nothing is forwarded to sys-firewall. Debian-8 worked better, but when I cloned & upgraded that to d9, it started acting the same way. F25 misbehavior as netVM happens on both of my PCs).

[0spinboson]

4.0.4. I haven't done anything weird in dom0, just update it and update VMs (which also took some effort, because of weird issues with getting f25 to act as netVM. Works some times, but at other times nothing is forwarded to sys-firewall. Debian-8 worked better, but when I cloned & upgraded that to d9, it started acting the same way. F25 misbehavior as netVM happens on both of my PCs).

[marmarek]

Try restarting the service: systemctl restart qubesd

[marmarek]

Try restarting the service: systemctl restart qubesd

[0spinboson]

That works, and I can start sys-net and -firewall now, but can't open a terminal window.

[0spinboson]

That works, and I can start sys-net and -firewall now, but can't open a terminal window.

[marmarek]

Try qvm-start-gui --all

[marmarek]

Try qvm-start-gui --all

[0spinboson]

That also works

[0spinboson]

That also works

[marmarek]

Do you have terminal now?

[marmarek]

Do you have terminal now?

[0spinboson]

Yes.

[0spinboson]

Yes.

[0spinboson]

After playing around a bit, a few remarks:

1. (obviously) this fix isn't persistent across reboots. Also, the notification area widgets are missing.
2. I have to run the qvm-start-gui every time I run something / start a new VM, to get those GUIs to show up.
3. qvm-start-gui --all also 'fixes' another issue I was running into, namely that GUIs weren't showing up properly after I'd started/shutdown VMs a number of times. (I also start seeing warnings about thin provisioning assigning more space than this SSD has -- I posted a screenshot with the error in the rc1 thread in qubes-users).

[0spinboson]

After playing around a bit, a few remarks:

1. (obviously) this fix isn't persistent across reboots. Also, the notification area widgets are missing.
2. I have to run the qvm-start-gui every time I run something / start a new VM, to get those GUIs to show up.
3. qvm-start-gui --all also 'fixes' another issue I was running into, namely that GUIs weren't showing up properly after I'd started/shutdown VMs a number of times. (I also start seeing warnings about thin provisioning assigning more space than this SSD has -- I posted a screenshot with the error in the rc1 thread in qubes-users).

[marmarek]

Ah, there is qvm-start-gui --all --watch. Check also ~/.xsession-errors - maybe there is some hint why it crashed.

[marmarek]

Ah, there is qvm-start-gui --all --watch. Check also ~/.xsession-errors - maybe there is some hint why it crashed.

[0spinboson]

xsession-errors.txt
a few errors at the top here, but since they lack timestamps I don't know what they correlate with.
more:
xsession-errors.old.txt

[0spinboson]

xsession-errors.txt
a few errors at the top here, but since they lack timestamps I don't know what they correlate with.
more:
xsession-errors.old.txt

[0spinboson]

small update: even with 'qvm-start-gui --all --watch' running, it still misses updates (I get 1 or more from these messages "Unable to init server: could not connect: connection refused" / "failed to parse arguments: cannot open display" / "Failed to connect to Mir: Failed to connect to server socket"), at which point I have to run 'qvm-start-gui --all manually to get it working again, after which it's fine).

[0spinboson]

small update: even with 'qvm-start-gui --all --watch' running, it still misses updates (I get 1 or more from these messages "Unable to init server: could not connect: connection refused" / "failed to parse arguments: cannot open display" / "Failed to connect to Mir: Failed to connect to server socket"), at which point I have to run 'qvm-start-gui --all manually to get it working again, after which it's fine).

[marmarek]

Mir?! From where you've got it?

[marmarek]

Mir?! From where you've got it?

[0spinboson]

Xenial-based standalone vm. Was playing around a bit with it a while back.

[0spinboson]

Xenial-based standalone vm. Was playing around a bit with it a while back.

[marmarek]

(continuation of discussion from QubesOS/updates-status#176)
Can you post service start order from both failed and succeed boot? You can get it with:

journalctl -b -0 | grep 'systemd.*\(Start\|Fail\)'

And use -b -1 for previous boot, -2 for the boot before etc.

[marmarek]

(continuation of discussion from QubesOS/updates-status#176)
Can you post service start order from both failed and succeed boot? You can get it with:

journalctl -b -0 | grep 'systemd.*\(Start\|Fail\)'

And use -b -1 for previous boot, -2 for the boot before etc.

[0spinboson]

boot1.txt < success
boot0.txt < fail
here you go

[0spinboson]

boot1.txt < success
boot0.txt < fail
here you go

[marmarek]

Looks like startup ordering issue with "LVM2 PV scan on device 8:34". I'll add appropriate dependency.

[marmarek]

Looks like startup ordering issue with "LVM2 PV scan on device 8:34". I'll add appropriate dependency.

[seandilda]

Are packages with this fix available yet? I updated to current-testing this morning, and I'm still seeing the problem.

[seandilda]

Are packages with this fix available yet? I updated to current-testing this morning, and I'm still seeing the problem.

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.6-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.6-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.11-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.11-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update