Remoteupdate der Recovery-Version

[Martin Dresbach]

Hallo zusammen!

Gibt es die Möglichkeit, ein direktes Remoteupdate der Recovery-Version
durchzufÃŒhren?

Um meine Situation etwas genauer zu erklÀren:
Ich benutze die Recovery-Option nicht als "Rettungsring", sondern um
zwei unterschiedliche Konfigurationen zur VerfÃŒgung zu haben. Per
Cronjob boote ich dann zu festgelegten Zeitpunkten entweder die eine
oder die andere Version. Funktioniert soweit auch alles problemlos.

Betreibe ich jedoch gerade die Standard-Version und möchte etwas an der
Recovery-Version verÀndern, muss ich bisher erst ein Remoteupdate
machen, rebooten, aus dieser Version die Recovery-Version erstellen, ein
erneutes Remoteupdate durchfÃŒhren (um wieder die vorherige
Standard-Version aufzuspielen) und erneut rebooten. Das nervt ziemlich
und frisst auch einiges an Zeit. Zumal ein Reboot zur Änderung einer
inaktiven Version nicht einmal nötig wÀre.

Daher jetzt die Frage, ob man direkt die (inaktive) Recovery-Version
updaten kann.

Hoffe mir kann da jemand einen Tip geben.

Vielen Dank und liebe GrÌße,
Martin

[Peter Schiefer]

Hallo Martin,

Gibt es die Möglichkeit, ein direktes Remoteupdate der Recovery-Version
durchzuführen?

ja - wenn Du dir zum Übertragen der durch den build (mkfli4l.[sh/bat]) ein
eigenes Script schaffst oder alternativ diese per Hand überträgst.
Bei der Übertragung ist folgendes zu übertragen:

Quelle Ziel
<builddir>/kernel fli4l:/boot/kernel2
<builddir>/rootfs.img fli4l:/boot/rootfs2.img
<builddir>/opt.img fli4l:/boot/opt2.img
<builddir>/rc.cfg fli4l:/boot/rc2.cfg

Daher jetzt die Frage, ob man direkt die (inaktive) Recovery-Version
updaten kann.

siehe oben - das geheimnis liegt im Namen der Dateien unter /boot auf dem
fli4l. habe diese die ergänzende 2 ist das die Version die im
syslinux-Bootmenü als Recover-Version gewählt werden kann.

Wenn man statt der 2 eine 3 in die Dateinamen setzt, steht einem durch
auswahl von t beim syslinux-Bootemenü sogar eine dritte Version zur
Verfügung (eine Testimg-Version)

Hoffe mir kann da jemand einen Tip geben.

hoffe meine Infos helfen Dir ;)

Gruß Peter

[Martin Dresbach]

Hallo Peter!

Danke fÃŒr die schnelle Antwort. Ob ich mir dafÃŒr ein Script basteln
werde, weiß ich zwar jetzt noch nicht, aber auch eine Übertragung per
SCP hilft mir schon sehr viel weiter.
Also ist das "Geheimnis" tatsÀchlich nur die angehÀngte 2 im
Dateinamen?!? Hatte gedacht, die Versionen wÃŒrden sich in irgendeiner
Form doch noch etwas mehr unterscheiden...

[quote]hoffe meine Infos helfen Dir ;)[/quote]
Ja, sehr!

Danke und liebe GrÌße,
Martin

[Christoph Schulz]

Hallo!

Post by Martin Dresbach
Hallo zusammen!
Gibt es die Möglichkeit, ein direktes Remoteupdate der Recovery-Version
durchzuführen?
Ich benutze die Recovery-Option nicht als "Rettungsring", sondern um
zwei unterschiedliche Konfigurationen zur Verfügung zu haben. Per
Cronjob boote ich dann zu festgelegten Zeitpunkten entweder die eine
oder die andere Version. Funktioniert soweit auch alles problemlos.
[...]

Das finde ich jetzt nicht so günstig.

Die Recovery-Version ist nun mal für den Zweck der Wiederherstellung einer
vorigen, als stabil bekannten Version gedacht. Alle Werkzeuge "drumherum"
gehen auch davon aus, genauso wie die GUI. Das, was du hier machst, ist
quasi eine "Vergewaltigung" dieses Mechanismus für ganz andere Zwecke.

Ich würde dich somit bitten, ein Feature-Ticket im fli4l-Bugtracker
anzulegen, in dem du deinen Anwendungsfall detailliert beschreibst (z.B.
"Unterstützung multipler Konfigurationen"). So kann jemand in Zukunft ein
vernünftiges System entwickeln, was deinen Anwendungsfall abdeckt. Der
Ratschlag von Peter ist zwar korrekt und kurzfristig sicherlich hilfreich,
aber ohne irgendwelche Garantien für die Zukunft.


Viele Grüße,

[Martin Dresbach]

Hallo Christoph!

Mir ist durchaus bewusst, dass der ursprÃŒngliche Gadanke hinter der
Recovery-Funktion ein anderer war, als der fÃŒr was ich es benutze.

Da dieser Mechanismus jedoch zuverlÀssig funktioniert (wie ich finde),
sehe ich auch keinen Grund, diesen nicht zu nutzen. Dem Fli ist es ja
letztendlich egal, aus welchem tatsÀchlichen Grund nun die alternative
(bzw. Recovery) Version gebootet werden soll.
Leider ist dies momentan fÃŒr meinen Einsatzzweck die einzige
Möglichkeit, einen automatiesierten Ablauf zu realisieren.

Und sind wir doch mal ganz ehrlich: Wer wÃŒrde denn bitte das Rad neu
erfinden? Es existiert bereits genau der Mechanismus um alternative
Configs / Setups zu nutzen, nur heißt dieser nun mal "opt_recover" und
nicht "opt_multiconfig". Ganz davon abgesehen gibt es ja dank dem
Entwickler des Paketes sogar die (undokumentierte) Funktion, eine dritte
Config zum Testen einzubinden. und mit etwas Schreibarbeit wÀren
durchaus auch mehr als 3 Configs möglich.

Allerdings wÃŒrde mich mal interessieren, was aus rein technischer (bzw.
deiner) Sicht wirklich gegen meinen Anwendungsfall spricht. Immerhin ist
ja auch eine Recovery-Version nur eine alternative Config welche im
Bedarfsfall (bzw. Fehlerfall) gebootet wird.

Ich hatte es Ìbrigens zuvor nicht erwÀhnt, aber ich betreibe dieses
Setup auf einem 3.10.7. Ein Feature-Request wÃŒrde also sicherlich nie
zur Umsetzung kommen. Jedenfalls nicht fÃŒr den 3er-Zweig.

Das klang jetzt vielleicht alles ein wenig hart, ist aber nicht so
gemeint! Du weißt doch, dass ich immer fÃŒr deine Kritik und Hilfe
offen und dankbar bin! :)

Liebe GrÌße,
Martin

[Martin Dresbach]

Hallo.

Auch wenn es sicherlich fÌr den 3er-Zweig keine solche VerÀnderung
mehr geben wird, habe ich dennoch ein Ticket angelegt. WÀre im
4er-Zweig ja bestimmt genauso schön zu haben. :)

https://ssl.nettworks.org/bugs/browse/FFL-1878

Liebe GrÌße,
Martin