Upgrades to v2023.2 and later releases are only supported from releases v2022.1 and later. This is due to migrations that have been removed to simplify maintenance.
Was genau würde denn passieren, wenn ein Knoten von einer älteren Gluon-Version auf 2023.2 upgraden will? Lehnt der Autoupdater das Upgrade einfach ab? Oder wird das Upgrade durchgeführt, aber hinterher funktioniert der Knoten nicht korrekt?
Ich frage, weil wir bei Freifunk Bremen noch ein paar Knoten haben, die das letzte Upgrade auf 2023.1.1 noch nicht gemacht haben (die Gründe wissen wir nicht) und halt noch auf 2021.1.2 laufen. Und es gibt sogar noch Knoten, bei denen das Autoupdate abgeschaltet ist und die deshalb mit 2019.1.3 laufen.
Da würde mich halt interessieren, ob wir bei einem künftigen Upgrade auf 2023.2 diese Knotenbetreiber vorher warnen müssen (damit ihre Knoten nicht kaputtgehen), oder ob wir denen nur z.B. die alten Zwischenversionen anbieten müssen, damit sie manuell nacheinander die Upgrades einspielen können.
Danke für den Anstoß/Reminder.
Ich wollte das immer mal zusammenschreiben.
Da wir beim Neanderfunk Anfang des Jahres bei der dem Einzug von FF-BGL das Feld bis zu (frühen) gluon2016 aufgerollt haben:
Die Liste der EdgeCases ist lang.
Falls mir niemand zuvorkommt, schreibe ich die wichtigsten 6-7 Dinge später zusammen.
Leider ist ein Upgrade Check auf dem Knoten aktuell nicht sinnvoll implementierbar (sysupgrade hat keinen Pre-Upgrade Hook in dem man praktische Dinge machen könnte).
Ob es jedoch wirklich zum Upgrade kommt, kommt stark darauf an. Grundsätzlich kann es aber schon dadurch kaputt gehen.
Den Upgrade Pfad hat @fmaurer hier letztes Jahr mal etwas aufgemalt:
Man kann sich nun einerseits über sowas wie das nginx geo Modul IP Listen bauen um unterschiedlichen Knoten unterschiedliche views bzw. redirects auszuliefern.
Und dann haben neuere Gluon Versionen noch einen HTTP Header mit der aktuellen Version in der autopudater Anfrage. Darüber könnte man künftig Dinge tun. Das ist aber leider noch ein vergleichsweise junges Feature und aktuell vermutlich noch nicht relevant.
Das ist in der Tat sehr gut.
Wenn man sich an die Schritte hält, dann ist es weitgehend geräuschlos bis auf Folgendes, was ich noch in Erinnung habe:
CPE210 (v1.x?) hat auf dem Weg von 2016 bis 2021 das Partitionslayout geändert, d.h. da musste ggf. das Update „geforced“ werden.
GL-Inet B1300 hat auf dem dem Weg von 2021.2x auf 2022.x einen „force“ gebraucht, weil irgendein Flag gefehlt hat.
zwischen 2023.1.x und 2023.2.x ist Nanostation XM (also die mit „neuen Boards“) nicht ohne „force“ mitgekommen.
Und wenn man sich nicht an obiges Schema hält, und größere Sprünge macht, dann gibt es Issues wie z.B.
Die Checksummen in den manifesten wurden von sha512 auf sha256 reduziert, d.h. späte 2016.2.x waren die ersten, die beides akzeptiert waren, sind also „Minimum“, wenn man weiter möchte. Wer sich das (build von gluon 2016.2.x) ersparen will, dem hilft evtl. hackscript unten.
Alternativ haben wir bei Neanderfunk noch eine Retro-VM, um so ein Gluon ggf. zu bauen. Kontaktiert uns mit site.conf/mk/modules, falls ihr einen Build braucht.)
Die Paritionsgröße/Paritionstabelle von ERX hat sich zwischen 2016 und 2021 mal geändert, Configverlust bei zu großem Sprung.
Die Paritionstabelle bei (mehreren?) x86-Images hat sich geändert, Configverlust bei zu großem Sprung
#!/bin/bash
#//
#// generate manifest-files for Gluon2016.2.x(?), both sha256 and sha512 for old routers
#// attention: imagenames for some routers (e.g. raspi, x86) may not match, due to different naming
#// of image-file and target-image
cd $1
echo $1
ZIELPFAD="./"
FLAVOUR="stable"
NOW=$(date -Is)
MANIFESTNAME="${FLAVOUR}.manifest"
echo "BRANCH=${FLAVOUR}">${MANIFESTNAME}
echo "DATE=${NOW}">>${MANIFESTNAME}
echo "PRIORITY=0">>${MANIFESTNAME}
echo "">>${MANIFESTNAME}
for FILEN in "${ZIELPFAD}"/gluon*; do
if [ -f ${FILEN} ]; then
# echo $FILE
FILEBASENAME=$(basename "${FILEN}")
SHA256=$(sha256sum "${FILEN}"|cut -d" " -f1)
SHA512=$(sha512sum "${FILEN}"|cut -d" " -f1)
FILESIZE=$(stat -c%s "${FILEN}")
VERSION=$(echo ${FILEN}|cut -d"-" -f4)
MODEL=$(echo ${FILEN}|cut -d"-" -f5-|sed 's/\-sysupgrade.*//')
echo "${MODEL} ${VERSION} ${SHA256} ${FILESIZE} ${FILEBASENAME}">>${MANIFESTNAME}
echo "${MODEL} ${VERSION} ${SHA512} ${FILESIZE} ${FILEBASENAME}">>${MANIFESTNAME}
fi
done
echo "---">>${MANIFESTNAME}
Wir wollten von v2021.1.x über v2023.1.x nach v2023.2.x, wie in dem Diagramm vorgesehen. Dabei fällt allerdings dies auf:
EFI only systems won’t boot due to removed EFI support (introduced in v2023.1). This was necessary to work around a bug that causes a config loss during direct upgrades from v2021.1.x to v2023.1.x with the x86-64, x86-generic and x86-legacy targets (#2967).Gluon v2023.2 reintroduced EFI support.
Gepaart hiermit stellt sich die Frage nach dem Upgradepfad für x86-basierte Offloader:
Upgrades to v2023.2 and later releases are only supported from releases v2022.1 and later. This is due to migrations that have been removed to simplify maintenance.
Aber augenscheinlich ist das ein reines v2023.1-Thema, d. h. man ist safe, wenn man v2023.1 ohne Patch-Release mit EFI-Support nie ausgerollt hatte und somit es keine EFI-VMs geben kann?
* Images built for the x86 targets are now natively bootable on EFI systems without CSM or BIOS support modes.
EFI support was found to break upgrades from Gluon v2021.1.x. It will be removed from v2023.1.x to be reintroduced in a later release.
v2023.1 hatte support für EFI offloader eingeführt, was zu Problemen führte.
v2023.1.2 hat den Support für EFI offloader deshalb wieder entfernt
v2023.2.x hat diese Probleme nicht
d. h. man ist safe, wenn man v2023.1 ohne Patch-Release mit EFI-Support nie ausgerollt hatte und somit es keine EFI-VMs geben kann?