Should Kalpa automatically run a system update?

English Applications
1

So, I thought that MicroOS Kalpa would run a system update automatically, the default being every day at midnight. I have a thread going on in TW, and I showed a screenshot how Discover announces available updates.

The response was:

Once you have run transactional-update dup , reboot to the new snapshot or if the machine is powered on and the reboot service is running it will auto reboot overnight…

So I’ve been reading the docs (Portal Kalpa) and it states:

Most of the time, you should not need to use any of these commands interactively, as Kalpa has automatic system updates via the transactional-update.service systemd service.

However, yesterday evening, out of curiosity, I manually ran:

transactional-update dup

… which resulted in a 1,100 package update!! (it’s installed in a VM and I installed it about a month ago).

So the big question: is my Kalpa not running the transactional-update.service systemd service?? What should I check ?

2

@aggie systemctl status transactional-update.timer this will tell you when it’s next due to run (Trigger line entry).

1 Like
3

Thanks for the quick reply … I shall run that command when I fire up Kalpa.

I would like to mention, I think I discovered the problem. I started up the System Settings app and I found this, set to Manual, so maybe that was the issue. I don’t ever remember setting that to Manual … so I changed it to Automatic

update

UPDATE … here’s your command

# systemctl status transactional-update.timer
● transactional-update.timer - Daily update of the system
     Loaded: loaded (/usr/lib/systemd/system/transactional-update.timer; enabled; preset: enabled)
     Active: active (waiting) since Wed 2023-08-16 21:52:47 CDT; 9min ago
    Trigger: Thu 2023-08-17 00:32:44 CDT; 2h 30min left
   Triggers: ● transactional-update.service
       Docs: man:transactional-update(8)

Aug 16 21:52:47 localhost.localdomain systemd[1]: Started Daily update of the system.
4

Discover has nothing to do with updating the base system. It only handles flatpaks.

That being said, there is currently a bug in Discover, when it comes to updating said flatpaks.

https://bugs.kde.org/show_bug.cgi?id=471548

1 Like
5

Hi @sfalken … thanks for the bug report. It seems my Kalpa Discover updates apps routinely. But I will keep a watch on it.

6

Okay, I ran this (see below) … does the statement:
“unmet condition check (ConditionACPower=true)”

Does that mean it’s not running the System Update because the laptop is not plugged in and charging?

I keep it charged often - I never let it get below 40%. (remember, this is running in a VM on the laptop).

# journalctl -u transactional-update.service
Aug 03 20:45:48 localhost.localdomain systemd[1]: Update the system was skipped because of an unmet condition check (ConditionACPower=true).
-- Boot 52543d6bd4ea49129deac6afbde67c4f --
Aug 07 13:41:00 localhost.localdomain systemd[1]: Update the system was skipped because of an unmet condition check (ConditionACPower=true).
-- Boot 8fe58004871f47839037ae811a14e034 --
Aug 09 07:16:45 localhost.localdomain systemd[1]: Update the system was skipped because of an unmet condition check (ConditionACPower=true).
-- Boot 0eb5c071da534a3e8a59dedd4b67d2ad --
Aug 16 13:57:36 localhost.localdomain systemd[1]: Update the system was skipped because of an unmet condition check (ConditionACPower=true).
7

@aggie I would guess so… I don’t see any mention of this in https://kubic.opensuse.org/documentation/man-pages/transactional-update.conf.5.html or https://kubic.opensuse.org/documentation/man-pages/transactional-update.service.8.html

All works fine here on my system that is powered on all the time, laptop and tablet just get updated when needed…

8

I don’t recall there being a requirement to be on AC power for the transactional-update timer to run.

More likely, what you’re running into is the timer itself.

There are two conditions where the update is going to be allowed to run:

A) It will run between 00:00 and 02:00 localtime

unless

B) The machine isn’t running at that time. Then on your next boot, the update will run at a random time between boot and 2 hours after being booted.

If you’re never letting the VM run for more than 2 hours at a time, it fails that check, and is skipping the automatic update.

9

@aggie If you fire up the machine and leave it running, there is a new snapshot (20230816) available so should see it run…

10
11

Well, I started up the laptop not long ago, and I just ran the timer check - and it shows it’s going to run 12 hours from now… I’m not going to get up at 2am to check on it:

# systemctl status transactional-update.timer
● transactional-update.timer - Daily update of the system
     Loaded: loaded (/usr/lib/systemd/system/transactional-update.timer; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/transactional-update.timer.d
             └─override.conf
     Active: active (waiting) since Thu 2023-08-17 12:27:57 CDT; 40min ago
    Trigger: Fri 2023-08-18 01:59:53 CDT; 12h left
   Triggers: ● transactional-update.service
       Docs: man:transactional-update(8)

Aug 17 12:27:57 localhost.localdomain systemd[1]: Started Daily update of the system.
12

You don’t have to stay up, it will either update, or it won’t, if you leave it running.

Just run 'sudo journalctl -u transactional-update` when you get up in the morning, and the last lines should look something like:

Aug 17 00:17:04 mustang transactional-update[16040]: transactional-update finished
Aug 17 00:17:04 mustang transactional-update[21889]: 2023-08-17 00:17:04 tukit 4.3.0 started
Aug 17 00:17:04 mustang transactional-update[21889]: 2023-08-17 00:17:04 Options: reboot notify
Aug 17 00:17:04 mustang transactional-update[21889]: 2023-08-17 00:17:04 Triggering reboot using notify
Aug 17 00:17:04 mustang transactional-update[21889]: 2023-08-17 00:17:04 Transaction completed.
Aug 17 00:17:04 mustang systemd[1]: transactional-update.service: Deactivated successfully.
Aug 17 00:17:04 mustang systemd[1]: Finished Update the system.
Aug 17 00:17:04 mustang systemd[1]: transactional-update.service: Consumed 24.386s CPU time.

I just grabbed the last eight lines of mine, as an example.

13

Thanks for your last reply @sfalken … and yea, I’ve executed a ‘transactional-update dup’ yesterday, out of curiosity (and stated in my first post).

So, I guess I’m gonna have to pour over the Kalpa documentation to learn how to change the settings for the ‘automatic update’ , i.e., to change the time to check, frequency of re-checks, and turn off the ‘power cord’ requirement.

I certainly understand the want to set the time to check at midnight-2am, for servers that are running 24x7, but not a desktop :+1:

14

@aggie you need to copy the default /usr/lib/systemd/system/transactional-update.service and timer over to /etc/systemd/system directory and modify as required, the service to remove the condition and the timer to set how/when you want to run.

2 Likes
15

@aggie Just an FYI for you. I see that ConditionACPower= is what is needed to meet the condition, see < 1218551 – systemd: Unable to override ConditionACPower=true>

1 Like
16

I’ll read up on the link and check it all out a bit later - thanks for the follow-up!