[Bugreport] 7490 mit 7.12/freetz-ng 16373 und Patch "Add boot manager"

riganit

Neuer User
Mitglied seit
7 Jan 2014
Beiträge
11
Punkte für Reaktionen
1
Punkte
3
Ich hab auf https://trac.boxmatrix.info/freetz-ng/report auf die Schnelle keine Möglichkeit gefunden ohne Registrierung ein Ticket anzulegen, vielleicht kann das jemand mit Account übernehmen. Sonst stehts halt hier fürs erste mal aufgeschrieben.

Hat man den Patch FREETZ_PATCH_MODFS_BOOT_MANAGER ("Add boot manager") gewählt und auf einer Box noch KEIN System im zweiten Slot (linux_fs_start=0 ist aktiv, linux_fs_start=1 ist leer, erst einmal geflasht), dann wird die "Neustart"-Seite des AVM-WebUI, die der Patch ja verändert, leer angezeigt (weiße Fläche ohne Button).

Es sieht so aus, als würde dieser Fall (nur 1 System im Flash) das Skript durcheinander bringen. Im freetz-WebUI unter "System" funktioniert es, dort wird linux_fs_start=1 als leer angezeigt.

Sobald man ein zweites Mal geflasht hat, passt alles. Es müsste also nur dieser Sonderfall berücksichtigt werden.
 
Es müsste also nur dieser Sonderfall berücksichtigt werden.
Hmm ... klingt erst einmal komisch, hätte aber tatsächlich daran liegen können, daß bei Versionen ab 07.08 dann irgendeine Variable nicht gesetzt ist. Das "Grundskript" ist ja schon vor 07.08 entstanden und da habe ich definitiv auch diese Konstallation berücksichtigt und ausführlich getestet (so ganz unberücksichtigt ist das also auch bisher schon nicht):

https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/gui_bootmanager#L1217

