help updating dom0 - no network - stuck with lots of pending updates

[jasonwals...@gmail.com]

I'm trying to update dom0, (419 Updates Selected).

After searching for infos on qubesOS website and from google, after various attempt, I'm still getting this message from dom0 :

"None of the selected packages could be updated."

When I click "check for new Updates", i'm getting this message :

"There is no network connection available. Please check your connection settings and try again"

I'm still having 419 Updates to make ....

I just upgraded from Qubes Os 3.1 to Qubes release 3.2 (R3.2)

You can find the logs from the command "sudo qubes-dom0-update --clean" here :

http://pastebin.com/Em0W21YV

Any help to properly update my dom0 will be very appreciated.

Thanks

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Dec 12, 2016 at 06:23:40AM -0800, jasonwals...@gmail.com wrote:
> I'm trying to update dom0, (419 Updates Selected).
>
> After searching for infos on qubesOS website and from google, after various attempt, I'm still getting this message from dom0 :
>
> "None of the selected packages could be updated."
>
> When I click "check for new Updates", i'm getting this message :
>
> "There is no network connection available. Please check your connection settings and try again"
>
> I'm still having 419 Updates to make ....
>
> I just upgraded from Qubes Os 3.1 to Qubes release 3.2 (R3.2)

In fact it looks like you're in the middle of upgrade process.

> You can find the logs from the command "sudo qubes-dom0-update --clean" here :
>
> http://pastebin.com/Em0W21YV
>
> Any help to properly update my dom0 will be very appreciated.

If updates are already downloaded (it looks so), you can try running
"sudo dnf update" in dom0 - maybe it will be better at resolving
dependencies.

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYTrrYAAoJENuP0xzK19csdssH/1Nwo/HOJCL9YfNHoPtRMIlV
qcUitez/qCx6q1TNRfXxydZH8dhn65eifiifMVFu9ayO3Jq8cLvPaggTKG2E8CHp
aChLjXkPzFVqbqlR2snIO5pVVGjLzufROHx1Bl5Jerv1oq9xBKEHo5zC6ID9j4zk
krOrtusECq2KMmch41fwIseb0M6E8FYZpkb5aWeuTVi9nG/Xf5evvDCzRzTleZdH
f03sYfEDYuwgXLIQQoByNtV9nribEtFaiv0Rbmlvh2kfBx9ZBJBYHPlzWW2mWJbx
rhufK+uKloqkOulWGH8eKVAen7zF6ki+kCNniaxI+yMQpjcsR3RNeNt+RylIHgo=
=tWtI
-----END PGP SIGNATURE-----

[jasonwals...@gmail.com]

> If updates are already downloaded (it looks so), you can try running
> "sudo dnf update" in dom0 - maybe it will be better at resolving
> dependencies.

[user@dom0 ~]$ sudo dnf update
sudo: dnf: command not found

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Is your sys-firewall based on Debian template? If so, there is
additional step in the upgrade procedure.

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYTxtBAAoJENuP0xzK19csjiQIAJEgCeXCh7wyqKhMiV8rMw2O
yuFA6CajSzUsQwZHR7oIqlwdK41sGlhKaxj1IHbTeSGzuVd0MHCyomMV3U8Dt7LW
/9E++hmk/r7ZYKAV+Ed1mFLFF0XNAZaSj3e8sPdc+plohl+Ccq67cQbPJYPv+z6i
LJRMJ1Ea+ZJMd1cZ187tLA1+QKfJ7tnDhigzLDt8WWHxmsH3NY9K7vYGj5OU7dA+
X32/N+xH4zXD1yTIxz1ffwQ7X9M3Dq9dDx3Xw/t9mN8Mp+q63ASV9PO8/w6rkvzf
LXwhvpqV3kgvk4as1OfRSRczznDLm6h9Pw82V/U5ZhR0OY8al5FkyGF5VnMRkVA=
=zwC5
-----END PGP SIGNATURE-----

[jasonwals...@gmail.com]

> Is your sys-firewall based on Debian template? If so, there is
> additional step in the upgrade procedure.

this is what I've done :

sudo qubes-dom0-update systemd-compat-libs perl-libwww-perl perl-Term-ANSIColor perl-Term-Cap gdk-pixbuf2-xlib speexdsp qubes-mgmt-salt-admin-tools lvm2

--> n

sudo qubes-don0-update --clean

this is the results of "yum info qubes-core-dom0" :

Installed Packages
Name : qubes-core-dom0
Arch : x86_64
Version : 3.1.18
Release : 1.fc20
Size : 1.7 M
Repo : installed
From repo : qubes-dom0-cached
Summary : The Qubes core files (Dom0-side)
URL : http://www.qubes-os.org
License : GPL
Description : The Qubes core files for installation on Dom0.

