[qubes-users] Re: dom0 clock keeps resetting to wrong time again

2019-02-01 Thread Jon deps
On 1/21/19 10:25 AM, Marcus Linsner wrote:
> On Sunday, January 20, 2019 at 7:02:34 PM UTC+1, john s. wrote:
>> On 1/20/19 12:06 AM, Andrew David Wong wrote:
>>> On 19/01/2019 5.08 PM, John S.Recdep wrote:
 On 1/14/19 9:55 PM, John S.Recdep wrote:
> On 1/14/19 10:10 AM, John S.Recdep wrote:
>> Hello,
>>
>> I believe my Bios time is UTC
>>
>> qubes-prefs shows my clockvm  as sys-net
>>
>> I have been trying to use sudo date --set <"localtime TZ">  to
>> get my dom0 correct.  Which it does but within 30-60  it is
>> changing to another TZ I don't recognize
>>
>> I have also tried  qvm-sync-clock  ,  and tried a qubes group
>> search as I remember fighting this out many times   with whonix
>> issues , however
>>
>> I am at a loss what to do further to problem-solve fix this  , 
>> appreciate your help
>>
>>
>> maybe I can switch the template for sys-net back to fedora-28
>> instead of -29  . ?
>>
>
> 1-14-19
>
> changing the clockvm to fed-28 and rerunning qvm-sync-clock did
> nothing BUT*  changing sys-net to debian-9  and qvm-sync-clock
> fixed it   sigh
>
> case anyone else gets this issue again ; prolly will fix
> whonixcheck complaints if any as well
>
> 'solved'
>
>>>
 Must be related to this 
 https://github.com/QubesOS/qubes-issues/issues/3983
>>>
 for myself it's not the  minimal fedora-29 its the regular one ;
 and it appears if fedora-29 is having time issues  that  that may
 be why my thunderbird appvm based on it,  is also  timestamping the
 messages wrong ?
>>>
>>>
>>> Try the workaround mentioned in the comments on that issue, if you
>>> haven't already. It's worked for me so far.
>>>
>>>
>>
>>
>> well if you mean:
>>
>> in the Fedora-29 template doing
>>
>> sudo chmod 700 /var/lib/private
>>
>>
>> [user@fedora-29 ~]$ sudo ls -l /var/lib/private/
>> total 4
> this looks inside the private dir, but what you want is to look at the dir 
> itself, here's two ways:
> [user@sys-firewall ~]$ stat /var/lib/private/
>   File: /var/lib/private/
>   Size: 4096  Blocks: 8  IO Block: 4096   directory
> Device: ca03h/51715d  Inode: 397353  Links: 3
> Access: (0700/drwx--)  Uid: (0/root)   Gid: (0/root)
> Access: 2018-05-24 01:13:40.23200 +0200
> Modify: 2018-05-24 01:13:40.23200 +0200
> Change: 2018-12-20 03:21:32.44700 +0100
>  Birth: -
> 
> [user@sys-firewall ~]$ ls -la /var/lib/|grep private
> drwx--  3 rootroot4096 May 24  2018 private
> 
> 
>> drwxr-xr-x 2 root root 4096 Dec  9 15:37 systemd
>> [user@fedora-29 ~]$ sudo chmod 700 /var/lib/private/
> now that you've already run this, it should be fixed already :)
>> [user@fedora-29 ~]$ sudo ls -l /var/lib/private/
>> total 4
>> drwxr-xr-x 2 root root 4096 Dec  9 15:37 systemd
>>
>>
>> doesn't seem to change any permissions on the systemd  directory  so
>> . doesn't seem like that is going to fix anything ?  maybe I'm
>> missing something basic?
> 

btw, what does it mean if I have no /var/lib/private  dir at all?

I use sys-net  as the qubes-pref  clockvm do you use  sys-firewall ?

in sys-net  I also  have no  /var/lib/private  fwiw


my dom0 clock is fine now with Fedora-29 or Debian-9  but my Fedora
app-based qubes VMs  are set to UTC and I'd like them set to  local
timezone  , as long as this doesn't mess up whonixcheck s ?

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/580cde02-0567-f8db-fd5e-13fb09c74a8b%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: dom0 clock keeps resetting to wrong time again

