My guess is that this won’t work if “version” is newer than the one displayed here, right?
The temporal prime directive forbids it.
1 Like
I use it if I haven’t updated in a while, and if I update to the latest version it usually gets an error, so I have to update gradually
Hi @Aqua1ung , I just ran intothe same issue. 41050 is currently the highest number
https://cdn.download.clearlinux.org/update/41050/
but https://cdn.download.clearlinux.org/latest is 41040
$ sudo swupd info
Distribution: Clear Linux OS
Installed version: 41040
Version URL: https://cdn.download.clearlinux.org/update
Content URL: https://cdn.download.clearlinux.org/update
just with --version it would fail:
$ sudo swupd update --version 41050
Update started
Version on server (41040) is not newer than system version (41040)
Update complete - System already up-to-date at version 41040
took me some time to figure out, but you can use the staging format:
$ sudo swupd update --version 41050 -F staging
Update started
Preparing to update from 41040 to 41050
Downloading packs (32.04 MB) for:
- bootloader-extras
- cloud-api
- clr-installer
- git
- kernel-native
- moreutils
- os-core
- os-core-plus
- os-core-update
- perl-basic
- sysadmin-basic
- vim
Finishing packs extraction...
[100%]
Statistics for going from version 41040 to version 41050:
changed bundles : 12
new bundles : 0
deleted bundles : 0
changed files : 38
new files : 4830
deleted files : 4839
Validate downloaded files
[100%]
Starting download of remaining update content. This may take a while (1 files)...
[100%]
Installing files...
[100%]
Update was applied
Calling post-update helper scripts
External command: none
Update took 47.8 seconds, 37 MB transferred
1 file was not in a pack
Update successful - System updated from version 41040 to version 41050
you can see the available formats here (wthouth the format,
https://cdn.download.clearlinux.org/update/version/
so in my case staging did the trick
https://cdn.download.clearlinux.org/update/version/formatstaging/latest
is 41050
2 Likes
So what happens is this
we make release candidates – which are exposed in the updates directory but are not (normally) visible to swupd yet. If and when QA passes (not all release candidates pass QA – they might have evil bugs) we expose the version number to swupd.
We send out the OS bits for the release during the RC phase (think of this as a large rsync/rsync-equivalent)
When we expose the release to swupd this is updating a 10 byte text file, so a very quick rsync.
(in a world with mirrors this time lag gives the mirrors time to sync etc)
If you want you can go to this release candidate (we internally call it staging) using
swupd update --format staging
but be warned – these are pre-QA versions that might not be great at all.
1 Like
@arjan ah, thx!. how is the behaviour if using a specific --version 41050 is this sticky or would anyhow auto upgrade (if auto update is not disabled).
Also for the swupd update --format staging is this a sticky thing and what to take care of if one wants to move back from staging to the latest numbered format, or should this not be done?
the format override is not sticky
ok, @arjan , how about switching to and back from staging
For a private mix I wonder what is more handy, two separate URI for staging and stable,
some magic identifying the client and dynamically define what is latest, or some different format
as its done on clear linux or if there are different ways.
for us, we’ve decided to do one content stream, and we have a different url to get the version – this allows us to do our QA against the actual external content (rules out one more potential source of error) and it’s really just the same stream.
if you would have different content, then it changes of course and you obviously end up with a full second stream
1 Like
how does it work with the different URLs, do you modify the /latest for each uri, or what is the difference?
And is the 2nd URL public available? Might be handy for testing
so swupd has a built in notion of the current “format”
and if you look at Index of /update/version/
(this URL is settable as the version url in swupd) you can see the various directories, one per format.
inside of that is a “latest” file that swupd uses to know what to go to.
You can override the format – and “staging” is special in that this is for the pre-qa builds.
a “format” is really a generation – and when we need the clients to visit a specific version before they can go to newer (later) versions, we increase the format so that those in, say, format 34 will visit the last release of format 34 – which transitions the client system to format 35.
This guaranteed “your system will visit this version before going to newer” lets us deal with incompatible changes, either in swupd or in the base OS that would arise from going to an older to a much newer version
3 Likes
@arjan how is the mechanism that swupd knows the last format available?
Is there some file stating the format number, or is swupd looking at a folder and picks the one with the highest version number?
it’s built into the binary (configure option) to have a safe default, but otherwise
/usr/share/defaults/swupd/format has this
2 Likes