On Friday, February 23, 2018 at 10:58:48 PM UTC+1, Marek Marczykowski-Górecki 
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On Fri, Feb 23, 2018 at 01:27:41PM -0800, Yuraeitha wrote:
> > On Thursday, February 22, 2018 at 9:26:42 AM UTC+1, Elias Mårtenson wrote:
> > > On 22 Feb 2018 4:24 pm, "Yuraeitha" <yura...@gmail.com> wrote:
> > > 
> > > Guess I'll draw the long straw, and just get rid of RC-3 and install RC-4 
> > > without confirmation whether it'd any good to do so. I'll probably never 
> > > find out the reason, but it's starting to make me a bit uneasy whether it 
> > > could have been due to Qubes RC-3 or not.
> > > 
> > > 
> > > I wouldn't bet on it. My system is based on rc4. My colleague who 
> > > installed rc3 did not have the problem. 
> > > 
> > > 
> > > Regards,
> > > Elias 
> > 
> > 
> > While my qvm-copy issue is gone, what triggered the issue for me isn't, and 
> > by the looks of it, it looks like it could happen for another future update 
> > again, if it hasn't already happened in the past without showing signs of 
> > it. I believe this may be the reason the qvm-copy issue happend to me, 
> > although I can't be sure yet. There is also a chance it was the same that 
> > happened to you? But either way, this is what frequently happens on my 
> > setup, I started noticing it the last 14 days or so.
> > 
> > Below is a recent example of the template's terminal output when it 
> > happens. I did the update after work followed up with sleeping, so I'm sure 
> > it was well beyond the default 6 hours for saving cache on repository 
> > updates.
> 
> According to dnf.conf manual, "The default corresponds to 48 hours".
> 
> Does it explains anything?
> 
> > This also happened on the second template (fedora-26-apps), and not on the 
> > first template I ran the update (fedora-26). Could this be because the 
> > updates are handled in the same place and the cache wasn't cleared? It 
> > seems likely to be a legit explanation, although remains to be confirmed.
> > 
> > There is also the issue I have with PGP checks, where I have to restart 
> > sys-net/sys-firewall to get proper PGP checks on updates.
> > 
> > All these seem to be connected to each others. Cache doesn't seem to be 
> > cleared properly where Qubes handles the updates. I'm not sure if that is 
> > actually the explanation for the behavior though. It looks like this.
> > 
> > This is from the latest update, the cache issue happens quite frequently 
> > despite the 6 hour window.
> > 
> > 
> > [user@fedora-26-apps ~]$ sudo dnf update 
> > --enablerepo=qubes-vm-*-current-testing
> 
> I'd recommend --refresh option, instead of separate "dnf clean all"
> call. This will cause dnf to check if metadata on the server have
> updated, and do not download (50+ MB) again if not.
> 
> (...)
> 
> > As it can be seen, in the first update it only checks the fedora 
> > repository, and no other repositories.
> > I haven't observed the details yet, for example I'm not sure if it 
> > sometimes includes Qubes repository, but not the Qubes current-testing 
> > repository. I'm not sure if it's a all or nothing situation, or if it can 
> > be "mixed", for example if current-testing isn't included despite the 
> > --enablerepo=qubes-vm-*-current-testing flag. For now though, I just know 
> > it's at least an all or nothing issue, whether it can be mixed is too early 
> > to tell.
> > 
> > At this point I might just re-install, unless it can be fixed. But it seems 
> > something is fundamentally broken, it seems safer to get a clean 
> > re-install. But I wonder if this could have explained the qvm-copy issue.
> 
> Have you installed those updates now? The not-checking-updates issue
> seems separate and in fact working as documented (but maybe not as
> expected). Other issues, should be fixed in the update.
> 
> - -- 
> 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-----
> 
> iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqQjoEACgkQ24/THMrX
> 1yxKAQf8DZYI17fmswIFANu8osyFKhcV3JYVRVUcDbI68HN1r/bQHAdkx+Y68pep
> 1oycNtiFYOGrPpzcWlbAVAMNdb/GJYhH/GxQSCRTuufxOFPljvNQtf7pMleeNh21
> dbfNsE8xZpbPTZ35j+baxjsb5jzLCcypUxzjU/1I3WfY9gmjQbXSoIvHacffGBex
> nz+6rkFGMLDTULLvQWRkbwLM53oInkWxtU0BpAh6ZW2OyV4SMzFu+NkWnxve3Kw6
> Qx6wEPADErR+k3mVEVwEq0FNsS8CMFiO8JUypbep5N38dBs71ZjVAl1TW6SvuvIH
> 4lw96WYVUo1QKcgAAhS4AQiaAdqcjA==
> =R+3Z
> -----END PGP SIGNATURE-----

If cache last 48 hours and not 6 hours, that certainly could explain it. I'll 
write down when I do future updates to see if it is gone when beyond 48 hours 
or if using --refresh within 48 hours.

Duly noted on the --refresh option. I've been worried if checking updates more 
frequently would stress the servers (considering when many people do it), so 
--refresh seems like a much, much better option. I'll definitely use this from 
now on.

I have indeed installed the listed updates. I think I understand what you mean, 
it's a little complex to rephrase it all in full words, but if I understood 
what you meant right I essentially I created these update holes on my own, 
which caused out-of-sync dom0/template updates when only "sometimes" using 
'clean all' within 48 hours instead of the thought 6 hours, (or --refresh, 
which I'll use from now on). So if I got this down right, if I properly and 
systematically use --refresh for both dom0/template in sync when it's within 48 
hours, then I won't risk out of sync updates again. I lack the technical 
insight, but with the little knowledge I have it does indeed seem pretty likely 
to explain the cache issue I experience, and the solution seems pretty good. It 
also removes the worries I had, I want to thank you for that too.

I'll give this adjusted user approach to updates a spin for a while before 
reporting back whether the cache update issue is fully gone.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/cae86e95-fff8-49e4-9bb4-e8d3a41191b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to