Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revert "develmaster: Prepare release v3.11.5 (release5/3.11.5)" #139

Merged
merged 1 commit into from
Sep 21, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@

<br />

Upgrading SailfishOS at the GUI (via *Settings→SailfishOS updates*) provides very little information about its progress / process / success, beyond reading `/var/log/systemupdate.log` after an upgrade. This can make troubleshooting issues hard.<br />
Upgrading SailfishOS at the GUI (per *Settings→SailfishOS updates*) provides very little information about its progress / process / success, beyond reading `/var/log/systemupdate.log` after an upgrade. This can make troubleshooting issues hard.<br />
Furthermore the GUI offers no control which SailfishOS version to upgrade to.

In contrast to that, Jolla's [guide how to upgrade SailfishOS at the command line](https://docs.sailfishos.org/Support/Help_Articles/Updating_Sailfish_OS/#update-using-the-command-line) offers full control, while lacking any logs or safety checks.<br />
Expand All @@ -18,7 +18,7 @@ Safety measures:
* Check BTRFS allocation, if the root filesystem uses BTRFS.
* Check battery state (since v1.0).
* Check if upgrading to a correct and available SailfishOS version.
* Check if omitting (i.e. "jumping over") a [stop release](https://docs.sailfishos.org/Support/Releases/) (since v0.3).
* Check if omitting (i.e., "jumping over") a [stop release](https://docs.sailfishos.org/Support/Releases/) (since v0.3).
* Automatically unapply all Patches, if Patchmanager 2 is installed.
* Stop systemd services for cron, btrfs-balance-checker etc. (since v2.2).
* Terminate running processes, which may disturb upgrading SailfishOS (since v2.7).
Expand All @@ -31,7 +31,7 @@ Usage (as root user):

* **sfos-upgrade [\<version\>]**<br />
With a version number provided as parameter, it sets SSU to this version and in release mode before upgrading to this SailfishOS version. This is the regular use case.<br />
Without a version number, it retrieves the one set for SSU to perform slightly relaxed checks, but does not alter SSU's settings for upgrading. Hence the version to upgrade to and SSU's "release mode" have to be set (by e.g. `ssu re <version>`) *before* executing `sfos-upgrade` without a parameter.
Without a version number, it retrieves the one set for SSU to perform slightly relaxed checks, but does not alter SSU's settings for upgrading. Hence the version to upgrade to and SSU's "release mode" have to be set (per e.g., `ssu re <version>`) *before* executing `sfos-upgrade` without a parameter.

* **sfos-upgrade --verify**<br />
Performs a "samegrade" operation, i.e. checks if the recent versions of all available RPMs are installed and updates or installs them accordingly.<br />
Expand All @@ -51,7 +51,7 @@ Notes:

* Built RPMs are available in the [release section](https://github.com/Olf0/sfos-upgrade/releases) and for easy installation on SailfishOS at [OpenRepos](https://openrepos.net/content/olf/sfos-upgrade).
* All operations comprise the RPMs from *all* enabled repositories, because that is **version --dup**'s implicit behaviour (as with **pkcon upgrade-system** and **zypper dist-upgrade** / **zypper dup** too, all utilising **libzypp**).
* When upgrading from a long outdated SailfishOS version (e.g. after a "factory reset"), **sfos-upgrade** eases and speeds up the process of upgrading to a recent SailfishOS release via consecutively installing all "stop releases" on the way.<br />
* When upgrading from a long outdated SailfishOS version (e.g., after a "factory reset"), **sfos-upgrade** eases and speeds up the process of upgrading to a recent SailfishOS release via consecutively installing all "stop releases" on the way.<br />
Simply run `sfos-upgrade <intended version>`, reboot, and repeat: it will guide you through all [stop releases](https://docs.sailfishos.org/Support/Releases/).<br />
When upgrading to SailfishOS releases < 4.1.0, you may omit running `post_sfos-upgrade` between consecutive SailfishOS upgrades (but do reboot each time!). But you shall run it after having upgraded to any SailfishOS release ≥ 4.1.0 or the ultimately intended version.
* To ensure that a SailfishOS installation is complete and up to date, use `sfos-upgrade --verify`; this will "samegrade" to the installed version, which is as close as one can get to the `version --verify` lost [since SailfishOS 2.2.1](https://together.jolla.com/question/187243/changelog-221-nurmonjoki/#187243-sailfish-version) (which only checked for missing or not up-to-date RPMs, while "samegrading" will also install them) without **zypper**. With it (per `pkcon install zypper`), a `zypper refresh && zypper verify --dry-run` comes closer to what `version --verify` did (only checking). While **zypper** can also be used for up-/down-/same-grading, that is [rather a "last resort"-measure than the primary recommendation](https://together.jolla.com/question/117335/verify-integrity-of-installed-packages-after-upgrade-or-later/?answer=214905#post-id-214905), hence use **sfos-upgrade** for that.
Expand Down
22 changes: 11 additions & 11 deletions bin/sfos-upgrade
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ export POSIXLY_CORRECT=1 # Also necessary for a sane `df` output, see https://g
# (see https://git.sailfishos.org/mer-core/bash / https://git.merproject.org/mer-core/bash ) and consequently in
# SailfishOS since its beginnings (checked for v1.0.0.5 by
# curl -fL https://releases.sailfishos.org/sources/sailfish-1.0.0.5-oss.tar.bz2 | tar -tv | fgrep bash , as no earlier
# released version is available there, e.g. the first ones at https://coderus.openrepos.net/whitesoft/sailversion ).
# released version is available there, e.g., the first ones at https://coderus.openrepos.net/whitesoft/sailversion ).
# In SailfishOS releases before 4.0, /bin/sh is just a symbolic link to /bin/bash anyway; though I have not checked
# that for ancient releases (which might be re-deployed after a "factory reset"), likely SailfishOS inherited that
# from Fedora, via MeeGo and Mer (MeeGo reconstructed), too (i.e., in addition to the presence of bash by default).
Expand All @@ -28,7 +28,7 @@ export POSIXLY_CORRECT=1 # Also necessary for a sane `df` output, see https://g
# 0 Everything worked fine: all applicable checks, all applicable, preparatory steps, and the upgrade proper
# 1 A check failed
# 2 Help called
# 3 Called incorrectly (e.g. with wrong parameters)
# 3 Called incorrectly (e.g., with wrong parameters)
# 4 Aborted upon user request
# 5 Error while interacting with the OS (reading / writing from the filesystem, calling programs, etc.)
# 6 Error while executing one of the preparatory steps for the upgrade proper
Expand Down Expand Up @@ -151,7 +151,7 @@ else
l?)
printf '%s\n' "Notice: The installed version $installed_release is smaller than the one currently set for SSU (${ssu_set})." >&2
printf '%s' "A possible reason for this is, that the `sailfish-osupdateservice osupdate-check` invoked by osupdate-check.service (which is regularly triggered by `osupdate-check.timer`)" >&2
printf '%s\n' " does more than just checking (observed with SailfishOS 3.2.1 and earlier): E.g. setting ssu to the recent release version or next stop release." >&2
printf '%s\n' " does more than just checking (observed with SailfishOS 3.2.1 and earlier): E.g., setting ssu to the recent release version or next stop release." >&2
printf '%s\n\n' "Never mind, the version for SSU will be set correctly again, later on." >&2
;;
g?)
Expand All @@ -174,7 +174,7 @@ then
exit 3
fi

mylist_sfos_releases='4.6.0.15,4.6.0.13,4.6.0.12,4.6.0.11,4.5.0.25,4.5.0.24,4.5.0.21,4.5.0.19,4.5.0.18,4.5.0.16,4.4.0.72,4.4.0.68,4.4.0.64,4.4.0.58,4.3.0.15,4.3.0.12,4.2.0.21,4.2.0.19,4.1.0.24,4.1.0.23,4.0.1.48,4.0.1.45,3.4.0.24,3.4.0.22,3.3.0.16,3.3.0.14,3.2.1.20,3.2.1.19,3.2.0.14,3.2.0.12,3.1.0.12,3.1.0.11,3.0.3.10,3.0.3.9,3.0.3.8,3.0.2.8,3.0.1.14,3.0.1.13,3.0.1.11,3.0.0.11,3.0.0.8,3.0.0.5,2.2.1.23,2.2.1.20,2.2.1.19,2.2.1.18,2.2.0.29,2.1.4.15,2.1.4.14,2.1.4.13,2.1.4.12,2.1.3.7,2.1.3.5,2.1.3.3,2.1.2.3,2.1.1.26,2.1.1.25,2.1.1.24,2.1.1.23,2.1.1.12,2.1.0.11,2.1.0.10,2.1.0.9,2.0.5.6,2.0.4.14,2.0.4.13,2.0.3.14,2.0.3.11,2.0.2.51,2.0.2.48,2.0.2.47,2.0.2.45,2.0.2.43,2.0.1.11,2.0.1.9,2.0.1.7,2.0.0.10,1.1.9.30,1.1.9.28,1.1.9.27,1.1.9.24,1.1.9.23,1.1.7.28,1.1.7.27,1.1.7.25,1.1.7.24,1.1.7.23,1.1.6.27,1.1.6.26,1.1.6.24,1.1.4.29,1.1.4.28,1.1.4.24,1.1.4.22,1.1.2.16,1.1.2.15,1.1.2.13,1.1.2.10,1.1.1.27,1.1.1.26,1.1.1.24,1.1.0.39,1.1.0.38,1.1.0.37,1.1.0.29,1.1.0.26,1.1.0.23,1.1.0.22,1.1.0.19,1.0.8.21,1.0.8.20,1.0.8.19,1.0.8.18,1.0.7.18,1.0.7.16,1.0.7.14,1.0.7.12,1.0.5.19,1.0.5.16,1.0.5.13,1.0.5.12,1.0.5.11,1.0.4.20,1.0.4.16,1.0.4.12,1.0.4.10,1.0.3.8,1.0.3.7,1.0.3.5,1.0.2.5,1.0.1.12,1.0.1.10,1.0.1.6,1.0.0.5,1.0.0.3,1.0.0.1,0.99.6.8,0.99.6.3,0.99.5.11,0.99.5.8,0.99.5.6'
mylist_sfos_releases='4.5.0.25,4.5.0.24,4.5.0.21,4.5.0.19,4.5.0.18,4.5.0.16,4.4.0.72,4.4.0.68,4.4.0.64,4.4.0.58,4.3.0.15,4.3.0.12,4.2.0.21,4.2.0.19,4.1.0.24,4.1.0.23,4.0.1.48,4.0.1.45,3.4.0.24,3.4.0.22,3.3.0.16,3.3.0.14,3.2.1.20,3.2.1.19,3.2.0.14,3.2.0.12,3.1.0.12,3.1.0.11,3.0.3.10,3.0.3.9,3.0.3.8,3.0.2.8,3.0.1.14,3.0.1.13,3.0.1.11,3.0.0.11,3.0.0.8,3.0.0.5,2.2.1.23,2.2.1.20,2.2.1.19,2.2.1.18,2.2.0.29,2.1.4.15,2.1.4.14,2.1.4.13,2.1.4.12,2.1.3.7,2.1.3.5,2.1.3.3,2.1.2.3,2.1.1.26,2.1.1.25,2.1.1.24,2.1.1.23,2.1.1.12,2.1.0.11,2.1.0.10,2.1.0.9,2.0.5.6,2.0.4.14,2.0.4.13,2.0.3.14,2.0.3.11,2.0.2.51,2.0.2.48,2.0.2.47,2.0.2.45,2.0.2.43,2.0.1.11,2.0.1.9,2.0.1.7,2.0.0.10,1.1.9.30,1.1.9.28,1.1.9.27,1.1.9.24,1.1.9.23,1.1.7.28,1.1.7.27,1.1.7.25,1.1.7.24,1.1.7.23,1.1.6.27,1.1.6.26,1.1.6.24,1.1.4.29,1.1.4.28,1.1.4.24,1.1.4.22,1.1.2.16,1.1.2.15,1.1.2.13,1.1.2.10,1.1.1.27,1.1.1.26,1.1.1.24,1.1.0.39,1.1.0.38,1.1.0.37,1.1.0.29,1.1.0.26,1.1.0.23,1.1.0.22,1.1.0.19,1.0.8.21,1.0.8.20,1.0.8.19,1.0.8.18,1.0.7.18,1.0.7.16,1.0.7.14,1.0.7.12,1.0.5.19,1.0.5.16,1.0.5.13,1.0.5.12,1.0.5.11,1.0.4.20,1.0.4.16,1.0.4.12,1.0.4.10,1.0.3.8,1.0.3.7,1.0.3.5,1.0.2.5,1.0.1.12,1.0.1.10,1.0.1.6,1.0.0.5,1.0.0.3,1.0.0.1,0.99.6.8,0.99.6.3,0.99.5.11,0.99.5.8,0.99.5.6'
my_recent_sfos_release="${mylist_sfos_releases%%,*}"
sailversion_sfos_releases=""
sailfishdocs_sfos_list=""
Expand Down Expand Up @@ -221,10 +221,10 @@ if [ "$installed_release" = "$upgrade_release" ]
then compar0=e4
else
sailfishdocs_stop_releases=""
# Because Jolla regularly fails to document their stop releases in a timely manner (see e.g. https://forum.sailfishos.org/t/scripted-download-of-https-jolla-zendesk-com-hc-en-us-articles-201836347-fails/7935/2 ),
# Because Jolla regularly fails to document their stop releases in a timely manner (see e.g., https://forum.sailfishos.org/t/scripted-download-of-https-jolla-zendesk-com-hc-en-us-articles-201836347-fails/7935/2 ),
# I had to change the policy how to deal with this lacking information: All final releases, which are not documented not to be a stop release, are handled as one starting with sfos-upgrade 3.9.1.
# mylist_stop_releases='4.6.0.15,4.5.0.25,4.4.0.72,4.3.0.15,4.2.0.21,4.1.0.24,4.0.1.48,3.4.0.24,3.2.0.12,3.0.0.8,2.2.0.29,2.0.5.6,2.0.0.10,1.1.9.30,1.1.7.28,1.1.2.16,1.0.2.5,1.0.0.5'
mylist_stop_versions='4.6.0,4.5.0,4.4.0,4.3.0,4.2.0,4.1.0,4.0.1,3.4.0,3.2.0,3.0.0,2.2.0,2.0.5,2.0.0,1.1.9,1.1.7,1.1.2,1.0.2,1.0.0'
# mylist_stop_releases='4.5.0.25,4.4.0.72,4.3.0.15,4.2.0.21,4.1.0.24,4.0.1.48,3.4.0.24,3.2.0.12,3.0.0.8,2.2.0.29,2.0.5.6,2.0.0.10,1.1.9.30,1.1.7.28,1.1.2.16,1.0.2.5,1.0.0.5'
mylist_stop_versions='4.5.0,4.4.0,4.3.0,4.2.0,4.1.0,4.0.1,3.4.0,3.2.0,3.0.0,2.2.0,2.0.5,2.0.0,1.1.9,1.1.7,1.1.2,1.0.2,1.0.0'
# 0.99.5.11 and 1.0.1.10 are not documented to be "stop releases" at https://docs.sailfishos.org/Support/Releases/
# But 2.0.5.6 seems to be a "stop release", at least on some devices, see comments thread to
# https://together.jolla.com/question/207172/downgrade-sailfish-os/?answer=207190#post-id-207190
Expand Down Expand Up @@ -314,7 +314,7 @@ else
;;
g4)
printf '%s\n' "Warning: About to DOWNGRADE SailfishOS from $installed_release to ${upgrade_release}, which downgrades to a \"point release\" \"below\" the stop release $stop_release." >&2
printf '%s\n\n' "While downgrading between \"point releases\" seems to be generally feasible, doing so \"below\" a stop release implies the slight danger of the changes making it a stop release not all being introduced with SailfishOS ${stop_release%.*}.0 (but e.g. with ${stop_release}, and thus potentially downgrading \"across\" these changes, which would break this SailfishOS installation)." >&2
printf '%s\n\n' "While downgrading between \"point releases\" seems to be generally feasible, doing so \"below\" a stop release implies the slight danger of the changes making it a stop release not all being introduced with SailfishOS ${stop_release%.*}.0 (but, e.g., with ${stop_release}, and thus potentially downgrading \"across\" these changes, which would break this SailfishOS installation)." >&2
break
;;
g?)
Expand All @@ -339,7 +339,7 @@ else
;;
g4)
printf '%s\n' "Warning: About to DOWNGRADE SailfishOS from $installed_release to ${upgrade_release}, which downgrades to a \"point release\" \"within\" the stop release range ${stop_release%.*}.x!" >&2
printf '%s\n\n' "While downgrading between \"point releases\" seems to be generally feasible, doing so \"within\" a stop release range implies the danger of the changes making it a stop release not all being introduced with SailfishOS ${stop_release%.*}.0 (but e.g. with ${installed_release}, and hence potentially downgrading \"across\" these changes, which would break this SailfishOS installation)." >&2
printf '%s\n\n' "While downgrading between \"point releases\" seems to be generally feasible, doing so \"within\" a stop release range implies the danger of the changes making it a stop release not all being introduced with SailfishOS ${stop_release%.*}.0 (but, e.g., with ${installed_release}, and hence potentially downgrading \"across\" these changes, which would break this SailfishOS installation)." >&2
break
;;
g?)
Expand Down Expand Up @@ -437,15 +437,15 @@ else
# but downloaded and installed one by one, hence requiring much less space on persistent storage (i.e., the root filesystem) for upgrading.
# OTOH, be aware that the download sizes Jolla mentions in their release notes are only valid for upgrading from the direct predecessor release,
# but one may upgrade from one stop release to another, comprising the RPMs of multiple releases.
# Furthermore these estimates from Jolla only cover their own default components (RPMs), individually installed RPMs (e.g. from the Jolla Store, OpenRepos or even Jolla's SailfishOS repositories) are not and cannot be accounted for.
# Furthermore these estimates from Jolla only cover their own default components (RPMs), individually installed RPMs (e.g., from the Jolla Store, OpenRepos or even Jolla's SailfishOS repositories) are not and cannot be accounted for.
if ! [ "$free_space" -gt 524288 ]
then # This hard ½ GiB limit is an rough estimate of an upper boundary for the sum of all RPM size increases by an upgrade plus space for the package management's indexes, caches etc.
printf '%s\n' "Aborting: Only 0.5 GiB or less ($free_space KiB) free space on the root filesystem!" >&2
printf '%s\n' "Before retrying, please clean up or enlarge the root filesystem, see:" >&2
printf '%s\n' "https://gitlab.com/Olf0/sailfishX#33-increasing-the-root-lvm-volume-size" >&2
exit 1
elif ! [ "$free_space" -gt 786432 ]
then # As the largest SailfishOS upgrades (Jolla's estimates: the sum of the sizes of all updated RPMs (which are installed by default), when directly upgrading from the predecessor release) have been over 600 MiB (e.g. SFOS 3.3.0 -> 3.4.0), a ¾ GiB limit to warn explicitly seems to be reasonable.
then # As the largest SailfishOS upgrades (Jolla's estimates: the sum of the sizes of all updated RPMs (which are installed by default), when directly upgrading from the predecessor release) have been over 600 MiB (e.g., SFOS 3.3.0 -> 3.4.0), a ¾ GiB limit to warn explicitly seems to be reasonable.
printf '%s\n' "Warning: Only 0.75 GiB or less ($free_space KiB) free space on the root filesystem!" >&2
printf '%s\n' "Please do consider to abort and then to clean up or to enlarge the root filesystem before retrying, see:" >&2
printf '%s\n' "https://gitlab.com/Olf0/sailfishX#33-increasing-the-root-lvm-volume-size" >&2
Expand Down
4 changes: 2 additions & 2 deletions rpm/sfos-upgrade.spec
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ Summary: Scripts for fail-safe upgrading of SailfishOS at the command lin
# The Git tag format must adhere to <release>/<version> since 2023-05-18.
# The <version> tag must adhere to semantic versioning, for details see
# https://semver.org/
Version: 3.11.4
Version: 3.11.3
# The <release> tag comprises one of {alpha,beta,rc,release} postfixed with a
# natural number greater or equal to 1 (e.g., "beta3") and may additionally be
# postfixed with a plus character ("+"), the name of the packager and a release
Expand All @@ -14,7 +14,7 @@ Version: 3.11.4
# build at GitHub and OBS, when configured accordingly; mind the sorting
# (`adud` < `alpha`). For details and reasons, see
# https://github.com/Olf0/sfos-upgrade/wiki/Git-tag-format
Release: release4
Release: release3
# The Group tag should comprise one of the groups listed here:
# https://github.com/mer-tools/spectacle/blob/master/data/GROUPS
Group: Applications/System
Expand Down
Loading