So, I’ve been experiencing a few issues with uupd, brew update failures etc, where’s the logs (journalctl -xeu uupd is not particularly useful, is there a real log file?). I also don’t like rpm-ostree updating 4 times a day, or automatically updating distroboxes (I have some for AI that have cantankerous installs that break on update), and seeing as it lives in /usr the only lever I have that persists is to disable it (as I understand it, doco is pretty sparse).
Anyhow, a while ago I hacked together a daily maintenance script that uses an edited /usr/share/ublue-os/topgrade.toml along with backups, updating distroboxes I want updated and a few other bibs and bobs…and does topgrade -y --config topgrade.toml
My main question(s) here is, is that file even being kept up to date with uupd now being used, it seems to do what I want, but enquiring minds want to know. Am I missing some important upgrades doing it this way? Everything important is in the main image, right? Bootc hasn’t broken some of my assumptions here?
A few ideas for a better uupd experience:
a damn persistent config file so I don’t have to automatically update distroboxes, can set times and recurrence etc.
some doco, somewhere, that explains how it works (happy to learn if it’s there, but I can’t find it, and I’ve been too lazy to dive into the source)
A couple of things I like to do in my script that could be useful / nice (I use notify-send and actually check my notifications)
notify the user that update has occurred successfully not just on error (assuming makes a security ass out of me)
report the SecAdvisories: line from rpm-ostree status, so I know whether to bother rebooting.
maybe an option for podman auto-update and podman image prune -f
Being able to add a pre / post update script to do user specific things (e.g. backup) would be cool.
Just want to end with, thanks for the hard work on uupd, happy to write it up as an issue on their github, thought I’d get a sanity check here first though.
When I saw your post I was curious. I knew uupd was coming, but did not hear it was in use. But to be honest, I do not follow the bazzite channel closely. I am on bluefin-dx.
The first thing I did was man uupd. Oops - no man page.
I see the service and timer are both inactive and dead on my system. So maybe bazzite is the first to get this one? journalctl has nothing in it about uupd except this line:
May 18 05:51:19 nitro5 rpm-ostree[29302]: uupd 1.1.0-1.fc42 -> 1.2.1-1.fc42
Looking at the unit file (systemctl cat uupd.service) shows the following Exec line:
Note the --disable-module-distrobox option. Indeed I see that option in the source for the update cmd:
I have a custom toolkit for creating distrobox / devcontainer containers because the standard stuff is too out of date for me. For example, the newest devcontainer “Feature” for python I can find only supports up to version 3.12 where 3.13 was released almost 8 months ago and I am using 3.14b1 as my normal version already. Same with go, zig, just about every tool chain I use is in that state.
So, I too, do not want the system trying to update my containers. It cannot possibly know how, or worse “when” (as you point out).