Updates thread

General
1

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.

1 Like
2

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.

5 Likes
3

TIL Thanks!
20 characters

4

What if the following were added to rpm-ostreed-automatic.service?

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'
1 Like
5

But why?

The main point is that the updates are invisible and the user doesn’t need to care about them.

6

People miss Windows pestering them it seems xD

3 Likes
7

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.

2 Likes
8

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.

1 Like
9

Then I am your black swan.
Bluefin GTS and stable updates normally drop on Sunday. I reboot Monday morning.

I keep my system drip-ready—updates stay smooth and clean.

10

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..

11

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.

2 Likes
12

This is covered in the docs, except the Sunday part, they just say weekly:

13

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.

❯ 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

Edit: I wanted to add a symbol and clean it up, this is the improved version.

❯ 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

7 Likes
14

Elegant, thank you for sharing! Minor nitpick: I’d go for a different symbol: 🗘

(more candidates: https://emojidb.org/update-emojis)

1 Like
15

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.

6 Likes
16

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.

# /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.

[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:

# /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.

17

Agreed on the 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.

18

The motd will actually inform you if your image is over month old if you haven’t toggled it off

1 Like
19

@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 :wink:

20

No it does not. I don’t know why would you think that.

Nothing is forcing you to reboot in the middle of your work. I mean most of users are running gtsor 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.

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.

We are always open for PRs if people think something would be good to be implemented.

1 Like