1
1
Fork
You've already forked bootc
1

Suggestion: Automatic Updates #24

Open
opened 2024年10月18日 10:55:09 +02:00 by boredsquirrel · 2 comments

Automatic updates are crucial to guarantee that all deployments are what they should be. The stable base makes bootc updates completely unproblematic.

The important variables are:

Unmetered Network

preset=yes

This is queried with nmcli, uBlue figured that out afaik.

This is crucial for phone hotspots, USB or Bluetooth tethering, and a warning needs to be displayed that their "metered" state needs to be changed manually.

They are all just registered as wifis or even etherned connections, for this system to work they need to be manually changed.

An interactive list showing the registered networks with checkboxes could be nice. Maybe there is a way to do this?

Battery State

preset=40

This is queried by reading a file. It should be above that percentage, otherwise an update might drain the battery and you lose important work.

This is a difficult one. What about desktop PC users? What about critical security updates?

The value can be changed to anything above 5% I think.

This may be setup in yafti, if the user uses a desktop PC.

AC Connected

preset=no

If an AC connection needs to be connected to work.

This could be used in a more complex function, that AC will allow updates even with a battery level below the minimum, but above like 5%

Implementation

The logic parts would need to be shell scripts I think, or some other programming language you think makes sense.

The different states could be used as systemd targets, with the updater being a systemd service depending on them.

This makes the system flexible

  • scripts have variables defined, like the battery state
  • 3 or more systemd targets get activated through them
  • a systemd service does the automatic bootc and flatpak updates.
  • a systemd timer can be used to set the update interval. The timer requires all, any or none of these targets to be active

This means the targets dont need to be disabled or anything, they can just be removed from the update timer.

Also the targets can be used for other things like enabling batterysaver mode, but this may duplicate functionality with other energy saving tools.

Automatic updates are crucial to guarantee that all deployments are what they should be. The stable base makes bootc updates completely unproblematic. The important variables are: ### Unmetered Network `preset=yes` This is queried with `nmcli`, uBlue figured that out afaik. This is crucial for phone hotspots, USB or Bluetooth tethering, and a warning needs to be displayed that their "metered" state needs to be changed manually. They are all just registered as wifis or even etherned connections, for this system to work they need to be manually changed. An interactive list showing the registered networks with checkboxes could be nice. Maybe there is a way to do this? ### Battery State `preset=40` This is queried by reading a file. It should be above that percentage, otherwise an update might drain the battery and you lose important work. This is a difficult one. What about desktop PC users? What about critical security updates? The value can be changed to anything above 5% I think. This may be setup in yafti, if the user uses a desktop PC. ### AC Connected `preset=no` If an AC connection needs to be connected to work. This could be used in a more complex function, that AC will allow updates even with a battery level below the minimum, but above like 5% ## Implementation The logic parts would need to be shell scripts I think, or some other programming language you think makes sense. The different states could be used as systemd targets, with the updater being a systemd service depending on them. This makes the system flexible - scripts have variables defined, like the battery state - 3 or more systemd targets get activated through them - a systemd service does the automatic bootc and flatpak updates. - a systemd timer can be used to set the update interval. The timer requires all, any or none of these targets to be active This means the targets dont need to be disabled or anything, they can just be removed from the update timer. Also the targets can be used for other things like enabling batterysaver mode, but this may duplicate functionality with other energy saving tools.
Owner
Copy link

These ideas are great, different behavior depending on battery and network state.

As is, HeliumOS automatically updates via bootc-fetch-apply-updates.service triggered by a corresponding systemd timer. The Flatpak updates are currently handled by GNOME Software and possibly Discover in the future.

There are plans to allow configuration via the system images GUI. I agree with your proposed implementation, it should be feasible to configure conditional automatic updates in that matter.

I'll add this to the roadmap.

These ideas are great, different behavior depending on battery and network state. As is, HeliumOS automatically updates via `bootc-fetch-apply-updates.service` triggered by a corresponding systemd timer. The Flatpak updates are currently handled by GNOME Software and possibly Discover in the future. There are plans to allow configuration via the system images GUI. I agree with your proposed implementation, it should be feasible to configure conditional automatic updates in that matter. I'll add this to the roadmap.

thaks for the reply, I will look at the service and see what could be added

thaks for the reply, I will look at the service and see what could be added
Sign in to join this conversation.
No Branch/Tag specified
dev
release
No results found.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
HeliumOS/bootc#24
Reference in a new issue
HeliumOS/bootc
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?