qubes-db does not work after qubes-db package upgrade, breaks qubes-whonix and tb-updater package

[adrelanos]

Processing triggers for qubes-whonix (1:5.7-1) ...
Failed connect to local daemon
Traceback (most recent call last):
  File "/usr/lib/qubes-whonix/replace-ips", line 233, in <module>
    main(sys.argv[1:])
  File "/usr/lib/qubes-whonix/replace-ips", line 204, in main
    if whonix_mode() == 'gateway':
  File "/usr/lib/qubes-whonix/replace-ips", line 79, in whonix_mode
    qubes_vm_type = subprocess.check_output(['qubesdb-read', '/qubes-vm-type']).rstrip()
  File "/usr/lib/python2.7/subprocess.py", line 573, in check_output
    raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['qubesdb-read', '/qubes-vm-type']' returned non-zero exit status 1
dpkg: error processing package qubes-whonix (--unpack):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for libglib2.0-0:amd64 (2.42.1-1+b1) ...
Errors were encountered while processing:
 qubes-whonix

Impact: Not great but by rerunning sudo apt-get dist-upgrade the upgrade process eventually completes.

Workaround: I should probably push a Whonix stable upgrade to ignore qubes-db failures?

Long term: Will it be possible in future to restart qubes-db without failure?

[marmarek]

Looks like qubes-db service is stopped because it's being updated too. qubes-db service in VM can be started/stopped/restarted normally. Is it possible to order qubes-whonix config step (trigger step?) after qubes-db config step (so service will be back running)?

[marmarek]

Looks like qubes-db service is stopped because it's being updated too. qubes-db service in VM can be started/stopped/restarted normally. Is it possible to order qubes-whonix config step (trigger step?) after qubes-db config step (so service will be back running)?

[adrelanos]

Dunno. Maybe a debian/control Depends: qubesdb would do? (Or perhaps even a Pre-Depends: is required.) qubes-whonix depending on qubesdb seems sane.