Available Packages
Name : qubes-core-dom0
Arch : x86_64
Version : 3.2.12
Release : 1.fc23
Size : 328 k
Repo : qubes-dom0-cached
Summary : The Qubes core files (Dom0-side)
URL : http://www.qubes-os.org
License : GPL
Description : The Qubes core files for installation on Dom0.

I'm still stuck with 411 pending updates.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-12-13 05:42, jasonwals...@gmail.com wrote:
>
>> Is your sys-firewall based on Debian template? If so, there is
>> additional step in the upgrade procedure.
>
> this is what I've done :
>
> sudo qubes-dom0-update systemd-compat-libs perl-libwww-perl perl-Term-ANSIColor perl-Term-Cap gdk-pixbuf2-xlib speexdsp qubes-mgmt-salt-admin-tools lvm2
>
> --> n
>
> sudo qubes-don0-update --clean
>

I would think that the "--clean" option would immediately discard all the packages you downloaded in the previous step. Perhaps this is why the instructions state that the above step should be attempted without "--clean" at first. But then it's puzzling that the instructions go on to recommend repeating the previous step with the "--clean" option if qubes-core-dom0 didn't update properly.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYUV08AAoJENtN07w5UDAwSvwP/1sNq3fETXDd7j0Q2WXUJoOX
23WYNRuFybHOWCN84UqJeWKheDUP/+A3YCPrMqzWns5b+TXKNVwkEWUMP4sWCKyI
o3PQUIY1SfQ/tVsvhzg/4SotQEUBKaqfcyZITa7bsFRvXsnMEDCiUJdwZlLw27rO
sYmBFMaU7HyR+Q/cCLlP7BWGCV4WfsQTTPkbGWSNLvQz6zhcvHlNAJzo79KbTB2a
XEDLy3yKWF+xMnu6R7LlYA/nFSCck2qLmbG8nZUi/BH0n4TIc08p8JibHsQMihij
HufFJoiDF5DoCP25M55sL6ospNYbN9UoyBJI/RafnDFpGogJD4UFLi2J5sYOtvpJ
yqguGBNgqSjEE0+fWVz++TlofqPSkKK2OJ0slegB4yI82gPaSMnaFaWO2xTqjWCB
ug39X52uGpPF6fFhpIes3s6KXDaXhXFBnyyM4Wn4fMspOQgvkfvdmefHlXesNhfW
xhq+BQPYFl0/2ycZB6p876mAL1lt2X+yLF0phkRLsrzyQ7Xv8Fr27b6IhUxvt7UR
ECnXXC3U2KcTt6Yd0gHCj6538U8pulSXtjFBhvVoNNWX2ndphDZ+LwN2HQ0UzoUb
UEOndl22iPPR+ycsEdU1/4i2UQEX0S4s2E8wl7LPrXQLyBTON8Q0nsUI2ixNv6uW
KAKBvvQ/AOVbneOju1N6
=ey7j
-----END PGP SIGNATURE-----

[jasonwals...@gmail.com]

After running this process a couple times :

https://www.qubes-os.org/doc/upgrade-to-r3.2/

I think I was able to upgrade to 3.2, but with new problems

Here's the results for "yum info qubes-core-dom0" :

Redirecting to '/usr/bin/dnf info qubes-core-dom0' (see 'man yum2dnf')

Failed to synchonize cache for repo 'updates', disabling.
Failed to synchonize cache for repo 'fedora', disabling.
Failed to synchonize cache for repo 'qubes-templates-itl', disabling.
Failed to synchonize cache for repo 'qubes-dom0-current', disabling.

Installed Packages:
Name : qubes-core-dom0
Arch : x86_64

Version : 3.2.12
Release : 1.fc23
Size : 1.7 M
Repo : @System

Summary : The Qubes core files (Dom0-side)
URL : http://www.qubes-os.org
License : GPL
Description : The Qubes core files for installation on Dom0.

I also notice that there is no more wifi network.

And when I try to start a VM i get this message :

"Error starting VM 'email': Error: Failed to connect to qmemman: [errno 2] no such file or directory"

Anyone can help to properly finish this upgrade to 3.2 process ?

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Did you proceed to upgrade your TemplateVMs according to the instructions after upgrading dom0?

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYUXUoAAoJENtN07w5UDAweBEP/igz1PgdnzY+DKhTjDiAZmj/
KTIM52T7oL+eF2xnQs/cYV+NHNgPzcQTvVEC2+Wkhus7cXBRqK9vI9RL1uVo6nAe
8aQpib0uCwPiGhhCXP65NLb+BFxafslpJhqyoz9SEZ3k9DVpknR/GrRM4/r63qBj
8fuWdaBDT+3AZtwXRsSyh/ic+hzcw6+UKKY3NZg+mnF3THOQh+699PkeXiuHVW6l
UMpASV6W+HJbKikCXUCJI8QdD603WOI4qgM6uIzrxKUlW/jcNKlOYJ4eylZ1Csvc
6EPJt4NqjsLm+N+MMH90tr6aMiW5Cy6FQcOTWGS/KTRzUxLqNtSoMxpaoxIybZ7q
Y/CiSq4THgS1AUoqsLsW4uti5cuAPgThh3cXnpkXhITnNafGQ2Uiu45GmTH0bstz
9NqT7HHsue6lg0EDDH1ug0WlsGmGrr2OdqTkDHLxDbZGGmHuEqHohzEqQwdSWe3a
ngVMdl7wTGl6hDUjwwYKLKHGJyrlNenQ5kjNp+wg4jz1bfXr26FcM59AHsIPM5je
6XSHfQRY5OBp/63VbodBhmTyG2JgMtUyLTj6l8B+87zDsai8f05EceFWNE2+gS5B
jBEy5AeDJSKFOYwYeVuQH9veoDY+YmYa97bUfslVDONAJ1VOjIZIBaecfktcI8jx
aY6jYJJa8tkyTP4CRm4S
=NZ5p
-----END PGP SIGNATURE-----