2019-01-21 Thread Marcus Linsner
On Sunday, January 20, 2019 at 7:02:34 PM UTC+1, john s. wrote:
> On 1/20/19 12:06 AM, Andrew David Wong wrote:
> > On 19/01/2019 5.08 PM, John S.Recdep wrote:
> >> On 1/14/19 9:55 PM, John S.Recdep wrote:
> >>> On 1/14/19 10:10 AM, John S.Recdep wrote:
>  Hello,
> 
>  I believe my Bios time is UTC
> 
>  qubes-prefs shows my clockvm  as sys-net
> 
>  I have been trying to use sudo date --set <"localtime TZ">  to
>  get my dom0 correct.  Which it does but within 30-60  it is
>  changing to another TZ I don't recognize
> 
>  I have also tried  qvm-sync-clock  ,  and tried a qubes group
>  search as I remember fighting this out many times   with whonix
>  issues , however
> 
>  I am at a loss what to do further to problem-solve fix this  , 
>  appreciate your help
> 
> 
>  maybe I can switch the template for sys-net back to fedora-28
>  instead of -29  . ?
> 
> >>>
> >>> 1-14-19
> >>>
> >>> changing the clockvm to fed-28 and rerunning qvm-sync-clock did
> >>> nothing BUT*  changing sys-net to debian-9  and qvm-sync-clock
> >>> fixed it   sigh
> >>>
> >>> case anyone else gets this issue again ; prolly will fix
> >>> whonixcheck complaints if any as well
> >>>
> >>> 'solved'
> >>>
> > 
> >> Must be related to this 
> >> https://github.com/QubesOS/qubes-issues/issues/3983
> > 
> >> for myself it's not the  minimal fedora-29 its the regular one ;
> >> and it appears if fedora-29 is having time issues  that  that may
> >> be why my thunderbird appvm based on it,  is also  timestamping the
> >> messages wrong ?
> > 
> > 
> > Try the workaround mentioned in the comments on that issue, if you
> > haven't already. It's worked for me so far.
> > 
> > 
> 
> 
> well if you mean:
> 
> in the Fedora-29 template doing
> 
> sudo chmod 700 /var/lib/private
> 
> 
> [user@fedora-29 ~]$ sudo ls -l /var/lib/private/
> total 4
this looks inside the private dir, but what you want is to look at the dir 
itself, here's two ways:
[user@sys-firewall ~]$ stat /var/lib/private/
  File: /var/lib/private/
  Size: 4096Blocks: 8  IO Block: 4096   directory
Device: ca03h/51715dInode: 397353  Links: 3
Access: (0700/drwx--)  Uid: (0/root)   Gid: (0/root)
Access: 2018-05-24 01:13:40.23200 +0200
Modify: 2018-05-24 01:13:40.23200 +0200
Change: 2018-12-20 03:21:32.44700 +0100
 Birth: -

[user@sys-firewall ~]$ ls -la /var/lib/|grep private
drwx--  3 rootroot4096 May 24  2018 private


> drwxr-xr-x 2 root root 4096 Dec  9 15:37 systemd
> [user@fedora-29 ~]$ sudo chmod 700 /var/lib/private/
now that you've already run this, it should be fixed already :)
> [user@fedora-29 ~]$ sudo ls -l /var/lib/private/
> total 4
> drwxr-xr-x 2 root root 4096 Dec  9 15:37 systemd
> 
> 
> doesn't seem to change any permissions on the systemd  directory  so
> . doesn't seem like that is going to fix anything ?  maybe I'm
> missing something basic?

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/44e5d8af-9bf4-42c0-adea-cd90869af086%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: dom0 clock keeps resetting to wrong time again

2019-01-20 Thread john s.
On 1/20/19 12:06 AM, Andrew David Wong wrote:
> On 19/01/2019 5.08 PM, John S.Recdep wrote:
>> On 1/14/19 9:55 PM, John S.Recdep wrote:
>>> On 1/14/19 10:10 AM, John S.Recdep wrote:
 Hello,

 I believe my Bios time is UTC

 qubes-prefs shows my clockvm  as sys-net

 I have been trying to use sudo date --set <"localtime TZ">  to
 get my dom0 correct.  Which it does but within 30-60  it is
 changing to another TZ I don't recognize

 I have also tried  qvm-sync-clock  ,  and tried a qubes group
 search as I remember fighting this out many times   with whonix
 issues , however

 I am at a loss what to do further to problem-solve fix this  , 
 appreciate your help


 maybe I can switch the template for sys-net back to fedora-28
 instead of -29  . ?

