I read in another post that Flatpaks are updated twice a day. That’s fine, but I don’t always leave my laptop on, and many times it’s asleep when the scheduled updates occur. As a result, it’s not uncommon for days to pass with Flatpak updates pending unless I update them manually.
Is this a known issue?
thanks!
The uupd.service runs after 6 hours of the unit being inactive and/or 20 minutes after boot. The systemd unit for the timer contains the Persistent=true directive, which means it should activate immediately upon resume if it missed the last start time.
That said, it’s possible there is some other issue going on with your system that prevents the unit from activating. If you see updates available in the KDE Plasma Discover app, it’s also possible that these have registered as pending in the Discover app’s update cache before the uupd.timeractivates. The same goes for whatever GNOME uses as an app store. Can you make sure that isn’t the case? I would refresh the update cache in the app store after, say, 30 minutes.
Interesting, so after we move away and remove discover (with Bazzar) that might not be the case with the discover update cache?
When Discover goes away and Bazaar takes its place, it might still be an issue with Bazaar’s update cache, but to be honest I’m not sure how Bazaar works in that regard.
Common issue with all Universal Blue flavours: if you are used to always hibernating and suspending, only rebooting when it’s needed to apply updates, you are out of luck.
For some reason, a simple background notification that says something like “system updates will be applied upon the next reboot” is considered intrusive and forceful. So we are not notified. Hence never know it’s time for a reboot.
This is discussed several times each time with the same conclusion that it’s almost like blasphemy to receive a gentle informative notification like that.
Well, to be fair, flatpaks are a bit different than system updates via ostree. I’m fine with rebooting once a week for those, but I’d like to make sure that if there are flatpaks to be updated that they do so even if I miss the flatpak autoupdater.
I’ve upgraded to Bazzar over Discover, so it should be interesting to see if my laptop updates timely as far as flatpaks are concerned.
Bazaar has nothing to do with these. Neither did Discover. On Aurora those handled by uupd.timer
thanks! I’ll keep an eye on things, and when I see a flatpak pending watch to see if it updates within an hour after coming out of sleep mode (and missing the scheduled updates)
Yes, this is a known issue related to usage patterns.
Several of us Universal Blue users (I use bluefin-dx) realized that since earlier this year a change was made that prevented automated updates from working as they had in the past. There has been a lot of debate as to why. Most of it not very helpful - to be honest.
But, yes, it is related to “when” the device is in sleep mode. AND I am glad that is the behavior. I do not want to wake up with my battery being drained because of some ill-informed opinion about the importance of applying those updates. Have you used Windows in the last 10 years? sigh.
I know about when bluefin pushes new versions. And so when I am at a place where I can reboot without negatively impacting what I am doing, I just do a ujust update and see what happens. If bootc layers get staged for deployment I then reboot.
AND flatpaks, brew, etc get updated too!
I have found this to be a happy place to be. The best of both worlds.
So I like it this way. Even if others do not.
My $0.02.
Sure, but the whole point is that you should NEVER have to do ujust update. You should get flatpak updates in a timely fashion (subject to debate when that should be).
ostree updates are a different monster as a reboot must be done manually at a time if your choosing.
yep - I disagree. I appreciate the lack of disruption while I am heads down.
They are seeing the pending updates somewhere. My guess is that it was in Discover. It would be helpful if they specified where.
flatpak remote-ls --updates
That command shows only available runtimes and applications where updates are available. This is in contrast to installed runtimes and applications. Are the ones that are listed already installed on your system?
Yes, they were installed. I saw pending updates for already installed flatpkaks for at least a couple of days after taking my laptop in and out of sleep.
At this point, I’m just going to watch it and see if this continues, but it was odd given the uupd.service has that directive and is supposed to pick it up if if it misses it due to being hibernated or in sleep mode.
I totally agree with you, but you can’t expect “the 96%” to “know” when updates are pushed, helping you to determine when to do a reboot.
My only point is that currently we are not informed at all. I’m not talking about performing updates at night or anything close to as how Microsoft does it.
A simple notification that informs the user that updates will be installed automatically upon reboot or (when no staging has taken place simply because the system didn’t even check for updates due to weeks or months of using only hibernation) even just something that reminds the user that it’s time for a weekly or monthly reboot. Whatever. That’s all.
That was part of the debate that I mentioned. I fall in the camp that prefers to be notified so I can manage my time effectively. And so I ended up writing my own. It is much too technical of an exercise to get it setup, and so I only mention it here.
Roughly half of the folks responding are of the opinion that the 96% should not even need to be aware that updates are occurring.
In the world of Software Engineering we use the term “declared state”. A loose translation in this context might be: “I don’t care how you do it just make sure my system stays secure and up to date so I do not have to worry about it”.
That is the thinking behind those opinions. And I do know from where the are coming, I have the same expectation of my gardener - just make sure my lawn is mowed, flower beds are maintained, sprinkler system stays working so I don’t have to think about it. That is why I pay a monthly fee.
I just don’t care to apply the same logic to the laptop on which I so heavily rely. But I do realize that is a very personal preference and can understand why others feel differently.
Hope that helps you understand both sides a little more.
FYI, even I do not care for how Microsoft manages updates. It is impossible to understand what the OS is protected from. It depends on many things - including what order updates were applied.
So, even I do not consider MS Windows a good example. It is an example, however, of what I don’t want for anyone.
After reading this thread I’m checking my uupd.timer and I’m surprised to discover it’s disabled:
❯ systemctl status uupd.timer
○ uupd.timer - Auto Update System Timer For Universal Blue
Loaded: loaded (/usr/lib/systemd/system/uupd.timer; disabled; preset: disabled)
Active: inactive (dead)
Trigger: n/a
Triggers: ● uupd.service
I’m using Bluefin. Is this expected?
I don’t think so. You can try enabling it with sudo systemctl enable --now uupd.timer.
Not sure if bluefin actually moved to using uupd