[jasonwals...@gmail.com]

> Did you proceed to upgrade your TemplateVMs according to the instructions after upgrading dom0?

after rebooting as decribe in step #7 from upgrading dom0 (Reboot Dom0) :

Only dom0 is in an active state.

When i try to start a terminal for Template: debian-8, i get this message :

"Starting the 'debian-8' VM ... error while starting the debian-8 'VM': ERROR: failed to connect to qmemman : [errno 2] no such file or directory"

So no i didn't proceed to upgrade my TemplateVMs ... I'm not able to open a terminal ! (And trying to update from Qubes VM Manager gives me the same message)

Also, I don't see how I can upgrade something new if I can't connect to a network (not even wired)

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Yes, I see the problem. It sounds like your ServiceVMs are based on
debian-8. Have you tried basing them on the default Fedora template
instead?

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYUlwbAAoJENtN07w5UDAwcM0QALETdNr/RNlVXl3aNUazbqg+
GZsMycesGu/n8E15fnxjUwcBGfDdXIwdXZHVxCQkpx0Z3CbtuqmKyVwsjjkj2bxu
h/kMV6oWkOe2jC4SxfrGpf1xQPxypMcPcp+PFPZ9/y6UeETjRqONlGfyqfCTPhla
TbQg6xIJhPwEx7AfyAimej3RS+bj2z25Fqwc0x2zZhlZQMndNcNVFWvjurf1wUrm
+segczlMbpIhnu/LUsEHwCgaLmvw6f4GIuqdLtvX95X/8rjpKyo8k1MxDP+/5Sql
Xr+1WaM1WJYK78B03AFdlnXg+pu4la0r0oSlim1+YIY+CXVUjHLM2y7QiDukebfF
p5cuImbG4NJ0GMhggnGa/HO8r1LfTL0Qwne3GHPQh7J6fk/NF1L6jkkdWO9ILW6w
erLIF0fLOahf4F4HYUGux40JOFJfehbVmkwSTdq8dELT1XUvjzXL7KttGAoBOfO0
CrW5WUNsIdT2xBSTjnM4Jpww+n0qOI6rWwbjftu7/pCf18P8T6GD2ncVnDqo21y6
YQsG/La+PA0J8eOyDJfHMjXIRLgp/YxbLdYRUwlK0hSatoSvLBL6rNXvxHnlxdE3
njIp9ANqYpVAtFEjbBF4tl7YnHjvPvkJLsRUQeXve7/9aNt6BJg6TYW5Rdnby03v
wHgciezqBB+PRusWDG4Y
=wdlo
-----END PGP SIGNATURE-----

[jasonwals...@gmail.com]

> Yes, I see the problem. It sounds like your ServiceVMs are based on
> debian-8. Have you tried basing them on the default Fedora template
> instead?

Ok, I have now assign sys-net & sys-firewall to fedora-23 TemplateVM, I still have the same qmemman error.

Is it normal that when I start my computer (after decryption) that my desktop looks like this (this is also how my desktop looked like before the upgrade) :

https://s23.postimg.org/tgs6vy8yj/006.jpg

and now (after the upgrade) looks like this :

https://s30.postimg.org/o1ot24zoh/007.jpg

In the last picture you can see that only dom0 is in active state with 3934 MB as MEM. (its always at 3934 MB)

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-12-15 05:35, jasonwals...@gmail.com wrote:
>
>> Yes, I see the problem. It sounds like your ServiceVMs are based
>> on debian-8. Have you tried basing them on the default Fedora
>> template instead?
>
> Ok, I have now assign sys-net & sys-firewall to fedora-23
> TemplateVM, I still have the same qmemman error.
>

- From this thread:

https://groups.google.com/d/topic/qubes-users/s3FJWqKw6Ps/discussion

'Please check "sudo systemctl status qubes-qmemman", or better "sudo
journalctl -u qubes-qmemman" for error messages. Then you can restart
the service with "sudo systemctl restart qubes-qmemman".'

