Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upUpdate cause qubes-mount-dir to not start in R3.2 archlinux template (broken systemd dependency) #2609
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ptitdoc
Jan 28, 2017
The dependency cycle is apparently:
qubes-db > qubes-sysinit > qubes-mount-dirs > local-fs > qubes-db
We need to break either
local-fs > qubes-db
or
qubes-sysinit > qubes-mount-dirs
Any advice ?
ptitdoc
commented
Jan 28, 2017
•
edited
Edited 1 time
-
ptitdoc
edited Jan 28, 2017 (most recent)
edited
-
Jan 28, 2017 (most recent)
|
The dependency cycle is apparently: We need to break either Any advice ? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cryptix
Jan 28, 2017
I saw this as well (programs wouldn't start because /home/user wasn't present) but sometimes it works? Just asking before I create a duplicate issue.
cryptix
commented
Jan 28, 2017
|
I saw this as well (programs wouldn't start because |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ptitdoc
Jan 28, 2017
I suggest replacing in qubes-db.service:
After=local-fs.target systemd-modules-load.service fedora-loadmodules.service
by
After=proc-xen.mount systemd-modules-load.service fedora-loadmodules.service
ptitdoc
commented
Jan 28, 2017
•
edited
Edited 1 time
-
ptitdoc
edited
Jan 28, 2017 (most recent)
edited
-
Jan 28, 2017 (most recent)
|
I suggest replacing in qubes-db.service: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ptitdoc
Jan 28, 2017
@cryptix : There are in fact multiple problems in my case. Are you talking about the archlinux template ?
Which qubes-core-vm package version are you using ? The problem I'm reffering to should occur since version qubes-core-vm 3.2.13.
ptitdoc
commented
Jan 28, 2017
•
edited
Edited 1 time
-
ptitdoc
edited
Jan 28, 2017 (most recent)
edited
-
Jan 28, 2017 (most recent)
|
@cryptix : There are in fact multiple problems in my case. Are you talking about the archlinux template ? Which qubes-core-vm package version are you using ? The problem I'm reffering to should occur since version qubes-core-vm 3.2.13. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cryptix
Jan 28, 2017
Are you talking about the archlinux template ?
yes. only having this with the arch template.
cryptix
commented
Jan 28, 2017
yes. only having this with the arch template. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ptitdoc
Jan 28, 2017
Since qubes-core-vm 3.2.13, the code related to mounting /rw and /home changed so much that it may have solved some race condition observed before 3.2.13.
(cf QubesOS/qubes-core-agent-linux#21)
ptitdoc
commented
Jan 28, 2017
|
Since qubes-core-vm 3.2.13, the code related to mounting /rw and /home changed so much that it may have solved some race condition observed before 3.2.13. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cryptix
Jan 28, 2017
my template has qubes-vm-core 3.2.15-9 and I'm still seeing this.
Granted, it happens sparingly but if it does it usually persists for 5-10 tries of rebooting the appVM.
cryptix
commented
Jan 28, 2017
|
my template has qubes-vm-core 3.2.15-9 and I'm still seeing this. Granted, it happens sparingly but if it does it usually persists for 5-10 tries of rebooting the appVM. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ptitdoc
Jan 28, 2017
It look like the same symptoms. But I really wonder why it works sometimes.
You can try applying the proposed change to /usr/lib/systemd/system/qubes-db.service manually.
ptitdoc
commented
Jan 28, 2017
|
It look like the same symptoms. But I really wonder why it works sometimes. You can try applying the proposed change to /usr/lib/systemd/system/qubes-db.service manually. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ptitdoc
Jan 28, 2017
Somehow, I'm using an old version of qubes-db... and this problem is now fixed...
ptitdoc
commented
Jan 28, 2017
•
edited
Edited 1 time
-
ptitdoc
edited
Jan 28, 2017 (most recent)
edited
-
Jan 28, 2017 (most recent)
|
Somehow, I'm using an old version of qubes-db... and this problem is now fixed... |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ptitdoc
Jan 28, 2017
I'm quite surprised that you use qubes-vm-core-3.2.15. Did you modified things to build it properly?
ptitdoc
commented
Jan 28, 2017
|
I'm quite surprised that you use qubes-vm-core-3.2.15. Did you modified things to build it properly? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jan 28, 2017
Member
Somehow, I'm using an old version of qubes-db... and this problem is now fixed...
Yes, this was fixed as part of #2194. And the fix goes even further than you suggest - remove local-fs.target from dependencies, as in fact /proc/xen is not used anymore (at least by qubes-db).
Yes, this was fixed as part of #2194. And the fix goes even further than you suggest - remove |
marmarek
closed this
Jan 28, 2017
marmarek
added
the
duplicate
label
Jan 28, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cryptix
Jan 28, 2017
Did you modified things to build it properly?
you mean because of the pulseaudio 10 headers and xorg version? well.. I was lucky to build the template before that update landed in archland.
cryptix
commented
Jan 28, 2017
you mean because of the pulseaudio 10 headers and xorg version? well.. I was lucky to build the template before that update landed in archland. |
ptitdoc commentedJan 28, 2017
Qubes OS version (e.g.,
R3.2):R3.2
Affected TemplateVMs (e.g.,
fedora-23, if applicable):archlinux
Expected behavior:
Template boot properly with last qubes-agent
Actual behavior:
Template boots but qubes-mount-dirs does not start. Because of that /home/ is empty and gui-agent fails.
Steps to reproduce the behavior:
General notes:
Jan 28 15:57:53 localhost systemd[1]: local-fs.target: Found ordering cycle on local-fs.target/start
Jan 28 15:57:53 localhost systemd[1]: local-fs.target: Found dependency on qubes-mount-dirs.service/start
Jan 28 15:57:53 localhost systemd[1]: local-fs.target: Found dependency on qubes-sysinit.service/start
Jan 28 15:57:53 localhost systemd[1]: local-fs.target: Found dependency on qubes-db.service/start
Jan 28 15:57:53 localhost systemd[1]: local-fs.target: Found dependency on local-fs.target/start
Jan 28 15:57:53 localhost systemd[1]: local-fs.target: Breaking ordering cycle by deleting job qubes-mount-dirs.service/start
Jan 28 15:57:53 localhost systemd[1]: qubes-mount-dirs.service: Job qubes-mount-dirs.service/start deleted to break ordering cycle starting with local-fs.target/start
Related issues:
QubesOS/qubes-core-agent-linux#21