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?


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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to