Auto update stopped working?

Last night I checked the update log ( journalctl -u ublue-update.service ) and noticed that the last entry is from Feb 14. Prior to that it would automatically check for updates every 6h - I know that since I used to check the logs daily.

I checked the auto update status with ujust toggle-update and it says auto updates are on.

I then ran ujust update and got ostree and flatpak updates. Prior to that my PC had been on non-stop for over 16h (which it is daily). Maybe it was a coincidence and those updates came in in the last 6h, but it seems very unlikely.

How can i troubleshoot this?

We don’t use ublue-update.service anymore on the newer images, i think the change was made in the beginning of february.

Currently we only use the older services (rpm-ostreed-automatic.timer and .service).

So if you checked that service, its normal that it hasn’t run after that

Are you on the stable image or something else?

Thank you for the reply.

I’m on stable, with weekly checks according to the “Aurora preferences” in Settings.

What logs should I check now then to verify the auto updates works, because it seems it doesn’t?

And what was the reason for going back to older services?

You can check rpm-ostree status first, that should show if the service has run

and also check systemctl status rpm-ostreed-automatic.timer it also should you some info when it will trigger next.

1 Like

I think it looks OK?

❯ rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run 15min ago
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/aurora:stable
                   Digest: sha256:ee5d2e2c681c0c3a42fc2deafa937ddbbed20733073aca4c8a82322ad43afc79
                  Version: 41.20250224.6 (2025-02-24T16:00:28Z)

  ostree-image-signed:docker://ghcr.io/ublue-os/aurora:stable
                   Digest: sha256:48560c2aa9fbc6a2e1a1c21fc25ec7bd164e17020826d2a41cf36f00353a4424
                  Version: 41.20250209.1 (2025-02-09T05:57:01Z)