>>>
>>> 1-14-19
>>>
>>> changing the clockvm to fed-28 and rerunning qvm-sync-clock did
>>> nothing BUT*  changing sys-net to debian-9  and qvm-sync-clock
>>> fixed it   sigh
>>>
>>> case anyone else gets this issue again ; prolly will fix
>>> whonixcheck complaints if any as well
>>>
>>> 'solved'
>>>
> 
>> Must be related to this 
>> https://github.com/QubesOS/qubes-issues/issues/3983
> 
>> for myself it's not the  minimal fedora-29 its the regular one ;
>> and it appears if fedora-29 is having time issues  that  that may
>> be why my thunderbird appvm based on it,  is also  timestamping the
>> messages wrong ?
> 
> 
> Try the workaround mentioned in the comments on that issue, if you
> haven't already. It's worked for me so far.
> 
> 


well if you mean:

in the Fedora-29 template doing

sudo chmod 700 /var/lib/private


[user@fedora-29 ~]$ sudo ls -l /var/lib/private/
total 4
drwxr-xr-x 2 root root 4096 Dec  9 15:37 systemd
[user@fedora-29 ~]$ sudo chmod 700 /var/lib/private/
[user@fedora-29 ~]$ sudo ls -l /var/lib/private/
total 4
drwxr-xr-x 2 root root 4096 Dec  9 15:37 systemd


doesn't seem to change any permissions on the systemd  directory  so
. doesn't seem like that is going to fix anything ?  maybe I'm
missing something basic?








-- 
A895 0C7C A244 8E2E FD77 A3DB 180B 7D4D D158 F8B6

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3598c18a-de8e-1ac6-9e38-b1ef78920773%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Re: dom0 clock keeps resetting to wrong time again

2019-01-19 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 19/01/2019 5.08 PM, John S.Recdep wrote:
> On 1/14/19 9:55 PM, John S.Recdep wrote:
>> On 1/14/19 10:10 AM, John S.Recdep wrote:
>>> Hello,
>>> 
>>> I believe my Bios time is UTC
>>> 
>>> qubes-prefs shows my clockvm  as sys-net
>>> 
>>> I have been trying to use sudo date --set <"localtime TZ">  to
>>> get my dom0 correct.  Which it does but within 30-60  it is
>>> changing to another TZ I don't recognize
>>> 
>>> I have also tried  qvm-sync-clock  ,  and tried a qubes group
>>> search as I remember fighting this out many times   with whonix
>>> issues , however
>>> 
>>> I am at a loss what to do further to problem-solve fix this  , 
>>> appreciate your help
>>> 
>>> 
>>> maybe I can switch the template for sys-net back to fedora-28
>>> instead of -29  . ?
>>> 
>> 
>> 1-14-19
>> 
>> changing the clockvm to fed-28 and rerunning qvm-sync-clock did
>> nothing BUT*  changing sys-net to debian-9  and qvm-sync-clock
>> fixed it   sigh
>> 
>> case anyone else gets this issue again ; prolly will fix
>> whonixcheck complaints if any as well
>> 
>> 'solved'
>> 
> 
> Must be related to this 
> https://github.com/QubesOS/qubes-issues/issues/3983
> 
> for myself it's not the  minimal fedora-29 its the regular one ;
> and it appears if fedora-29 is having time issues  that  that may
> be why my thunderbird appvm based on it,  is also  timestamping the
> messages wrong ?
> 