(https://www.debian.org/doc/debian-policy/ch-relationships.html)

Should I depend on qubesdb or qubesdb-vm package?

[adrelanos]

Dunno. Maybe a debian/control Depends: qubesdb would do? (Or perhaps even a Pre-Depends: is required.) qubes-whonix depending on qubesdb seems sane.

(https://www.debian.org/doc/debian-policy/ch-relationships.html)

Should I depend on qubesdb or qubesdb-vm package?

[marmarek]

Should I depend on qubesdb or qubesdb-vm package?

Service belongs to qubesdb-vm so that one.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[marmarek]

Should I depend on qubesdb or qubesdb-vm package?

Service belongs to qubesdb-vm so that one.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[adrelanos]

This also breaks tb-updater during apt-get upgrades.

I wonder if debian/pkg-name.triggers could be somehow converted to systemd units. Because then we wouldn't have this issue. qubesdb already orders itself very early.

[adrelanos]

This also breaks tb-updater during apt-get upgrades.

I wonder if debian/pkg-name.triggers could be somehow converted to systemd units. Because then we wouldn't have this issue. qubesdb already orders itself very early.

[marmarek]

Not sure about that. But even if possible, that would need to be asynchronous (to really wait until qubes-db is started again), which means update may still do something after apt-get finishes. apt-get -y dist-upgrade && poweroff will break things.

[marmarek]

Not sure about that. But even if possible, that would need to be asynchronous (to really wait until qubes-db is started again), which means update may still do something after apt-get finishes. apt-get -y dist-upgrade && poweroff will break things.

[adrelanos]

There are also various trigger configurations. But I cannot make head or tail of it.
http://man7.org/linux/man-pages/man5/deb-triggers.5.html

Posted two questions on debian-mentors. (Not yet in archive.)

• Can debian/pkg.triggers wait for another package's systemd unit file?
• Convert debian/pkg-name.triggers into systemd unit file?

[adrelanos]

There are also various trigger configurations. But I cannot make head or tail of it.
http://man7.org/linux/man-pages/man5/deb-triggers.5.html

Posted two questions on debian-mentors. (Not yet in archive.)

• Can debian/pkg.triggers wait for another package's systemd unit file?
• Convert debian/pkg-name.triggers into systemd unit file?

[adrelanos]

qubes-whonix 5.7.2-1 was added to Whonix jessie-proposed-updates and testers repository.

[adrelanos]

qubes-whonix 5.7.2-1 was added to Whonix jessie-proposed-updates and testers repository.

[adrelanos]

debian/control Depends: qubesd-vm fixed this. No longer breaking during apt-get dist-upgrade.

[adrelanos]

debian/control Depends: qubesd-vm fixed this. No longer breaking during apt-get dist-upgrade.

[marmarek]

So, closeable?

[marmarek]

So, closeable?

[adrelanos]

follow up issue for Qubes:
#2509

---

Setting up qubes-core-agent (3.2.13-1+deb8u1) ...
[...]
Job for qubes-whonix-network.service failed. See 'systemctl status qubes-whonix-network.service' and 'journalctl -xn' for details.
Setting up libqubesdb (3.2.3-1+deb8u1) ...
Setting up qubesdb (3.2.3-1+deb8u1) ...
Setting up qubesdb-vm (3.2.3-1+deb8u1) ..

Not breaking anything [at the moment as that script stays as is], but not great, and looking bad. So desirable to fix. I guess it is happening during a "long" systemd start command during debian postinst so there is a good chance #2509 would fix it.

---

Setting up tb-updater (3:3.7.9-1) ...
Job for tb-updater-first-boot.service failed. See 'systemctl status tb-updater-first-boot.service' and 'journalctl -xn' for details.
Failed connect to local daemon

• tb-updater-first-boot.service failing is cosmetic.
• tb-updater updating Tor Browser in TemplateVM /var/cache/tb-binary is broken which is not critical (in AppVM Tor Browser updates still working; manual run of update-torbrowser in TempalteVM still working), but I want to fix that. Probably by no longer using qubesdb-read but rather /var/run/qubes/this-is-templatevm (qubesdb-read only as fallback for Qubes R3.1 compatibility). [Because tb-updater is a generic package, a dependency on qubesdb-vm would not be great.]

[adrelanos]

follow up issue for Qubes:
#2509

---

Setting up qubes-core-agent (3.2.13-1+deb8u1) ...
[...]
Job for qubes-whonix-network.service failed. See 'systemctl status qubes-whonix-network.service' and 'journalctl -xn' for details.
Setting up libqubesdb (3.2.3-1+deb8u1) ...
Setting up qubesdb (3.2.3-1+deb8u1) ...
Setting up qubesdb-vm (3.2.3-1+deb8u1) ..

Not breaking anything [at the moment as that script stays as is], but not great, and looking bad. So desirable to fix. I guess it is happening during a "long" systemd start command during debian postinst so there is a good chance #2509 would fix it.

---

Setting up tb-updater (3:3.7.9-1) ...
Job for tb-updater-first-boot.service failed. See 'systemctl status tb-updater-first-boot.service' and 'journalctl -xn' for details.
Failed connect to local daemon

• tb-updater-first-boot.service failing is cosmetic.
• tb-updater updating Tor Browser in TemplateVM /var/cache/tb-binary is broken which is not critical (in AppVM Tor Browser updates still working; manual run of update-torbrowser in TempalteVM still working), but I want to fix that. Probably by no longer using qubesdb-read but rather /var/run/qubes/this-is-templatevm (qubesdb-read only as fallback for Qubes R3.1 compatibility). [Because tb-updater is a generic package, a dependency on qubesdb-vm would not be great.]

[marmarek]

Probably by no longer using qubesdb-read but rather /var/run/qubes/this-is-templatevm (qubesdb-read only as fallback for Qubes R3.1 compatibility). [Because tb-updater is a generic package, a dependency on qubesdb-vm would not be great.]

Yes, this would be a good solution. If you'd like to keep R3.1 compatibility, check for any /var/run/qubes/this-is-* - if there is none, fallback to qubesdb-read, otherwise proceed with /var/run/qubes/this-is-templatevm

[marmarek]

Probably by no longer using qubesdb-read but rather /var/run/qubes/this-is-templatevm (qubesdb-read only as fallback for Qubes R3.1 compatibility). [Because tb-updater is a generic package, a dependency on qubesdb-vm would not be great.]

Yes, this would be a good solution. If you'd like to keep R3.1 compatibility, check for any /var/run/qubes/this-is-* - if there is none, fallback to qubesdb-read, otherwise proceed with /var/run/qubes/this-is-templatevm

[adrelanos]

Yes.

tb-updater is designed not to break upgrading (exit 0) when run from postinst but not from chroot. However, the tool for detection of chroot, ischroot is buggy.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685034

Do we have a more reliable way to detect chroot?

[adrelanos]

Yes.

tb-updater is designed not to break upgrading (exit 0) when run from postinst but not from chroot. However, the tool for detection of chroot, ischroot is buggy.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685034

Do we have a more reliable way to detect chroot?

[adrelanos]

Various enhancements were backported and pushed to Whonix 13 stable branch.
https://github.com/Whonix/tb-updater/commits/Whonix13

This is now in Whonix jessie-proposed-updates and testers repository.

[adrelanos]

Various enhancements were backported and pushed to Whonix 13 stable branch.
https://github.com/Whonix/tb-updater/commits/Whonix13

This is now in Whonix jessie-proposed-updates and testers repository.

[adrelanos]

This is now also in Whonix jessie (stable) repository. Therefore, close please.

[adrelanos]

This is now also in Whonix jessie (stable) repository. Therefore, close please.