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:
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.