# Updates thread **URL:** \ **Category:** General\ **Created:** [May 19, 2025, 8:24am UTC](https://universal-blue.discourse.group/t/updates-thread/8833 "2025-05-19T08:24:51Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![klmcw](https://avatars.discourse-cdn.com/v4/letter/k/eb8c5e/32.png) [@klmcw](https://universal-blue.discourse.group/u/klmcw)\ **Post date:** [May 19, 2025, 8:24am UTC](https://universal-blue.discourse.group/t/updates-thread/8833/1 "2025-05-19T08:24:51Z")
> [@Bluefin is now based on Fedora 42 / Universal Blue Updates](https://universal-blue.discourse.group/t/bluefin-is-now-based-on-fedora-42-universal-blue-updates/7815/29): > > When is the update trigger time? What does `rpm-ostree status -v` show you? If you have a new deployment with a bunch of packages that are being updated - as a new (index: 0); you will see 3 deployments in the list instead of just 2 - then the update/upgraded deployment has been staged. If so, just reboot - the changes do not get applied until reboot. That is the ostree / bootc design. If you do not see a list of 3 deployments then do `ujust update` followed by a reboot if it downloads new layers and stages a deployment. The key is that it updates/upgrades when you reboot. The system downloads the layers to update throughout the day in the background. To see when those events have been happening do `journalctl -u rpm-ostreed-automatic.service`. I usually just periodically (roughly once a week when I am at a good stopping point) run `ujust update` and reboot if I notice an update. Best of both worlds. I leverage the auto d/l but control _when_ update occurs with an explicit reboot. I love it. I hated the forced reboots in the middle of giving a presentation when I was still working. THAT was totally disrupting, but was my company’s policy for Windoze for critical system updates. ---
**Author:** ![pauldoo](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/pauldoo/32/892_2.png) [@pauldoo](https://universal-blue.discourse.group/u/pauldoo)\ **Post date:** [May 19, 2025, 8:34am UTC](https://universal-blue.discourse.group/t/updates-thread/8833/2 "2025-05-19T08:34:43Z")
> [@Bluefin is now based on Fedora 42 / Universal Blue Updates](https://universal-blue.discourse.group/t/bluefin-is-now-based-on-fedora-42-universal-blue-updates/7815/30): > > The config file isn’t sudo writable, so not sure if it can be overridden. The trick is to not think about where the config is and whether that file is writable. Use `systemctl edit ..` and it’ll do the right thing. In this particular case it will likely put some overrides into “/etc” and leave the rest of the definition alone. Once you’re done you can use `systemctl cat` again to see where all the bits of config for the unit come from. ---
**Author:** ![JohnAtl](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/johnatl/32/3485_2.png) [@JohnAtl](https://universal-blue.discourse.group/u/JohnAtl)\ **Post date:** [May 19, 2025, 10:46am UTC](https://universal-blue.discourse.group/t/updates-thread/8833/3 "2025-05-19T10:46:44Z")
TIL Thanks! 20 characters ---
**Author:** ![phreed](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/phreed/32/2417_2.png) [@phreed](https://universal-blue.discourse.group/u/phreed)\ **Post date:** [May 28, 2025, 10:10pm UTC](https://universal-blue.discourse.group/t/updates-thread/8833/4 "2025-05-28T22:10:29Z")
What if the following were added to `rpm-ostreed-automatic.service`? ```plaintext ExecStartPost=/bin/bash -c 'if /usr/bin/rpm-ostree status --json | /usr/bin/jq -e ".deployments[0].booted == false" > /dev/null; then notify-send "Restart Needed" "There is a BlueFin update pending. Run \`systemctl reboot\`"; fi' ``` ---
**Author:** ![inffy](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/inffy/32/7996_2.png) [@inffy](https://universal-blue.discourse.group/u/inffy)\ **Post date:** [May 29, 2025, 5:05am UTC](https://universal-blue.discourse.group/t/updates-thread/8833/5 "2025-05-29T05:05:06Z")
But why? The main point is that the updates are invisible and the user doesn’t need to care about them. ---
**Author:** ![mandarinoo](https://avatars.discourse-cdn.com/v4/letter/m/ed655f/32.png) [@mandarinoo](https://universal-blue.discourse.group/u/mandarinoo)\ **Post date:** [May 29, 2025, 7:54am UTC](https://universal-blue.discourse.group/t/updates-thread/8833/6 "2025-05-29T07:54:37Z")
People miss Windows pestering them it seems xD ---
**Author:** ![zilexa](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/zilexa/32/2221_2.png) [@zilexa](https://universal-blue.discourse.group/u/zilexa)\ **Post date:** [May 29, 2025, 8:51am UTC](https://universal-blue.discourse.group/t/updates-thread/8833/7 "2025-05-29T08:51:28Z")
It’s nice to be made aware that an update is a reboot away. Not forcing me to reboot. But to know I should. I dont know anyone that does that by themselves ever unless their machine stops working, or unless they are made aware (without forcing, pestering or whatever you have in your mind) it’s almost time for a manual reboot. I guess it’s a generational difference, that’s the only way I can imagine why this mindset so hard to understand. _I dont turn my phone off == exactly the same as I dont turn my laptop off._ I’ve been trying to explain this but each time being compared to crap OS’s like Windows that take over control. ---
**Author:** ![Mshrm](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/mshrm/32/5588_2.png) [@Mshrm](https://universal-blue.discourse.group/u/Mshrm)\ **Post date:** [May 29, 2025, 11:34am UTC](https://universal-blue.discourse.group/t/updates-thread/8833/8 "2025-05-29T11:34:12Z")
I would like an indicator to know if there is a security update available so I can update right away if I choose. My work PC forces a restart, which can be annoying when I am busy working. ---
**Author:** ![JohnAtl](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/johnatl/32/3485_2.png) [@JohnAtl](https://universal-blue.discourse.group/u/JohnAtl)\ **Post date:** [May 29, 2025, 12:08pm UTC](https://universal-blue.discourse.group/t/updates-thread/8833/9 "2025-05-29T12:08:04Z")
> [@zilexa](#): > > I dont know anyone that does that by themselves ever Then I am your [black swan](https://en.m.wikipedia.org/wiki/Black_swan_theory). Bluefin GTS and stable updates normally drop on Sunday. I reboot Monday morning. I keep my system drip-ready—updates stay smooth and clean. ---
**Author:** ![zilexa](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/zilexa/32/2221_2.png) [@zilexa](https://universal-blue.discourse.group/u/zilexa)\ **Post date:** [May 29, 2025, 1:21pm UTC](https://universal-blue.discourse.group/t/updates-thread/8833/10 "2025-05-29T13:21:08Z")
Thank you. But I hope you can imagine there are other people out there that do things differently.. A system that is designed for the 96% but then making a hard assumption that people always turn off/reboot regularly, say once a week or month, makes no sense to me. Also, there is no way of knowing for end users that updates “normally drop on Sunday”. Again, the 96% doesn’t know that, since there is not any kind of communication about it.. ---
**Author:** ![inffy](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/inffy/32/7996_2.png) [@inffy](https://universal-blue.discourse.group/u/inffy)\ **Post date:** [May 29, 2025, 1:30pm UTC](https://universal-blue.discourse.group/t/updates-thread/8833/11 "2025-05-29T13:30:58Z")
Well I would guess that the 96% of the users do reboot regularly, or even shutdown their PCs every day. Some of use even update just manually daily and then reboot, each to their own. Everybody is of course welcome to use their machine how they want, but the point still is that updates are meant to be “invisible” for the majority of users. ---
**Author:** ![JohnAtl](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/johnatl/32/3485_2.png) [@JohnAtl](https://universal-blue.discourse.group/u/JohnAtl)\ **Post date:** [May 29, 2025, 1:38pm UTC](https://universal-blue.discourse.group/t/updates-thread/8833/12 "2025-05-29T13:38:58Z")
> [@zilexa](#): > > Also, there is no way of knowing for end users that updates “normally drop on Sunday”. Again, the 96% doesn’t know that, since there is not any kind of communication about it. This is covered in the docs, except the Sunday part, they just say weekly: > **[Administrator's Guide | Bluefin](https://docs.projectbluefin.io/administration/)** > > Day to Day Operation ---
**Author:** ![CerealParadox](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@CerealParadox](https://universal-blue.discourse.group/u/CerealParadox)\ **Post date:** [May 29, 2025, 1:54pm UTC](https://universal-blue.discourse.group/t/updates-thread/8833/13 "2025-05-29T13:54:56Z")
Building upon the script that @phreed shared, I modified my Starship prompt (y’all are using `ujust bluefin-cli` right?) I do not reboot my computer very often either, so I thought it would be cool to have a subtle indication when there are updates staged and ready to go. ```auto ❯ cat ~/.config/starship.toml [custom.update] command = "/bin/bash -c 'if /usr/bin/rpm-ostree status --json | /usr/bin/jq -e \".deployments[0].booted == false\" > /dev/null; then echo \"(Bluefin Update Available)\"; fi'" when = true format = " [($output)]($style) " style = "bold green" ``` By adding this block to `starship.toml` file (you may have to create it, if you haven’t made one), it preserves the default behavior of Starship prompt but will add “(Bluefin Update Available)” when one will be applied on next boot. ![image](https://global.discourse-cdn.com/free1/uploads/univeral_blue/optimized/2X/e/e191bc202ddb16cbce7e1c4d2b30aa9995df1a38_2_690x81.png) Edit: I wanted to add a symbol and clean it up, this is the improved version. ```auto ❯ cat ~/.config/starship.toml [custom.update] when = "/usr/bin/rpm-ostree status --json | /usr/bin/jq -e \".deployments[0].booted == false\" > /dev/null;" command = 'echo "Bluefin update staged"' symbol = "♻" format = " $symbol [($output)]($style) " style = "italic green" ``` ![image](https://global.discourse-cdn.com/free1/uploads/univeral_blue/optimized/2X/1/10cd97c90a6b3bfe8312c4e908bd33eea634733b_2_690x85.png) ---
**Author:** ![salim](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/salim/32/3536_2.png) [@salim](https://universal-blue.discourse.group/u/salim)\ **Post date:** [May 29, 2025, 3:19pm UTC](https://universal-blue.discourse.group/t/updates-thread/8833/14 "2025-05-29T15:19:29Z")
Elegant, thank you for sharing! Minor nitpick: I’d go for a different symbol: `🗘` (more candidates: [https://emojidb.org/update-emojis](https://emojidb.org/update-emojis)) ---
**Author:** ![pauldoo](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/pauldoo/32/892_2.png) [@pauldoo](https://universal-blue.discourse.group/u/pauldoo)\ **Post date:** [May 29, 2025, 3:32pm UTC](https://universal-blue.discourse.group/t/updates-thread/8833/15 "2025-05-29T15:32:43Z")
There are two groups here, the frequent rebooters and the never rebooters. Neither is right or wrong. There needs to be a solution that works for both and annoys neither. How about this: If there is an update staged, _and_ the system has been up for more than 48h, only then provide a subtle indication somewhere (in the motd, a highlight on the power button, whatever). Frequent rebooters will never see it. Never rebooters will. ---
**Author:** ![phreed](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/phreed/32/2417_2.png) [@phreed](https://universal-blue.discourse.group/u/phreed)\ **Post date:** [May 29, 2025, 4:54pm UTC](https://universal-blue.discourse.group/t/updates-thread/8833/16 "2025-05-29T16:54:40Z")
When do you all run `ujust update`? Never, every-day, weekly? Each person is going to have a set of maintenance tasks which they perform. My view is that this is not something which should be decided by the base system. However, I do think the base system should provide a set of systemd unit files for performing these maintenance tasks. The individual can then schedule them as they see fit. ```ini # /etc/systemd/system/task-a.service [Unit] Description=Run task a [Service] Type=oneshot ExecStart=/usr/local/bin/task-a.sh ``` These could then be run via the various triggering units. `timer`, `path`, `socket`, `target`, `systemctl start`, or `service` via `ExecStartPost=`, `OnSuccess=`, `OnFailure=`. Here is a `timer`. ```ini [Timer] OnCalendar=Mon *-*-* 03:15:00 Unit=task-a.service ``` The bluefin documentation would identify these maintenance task services and recommend mechanisms for triggering them. The mechanisms would be based on `systemctl edit`. Give people the tools, some guidance, and let them decide for themselves. The topically relevant question is, **how should these services notify the operator when something goes wrong or otherwise needs attention?** There could be a notification service in user space which could be triggered. Maybe something like: ```ini # /etc/systemd/system/trigger-user-notify.service [Unit] Description=Trigger user notification [Service] Type=oneshot ExecStart=/bin/bash -c 'sudo -u youruser /bin/systemctl --user start notify-task.service' ``` Having these services would also allow the `ujust` tasks to use `systemctl start` to run these maintenance tasks. Or, possibly the other way around, the service runs the `ujust` task. ---
**Author:** ![CerealParadox](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@CerealParadox](https://universal-blue.discourse.group/u/CerealParadox)\ **Post date:** [May 29, 2025, 5:18pm UTC](https://universal-blue.discourse.group/t/updates-thread/8833/17 "2025-05-29T17:18:26Z")
Agreed on [the motd](https://github.com/ublue-os/packages/blob/b5f9619ad0b43c95228d80f192f23db7a9215e59/packages/ublue-motd/src/ublue-motd) being a good place to indicate that updates are staged and available on next boot, but for now my Thursday morning quick hack makes me happy and is safely in userland. ---
**Author:** ![inffy](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/inffy/32/7996_2.png) [@inffy](https://universal-blue.discourse.group/u/inffy)\ **Post date:** [May 29, 2025, 5:20pm UTC](https://universal-blue.discourse.group/t/updates-thread/8833/18 "2025-05-29T17:20:53Z")
The motd will actually inform you if your image is over month old if you haven’t toggled it off > ---
**Author:** ![klmcw](https://avatars.discourse-cdn.com/v4/letter/k/eb8c5e/32.png) [@klmcw](https://universal-blue.discourse.group/u/klmcw)\ **Post date:** [May 29, 2025, 5:26pm UTC](https://universal-blue.discourse.group/t/updates-thread/8833/19 "2025-05-29T17:26:47Z")
@inffy that means our only option is to disable automatic updates and discipline ourselves to do them manually. Too many years on the job of being forced to reboot right in the middle of the day, at the worst possible time. When I log into my router admin app I see a blinking icon in the toolbar if there are firmware updates available. When I see that it is a trigger for me to schedule time to bring all of the nodes of my mesh network online and do the update - at a time that will not disrupt my household. Heck even here in discourse I see a badge on my avatar if there are any replies or mentions. I could go on, but will stop there. For many of us it is considered bad design to completely hide what is going on. If I am heads down on a complex coding problem and have a bunch of stuff open to support where I am right now, I am not going to reboot for at least a couple of days. And I am so engrossed I am not going to remember to go do an `rpm-ostree status`. I’ll just wait until I am at a good stopping point and then do a `ujust update` which for the last several months almost always results in layers being downloaded anyway. But if I was reminded of available updates I might change that strategy to enable the reboot earlier than I was planning (or forgetting to plan). So to turn your comment on its head - many of us do not understand why you (core team) want to not be transparent about updates being available. What are you trying to hide? It feels very odd and backwards to those of us who take the position that there absolutely be some indication that updates are available. Ideally it would be a blinking red (or maybe a blue U) icon next to the wifi, bluetooth, battery indicators. The solution that @phreed mentions is just something he knew how to accomplish. I am wrapping up work on the current issue I have been working this week. Let me take a stab at writing a POC Gnome extension to do what I am describing. @phreed - if we had a blinking blue U (like the universal blue menu) in the top right with the other system indicators - would that work for you? I know some have issues with nagging notifications. For bluefin it really should be a blinking dinosaur, but not sure I could pull that off 😉 ---
**Author:** ![inffy](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/inffy/32/7996_2.png) [@inffy](https://universal-blue.discourse.group/u/inffy)\ **Post date:** [May 29, 2025, 5:46pm UTC](https://universal-blue.discourse.group/t/updates-thread/8833/20 "2025-05-29T17:46:09Z")
> [@klmcw](#): > > @inffy that means our only option is to disable automatic updates and discipline ourselves to do them manually. No it does not. I don’t know why would you think that. > [@klmcw](#): > > Too many years on the job of being forced to reboot right in the middle of the day, at the worst possible time. > > If I am heads down on a complex coding problem and have a bunch of stuff open to support where I am right now, I am not going to reboot for at least a couple of days. And I am so engrossed I am not going to remember to go do an `rpm-ostree status`. I’ll just wait until I am at a good stopping point and then do a `ujust update` which for the last several months almost always results in layers being downloaded anyway. Nothing is forcing you to reboot in the middle of your work. I mean most of users are running `gts`or `stable` propably (on bluefin, on Aurora we only provide stable/stable-daily/latest). They don’t need to reboot because there are now updates until every sunday. So once a week. Doesn’t really matter what day you reboot if its once a week. > [@klmcw](#): > > So to turn your comment on its head - many of us do not understand why you (core team) want to not be transparent about updates being available. What are you trying to hide? > > If I am heads down on a complex coding problem and have a bunch of stuff open to support where I am right now, I am not going to reboot for at least a couple of days. And I am so engrossed I am not going to remember to go do an rpm-ostree status. I’ll just wait until I am at a good stopping point and then do a ujust update which for the last several months almost always results in layers being downloaded anyway. Why do you think there is somekind of conspiracy here? I’m sure @j0rge can (once again) explain the reasoning, not wanting to have the paradigm to “install updates and then reboot right now” like in the “normal desktop linuxes”. Point being it is all automated in the background. > [@klmcw](#): > > It feels very odd and backwards to those of us who take the position that there absolutely be some indication that updates are available. Ideally it would be a blinking red (or maybe a blue U) icon next to the wifi, bluetooth, battery indicators. We are always open for PRs if people think something would be good to be implemented. [Next page](https://universal-blue.discourse.group/t/updates-thread/8833.md?page=2)