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 firstname.lastname@example.org. 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.