After doing a reinstall and restore from backup of my Qubes 4.0 system,
I have a number of AppVM's that do not want to start for some unknown
reason. The frustrating thing is there are no AppVM or dom0 logs that
give me any clue as to where to start chasing down the problem. I have
grep'ed all logs for "qubesdb-daemon" in dom0, and all I can find is
qubes.log is saying it could not start the daemon. Not very helpful.
All log files in /var/log/qubes/qubesdb.VMNAME.log are zero bytes for
all AppVM's that do not run.
Putting the broken AppVM in debugging mode does not help, nor does using
the -p and -v flags on the qvm-[run,start] command lines. Why it won't
start is a total enigma since I can not see any error logs on either
side. Some AppVM's work just fine, while others simply do not. They all
use the exact same fedora-29 template and the same settings that they
had before the backup.
From dom0 qubesvm.py starting at line 1537 I see what appears to be the
relevant code giving my pop-up error message:
try:
yield from self.start_daemon(
qubes.config.system_path['qubesdb_daemon_path'],
str(self.xid),
self.name)
except subprocess.CalledProcessError:
raise qubes.exc.QubesException(
'Cannot execute qubesdb-daemon)
Is this code unable to create a system_path using the xid and appvm
name? Or just read one? A subprocess fork error, or an error deeper
inside some nameless forked process?
Most VM's start normally, so it should not be the "path" to the daemon
executable on either side, as that path and executable is in common with
other VM's that work just fine with the exact same template.
I only thing I see different between these is qvm-prefs is returning xid
== -1 for those that seem not to work, and positive integer values for
those that do work. If the above code is building a path using the -1
xid then this might be a problem?
Could this somehow also be evidence of some kind of lvm pool or qubes
database corruption from the restore process? I don't recall seeing any
error messages during the restore processing, but as it happens, the
ones that do not work were actually VM's restored later in that overall
process. Since they were deemed less important I happened to do them
last. Not sure if that could be relevant here or not, as I have the
exact same system disk space as before. It just sounds suspicious that
the later ones to be restored are the ones that seem to be not running.
Anyone have a clue where else to look for a real error messages? Perhaps
some esoteric dmesg or xl command looking for a xen system error by
another name? Or do I just need to --set a unique xid to each AppVM to
make them start properly?
thanks,
Steve
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/6a1bc3a1-e9ad-2b56-ce38-ddb0c004a9a8%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.