> Is it normal that when I start my computer (after decryption) that
> my desktop looks like this (this is also how my desktop looked like
> before the upgrade) :
>
> https://s23.postimg.org/tgs6vy8yj/006.jpg
>
> and now (after the upgrade) looks like this :
>
> https://s30.postimg.org/o1ot24zoh/007.jpg
>

Looks pretty normal to me. Is there any particular part that seems
abnormal to you?

> In the last picture you can see that only dom0 is in active state
> with 3934 MB as MEM. (its always at 3934 MB)
>

Since you don't have any other VMs running, all available memory is
allocated to dom0. Normally, it would be dynamically reallocated as
you start more VMs (but I know that you can't currently start any more
VMs).

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYUp5mAAoJENtN07w5UDAwfHYQAKuDJJ2joI//RxX2jNk0A8CP
/fQvhCeSu2rg6YD82TcItTiLUVSCaOp7DymJCosMxQDeW2VE9syjMtxI58nDWEjZ
i0UbeX/9S+Z+O90l3PKnPZRuNDMMPdxi/lT5k7QPT6eTBl7Lw5jaM4ROt1PJxHsf
FaqsfKVe436SSoutLnZWAvAT7CWUJ6LJJwKyZjCEzvM6D77LWGvKnzzxsyhZ71Vx
qvBn0jd5yJrHXawblDdhYFAaqSFa7+n70GLc+Oby7CbZXV3hB4XMf5xaqjddorE+
NU/rw8si1L08iz9o8qV7BH6xnUk0vX4u4lfJES7axPbBO8F554Bt3HIeLDuzIZO7
9ZqFuyfnud6WxB4B9oMjkXsjCLkvGqFKcBPgFG9MGccGF3sEiSPBnggnPMVCvYsE
nNx7OV6XkbGWzI8W+N+5Qzd5uZj/64kI8WMXjjBQoVK4UoQCppikNpjgxRylyOXI
wCP5Bn/bj09bouU7pYq8RMNxEUH2NNpIsqY5RkTYGvgEpJycgY9VrcgSMG2MlmMm
1Jy71by1k/NwNc19pW8rqnJ520+M1sCnD/+CHdvRMbERdqid+4bHC1nL+lHxXYlD
nURBd6fMWDiQ4FTFI9zKvDM/T5x8ko6pUo7ap15SVqYPCfA0yCYtNMSljuRFl/BZ
VZQfIlNB9Jyh19MWe2oU
=7FFV
-----END PGP SIGNATURE-----

[jasonwals...@gmail.com]

> - From this thread:
>
> https://groups.google.com/d/topic/qubes-users/s3FJWqKw6Ps/discussion
>
> 'Please check "sudo systemctl status qubes-qmemman", or better "sudo
> journalctl -u qubes-qmemman" for error messages. Then you can restart
> the service with "sudo systemctl restart qubes-qmemman".'