~ 
❯ systemctl status rpm-ostreed-automatic.timer
● rpm-ostreed-automatic.timer - rpm-ostree Automatic Update Trigger
     Loaded: loaded (/usr/lib/systemd/system/rpm-ostreed-automatic.timer; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/rpm-ostreed-automatic.timer.d
             └─override.conf
     Active: active (waiting) since Wed 2025-02-26 10:00:53 CET; 1h 17min ago
 Invocation: 18dce54d1f4c4e7bbe9cdc7a93b294f2
    Trigger: Thu 2025-02-27 04:08:16 CET; 16h left
   Triggers: ● rpm-ostreed-automatic.service
       Docs: man:rpm-ostree(1)
             man:rpm-ostreed.conf(5)

Feb 26 10:00:53 aurora systemd[1]: Started rpm-ostreed-automatic.timer - rpm-ostree Automatic Update Trigger.

Also, it says the next check is tomorrow, but in Aurora prefs it says to check weekly. What’s the connection between the two?

aurora:stable has a weekly release schedule so on Saturday/Sunday depending on your timezones there will be a new release.

The actual update timer service will still check updates on interval but it won’t have any OS updates until the weekend.

If you want to have daily updates but want to have “more stable kernel” you move to stable-daily images or even latest

So the Aurora preference panel box doesn’t mean how often it checks, it’s just a friendlier name for the stable stream (aka one is update per week).

Flatpaks will still update twice a day in the background

1 Like

Makes sense, great explanation!
Resolved, thanks!

1 Like

I may have celebrated too soon.

The two previous commands give:

❯ rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/aurora:stable
                   Digest: sha256:ee5d2e2c681c0c3a42fc2deafa937ddbbed20733073aca4c8a82322ad43afc79
                  Version: 41.20250224.6 (2025-02-24T16:00:28Z)

  ostree-image-signed:docker://ghcr.io/ublue-os/aurora:stable
                   Digest: sha256:48560c2aa9fbc6a2e1a1c21fc25ec7bd164e17020826d2a41cf36f00353a4424
                  Version: 41.20250209.1 (2025-02-09T05:57:01Z)

~ 
❯ systemctl status rpm-ostreed-automatic.timer
● rpm-ostreed-automatic.timer - rpm-ostree Automatic Update Trigger
     Loaded: loaded (/usr/lib/systemd/system/rpm-ostreed-automatic.timer; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/rpm-ostreed-automatic.timer.d
             └─override.conf
     Active: active (waiting) since Wed 2025-02-26 10:00:53 CET; 3 days ago
 Invocation: 18dce54d1f4c4e7bbe9cdc7a93b294f2
    Trigger: Sun 2025-03-02 04:01:27 CET; 13h left
   Triggers: ● rpm-ostreed-automatic.service
       Docs: man:rpm-ostree(1)
             man:rpm-ostreed.conf(5)

Feb 26 10:00:53 aurora systemd[1]: Started rpm-ostreed-automatic.timer - rpm-ostree Automatic Update Trigger.

I only reboot my pc once every 2-3 weeks, and suspend it overnight. During the day it typically runs for >14 hours.

Note that it says it hasn’t run since boot, and that next trigger is tomorrow at 4am. I have checked the output every day, and so far all triggers have been for 4am the following day when my PC is suspended. It means the update trigger will never run while the PC is on (unless I’ve misunderstood the output). If I’m mistaken then please enlighten me.

Also, where is the 4am time set/configured?

With the previous ublue update service, the update check would fail right after waking up the PC (I posted about it here), but it would then run again after 6h so it was almost moot. Is this “new” update trigger a temporary solution? Because it seems less reliable.

1 Like

I have the same issue you described with Bluefin.

Seems that the timer is triggered after wake from suspend, but the rpm-ostreed.automatic.service fails due to the exec condition not met.
From the /usr/lib/systemd/system/rpm-ostreed-automatic.timer.d/override.conf
xecCondition=/bin/bash -c ‘[[ “$(busctl get-property org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager Metered | cut -c 3-)” == @(2|4) ]]’
If I run this command it checks out to 4 on my machine. So could it be that the Network Manager is not yet started when the update service is run directly after wakeup from suspend? If yes how can that be fixed?

Should we file a bug ticket about this so it can be fixed, or is it a already a known issue?

Right now we don’t have any automatic updates, which is one of the key features of Aurora/Bluefin. If the update time is tz dependent (i.e. 4am in CET but 10pm in EST) then some devs might not even be aware of this bug.

Atleast few of us in the Aurora maintainers are from EU.

I’ve checking on my own laptop for this and this is what mine shows:

 /home/juha : systemctl status rpm-ostreed-automatic.timer
● rpm-ostreed-automatic.timer - rpm-ostree Automatic Update Trigger
     Loaded: loaded (/usr/lib/systemd/system/rpm-ostreed-automatic.timer; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/rpm-ostreed-automatic.timer.d
             └─override.conf
     Active: active (waiting) since Mon 2025-03-10 13:39:00 EET; 2h 48min ago
 Invocation: b6093d7675134fe598eefc9d7419f842
    Trigger: Mon 2025-03-10 16:43:35 EET; 15min left
   Triggers: ● rpm-ostreed-automatic.service
       Docs: man:rpm-ostree(1)
             man:rpm-ostreed.conf(5)
/home/juha : systemctl status rpm-ostreed-automatic.service
○ rpm-ostreed-automatic.service - rpm-ostree Automatic Update
     Loaded: loaded (/usr/lib/systemd/system/rpm-ostreed-automatic.service; static)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf, 50-keep-warm.conf
             /usr/lib/systemd/system/rpm-ostreed-automatic.service.d
             └─override.conf
     Active: inactive (dead)
TriggeredBy: ● rpm-ostreed-automatic.timer
       Docs: man:rpm-ostree(1)
             man:rpm-ostreed.conf(5)
/home/juha : rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:latest
                   Digest: sha256:cfdead231281fe47da210f45ac70b5129e27e088769dc4e176e0375b50b881f3
                  Version: latest-41.20250310 (2025-03-10T05:06:01Z)
  ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:latest
                   Digest: sha256:22904bf0e15e0d1c0ac44c79567addaa9c921ba92b9521d2f89b3ffbcb9e03b2
                  Version: latest-41.20250309.2 (2025-03-09T10:30:34Z)
  ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:latest
                   Digest: sha256:4f5c8103eaf87c6cad1e53334b9c7eae864e03abc21df619269661783e378b6f
                  Version: latest-41.20250213.1 (2025-02-13T06:28:37Z)
                   Pinned: yes

My laptop usually is just sleeping during the night time here in the EU. And I just

So looking at that, next time the timer triggers is
Trigger: Mon 2025-03-10 16:43:35 EET; 15min left

As this is not my work laptop, its usually opened before work (around 6-7am) and then put to sleep and opened in the evening again. But I usually also update manually in the morning (atleast sometimes).

Although I can’t just now remember was the service checking once or twice a day for updates. But looking at the service components atleast the trigger seems to be there

So the trigger time came and seems to have launched normally

/home/juha : systemctl status rpm-ostreed-automatic.timer
● rpm-ostreed-automatic.timer - rpm-ostree Automatic Update Trigger
     Loaded: loaded (/usr/lib/systemd/system/rpm-ostreed-automatic.timer; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/rpm-ostreed-automatic.timer.d
             └─override.conf
     Active: active (waiting) since Mon 2025-03-10 13:39:00 EET; 3h 5min ago
 Invocation: b6093d7675134fe598eefc9d7419f842
    Trigger: Tue 2025-03-11 04:05:00 EET; 11h left
   Triggers: ● rpm-ostreed-automatic.service
       Docs: man:rpm-ostree(1)
             man:rpm-ostreed.conf(5)
Mar 10 13:39:00 neptune systemd[1]: Started rpm-ostreed-automatic.timer - rpm-ostree Automatic Update Trigger.

And if checking the status

/home/juha : rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run 50s ago
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:latest
                   Digest: sha256:cfdead231281fe47da210f45ac70b5129e27e088769dc4e176e0375b50b881f3
                  Version: latest-41.20250310 (2025-03-10T05:06:01Z)
  ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:latest
                   Digest: sha256:22904bf0e15e0d1c0ac44c79567addaa9c921ba92b9521d2f89b3ffbcb9e03b2
                  Version: latest-41.20250309.2 (2025-03-09T10:30:34Z)
  ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:latest
                   Digest: sha256:4f5c8103eaf87c6cad1e53334b9c7eae864e03abc21df619269661783e378b6f
                  Version: latest-41.20250213.1 (2025-02-13T06:28:37Z)
                   Pinned: yes

So the process is “twice” a day, 12hour interval.

Thanks. That’s weird, my trigger has never displayed any other time than 4am.

If you suspend your computer(s) tonight, what’s the output from those three commands when you wake it/them up tomorrow? Please share tomorrow so that we can compare.

Yes will try to remember to check it tomorrow morning.

1 Like

Hi people,

While I don’t have an issue with the auto-update not working, I do have a question about it.

I have my Aurora stable being updated once a week, but that happens on Sundays only.

Is it possible to have it update on Fridays or any other day of the week? Thanks.

Nope. The day when a new weekly is build is set on the build infra.

Of course you can build a custom image and change it there.

Or rebase to a stable-daily where you get the package updates daily but get to keep the gated kernel from CoreOS