[bug] DispVM savefile creation hangs at "Waiting for DVM..."

23 views
Skip to first unread message

Andrew

unread,
Jun 13, 2017, 11:55:18 AM6/13/17
to qubes-users
Hi,

I recently experienced a very frustrating bug, where my Whonix
disposable VM could not be recreated after a `dist-upgrade` in the
underlying Whonix workstation template. The symptoms were, after trying
to create it with `qvm-create-default-dvm`:
-the VM becomes yellow in Qubes Manager and never becomes green
-qrexec could not connect
-qvm-create-default-dvm hangs at "Waiting for DVM ..."
-`xl console` access still worked fine
-no DVM savefile created

Following Patrick's advice in
https://forums.whonix.org/t/dvm-fails-to-start-after-whonix-update-dist-upgrade/3109/5
(a user reporting seemingly the same bug), I found that three systemd
units failed:
-apparmor
-qubes-gui-agent
-tb-updater-first-boot

Long story short, the problem was that /var/cache/tb-binary/.tb/ was
filled with ~1.5GB of old Tor Browser folders, which caused
tb-updater-first-boot to fail, which (I guess) cascaded. Removing these
old directories, shutting down the template, then obliterating the DVM
and recreating it solved the problem.

Patrick, is there some way to detect if the tor-browser directory has
been changed, and only then save a copy? Or perhaps it's better to
explicitly ask what to do on each invocation of the Tor Browser
Downloader? At the very least, it should detect when there is not
enough space and give some sort of warning/instructions.

Hope this helps,
Andrew

Patrick Schleizer

unread,
Jun 14, 2017, 10:09:25 AM6/14/17
to Andrew, qubes-users, Patrick Schleizer
Andrew:
> Hi,
>
> I recently experienced a very frustrating bug, where my Whonix
> disposable VM could not be recreated after a `dist-upgrade` in the
> underlying Whonix workstation template. The symptoms were, after trying
> to create it with `qvm-create-default-dvm`:
> -the VM becomes yellow in Qubes Manager and never becomes green
> -qrexec could not connect
> -qvm-create-default-dvm hangs at "Waiting for DVM ..."
> -`xl console` access still worked fine
> -no DVM savefile created
>
> Following Patrick's advice in
>
https://forums.whonix.org/t/dvm-fails-to-start-after-whonix-update-dist-upgrade/3109/5
> (a user reporting seemingly the same bug), I found that three systemd
> units failed:
> -apparmor
> -qubes-gui-agent
> -tb-updater-first-boot

qubes-gui-agent bug? Probably should not break under this condition?

> Patrick, is there some way to detect if the tor-browser directory has
> been changed, and only then save a copy?

As a user: you would know if you made changes to
/var/cache/tb-binary/.tb/ / if you started Tor Browser in Qubes TemplateVM.

As a developer at the code level: create a checksum of the folder in
tb-updater after:

tb_run_function tb_patch

(add a new function tb_checksum)

Then delete older folders that have not been modified. (add new function
tb_delete)

Not sure what do do about old versions not previously checksummed.

Or perhaps super simple: Maybe we should not support customizations in
/var/cache/tb-binary/.tb/ at all and delete all old versions without
asking in postinst.

Or a bit nicer: delete all old versions but one or two without asking.

TODO ticket:
https://phabricator.whonix.org/T671

developer discussion:
https://forums.whonix.org/t/7-0a3-tor-browser-series-defunct-in-whonix/3786/17

> Or perhaps it's better to
> explicitly ask what to do on each invocation of the Tor Browser
> Downloader?

No. Usability mess. Also not possible/sane in postinst.
Reply all
Reply to author
Forward
0 new messages