38 lines
1.7 KiB
Plaintext
38 lines
1.7 KiB
Plaintext
# TP27 — RouterBOOT-Firmware auf 7.24 nachziehen (2026-08-17).
|
|
#
|
|
# KONTEXT: Christoph hat alle vier MikroTik selbst auf RouterOS 7.24 stable
|
|
# gehoben. Verifiziert, nichts kaputt. Was dabei offen blieb, ist die zweite
|
|
# Haelfte jedes MikroTik-Upgrades: die **RouterBOOT-Firmware** haengt zurueck.
|
|
#
|
|
# crs326-core 7.19.5 -> 7.24
|
|
# crs326-branch 7.19.5 -> 7.24
|
|
# ap1 7.23.2 -> 7.24
|
|
# ap2 7.23.2 -> 7.24
|
|
#
|
|
# `/system routerboard upgrade` SCHREIBT die Firmware nur; wirksam wird sie
|
|
# erst beim naechsten Reboot. Darum: erst schreiben, dann gezielt rebooten,
|
|
# dann `current-firmware` gegenpruefen — vorher zeigt sie weiter den alten Wert.
|
|
#
|
|
# WARUM UEBER GC UND NICHT MikroMCP: `/system routerboard upgrade*` steht auf
|
|
# der MikroMCP-Deny-Liste (zu Recht — es schreibt den Bootloader). Der
|
|
# GC-Weg ist ohnehin der vorgeschriebene.
|
|
#
|
|
# Push je Geraet:
|
|
# python3 nautobot/gc-manual-plan.py --device <name> \
|
|
# --commands-file routeros/tp27-routerboot-firmware-724.rsc \
|
|
# --change-id TP27-fw-<name> --deploy
|
|
#
|
|
# Danach Reboot (MikroMCP `reboot`), dann:
|
|
# current-firmware muss 7.24 sein.
|
|
#
|
|
# REIHENFOLGE (bewusst): ap2 -> ap1 -> core -> branch.
|
|
# branch zuletzt, weil der Arbeitsplatz per LAN daran haengt — er ist die
|
|
# Lifeline zu allen anderen Geraeten und wird erst angefasst, wenn der Rest
|
|
# nachweislich sauber oben ist.
|
|
#
|
|
# Backups davor: <geraet>-post724-pre-fw-20260817.backup
|
|
|
|
:do { /system routerboard upgrade } on-error={ :log info "tp27: upgrade warf" }
|
|
|
|
:log info ("tp27: fw-geschrieben current=" . [/system/routerboard/get current-firmware] . " upgrade=" . [/system/routerboard/get upgrade-firmware] . " (current wechselt erst nach dem Reboot)")
|