Problem
linuxmuster-release-upgrade runs a long chain of steps (time sync, resolv.conf
save, grub boot disk detection/reconfig, do-release-upgrade to 26.04,
cloud-init removal, service disabling, resolv.conf restore, samba-ad-dc,
sophomorix tweak, repo sources, linuxmuster package upgrade, optional
reboot). It's a long-running, network- and reboot-adjacent process, so
partial failures (interrupted SSH session, transient network issue,
do-release-upgrade hiccup, etc.) are a realistic scenario - and the
natural recovery action for an admin is to just run the script again.
Several past issues (#175, #186, #187) were exactly about non-idempotent
resolv.conf handling breaking on a second run (destroying resolv.conf
entirely, or crashing because the backup file from a previous run either
didn't exist yet or had already been consumed). The goal of this issue is
to address idempotency for the whole script, not case by case as new
symptoms get reported.
Known gaps as of 20260812
- The
do-release-upgrade -c availability check aborts the whole script
once the OS has already been upgraded to 26.04 (e.g. by a previous,
later-failing run). do-release-upgrade -c only reports a release newer
than the currently installed one, so once the system is already on
26.04 it reports nothing, the script's grep -q "$NEXT_RELEASE" check
fails, and it exits with "Release 26.04 is not available!" - before ever
reaching the samba-ad-dc/sophomorix/repo-sources/linuxmuster-package
steps that might be exactly what failed and needs retrying. This is the
most severe gap: it currently makes the whole back half of the script
unreachable on any re-run after the OS-level upgrade itself succeeded.
- resolv.conf save/restore, the apt tweak file removal, and stopping
linbo-torrent/multicast sessions have all had (or are getting) guards
added so they no longer fail or clobber state on a second run - but this
has been fixed reactively, one reported bug at a time.
Goal
Review the script end to end and make every step either naturally
idempotent (safe no-op if already done) or explicitly guarded, so that
re-running the whole script after a failure at any point converges on
the same correct end state without manual cleanup.
Problem
linuxmuster-release-upgraderuns a long chain of steps (time sync, resolv.confsave, grub boot disk detection/reconfig,
do-release-upgradeto 26.04,cloud-init removal, service disabling, resolv.conf restore, samba-ad-dc,
sophomorix tweak, repo sources, linuxmuster package upgrade, optional
reboot). It's a long-running, network- and reboot-adjacent process, so
partial failures (interrupted SSH session, transient network issue,
do-release-upgradehiccup, etc.) are a realistic scenario - and thenatural recovery action for an admin is to just run the script again.
Several past issues (#175, #186, #187) were exactly about non-idempotent
resolv.conf handling breaking on a second run (destroying resolv.conf
entirely, or crashing because the backup file from a previous run either
didn't exist yet or had already been consumed). The goal of this issue is
to address idempotency for the whole script, not case by case as new
symptoms get reported.
Known gaps as of 20260812
do-release-upgrade -cavailability check aborts the whole scriptonce the OS has already been upgraded to 26.04 (e.g. by a previous,
later-failing run).
do-release-upgrade -conly reports a release newerthan the currently installed one, so once the system is already on
26.04 it reports nothing, the script's
grep -q "$NEXT_RELEASE"checkfails, and it exits with "Release 26.04 is not available!" - before ever
reaching the samba-ad-dc/sophomorix/repo-sources/linuxmuster-package
steps that might be exactly what failed and needs retrying. This is the
most severe gap: it currently makes the whole back half of the script
unreachable on any re-run after the OS-level upgrade itself succeeded.
linbo-torrent/multicast sessions have all had (or are getting) guards
added so they no longer fail or clobber state on a second run - but this
has been fixed reactively, one reported bug at a time.
Goal
Review the script end to end and make every step either naturally
idempotent (safe no-op if already done) or explicitly guarded, so that
re-running the whole script after a failure at any point converges on
the same correct end state without manual cleanup.