Try the workaround mentioned in the comments on that issue, if you
haven't already. It's worked for me so far.

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxDu58ACgkQ203TvDlQ
MDBzKhAArvHttmj5JRvADCam2DIbKlUnN6CdZkbrpL4yn88rIWAIgjy3BD4vBHe5
zXOdneGzXQreiXyKIKcwgviZvnPitbgo4Udu2D8nr8LmDN35/xm3fGcsjpH9vePn
n80J/oGpKKE07dWj9nq7zHyFeaI0eSxvhpKtySF1zdYswZts3ttBgmvmDWYHxKXz
yWlz+ELk1glOUyI/YR+HfKv771qRcti5BWVmX4tRoAgtB4XAybp0rd7llPQ9HVse
mZmkL5k+CoG9pWtF1i8j/wJ5b89l0uaqcDx+02DyJ3FmVifWuxiTaOtxAgE0zNhn
VvS0vlBxsy2DBxX0uCJor/bE5El8dZm6K5EtxAgu6keOojcWHlducArUBQHNQdrI
CHZlOV9Z3hAR8DntCrmNZA7BnvaRlqXyco5R6SAPdhJmSWvagZwcRC4ZE3qog78s
IXcqPTrdACPCACEnT8tOj75ttNgce1EvrtFxSOjZyojG87vFaf7H6Og5UZmZke1w
E6lRpXfp0Mj/i/OTefWCUG8SopRmGEPCXlIfaL8lIOolsEoLwwq/La5LciVT+Ot3
XGEPw74Vz8ASvUPXYv/PW0lgmgLPAW2LhyNi4b/rtBbFPDrtxT6cUuz52L9b+rcq
4rpczGbtb941UNwRbOgx6Jtg0ETBpqEMClFVwgVZbYOtO7fsPJY=
=gHVS
-END PGP SIGNATURE-

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/820985d2-109b-edcc-c15d-8b8e10e17b93%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: dom0 clock keeps resetting to wrong time again

2019-01-19 Thread John S.Recdep
On 1/14/19 9:55 PM, John S.Recdep wrote:
> On 1/14/19 10:10 AM, John S.Recdep wrote:
>> Hello,
>>
>> I believe my Bios time is UTC
>>
>> qubes-prefs shows my clockvm  as sys-net
>>
>> I have been trying to use sudo date --set <"localtime TZ">  to get my
>> dom0 correct.  Which it does but within 30-60  it is changing to another
>> TZ I don't recognize
>>
>> I have also tried  qvm-sync-clock  ,  and tried a qubes group search as
>> I remember fighting this out many times   with whonix  issues , however
>>
>> I am at a loss what to do further to problem-solve fix this  ,
>> appreciate your help
>>
>>
>> maybe I can switch the template for sys-net back to fedora-28 instead of
>> -29  . ?
>>
> 
> 1-14-19
> 
> changing the clockvm to fed-28 and rerunning qvm-sync-clock did nothing
> BUT*  changing sys-net to debian-9  and qvm-sync-clock  fixed it   sigh
> 
> case anyone else gets this issue again ; prolly will fix whonixcheck
> complaints if any as well
> 
> 'solved'
> 

Must be related to this
https://github.com/QubesOS/qubes-issues/issues/3983

for myself it's not the  minimal fedora-29 its the regular one ; and it
appears if fedora-29 is having time issues  that  that may be why my
thunderbird appvm based on it,  is also  timestamping the messages wrong ?

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0af706cf-9095-b6af-20b3-cb4ae592cc96%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: dom0 clock keeps resetting to wrong time again

2019-01-14 Thread John S.Recdep
On 1/14/19 10:10 AM, John S.Recdep wrote:
> Hello,
> 
> I believe my Bios time is UTC
> 
> qubes-prefs shows my clockvm  as sys-net
> 
> I have been trying to use sudo date --set <"localtime TZ">  to get my
> dom0 correct.  Which it does but within 30-60  it is changing to another
> TZ I don't recognize
> 
> I have also tried  qvm-sync-clock  ,  and tried a qubes group search as
> I remember fighting this out many times   with whonix  issues , however
> 
> I am at a loss what to do further to problem-solve fix this  ,
> appreciate your help
> 
> 
> maybe I can switch the template for sys-net back to fedora-28 instead of
> -29  . ?
> 

1-14-19

changing the clockvm to fed-28 and rerunning qvm-sync-clock did nothing
BUT*  changing sys-net to debian-9  and qvm-sync-clock  fixed it   sigh

case anyone else gets this issue again ; prolly will fix whonixcheck
complaints if any as well

'solved'

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/78758e3e-d21c-83c0-a1c4-29ee767f1d5d%40riseup.net.
For more options, visit https://groups.google.com/d/optout.