Post install step fails running /usr/bin/qubes-prefs default-kernel

[osresearch]

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

R4.0-rc1

Affected TemplateVMs (e.g., fedora-23, if applicable):

---

Expected behavior:

Install script sets the default kernel and continues post install steps

Actual behavior:

['/usr/bin/qubes-prefs', 'default-kernel', '4.9.35-19'] failed
....
FileNotFoundError: (Errno 2) No such file or directory

Steps to reproduce the behavior:

Happened both with automatic partitioning as well as manual partitioning. I'm installing with coreboot based firmware, but R3.2 had no problems, so I'm hoping this isn't related to the firmware.

General notes:

---

Related issues:

[marmarek]

This may be another instance of #2960. Check journalctl why qubesd service crashed/failed to start.

[marmarek]

This may be another instance of #2960. Check journalctl why qubesd service crashed/failed to start.

[osresearch]

Sorry for the screenshots -- I wish I had a serial console on this machine...

Looks like the first error is:

xenstored: TDB: tdb_open_ex: could not open file /var/lib/xenstored/tdb: No such file or directory

Then xen-init=dom0 and startup-misc.sh have errors accessing libx_domain_info. libxl__userdata_path, libxl_get_physinfo and libx_get_scheduler.

qubesd reports errors connecting to socket '/var/run/libvirt/libvirt-sock'

[osresearch]

Sorry for the screenshots -- I wish I had a serial console on this machine...

Looks like the first error is:

xenstored: TDB: tdb_open_ex: could not open file /var/lib/xenstored/tdb: No such file or directory

Then xen-init=dom0 and startup-misc.sh have errors accessing libx_domain_info. libxl__userdata_path, libxl_get_physinfo and libx_get_scheduler.

qubesd reports errors connecting to socket '/var/run/libvirt/libvirt-sock'

[marmarek]

getting physinfo: Permission denied most commonly means incompatible xen and toolstack versions. Note that R4.0 have Xen 4.8, so boot image from R3.2 would not work (Xen 4.6 there). Maybe #2990?

[marmarek]

getting physinfo: Permission denied most commonly means incompatible xen and toolstack versions. Note that R4.0 have Xen 4.8, so boot image from R3.2 would not work (Xen 4.6 there). Maybe #2990?

[osresearch]

That sounds very likely -- I have a 4.6 xen.gz in the firmware that is the default if there isn't a signed /boot/xen available. I'll update the image and give it another try.

[osresearch]

That sounds very likely -- I have a 4.6 xen.gz in the firmware that is the default if there isn't a signed /boot/xen available. I'll update the image and give it another try.

[osresearch]

Doing a full re-install with Xen 4.8.1 fixed this issue.

[osresearch]

Doing a full re-install with Xen 4.8.1 fixed this issue.