Hier schlägt entweder das "is_kernel_present" (https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/gui_bootmanager#L437) nicht korrekt fehl (weil die Kernel-Partition doch irgendwelche komischen Daten enthält und nicht nur gelöscht ist - eine leere Flash-Partition sollte aus lauter Eins- oder Null-Bits bestehen, auch wenn ich nur die ersten 128 Bit teste) oder es liegt doch erst an der weiteren Verarbeitung. Ich will jetzt nicht beschwören, daß ich die auch mit leeren Partitionen getestet habe, aber ich bin mir einigermaßen sicher, daß ich den Javascript-Code auch für "inactive_version=missing" implementiert habe und dann teste ich so etwas i.d.R. auch.

Die (für eine Fehlersuche unbedingt erforderlichen) "Rohdaten" zzgl. ein paar weiterer Informationen erhält man jedenfalls, wenn man in einer Shell mal "gui_bootmanager debug" aufruft (https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/gui_bootmanager#L1335) - ausgehend von diesen Ergebnissen muß man dann weiter schauen.

Wobei es schon merkwürdig ist, wenn auf einer Box mit Freetz nur ein einziges System vorhanden ist ... normalerweise würde man ja sein allererstes Freetz-Image auf einer Box nicht unbedingt in der Partition installieren, in der zu diesem Zeitpunkt das einzige gewiß funktionsfähige System liegt.

Aber wie auch immer (das soll also das "Fehlverhalten" der Anzeige nicht entschuldigen, da interessiert mich die eigentliche Ursache schon) ... ein nachfolgendes "gui_bootmanager get_values" sollte dann spätestens Aufschluß geben, ob die an den Javascript-Code übermittelten Daten die erwarteten sind - da sollte dann das erwähnte inactive_system=missing stehen.

Ist auch das noch "wie erwartet", muß man halt mal mit den Developer-Tools des Browsers gucken, was da schiefgeht ... die Abfrage für dieses "missing" und die passende Fehlermeldung (https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/add_to_system_reboot.sh#L68) sind jedenfalls vorgesehen, auch in der Version für FRITZ!OS ab 07.08.

---------------------------------------------------------------------------------------------------

Bei mir klappt jedenfalls dann auch die Erkennung dieser Konstellation einwandfrei, wie man hier sehen kann (zuerst sind beide Systeme installiert, dann lösche ich den zweiten Kernel (linux_fs_start ist zufällig ohnehin gerade 0) und danach wird das inaktive System korrekt als "leer" erkannt):
Code:
root@fb7490:~ $ gui_bootmanager debug
system type = VR9
system selector = 0
system is switched = false
system branding = avm
system branding is changeable = true
active kernel = /dev/mtdblock0
active filesystem = /wrapper/filesystem_core.squashfs
active system version = 113.07.11
active system date = 22.05.2019, 10:47:40 Uhr
active system modification date = 05.06.2019, 21:34:42 Uhr
active system modification source = modfs
brandings supported on active system = 1und1 avm
inactive kernel = /dev/mtdblock2
inactive system is installed = true
inactive filesystem = mount:/dev/mtdblock3:/filesystem_core.squashfs
inactive filesystem mounted on /var/tmp/5367_1573690491/alt_root
inactive system version = 113.07.01
inactive system date = 10.09.2018, 11:42:49 Uhr
inactive system modification date = 05.06.2019, 21:50:45 Uhr
inactive system modification source = modfs
brandings supported on inactive system = 1und1 avm
inactive filesystem dismounted
root@fb7490:~ $ echo "mtd 2 erase all" >/proc/mtd
root@fb7490:~ $ gui_bootmanager debug
system type = VR9
system selector = 0
system is switched = false
system branding = avm
system branding is changeable = true
active kernel = /dev/mtdblock0
active filesystem = /wrapper/filesystem_core.squashfs
active system version = 113.07.11
active system date = 22.05.2019, 10:47:40 Uhr
active system modification date = 05.06.2019, 21:34:42 Uhr
active system modification source = modfs
brandings supported on active system = 1und1 avm
inactive kernel = /dev/mtdblock2
inactive system is installed = false
inactive filesystem = mount:/dev/mtdblock3:/filesystem_core.squashfs
inactive system checks skipped
root@fb7490:~ $ gui_bootmanager clear_cache
root@fb7490:~ $ gui_bootmanager get_values
active_version="113.07.11"
active_date="22.05.2019, 10:47:40 Uhr"
active_modified_by="modfs"
active_modified_at="05.06.2019, 21:34:42 Uhr"
active_brandings="1und1 avm"
inactive_version="missing"
current_branding="avm"
switch_branding_support=true
current_switch_value=0
system_is_switched=false
root@fb7490:~ $
In diesem Zustand zeigt dann auch das GUI (íst zwar 07.11 und nicht 07.12, aber das sollte erst einmal keinen Unterschied machen) korrekt bei mir an:
inactive_missing.PNG

Da kann ich also erst einmal keinen Fehler finden ... daher brauche ich (wenn ich da irgendetwas untersuchen wollte) weitere Infos - ganz so simpel und eindeutige wie oben beschrieben, ist das Ganze dann doch nicht unbedingt.

Wenn es am Ende nur daran liegt, daß die alternative Kernel-Partition eben doch nicht leer ist und damit versucht wird, ein gar nicht installiertes Dateisystem zu mounten, dann kann man sicherlich noch etwas machen ... wobei dann irgendwo bei mir wieder die Frage auftaucht, woher da ein halbes OS (also nur ein Kernel) kommen soll.

Jedenfalls rechnet das Skript tatsächlich nicht mehr damit, daß es das alternative System nicht mounten kann, wenn es doch eines gibt: https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/gui_bootmanager#L1217 - hier müßte ggf. Zeile 1218 um drei Zeilen nach unten verschoben werden, damit es erst nach erfolgreichem Mounten gesetzt wird.

Aber zuvor will ich schon noch wissen, ob diese Konstellation (nicht-leere Kernel-Partition, aber kein YAFFS2 bzw. kein Inhalt und damit auch keine "filesystem_core.squashfs" in der zugehörigen Dateisystem-Partition) tatsächlich auch die Ursache ist.

Am Ergebnis des Mountens der YAFFS2-Partition kann ich das jedenfalls nicht festmachen (das ist der zusätzliche Schritt, der bei VR9-Boxen fällig wird), denn deren Strukturen werden einfach neu eingerichtet beim Mount-Versuch, wenn sie zuvor nicht existierten.

Und an der Existenz der "filesystem_core.squashfs" will ich es auch nicht festmachen, weil der Code an dieser Stelle auch für andere Modelle, wo es keine YAFFS2-Partition gibt, derselbe ist und damit zusätzlich noch in "device file" vs. "regular file" unterschieden werden müßte (wobei "test -e" funktionieren könnte).

Aber am Ende ist es eigentlich auch egal, WARUM das alternative System nicht gemountet werden kann ... nur bei der Frage, ob so ein Mount-Fehler am Ende tatsächlich auf ein "missing" hinauslaufen sollte (es kann sich ja u.U. auch um ein unbekanntes Dateisystem-Format handeln, wenn z.B. noch eine Version < 06.5x in der alternativen Partition steckt), bin ich noch im Zweifel. Eigentlich ist für diesen Fall ja eine andere Fehlerbehandlung vorgesehen (https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/add_to_system_reboot.sh#L67), die dem Benutzer weiterhin die Chance erhält, auf die andere Partition umzuschalten - das wäre beim Verschieben der Zeile 1218 nach unten dann auch hinfällig.

Hier kommen für meine Begriffe jedenfalls sooo viele "Unstimmigkeiten" zusammen (damit die Seite erst mal leer ist), daß ich mir diese sehr exotische Situation irgendwie nicht so richtig erklären kann und nur, um dann 100% "sicher" zu sein, will ich nicht unbedingt ändern ... der Rattenschwanz an Regressionstests ist einfach zu lang.

--------------------------------------------------------------------------------------------------

Außerdem verstehe ich nicht, warum offenbar (beim Trace) die Shell nach dem Aufruf "mp=$(mount_alternative_system)" die Elterninstanz beendet (jedenfalls kommt unmittelbar danach "cleanup"), wenn doch die Funktion "mount_alternative_system" eigentlich eine Subshell ist (runde Klammer um den Body) - das dort enthaltene "exit 1" sollte eigentlich nicht die Parent-Instanz beenden. An anderen Stellen (wo der Rückgabewert dann gleichzeitig der Funktionswert ist - z.B. für "is_puma_based_device") klappt das ja auch:
Code:
+ is_puma_based_device
+ [ -f /etc/puma6_helper.sh ]
+ . /etc/puma6_helper.sh
+ PUMAHELPER_PUMA6HWIDS=199 204 213 220 231
+ PUMAHELPER_PUMA7HWIDS=233
+ unset IS_PUMA6 IS_PUMA7 IS_ARM IS_ATOM
[...]
+ type is_puma7
+ [  = y ]
+ exit 1
[...]
+ mount -t yaffs2 -o ro /dev/mtdblock3 /var/tmp/6890_1573692616/wrapper
+ mount -t squashfs -o ro /var/tmp/6890_1573692616/wrapper/filesystem_core.squashfs /var/tmp/6890_1573692616/alt_root
+ exit 1
+ mp=
+ cleanup
+ [ -z /var/tmp/6890_1573692616 ]
Ich muß erst mal nachlesen, warum sich die Shell hier so komisch verhält (eine "bash" macht es tatsächlich genauso) und bei "exit 1" keine leere Variable zuweist (obwohl dieses "mp=" da ja auch noch steht), sondern stattdessen den Exit-Befehl in der Subshell auf sich selbst bezieht.

Vielleicht habe ich ja auch mal wieder nur "Shell" nicht verstanden und der POSIX-Standard sieht das irgendwo so vor - oder es ist noch eine andere Trap-Condition, die hier zuschlägt, denn "cleanup" wird ja bei "HUP EXIT INT TERM" jeweils aufgerufen. Ein reiner Fehler kann es aber auch wieder nicht sein, dafür fehlt dann die (Shell-)Message ... irgendwie schon komisch. Jedenfalls ist dieses direkte Aussteigen nach der Zuweisung auch die Ursache für leere Seiten ... nur bringt damit das Verlagern der Zeile 1218 nach hinten ja überhaupt nichts, wenn das Skript doch schon bei der Zuweisung an "mp" aussteigt.

Wobei das eben alles nur das "Sahnehäubchen" ist, was ich hier weiter getestet habe ... die Gretchenfrage bleibt es, warum da überhaupt versucht wird, das alternative System zu mounten und ob die Kernel-Partition da "unerwarteten" Inhalt hat.

EDIT:
Schon witzig ... wenn die Ausgabe einer Subshell, die mit einem Exit-Code <> 0 verlassen wurde, direkt einer Variablen zugewiesen werden soll, gibt das einen Fehler: https://pubs.opengroup.org/onlinepubs/9699919799/ - Punkt 2.8.1

Wird diese Ausgabe aber nur intern verwendet und z.B. direkt in einem "printf"-Statement für eine "%s"-Variable substituiert, wird der Exit-Code der Subshell ignoriert (was ich an mehreren Stellen verwendet habe).

Obendrein gilt das aber auch nur für den Parent-Prozess, also für die oberste Ebene ... derselbe Mechanismus funktioniert eine Ebene tiefer problemlos:
Code:
+++ find_mountpoint_for_device /dev/mtdblock3
++++ sed -n -e 's|^[0-9]\+ [0-9]\+ [0-9:]* [^ ]* \(.*\) .* - [^ ]* /dev/mtdblock3 .*|\1|p' /proc/self/mountinfo
+++ line=
+++ '[' 0 -eq 0 ']'
+++ '[' 0 -eq 0 ']'
+++ exit 1
++ wre=
++ '[' 1 -ne 0 ']'
, wie man am "find_mountpoint_for_device" sehen kann, das ebenfalls mit "exit 1" verlassen wird und trotzdem geht es nach der Zuweisung (eines leeren Wertes) an die Variable "wre" dann ganz normal weiter und die Subshell wird nicht beendet an dieser Stelle.

Steht vor dem Variablennamen gar noch ein "readonly", klappt das auch auf der obersten Ebene:
Code:
+ get_modified_by /var/tmp/11061_1573701172/alt_root
+ base=/var/tmp/11061_1573701172/alt_root
+ i=0
+ i=1
+ [ -f /var/tmp/11061_1573701172/alt_root/etc/.yourfritz_version ]
+ i=2
+ [ -f /var/tmp/11061_1573701172/alt_root/etc/.freetz-version ]
+ i=3
+ [ -f /var/tmp/11061_1573701172/alt_root/etc/.modfs_version ]
+ exit 1
+ readonly alternative_modified=
+ change_branding_support
Auch hier wird zwar die Subshell wieder mit "exit 1" verlassen und deren STDOUT ist leer, aber die Zuweisung an "alternative_modified" (das ist eine ältere Skript-Version) funktioniert noch tadellos. Nimmt man das "readonly" an dieser Stelle weg (damit wird aus einem Builtin-Aufruf wieder eine einfache Zuweisung), kracht es wieder:
Code:
+ get_modified_by /var/tmp/10903_1573701043/alt_root
+ base=/var/tmp/10903_1573701043/alt_root
+ i=0
+ i=1
+ [ -f /var/tmp/10903_1573701043/alt_root/etc/.yourfritz_version ]
+ i=2
+ [ -f /var/tmp/10903_1573701043/alt_root/etc/.freetz-version ]
+ i=3
+ [ -f /var/tmp/10903_1573701043/alt_root/etc/.modfs_version ]
+ exit 1
+ alternative_modified=
+ cleanup

Manchmal ist Shell-Code tatsächlich die reinste Wundertüte ... aber zumindest habe ich jetzt ein paar Ideen, woran es am Ende scheitert.

Aber die Frage nach der Ursache auf der Box beim TO, bleibt davon immer noch unberührt ... es sollte gar nicht erst zum Mount-Versuch kommen und damit auch nicht zum Abbruch an der Stelle mit dem Mounten des alternativen Systems.
 
Zuletzt bearbeitet:
Neuer Beitrag (absichtlich, damit man nicht den ganzen Rest von #2 lesen muß):

Mit diesem Commit: https://github.com/PeterPawn/YourFritz/commit/4cf1a1c00a71a4c5390a7816390e5560fbb1b0f6 sollte das Problem der leeren Seite auch dann nicht mehr auftauchen, wenn die Kernel-Partition Daten enthält und das Dateisystem dann doch nicht gemountet (und ausgewertet) werden kann.

Es bleibt aber bei der Unterscheidung
  • kein Kernel => kein alternatives System installiert, keine Umschaltung möglich
  • Fehler beim Mounten => Warnung, daß das System nicht erkannt werden kann, aber Umschalten wird ermöglicht
Am Ende ist es nur die Unterscheidung, ob die Ausgabe der Subshell bei Exit-Code 1 wegen Mount-Fehlers direkt einer Variablen zugewiesen wird oder ob da noch ein zusätzliches "printf" benutzt wird und damit der Exit-Code nicht das gesamte Skript abbricht.

Ich bin ja immer noch der Ansicht, daß hier sowohl die "bash" als auch "ash" aus der BusyBox gegen die POSIX-Spezifikation verstoßen (https://pubs.opengroup.org/onlinepubs/9699919799/ - Punkt 2.8.1), wenn sie bei nicht ausgeführter Variablenzuweisung keine Diagnose-Nachricht ausgeben - aber vielleicht wird die ja wieder durch die TRAP-Behandlung abgewürgt.
 
Vielen Dank für deine sehr ausführliche Antwort. Wenn ich das richtig verstehe hast du den entsprechenden Code geschrieben.
Sorry, dass ich einfach unterstellt habe, dass dieser Fall nicht berücksichtigt war. Das war ins blaue geschossen.

Ich weiß leider nicht, was in dem Moment tatsächlich in der zweiten Partition war. Der Ablauf war ausgehend von einer fabrikneuen Box:
  1. Strom dran, Funktion prüfen, installierte Firmware feststellen (6.83), Strom weg
  2. Strom dran, mit deinen Powershell-Skripten im Bootloader fangen und freetz-Image (mit 7.12 und dem Bootmanager) booten
  3. Neustartseite ist leer, auch nach weiteren normalen Bootvorgängen
  4. minimales freetz-Image ohne den Patch über freetz-WebUI flashen
  5. Neustartseite geht wieder
  6. vorheriges Image (mit Bootmanager) nochmal drauf
  7. Neustartseite gepatcht und funktioniert
Wird denn beim Flashen über Bootloader auch erst auf die zweite Partition umgeschaltet? Oder geht das in die gerade aktive, in diesem Fall einzige die etwas (sinnvolles) enhält.

Um das genauer untersuchen zu können, müsste ich also erst den Fabrikzustand der Box wieder herstellen. Ist das möglich?
Ich denke das
echo "mtd x erase all" >/proc/mtd
reicht dazu nicht? Und kann ich das bedenkenlos machen?
Ist es korrekt, dass linux_fs_start=0 /dev/mtdblock0 entspricht und linux_fs_start=1 /dev/mtdblock2?
Was ist dann /dev/mtdblock1?

Hier meine aktuelle Ausgabe von gui_bootmanager:
Code:
root@fritz:/var/mod/root# gui_bootmanager debug
system type = VR9
system selector = 1
system is switched = false
system branding = avm
system branding is changeable = true
active kernel = /dev/mtdblock2
active filesystem = /wrapper/filesystem_core.squashfs
active system version = 113.07.12
active system date = 08.07.2019, 12:09:26 Uhr
active system modification date = 14.11.2019, 01:02:03 Uhr
active system modification source = Freetz-NG
brandings supported on active system = 1und1 avm
inactive kernel = /dev/mtdblock0
inactive system is installed = true
inactive filesystem = mount:/dev/mtdblock1:/filesystem_core.squashfs
inactive filesystem mounted on /var/tmp/8252_1573764264/alt_root
inactive system version = 113.07.12
inactive system date = 08.07.2019, 12:09:26 Uhr
inactive system modification date = 11.11.2019, 23:45:05 Uhr
inactive system modification source = Freetz-NG
brandings supported on inactive system = 1und1 avm
inactive filesystem dismounted
root@fritz:/var/mod/root# gui_bootmanager get_values
active_version="113.07.12"
active_date="08.07.2019, 12:09:26 Uhr"
active_modified_by="Freetz-NG"
active_modified_at="14.11.2019, 01:02:03 Uhr"
active_brandings="1und1 avm"
inactive_version="113.07.12"
inactive_date="08.07.2019, 12:09:26 Uhr"
inactive_modified_by="Freetz-NG"
inactive_modified_at="11.11.2019, 23:45:05 Uhr"
inactive_brandings="1und1 avm"
current_branding="avm"
switch_branding_support=true
current_switch_value=1
system_is_switched=false
 
Oder geht das in die gerade aktive, in diesem Fall einzige die etwas (sinnvolles) enhält.
So ist es ... über den Bootloader wird (bei diesen "selbstinstallierenden" Images, das gilt NICHT für DOCSIS-Boxen, falls das ein späterer Leser mißverstehen möchte) in die gerade aktive Partition installiert (auch das AVM-Recovery-Programm macht das so) und wenn man das ändern will, muß man entweder den Code für diese Installation in der neuen Version anpassen (was Freetz nicht macht) oder vor dem Start der Box mit diesem Image von Hand auf die anderen Partitionen umschalten.

Bei der Installation als Update übernimmt anderer Code das Schreiben in den Flash (ein Shell-Skript "/var/install", das in dem Firmware-Image enthalten ist und mit Kernel und Dateisystem zusammen entpackt wird beim Aufruf des Updates), dieser schreibt direkt in die alternativen Partitionen und schaltet - nach Erfolg bei diesem Schreiben - auf dieses Set um, bevor die Box neu gestartet wird.

Was ist dann /dev/mtdblock1?
Mach doch einfach mal ein cat /proc/mtd ... die Namen sind eigentlich "selbsterklärend". Wer es ganz genau wissen will, macht das aus jedem installierten System einmal und vergleicht die Ausgaben.

Den Warnhinweis, daß die Nummerierungen im Bootloader NICHTS mit der Nummerierung im laufenden System zu tun haben, muß man ja hoffentlich nicht noch einmal wiederholen (auch wenn ich das hiermit gleich noch einmal getan haben sollte).

Fabrikzustand der Box wieder herstellen. Ist das möglich?
Zumindest nicht im notwendigen Umfang ... die Frage ist ja, warum da (vermutlich) in der inaktiven Kernel-Partition irgendwelche Daten standen. Das könnte ich mir ggf. noch mit Artefakten aus den Tests bei der Produktion erklären ... aber das ist auch nur eine Vermutung, ebenso wie die Annahme, daß es daran lag.

Da ein "erase ..."-Kommando über "/proc/mtd" zwar Daten löschen kann, aber der Zustand beim Auftreten des Problems damit doch nicht rekonstruiert wird, müßte mal jemand mit einer "fabrikneuen" 7490 (was langsam schwer wird, da die auch aussterben) nachsehen, was bei ihm da in den alternativen Partitionen steht. Du kannst da inzwischen nichts mehr zur Klärung beitragen ... es sei denn, Du tauschst die Box irgendwann :cool: beim Händler.

Ich hätte jedenfalls einen (anderen/zusätzlichen) Fehler gefunden durch diese Meldung (die Merkwürdigkeit bei der Zuweisung an "mp", wo ich immer noch nicht 100% sicher bin, ob "bash" und "ash" da tatsächlich den POSIX-Standard korrekt umsetzen) ... irgendwann wird dann auch die neue Version Einzug in Freetz halten, wenn dort der auszucheckende Stand meines Repos aktualisiert wurde.
 
über den Bootloader wird [..] in die gerade aktive Partition installiert
Gut zu wissen, auch wenn es normalerweise keine Rolle spielen dürfte.

Du kannst da inzwischen nichts mehr zur Klärung beitragen ... es sei denn, Du tauschst die Box irgendwann :cool: beim Händler.
Da ich diese Box nicht von einem Händler habe, sondern aus privatem Überbestand, kann ich die nicht umtauschen. Das würde ich aber auch nur deswegen nicht machen.

Dann belassen wir es mal dabei. Es ist ja mehr ein kosmetisches Problem. Danke dir für die Ursachenforschung und Erklärungen
 
Da ich diese Box nicht von einem Händler habe, sondern aus privatem Überbestand
Dann hat sich das ohnehin erledigt ... auch ich kriege eine (vorsichtig geöffnete) FRITZ!Box-Verpackung wieder so versiegelt (wenn auch das Einpacken einer Box immer irgendwie an Origami erinnert), daß ein "normaler Käufer" davon nichts bemerkt.

Bei dieser Konstellation liegt es für mich am nächsten, daß da einfach schon mal ein System in der zweiten Partition installiert war ... warum das dann nicht gemountet werden konnte (ggf. auch einfach eine Version < 06.5x, wo dann das SquashFS3 nicht erkannt wurde und durch den nunmehr behobenen Fehler das Skript zu früh abgebrochen wurde), spielt dann auch keine Rolle mehr.

Zumal die Aussage (in #1), daß "linux_fs_start" hier tatsächlich auf "0" gesetzt war, diese Annahme dann noch mehr stützt - beim ersten flüchtigen Lesen nimmt man das halt erst einmal so hin als "Aussage", die nicht unbedingt stimmen muß und aus fehlendem Verständnis für die Abläufe stammen könnte.

Erst mit den anderen Umständen ergibt das dann sogar wieder Sinn ... bei fabrikneuen Boxen ist dieser Wert aber i.d.R. gar nicht gesetzt (so kenne ich das jedenfalls und Gegenteiliges wurde bisher nicht beobachtet bzw. hatte andere Ursachen, wie sich dann im Nachhinein eigentlich immer herausstellte), was dann gleichbedeutend zu einer explizit eingetragenen "0" ist.
 
Ich bin mir ziemlich sicher dass die Box wirklich unbenutzt war. Jedenfalls hatte sie 0 Betriebsstunden und wenn ich mich richtig erinnere nach dem Flashen auch nur 2 Starts.
Wegen linux_fs_start, du meinst wenn jemand schon mal in die zweite Partition geflasht hat und dann wieder auf die erste umgestellt? Glaub ich eigentlich nicht, siehe oben.
Ob der Wert tatsächlich nicht gesetzt war oder implit "0" weiß ich nicht. Ich beziehe mich dabei auf die Anzeige im Webinterface.
 
OK, das ist auch wieder etwas anderes ... in #1 liest sich das noch so, als wäre die Angabe das Ergebnis irgendeines Auslesens (z.B. über EVA, während das Freetz-Image installiert wurde). Aus der Ausgabe meines Boot-Managers kann die Angabe ja eigentlich nicht stammen, wenn der überhaupt nichts in der Seite anzeigen wollte.

Wir schreiben offenbar desöfteren aneinander vorbei ... auch die Feststellung:
Im freetz-WebUI unter "System" funktioniert es, dort wird linux_fs_start=1 als leer angezeigt.
klang für mich zunächst mal so, als würde das im Freetz-GUI irgendwie unterschieden.

Nach der Lektüre der betreffenden Datei aus "Freetz-NG" (in "Freetz" gibt es diesen Teil ja gar nicht), kann ich mir das aber eigentlich nicht wirklich vorstellen:


Da wird also (zunindest nach dem, was ich beim Lesen verstehe) in Zeile 52 in jedem Falle (egal, ob das Mounten in "resmnt" funktioniert hat oder nicht) noch ein "FritzOS rev ()" ausgegeben ... das sehe ich jedenfalls nicht als "leer" an, sondern als "unvollständig".

---------------------------------------------------------------------------------------------------------

Aber ich würde das hier jetzt tatsächlich begraben wollen ... die Ursache für die "nicht-leere Kernel-Partition" finden wir durch nachträgliches Theoretisieren ohnehin nicht mehr, die Vorkehrungen waren vorhanden (in "gui_bootmanager" auch tatsächlich, das "system_lfs.cgi" interessiert sich für den Fall gar nicht und arbeitet einfach stur durch) und warum sie bei dieser Box nicht gegriffen haben, wird ein Rätsel bleiben.

Daß danach die Seite nicht mehr korrekt angezeigt wurde, weil beim Mount-Versuch (der normalerweise gar nicht erst erfolgen sollte, wenn die Kernel-Partition tatsächlich leer ist) das Sammeln der Daten abgebrochen wurde, ist inzwischen korrigiert ... ich weiß nicht, was ich sonst noch machen könnte.

Sollte ein anderer Benutzer irgendwann mal vor einem ähnlichen Problem stehen, nehme ich von diesem gerne die Ausgabe von "gui_bootmanager debug" entgegen ... dieses "sub-command" gibt es ja nur (bzw. gerade) für die Diagnose solcher Probleme.
 
Da wird also [...] in Zeile 52 in jedem Falle [...] noch ein "FritzOS rev ()" ausgegeben ... das sehe ich jedenfalls nicht als "leer" an, sondern als "unvollständig".
Genau, das hatte ich mit leer gemeint, eben keine sinnvollen Daten, die Infos fehlen, sind quasi leer.
 

Neueste Beiträge

Statistik des Forums

Themen
244,640
Beiträge
2,215,731
Mitglieder
371,221
Neuestes Mitglied
Charly1311
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.