R4.0 with fedora 28 template sys-net fails to sync time
39 views
Skip to first unread message
Alex
Sep 15, 2018, 3:45:34 PM9/15/18
to qubes-users
Hi all,
I happen to have run into the problem as per the subject. What happened
is this:
* I recently installed a fully clean R4.0 system, with default templates
and sys-* qubes (this means fedora 26)
* I upgraded the default template, after cloning it, to fedora 28
* This means that now I have a fedora-28 based sys-net
* The system fails to sync the time to NTP servers
What I debugged until now:
* in sys-net, the service systemd-timesyncd should start and update the
time - it's enabled by default
* it does not, because it fails to start due to some inaccessible
directory that is not detailed in the logs
* googling around I found that it looks like one of the usual
surprise-ridden features of systemd, namely DynamicUser, that seems to
have problems with FUSE mounts and the custom-namespace-based isolation
(https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdTimesyncdFailure?showcomments).
I'm thinking this issue is manifesting itself with some of the Qubes
infrastructure.
Does anybody have a recommended way of fixing this, that avoids just
waiting for the systemd guys to fix this? I don't like the idea of
editing systemd's "packaged" unit files, nor am I willing to go set
weird permission / mount options for qubes' directory mounts. What I'd
like to have is a way of having dom0's time set from a network (NTP)
source without necessarily having to successfully set the time in my
sys-net.
What I'm thinking of doing is having a separate clock vm, with a more
standard ntpd, but I'm not sure of the network "position" inside qubes -
will it be enough to give it "sys-net" as the network vm?
Thanks in advance for any guidance...
--
Alex
I happen to have run into the problem as per the subject. What happened
is this:
* I recently installed a fully clean R4.0 system, with default templates
and sys-* qubes (this means fedora 26)
* I upgraded the default template, after cloning it, to fedora 28
* This means that now I have a fedora-28 based sys-net
* The system fails to sync the time to NTP servers
What I debugged until now:
* in sys-net, the service systemd-timesyncd should start and update the
time - it's enabled by default
* it does not, because it fails to start due to some inaccessible
directory that is not detailed in the logs
* googling around I found that it looks like one of the usual
surprise-ridden features of systemd, namely DynamicUser, that seems to
have problems with FUSE mounts and the custom-namespace-based isolation
(https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdTimesyncdFailure?showcomments).
I'm thinking this issue is manifesting itself with some of the Qubes
infrastructure.
Does anybody have a recommended way of fixing this, that avoids just
waiting for the systemd guys to fix this? I don't like the idea of
editing systemd's "packaged" unit files, nor am I willing to go set
weird permission / mount options for qubes' directory mounts. What I'd
like to have is a way of having dom0's time set from a network (NTP)
source without necessarily having to successfully set the time in my
sys-net.
What I'm thinking of doing is having a separate clock vm, with a more
standard ntpd, but I'm not sure of the network "position" inside qubes -
will it be enough to give it "sys-net" as the network vm?
Thanks in advance for any guidance...
--
Alex
Marcus Linsner
Sep 15, 2018, 7:29:27 PM9/15/18
to qubes-users
Alex
Sep 16, 2018, 4:23:39 AM9/16/18
to qubes...@googlegroups.com
On 9/16/18 1:29 AM, Marcus Linsner wrote:
> On Saturday, September 15, 2018 at 9:45:34 PM UTC+2, Alex wrote:
>> Hi all,
>> I happen to have run into the problem as per the subject. What happened
>> is this:
>> [..]
> On Saturday, September 15, 2018 at 9:45:34 PM UTC+2, Alex wrote:
>> Hi all,
>> I happen to have run into the problem as per the subject. What happened
>> is this:
>> * The system fails to sync the time to NTP servers
>>
>
Thank you; I really should have googled harder... My bad!
>>
>
--
Alex
Reply all
Reply to author
Forward
0 new messages