results for "sudo systemctl status qubes-qmemman" (I'm not able to transfer logs to another computer from dom0 at the moment so i need to write the logs ...) :

Active: failed (Results: exit-code)
Process: 2081 ExecStart=/usr/lib/qubes/qmemman_deamon.py (code=exited, status=1/FAILURE)
Main PID: 2081 (code-exited, status=1/FAILURE)

qmemman_deamon.py[2081]: self.connect_unixsocket(address)
qmemman_deamon.py[2081]: File "/usr/lib64/python2.7/logging/handlers.py" line 789, in connect_unixsocket
qmemman_deamon.py[2081]: self.socket.connect(address)
qmemman_deamon.py[2081]: File "/usr/lib64/python2.7/socket.py", line 228, in meth
qmemman_deamon.py[2081]: return getadttr(self._sock,name)(*args)
qmemman_deamon.py[2081]: socket.error: [errno 111] Connection refused

systemd[1]: qubes-qmemman.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start Qubes memory management deamon
systemd[1]: qubes-qmemman.service: Unit entered failed state.
systemd[1]: qubes-qmemman.service: Failed with result 'exit-code'

it seams to be the same error for "sudo journalctl -u qubes-qmemman"

In Qubes VM manager, when I right click on dom0 and then click on VM settings, nothing happens, I can infinitly click on "VM settings". This does not apply to other VMs.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/15/16 07:10, jasonwals...@gmail.com wrote:
>
>> - From this thread:
>>
>> https://groups.google.com/d/topic/qubes-users/s3FJWqKw6Ps/discussion
>>
>> 'Please check "sudo systemctl status qubes-qmemman", or better "sudo
>> journalctl -u qubes-qmemman" for error messages. Then you can restart
>> the service with "sudo systemctl restart qubes-qmemman".'
>
>
>
> results for "sudo systemctl status qubes-qmemman" (I'm not able to transfer logs to another computer from dom0 at the moment so i need to write the logs ...) :
>
> Active: failed (Results: exit-code)
> Process: 2081 ExecStart=/usr/lib/qubes/qmemman_deamon.py (code=exited, status=1/FAILURE)
> Main PID: 2081 (code-exited, status=1/FAILURE)
>
> qmemman_deamon.py[2081]: self.connect_unixsocket(address)
> qmemman_deamon.py[2081]: File "/usr/lib64/python2.7/logging/handlers.py" line 789, in connect_unixsocket
> qmemman_deamon.py[2081]: self.socket.connect(address)
> qmemman_deamon.py[2081]: File "/usr/lib64/python2.7/socket.py", line 228, in meth
> qmemman_deamon.py[2081]: return getadttr(self._sock,name)(*args)
> qmemman_deamon.py[2081]: socket.error: [errno 111] Connection refused
>
> systemd[1]: qubes-qmemman.service: Main process exited, code=exited, status=1/FAILURE
> systemd[1]: Failed to start Qubes memory management deamon
> systemd[1]: qubes-qmemman.service: Unit entered failed state.
> systemd[1]: qubes-qmemman.service: Failed with result 'exit-code'
>
> it seams to be the same error for "sudo journalctl -u qubes-qmemman"
>

And what happens when you restart qubes-qmemman?

> In Qubes VM manager, when I right click on dom0 and then click on VM settings, nothing happens, I can infinitly click on "VM settings". This does not apply to other VMs.
>

That menu option doesn't do anything for dom0, so what you describe is normal. (But admittedly sub-optimal from a UX perspective. We're working on that.)

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYUsWtAAoJENtN07w5UDAwh1gQAI5+SFxp5jtNF4DPfhsSei45
gaI8OQq9RyWvEzLp2lbm/QSefPkLaD8Y7sEi+RYV4n/WRbO/yqIbQK+9ZK5anJ7f
xxIzZYepoSDQYbcuCrBrJFioStby4oqF6XJRsmY12MfAKo4A2kdjz5Xu/ZES+si7
6CndMBoUReEtWFhrODr/e5Fwr6m4WcugkejqgooiIUt6IAPhsDlyFOxuvt44UMmX
5cI0aPJPiKlCCkQ2p+ML7QXinb6Ua7KlYyhcN53YejXxrTt06JxWBdEsFiY2n11k
xcI7cOm4awNdKl2OGT4mLacr85wspPGohjgQ1mzfpQ+CO+LOdxLoCpF2oYgrxAL6
BWZTVRsyJ2hv4N7HftsDL5WpFaNtIiM99vxspwhV8h4D8YQd+Ho7ryZeCdR6eJKe
gJL6VqaYRPPYo3E54Z7e1DO2CbwVLZ7aSu3KnNCu0GE55iaQesc6U2cFzjrs39Dt
i10urGtRPndeaDbBiHbWVedaUGxXW7GQPC5KYtyKILzKPrwewn6WXiN8oVzWsIbK
vw4KXrVuX6KKZij80zyTVoqx1MyNoir/24hSscSYXoFyD7zHFs/bxmsSSXoOvNYm
+V02F2UDS1FS2O4VE6pCYilHyyClf9qVGtq5drEQEZm7Rnims5NA6wNgSn5GBgv9
0KxZ0TCW9zw0/3f6i1he
=cMkb
-----END PGP SIGNATURE-----

[jasonwals...@gmail.com]

> And what happens when you restart qubes-qmemman?

this :

Job for qubes-qmemman.service failed because the control process exited with error code. See "systemctl status qubes-qmemman.service" and "journalctl -xe" for details.

"sudo systemctl status qubes-qmemman.service" returns the same kind of error as "sudo systemctl status qubes-qmemman" and "sudo journalctl -xe" is a bit long to copy, let me know if there is something specific to look there.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Dec 15, 2016 at 07:10:12AM -0800, jasonwals...@gmail.com wrote:
>
> > - From this thread:
> >
> > https://groups.google.com/d/topic/qubes-users/s3FJWqKw6Ps/discussion
> >
> > 'Please check "sudo systemctl status qubes-qmemman", or better "sudo
> > journalctl -u qubes-qmemman" for error messages. Then you can restart
> > the service with "sudo systemctl restart qubes-qmemman".'
>
>
>
> results for "sudo systemctl status qubes-qmemman" (I'm not able to transfer logs to another computer from dom0 at the moment so i need to write the logs ...) :
>
> Active: failed (Results: exit-code)
> Process: 2081 ExecStart=/usr/lib/qubes/qmemman_deamon.py (code=exited, status=1/FAILURE)
> Main PID: 2081 (code-exited, status=1/FAILURE)
>
> qmemman_deamon.py[2081]: self.connect_unixsocket(address)
> qmemman_deamon.py[2081]: File "/usr/lib64/python2.7/logging/handlers.py" line 789, in connect_unixsocket
> qmemman_deamon.py[2081]: self.socket.connect(address)
> qmemman_deamon.py[2081]: File "/usr/lib64/python2.7/socket.py", line 228, in meth
> qmemman_deamon.py[2081]: return getadttr(self._sock,name)(*args)
> qmemman_deamon.py[2081]: socket.error: [errno 111] Connection refused

This looks like a problem with connecting to syslog. Do you have
/dev/log in place? It should be something like this:

[marmarek@dom0 ~]$ ls -l /dev/log
lrwxrwxrwx 1 root root 28 Dec 13 23:57 /dev/log -> /run/systemd/journal/dev-log

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYU1b5AAoJENuP0xzK19cs3jQIAI2HSt3yo5VWeoKwHaSlD0j4
JJ6EUlxDvq2LNmBXGRIEZhtmFSSqVvIaDsb2WLeC9B6D1N+3MV1BMGpfC5bPWq1u
IiYe1kG1454W9wMTjZOx7QfqAU3eXSnWSeTCg+6itts7RBcu/1ShWg9H0S5Krq+e
Lz1AWEUc8fOfhKf3Vq6on3rc+ACA8/OV+4jS3xG4pRFDu5TdUNBvl1p2GiDuS4HY
HwqiigW1yJxLvObqRxN8bfncgQadugnkJy7q9kNab21Khs+YNVUe+Ni62KHnoQdB
N3UzeiXl6q3lTG1LQGwBCcAtCvKISK5AysE83gZnEDL3Xaela5GFwkEczvi/PL0=
=g9mO
-----END PGP SIGNATURE-----

[jasonwals...@gmail.com]

> This looks like a problem with connecting to syslog. Do you have
> /dev/log in place? It should be something like this:
>
> [marmarek@dom0 ~]$ ls -l /dev/log
> lrwxrwxrwx 1 root root 28 Dec 13 23:57 /dev/log -> /run/systemd/journal/dev-log

[user@dom0 ~]$ ls -l /dev/log
srw-rw-rw- 1 root root 0 Dec 16 07:32 /dev/log
[user@dom0 ~]$/run/systemd/journal/dev-log
bash: /run/systemd/journal/dev-log: Permission denied
[user@dom0 ~]$ sudo /run/systemd/journal/dev-log
sudo: /run/systemd/journal/dev-log: command not found

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Dec 16, 2016 at 04:58:35AM -0800, jasonwals...@gmail.com wrote:
>
> > This looks like a problem with connecting to syslog. Do you have
> > /dev/log in place? It should be something like this:
> >
> > [marmarek@dom0 ~]$ ls -l /dev/log
> > lrwxrwxrwx 1 root root 28 Dec 13 23:57 /dev/log -> /run/systemd/journal/dev-log
>
>
> [user@dom0 ~]$ ls -l /dev/log
> srw-rw-rw- 1 root root 0 Dec 16 07:32 /dev/log

So, you have a socket here instead of symlink.

> [user@dom0 ~]$/run/systemd/journal/dev-log
> bash: /run/systemd/journal/dev-log: Permission denied
> [user@dom0 ~]$ sudo /run/systemd/journal/dev-log
> sudo: /run/systemd/journal/dev-log: command not found

It isn't a command, it should be a socket. But apparently it doesn't
exist. Check status of systemd unit providing it:

systemctl status systemd-journcald-dev-log.socket

You may want to remove /dev/log and restart above unit (sudo systemctl
restart systemd-journcald-dev-log.socket).

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYVALEAAoJENuP0xzK19cskfUH/RJ71R7b8Ew5Z2BJJAPQdOBg
gjOhkwlu03xrtG7KOt6RFRG+ZONrFLFXROJBDBphlpgkzktagR4PkCrN9P7V5Uky
6Y6TwNHhzDYJnwJhEbwpD3zL63U+ZKXrvH3VYla6e5XsNsaDqQPke5nqXS+3jrL0
6K8CEvN2kj4IOKxd5qQ3WmNoLqwOmPuHWzsvmrRxtY1f71RmHW8o0YXrF4TXG5ap
t/qis2Y3MV11dNCVRiQXjIRrVX15IQg+ZeDPGiW/yesKnCuBkOiBv9LmF12PRgFA
063diMwYbnmfI/2K2l28CtOzV7sWCV4AZdrONidoY76TIXjUKRi33Razz5kIjSc=
=RPif
-----END PGP SIGNATURE-----

[ve2...@gmail.com]

> It isn't a command, it should be a socket. But apparently it doesn't
> exist. Check status of systemd unit providing it:
>
> systemctl status systemd-journcald-dev-log.socket
>
> You may want to remove /dev/log and restart above unit (sudo systemctl
> restart systemd-journcald-dev-log.socket).

[user@dom0 ~]$ systemctl status systemd-journcald-dev-log.socket
systemctl status systemd-journcald-dev-log.socket
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
[user@dom0 ~]$ sudo rm -rf /dev/log
[user@dom0 ~]$ systemctl status systemd-journcald-dev-log.socket
systemctl status systemd-journcald-dev-log.socket
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
[user@dom0 ~]$

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Dec 16, 2016 at 07:59:34AM -0800, ve2...@gmail.com wrote:
>
> > It isn't a command, it should be a socket. But apparently it doesn't
> > exist. Check status of systemd unit providing it:
> >
> > systemctl status systemd-journcald-dev-log.socket

A typo here, should be systemd-journald-dev-log.socket

> >
> > You may want to remove /dev/log and restart above unit (sudo systemctl
> > restart systemd-journcald-dev-log.socket).
>
> [user@dom0 ~]$ systemctl status systemd-journcald-dev-log.socket
> systemctl status systemd-journcald-dev-log.socket
> Loaded: not-found (Reason: No such file or directory)
> Active: inactive (dead)
> [user@dom0 ~]$ sudo rm -rf /dev/log
> [user@dom0 ~]$ systemctl status systemd-journcald-dev-log.socket
> systemctl status systemd-journcald-dev-log.socket
> Loaded: not-found (Reason: No such file or directory)
> Active: inactive (dead)
> [user@dom0 ~]$
>
>

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYVC3IAAoJENuP0xzK19csWyYIAIgk5DcD9RrMkYKh5ihFKCEy
kE3ugCML3gcLzV46selOk1J5Ye7mo2z1QKCJ/gIbwuFYzLp2tSXdI4BOZxgrKl1x
Cxl8cY5OvbYtZzZxBCJvYaeIrp4qBQnQjgyqE+7rT1TuPJnC0bGNMPXiXku89qM6
0f1x7udjo2zWqrQb+LE7/RMM7iBgKLAs2X+1m5NfbDl9Ddx43vXYfLpLzQ5qn0Zy
/7WY+AuZnQcZsoBRYcFX7JuHO8v8hHtLTYVScG5MukfaHAvZtJtcXNZq3bss0V4M
d+O7UE/sMN/2kf6qIVHAej34K4fEP8oxMa+Cy9CbBTGNae9tfDrKNb+z/a6oZy4=
=IPIc
-----END PGP SIGNATURE-----

[jasonwals...@gmail.com]

> > > It isn't a command, it should be a socket. But apparently it doesn't
> > > exist. Check status of systemd unit providing it:
> > >
> > > systemctl status systemd-journcald-dev-log.socket
>
> A typo here, should be systemd-journald-dev-log.socket

[user@dom0 ~]$ systemctl status systemd-journal-dev-log.socket
systemd-journal-dev-log.socket - Journal Socket (/dev/log)
Loaded: loaded (/usr/lib/systemd/system/systemd-journal-dev-log.socket; statis; vendor preset: disabled)
Active: inactive (dead) since Sat 2016-12-17 00:26:10 EST; 1min 49s ago
Docs: man:systemd-journal.service(8)
man:journald.conf(5)
Listen: /run/systemd/journal/dev-log (Datagram)

Dec 17 00:26:10 dom0 systemd[1]: Stopping Journal Socket (/dev/log).
Dec 17 00:26:10 dom0 systemd[1]: systemd-journald-dev-log.socket: Socket service systemd-journald.service already active, refusing.
Dec 17 00:26:10 dom0 systemd[1]: Failed to listen on Journal Socket (/dev/log).

[user@dom0 ~]$ sudo rm -rf /dev/log

[user@dom0 ~]$ sudo systemctl restart systemd-journald-dev-log.socket
Job for systemd-journald-dev-log.socket failed. See "systemctl status systemd-journald-dev-log.socket" and "journalctl -xe" for details.
[user@dom0 ~]$

[jasonwals...@gmail.com]

There is a typo in my last message but it was written as "journald-dev-log" rather than "journal-dev-log".

Is there something to do with my problems with dom0 ? At the bare minimum I would like at least to recover my files from my VMs.

Thanks

[raah...@gmail.com]

I had similar probs. clean install is way to go in future imo. Backups restored no problems. Only tip is if you make alot of changes to the default templates. clone them instead and use the clone for your vms, to ensure they get restored properly when backed up. But appvms should be no probs.

[jasonwals...@gmail.com]

Luckily, I was able to backup all my VMs from the state my computer was.

I did a clean install, now Qubes work as it should.

Just one thing : I want to use my backed up "debian-8" TemplateVM, how can I replace the original "debian-8" ? I'm not able to delete it and as long as its there I won't be able to retore my backed up "debian-8" Template VM.

All my appVMs restored without problems.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Dec 22, 2016 at 06:03:06AM -0800, jasonwals...@gmail.com wrote:
> On Tuesday, December 20, 2016 at 5:56:40 PM UTC-5, raah...@gmail.com wrote:
> > On Tuesday, December 20, 2016 at 9:11:58 AM UTC-5, jasonwals...@gmail.com wrote:
> > > There is a typo in my last message but it was written as "journald-dev-log" rather than "journal-dev-log".
> > >
> > > Is there something to do with my problems with dom0 ? At the bare minimum I would like at least to recover my files from my VMs.
> > >
> > > Thanks
> >
> > I had similar probs. clean install is way to go in future imo. Backups restored no problems. Only tip is if you make alot of changes to the default templates. clone them instead and use the clone for your vms, to ensure they get restored properly when backed up. But appvms should be no probs.
>
> Luckily, I was able to backup all my VMs from the state my computer was.
>
> I did a clean install, now Qubes work as it should.

Glad to hear that :)

> Just one thing : I want to use my backed up "debian-8" TemplateVM, how can I replace the original "debian-8" ? I'm not able to delete it and as long as its there I won't be able to retore my backed up "debian-8" Template VM.

Command line version of restore tool (qvm-backup-restore) allow you to
rename conflicting VMs (--rename-conflicting). The template will be
restored under different name (with "1" at the end), then you can switch
your VMs to that template. And after you switch all the VMs, you can
remove old template, and possibly rename the restored one back to
debian-8.

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYW93FAAoJENuP0xzK19csBAsH/1NeF4yUS64awIVO7Ompaffz
3MGhXe/Albnwfc9bMJe0Cc3XkXWp/XOWZfURKvndXecku4N/QFcNxxbT+APDb8SN
ZddlxIO/CR8ch2Y1XhGYp41+LLv9yriBOaeWkMbGSdlEUdJ7Hhx1HPMjkbh8FyBk
NsiVb4qovC2MMXinbsDdAiYxfLFrmBZ/CGb1/p6O5K/9zU6NcujkfLWSeFjkWjJC
OgT+Nx6iFWTFAKAkbdGL2bQfe74WDHOs3g8e58po3OmW2eISjCJz1Ijbbc+apnfy
vm+5ZUYlcEvNenMwUEEzxuZ8ljY9dgul2ilATO0qw2YQGHvFI+fIHPktGBDM76A=
=y9Tj
-----END PGP SIGNATURE-----

[jasonwals...@gmail.com]

> > Just one thing : I want to use my backed up "debian-8" TemplateVM, how can I replace the original "debian-8" ? I'm not able to delete it and as long as its there I won't be able to retore my backed up "debian-8" Template VM.
>
> Command line version of restore tool (qvm-backup-restore) allow you to
> rename conflicting VMs (--rename-conflicting). The template will be
> restored under different name (with "1" at the end), then you can switch
> your VMs to that template. And after you switch all the VMs, you can
> remove old template, and possibly rename the restored one back to
> debian-8.

I was able to restore all VMs with this command :

"qvm-backup-restore -d sys-net --rename-conflicting /run/media/user/New\ Volume/qubesbackup/qubes-2016-12-21T080046"

so now my (backed up) "debian-8" is "debian-81". It had been updated.

some AppVMs start properly, others doesn't : with this error message :

"Error starting VM: Requested operation is not valid: PCI device 0000:00:19:.0 is in use by driver xenlight, domain sys-net"

Is there something to do to access those VMs ?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Dec 22, 2016 at 08:40:02AM -0800, jasonwals...@gmail.com wrote:
> I was able to restore all VMs with this command :
>
> "qvm-backup-restore -d sys-net --rename-conflicting /run/media/user/New\ Volume/qubesbackup/qubes-2016-12-21T080046"
>
> so now my (backed up) "debian-8" is "debian-81". It had been updated.
>
> some AppVMs start properly, others doesn't : with this error message :
>
> "Error starting VM: Requested operation is not valid: PCI device 0000:00:19:.0 is in use by driver xenlight, domain sys-net"
>
> Is there something to do to access those VMs ?

Check what netvm is set for those VMs. I guess currently you have two of
them: sys-net and (just restored) sys-net1. Choose which one you want to
use and remove the other.

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYXE9mAAoJENuP0xzK19cs0w0H/RowEeL3+27Z2dXBkjuHiXfh
JUeCXhJ67Ho7yLbtdYfwJSgSG3QJrApaKq+9FN/IJ6n6Qw64LC6ahHg4QHacUe4M
6yEXUTVUh5dTqhfq4hNxd69EfqlOq2BHTDDCwEe3ZI90AwARYATIvzO6t2+wY7EW
S6e3Zcbu6C9pw9+5t0VsnvClkwFgSDNbSnR6h0sIzo3EthN/y1w3jVdD+qc2VHUH
6/cGbnzBCEZbksspOU1/gZU7rk5fIpqZuQD48ADMwm8WB0AxVcgFT67gKJv62+5k
gQDYtIEXS4lxjiaib80p2KYzAGNQicuDM7P77tJYiLDepAJgTcsbM7B0CS3uYAg=
=ZCiV
-----END PGP SIGNATURE-----

[jasonwals...@gmail.com]

> Check what netvm is set for those VMs. I guess currently you have two of
> them: sys-net and (just restored) sys-net1. Choose which one you want to
> use and remove the other.
>

Thanks a lot Marek and Andrew for your help and patience. I now have access to all my AppVMs.