Closed fda77 closed 2 years ago
Sollten die Eckdaten vorliegen, die zur Unterstützung dieser Modelle benötigt werden, kann/würde ich das einbauen.
Ich bin ohnehin gerade am Boot-Manager dran - gestern kam (im Branch) der Teil hinzu, der die Erkennung, ob der Bootloader die Änderungen am Branding zuläßt oder nicht, bereitstellen soll. Dafür sind auch einige Operationen mit dd
, cmp
und grep
erforderlich - da sollte es dann auch kein echtes Problem sein, einen "flattened (u)image tree" so zu zerlegen (aber eben immer nur mit den Bordmitteln, weil das auch ohne Freetz oder ausgetauschte BusyBox funktionieren soll), daß man die "Stammdaten" für das jeweilige System auslesen kann.
Nach dem, was man bisher über die Modelle mit FIT weiß, speichern die ja das gesamte Image in jeweils einer größeren Partition pro vorhandenes System. Daraus folgt dann für mich auch, daß man zur Analyse, ob da ein funktionsfähiges System installiert ist oder nicht, nicht einfach nur ein SquashFS-Image mounten und darin nach ein paar Infos suchen muß, sondern man muß sich erst einmal auf die Suche nach diesem SquashFS-Image machen und das dann auch noch so mounten, daß dabei möglichst wenig zusätzlicher Ressourcenbedarf entsteht, was dann das "Extrahieren" des SquashFS-Images als gesonderte Datei schon fast wieder verbietet. Also müßte man dabei vermutlich wieder mit Loop-Devices und Offsets hantieren, was auch von vielen Faktoren (bis hin zu "alignment issues") abhängen kann.
Was (für mich zumindest) aber nicht akzeptabel wäre, ist die Notwendigkeit zusätzlicher Pakete (solange sie sich vermeiden lassen, was nicht immer möglich ist, denn Kryptopgrafie in Shell ist natürlich Unsinn - zumindest jenseits von PoC) - da müßte dann also erst mal das Zerlegen eines FIT-Images mit (AVM-)Bordmitteln implementiert werden.
Ansonsten müßte man sich auf das platte Umschalten (wenn das da überhaupt funktionieren sollte - dazu habe ich auch noch nichts gelesen) von linux_fs_start
verlegen - das ist bisher zumindest auch noch nicht vorgesehen bei mir, weil mir "blinde" Aktionen (wo ich dann nicht mal weiß, ob das alternative System überhaupt existiert und lauffähig ist) eigentlich widerstreben.
Um das Einbauen zu können, braucht es folgende (Er-)Kenntnisse:
/proc/avm_partitions
) irgendwelche zusätzlichen Pseudo-Files, die nahrhafte Informationen zum laufenden und zum inaktiven System liefern könnten?linux_fs_status
), die ich mit Aussagen zu den installierten Systemen in Verbindung gebracht hatte - ist so etwas bei diesen Modellen vorhanden im Environment?/proc/sys/urlader
arbeiten solltebootslotctl
in dem Skript zur Installation aus dem RAM (/etc/init.d/E03-flash_update
) genau? Schaltet das schon irgendetwas um oder speichert es nur die Infos für das neue System, was bisher immer in firmware_info
bei jedem Start neu gesetzt wurde?fit-image
installiert ... nur wie heißt dann die Partition für das andere System? Das grep
, mit dem die ID ermittelt wird, würde die Zeichenkette fit-image
auch dann finden, wenn sie nur ein Teil des Partitionnamens wäre - damit dürften da keine Zusätze wie reserved
verwendet werden für das alternative System. Oder dieser Name ist am Ende auch nur derjenige, welcher für das FIT-Image im RAM(!) verwendet wird, wie bei anderen Modellen das kernel_ram
und rootfs_ram
?bootslotctl
letztlich sogar das Schreiben des FIT-Images in die Zielpartitionen übernehmen, denn der ganze Rest darin befaßt sich nur noch mit dem UBI-Layer für config
- und NAS-Partition.Das Installieren an sich mag zwar bei der Umschaltung nicht gebraucht werden, aber man muß auch erst mal erkunden, ob es noch andere Mechanismen gibt, die sich mit einem Umschalten durch Schreiben nach /proc/sys/urlader/environment
ins Gehege kommen (auch das /var/install
-Skript in den AVM-Images für diese Modelle schreibt ja gar nicht mehr selbst nach linux_fs_start
, sondern da ist auch alles nur noch ein Aufruf von bootslotctl
) würden oder ob es auch einen direkten Aufruf von bootslotctl
gäbe, der anstelle des Schreibens nach /proc/sys/urlader/environment
verwendet werden könnte.
Gleichzeitig ist wohl das Binary bootslotctl
nur ein Shim für den Aufruf von Funktionen in der libbootslotctl
und selbst die ist eher "winzig", auch wenn darin einige interessante Infos zu finden sind, wenn man mal ein strings
auf sie losläßt (auszugsweise hierher kopiert):
bootslotctl_get_other
bootslotctl_activate_other
bootslotctl_commit_other
bootslotctl_get_active
bootslotctl_get_committed
bootslotctl_commit_this
bootslotctl_get_fw_version
bootslotctl_on_boot
bootslotctl_program_other
/var/bootedslot
cannot parse currently booted slot
slot%d=
invalid slot
firmware_info
linux_fs_start
linux_fs_status
slot%1d
bootslotctl has already been initialized.
fit%d
invalid slot
/sys/class/mtd
/sys/class/mtd/%s/name
/dev/%s
MTD for slot %d not found.
open mtd
CONFIG_ENVIRONMENT_PATH
CONFIG_ENVIRONMENT_PATH not set
%s/environment
CONFIG_ENVIRONMENT_PATH invalid
Cortex-A9
Das CONFIG_ENVIRONMENT_PATH
i.V.m. dem %s/environment
würde schon mal darauf hindeuten, daß da tatsächlich auch noch das TFFS-Interface im procfs
verwendet wird (und die Library dann Sachen wie get_active
oder activate_other
auch nur über dieses Interface abwickelt) - gleichzeitig sehen einige Dinge (get_active
, get_other
, activate_other
und get_fw_version
) so aus, als gäbe es da schon ein paar Funktionen, die man vielleicht nachnutzen kann, anstatt das alles selbst machen zu wollen.
Denn auch ein Blick in das Binary bootslotctl
zeigt ein paar Strings, die durchaus für die hier benötigten Funktionen stehen könnten:
get_committed
get_active
get_other
commit_this
activate_other
commit_other
on_boot
is_committed
is_active
get_fw_version
program_other
und damit vielleicht schon bei AVM eine neue "Abstraktionsschicht" bieten, hinter der Unterschiede der Modelle in der Zukunft mal verschwinden sollen.
Aber das oben Geschriebene zeigt für mich auch deutlich, daß man noch viel zu wenig über den "inneren Aufbau" dieser Boxen weiß (das Zerlegen des AVM-Images ist das eine, das Verstehen der inneren Funktionen etwas anderes), um das mal eben aus dem Handgelenk zu schütteln.
Ich bin auch nicht davon überzeugt, daß man das (in endlicher Zeit) implementieren bzw. erst mal richtig erkunden kann, wenn man keine eigene Box dazu hat. Die Kommunikation gestaltet sich da schon dann schwierig, wenn zwei Seiten in etwa auf demselben Stand der Skills sind - je weiter der auseinander liegt, um so schwieriger wird das am Ende auch.
Aber man könnte es tatsächlich mal versuchen ... nur darf man die Erwartungen an (schnelle) Fortschritte dann auch nicht zu hoch hängen, außer jemand schafft es tatsächlich, das alles weitgehend selbständig zu ermitteln und die Erkenntnisse mit anderen zu teilen.
Falls sich Boxen mit diesem Aufbau bei AVM mehren sollten (bisher sind es m.W. noch nicht soo viele und nach meinem Dafürhalten auch nicht unbedingt Geräte aus dem Mainstream), lohnt sich das sicherlich in jedem Falle, sich damit zu befassen.
BTW ... die "Liste" oben, was man an Infos bräuchte, ist auch nur ein Anfang und erhebt keinerlei Anspruch auf Vollständigkeit - einiges an weiterem "Forschungsbedarf" ergibt sich auch erst aus den ersten Infos, die man dann erhält.
Ohne eigenes Gerät ist es schwer das umzusetzen. Immerhin funktioniert Freetz überhaupt, finde ich überraschend :D Als Identifikation reicht SEPARATE_FILESYSTEM_IMAGE in Freetz, nur dann werden die Bootmanager installiert, aktuell für FIT nicht mehr. Falls das herkömmliche mounten der 2. Partition nicht funktioniert, probiert man einfach die noch nicht vorhandene fit-Methode... Ich schick dir mal jemanden vorbei. Wenn ein freetz der BM aktualisiert werden soll, sag bescheid
Wenn ein freetz der BM aktualisiert werden soll, sag bescheid
Ich warte im Moment noch auf positive Rückmeldungen für die Änderungen, damit das auch mit 07.39 funktioniert. Zwar habe ich das so umgesetzt, daß es auch mit früheren OS-Versionen genauso läuft (bei mir auf einer 7490 getestet), aber das sagt mir nur, daß das gewählte Prinzip so funktioniert und noch fehlt die Info, ob das dann auch schon alles war, was geändert werden mußte, damit es mit 07.39 und folgenden Versionen (erst mal) wieder klappt.
Liegt also nur zum Teil in meinen Händen ... außer ich habe irgendwann genug vom Warten und mache auch ohne Feedback ein Merge - eigentlich nicht so ganz meins, wenn ich das nicht doch schon selbst getestet habe.
Laut https://boxmatrix.info/wiki/FRITZ!Repeater_6000 gibt es um Urlader
firmware_info: 253.07.19,slot1=07.19-85142,slot0=07.19-85252
Ich weiß ... aber ich würde gerne die Zusammenhänge verstanden haben, bevor ich da irgendetwas baue.
Ich bin ja auch der Ansicht, daß ein bootslotctl get_fw_version
(sofern das funktioniert, wovon ich aber ausgehe) seine Informationen irgendwo her holen wird - vielleicht ist es genau diese Erweiterung der Angaben in firmware_info
, aber das wüßte ich eben gerne genau und das kriegt man halt nur heraus, wenn man die Daten mal ändert und dann schaut, ob sich die Ausgabe von bootslotctl
ebenfalls ändert.
Wie geschrieben ... ohne passendes Gerät und immer nur aus zweiter Hand ist das einigermaßen schwierig. Mein Problem ist nur, daß ich keinen DSL-Anschluß mehr nutze und da man für schnelle Erfolge beim Untersuchen einer Box am besten auch gleich noch die Serielle bestückt, kann man die auch nicht einfach nur erwerben, mal 2 Wochen untersuchen und dann wieder gebraucht verkaufen (jedenfalls nicht ohne gehörigen Verlust).
Abgesehen davon, sind das im Moment alles ohnehin Mondpreise, die ich schon aus Prinzip nicht zu zahlen bereit bin, nicht mal als Betriebsausgabe und dann müßte man das auch noch passend begründen, daß man mit dem Kauf eine Gewinnerzielungsabsicht hatte und es nicht nur "Hobby" ist, was bei OpenSource-Projekten schon schwierig ist.
cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 4 (v7l)
cpu MHz : 2208.000
BogoMIPS : 51.34
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 1
model name : ARMv7 Processor rev 4 (v7l)
cpu MHz : 2208.000
BogoMIPS : 51.34
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 2
model name : ARMv7 Processor rev 4 (v7l)
cpu MHz : 2208.000
BogoMIPS : 51.34
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 3
model name : ARMv7 Processor rev 4 (v7l)
cpu MHz : 2208.000
BogoMIPS : 51.34
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
Hardware : Generic DT based system
Revision : 0000
Serial : 0000000000000000
cat /proc/mtd
dev: size erasesize name
mtd0: 011fc000 00001000 "rootfs_ram"
mtd1: 01000000 00400000 "nand-tffs"
cat /proc/avm_partitions
cat: can't open '/proc/avm_partitions': No such file or directory
cat /proc/sys/urlader
cat /proc/sys/urlader/environment
DMC SL1
HardwareFeatures cpu=390.2.0,emmc=5.0.17.0.2
HWRevision 253
HWSubRevision 3
ProductID Fritz_Box_HW253
SerialNumber xxxxxxxxxxxxxxxxxxxxx
annex Ohne
autoload yes
bootloaderVersion 1.11317
country 049
crash [0]0,0,0[1]0,0,0[2]1dc7adad,62146a70,6[3]0,0,0
firstfreeaddress 0x50500000
firmware_info 253.07.29,slot1=07.29-93257,slot0=07.29-93257
firmware_version avm
flashsize nor_size=0MB sflash_size=0KB nand_size=0MB emmc_size=1888MB
language de
linux_fs_start 0
maca xx:xx:xx:xx:xx:xx
macb xx:xx:xx:xx:xx:xx
macwlan xx:xx:xx:xx:xx:xx
macwlan2 xx:xx:xx:xx:xx:xx
macwlan3 xx:xx:xx:xx:xx:xx
macdsl xx:xx:xx:xx:xx:xx
memsize 0x40000000
mtd0 0x0,0x0
mtd1 0x3000000,0x8000000
mtd2 0x0,0x2000000
mtd3 0x2000000,0x3000000
mtd4 0x8000000,0xD000000
mtd5 0xD000000,0x75BFC000
my_ipaddress 192.168.178.1
prompt Eva_AVM
ptest
usb_rndis_mac xx:xx:xx:xx:xx:xx
wlan_key xxxxxxxxxxxxxxxxxxxxx
wlan_ssid FRITZ!Repeater#6000
da sind 4 datein drin aber alle leer
Die Preise aktuell sind unmöglich, ich hätte gern noch einen Pi4, bin aber nicht bereit das doppelte wie vor 1 Jahr zu bezahlen. Für einen zb Repeater 6000 braucht man kein DSL ;-)
Und die Ausgabe von "bootslotctl get_fw_version"? Schau mal was dieses Programm noch so hergibt
Wie rufe ich denn genau ab
Schau mal was dieses Programm noch so hergibt
???
Habe ich doch schon ... schließlich gibt's oben u.a. ein strings
vom Binary. Ohne System, auf dem man das ausführen kann, ist das aber auch nicht wirklich aussagekräftig.
Einen Repeater brauche ich nicht ... in meine obere Etage führt ein GbE-fähiges UTP-Kabel und da gibt es einen weiteren AP bzw. Ethernet für Fernseher (RPi mit LibreElec) und alles das, was man sonst noch so braucht. Das ist also auch kein Argument gegenüber dem FA, einen Repeater als Betriebsausgabe geltend zu machen, auch wenn der heute noch bei unter 250 EUR liegt und sofort abgeschrieben werden kann. Bei den Boxen wird das dann schon schwerer ... ab 250 EUR netto sind bei manchen Modellen auch drin.
OK, daß in /proc/mtd
so wenig steht, ist wieder verständlich ... das ist offenbar alles eMMC und dann finden sich die Partitionen bei den Block-Devices bzw. mit einem blkid
, wobei das vielleicht bei den Partitionen für die FIT-Images das installierte FS nicht erkennen könnte (keine Ahnung, ob das zum Standard-Repertoire von blkid
gehört oder AVM das aufgebohrt hat). Aber irgendwo wird AVM die Partitionen schon "mit Namen" verwalten (das macht man dort ja praktisch immer so - die /proc/avm_partitions
bei dem Puma-Geräten wäre ein Beispiel dafür) ... man muß es jetzt nur irgendwo finden.
Sind bei einem cat /sys/class/mtd/*/name
auch nur zwei MTD-Partitionen zu sehen ~oder emuliert AVM da dann doch noch irgendwelche TFFS-Partitionen über ein MTDRAM-Device, wie bei den Puma7-Geräten (iirc jedenfalls)~? Unsinn, das emulierte nand-tffs
steht ja oben in der Ausgabe von /proc/mtd
schon ... wenn das also eine MTD-(NAND-)Partition sein soll, während das Gerät nur eMMC-Speicher bietet (das ist ja nur noch "cooked MTD" :grin:), dann muß das auch eine Emulation sein.
Wobei ich mich hier jetzt erst einmal ausklinke ... für so ein "Ping-Pong" fehlt mir im Moment mal wieder die Zeit (und auch etwas die Geduld, bitte nicht falsch verstehen) - ich muß mal wieder etwas "richtiges" machen.
Korrektur oben bzgl. der Emulation für's TFFS
Und wenn ich mich nicht schwer irre, sind 17 MB des vorhandenen Hauptspeichers schon mal dadurch belegt, daß hier das Wurzeldateisystem für das FRITZ!OS in den Hauptspeicher kopiert wurde (das dürften die etwas mehr als 17 MB in /proc/mtd0
sein) - da wäre dann auch mal die Ausgabe der Kommandos mount
und df -h
interessant, um sich die Verteilung der Dateien und ggf. auch weitere Mountpunkte (vielleicht sogar mit Overlays?) anzusehen.
/proc/avm_partitions ^^ habe ich nicht
cat /sys/class/mtd/*/name
rootfs_ram
nand-tffs
mount
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=438452k,nr_inodes=109613,mode=755)
proc on /proc type proc (rw,relatime)
tmpfs on /var type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
securityfs on /sys/kernel/security type securityfs (rw,relatime)
none on /sys/kernel/debug type debugfs (rw,relatime)
pstore on /sys/fs/pstore type pstore (rw,relatime)
df -h
/dev/root 18.0M 18.0M 0 100% /
devtmpfs 428.2M 0 428.2M 0% /dev
tmpfs 428.3M 1.0M 427.3M 0% /var
Danke.
Blieben noch blkid
und der Aufruf von bootslotctl
mit den Parametern, die vermutlich erst einmal unkritisch sind:
get_active
get_other
is_active
get_fw_version
Mancher Aufruf braucht vermutlich noch einen weiteren Parameter als Angabe des zu verwendenden "slot"s ... da muß man dann etwas probieren, wie das richtig sein könnte (0/1 oder 1/2 oder irgendetwas ganz anderes - das hängt auch etwas vom Ausgabeformat bei get_active
und get_other
ab).
Wenn man sich einigermaßen mit den Möglichkeiten zum "Recovern" auskennt (das meint mehr den Umgang mit EVA-FTP als das AVM-Programm) oder in beiden Partitionsets eine lauffähige Version installiert hat, könnte man auch noch bootslotctl activate_other
probieren. Sollte danach das System nicht direkt neu starten (das also nur die vermutete Umschaltung bewirken und kein Reboot), kann man auch noch einmal in /proc/sys/urlader/environment
nachsehen, ob linux_fs_start
dadurch umgeschaltet wurde (dazu muß man natürlich auch den vorherigen Wert kennen).
Auch wäre dann interessant, ob ein wiederholter Aufruf immer wieder zwischen 0
und 1
hin und her schaltet oder ob das eine Einbahnstraße vom laufenden zum alternativen System ist, weil die Info, wer nun "other" wäre, irgendwo anders hinterlegt ist (es sollte u.a. eine /var/bootedslot
geben, deren Inhalt dabei interessant wäre - wenn der Name auch Programm ist, ändert sich deren Inhalt bis zum nächsten Start ja nicht mehr).
Da man durch diese Verwendung von bootslotctl
keine Einzelheiten der Installation mehr sieht, wäre auch ein Dump einer der FIT-Partitionen hilfreich (dazu muß das blkid
aber erst mal Infos liefern, welches Block-Device das wäre) ... die Frage dabei ist, ob das Image dort 1:1 hineinkopiert wurde oder ob es irgendwelche Transformationen gab. Dazu kann man dann den eigenen Dump dieser Partition mit der Image-Datei aus einem Firmware-Update (oder auch dem Freetz-Image) vergleichen, ggf. ist der Dump der Partition dabei größer und der Rest nach der Länge des zu vergleichenden Images kann/muß ignoriert werden.
blkid
-sh: blkid: not found
bootslotctl get_active 0/1
0
bootslotctl get_active 1/2
0
bootslotctl get_other
1
bootslotctl is_active
nichts kommt da
bootslotctl get_fw_version
illegal argument
bootslotctl activate_other
nichts kommt da
cat /proc/sys/urlader/environment
linux_fs_start 1
linux_fs_status 1
reboot gemacht
bootslotctl activate_other
cat /proc/sys/urlader/environment
linux_fs_start 0
linux_fs_status 1
bootslotctl activate_other
cat /proc/sys/urlader/environment
linux_fs_start 0
linux_fs_status 1
also es bleibt so
cat /var/bootedslot
kommt nichts
OK, nochmal danke.
Ein paar Mißverständnisse gilt es auszuräumen ...
bootslotctl get_active 0/1
Das war so natürlich nicht gemeint ... und beim get_active
wird sicherlich auch kein Parameter benötigt, denn da gibt es ja nichts "auszuwählen" ... der aktive "slot" ist halt der aktive und der andere nicht.
Aber die Ausgabe mit der 0
dürfte ein sicheres Zeichen dafür sein, daß AVM diese "slots" mit 0
und 1
nummeriert und nicht - wie bei Puma7-Geräten beim pumaglued
bzw. avm_uimg_update
auch schon gesehen (https://www.ip-phone-forum.de/threads/update-auf-neue-version-fb6591.311669/page-2#post-2451203) - mit 1
und 2
.
Damit sollte aber auch die Frage beantwortet sein, was bei get_other
ausgegeben wird - halt auch die Nummer des "other slot".
Die könnte man zwar auch wieder "errechnen", aber wenn AVM mal mit drei (gleichrangigen) Systemen im Flash auflaufen sollte, funktioniert solche "Binärarithmetik" ggf. nicht länger, während ein get_other
immer noch die Nummer des nächsten zu benutzenden Slots ausgeben könnte. (BTW - ich übernehme jetzt das englische "slot" von AVM auch als deutschen "Slot", das ist einfacher als "Partition-Set").
Beim get_fw_version
wird dann sicherlich noch die Angabe der Slot-Nummer erwartet, also bootslotctl get_fw_version <0|1>
und auf STDOUT wird es dann vermutlich die Versionsnummer ausgeben. Beim bootslotctl is_active <0|1>
wird sicherlich nur der Exit-Code entsprechend gesetzt, also sollte man da noch ein ; echo $?
an den Aufruf anhängen und das mit beiden Nummern mal testen (unter Kenntnis, was da gerade im (Urlader-)Environment steht).
Beim activate_other
werde ich gerade nicht so richtig schlau aus dem Ablauf ... bitte mal die folgende Sequenz abarbeiten:
grep linux_fs /proc/sys/urlader/environment
bootslotctl get_active
bootslotctl activate_other
grep linux_fs /proc/sys/urlader/environment
bootslotctl get_active <=== hier geht es darum, ob nach der Umschaltung, die beim `activate_other` wohl erfolgt, sich auch ohne Reboot schon das Ergebnis von `get_active` ändert
bootslotctl activate_other
grep linux_fs /proc/sys/urlader/environment
bootslotctl get_active
... damit sollte einmal auf das alternative System umgeschaltet werden und einmal zurück - wenn dieses activate_other
nicht doch eine Einbahnstraße ist.
Bei der /var/bootedslot
wäre eine Anzeige mittels ls -l
notwendig - die Frage, die sich mir da stellt, ist die, ob die Datei gar nicht existiert oder doch leer ist (ohne Fehlermeldung sollte man "leer" annehmen), aber ggf. ist das auch ein Symlink irgendwohin o.ä.
Wenn das ein Repeater ist, dann erklärt das ein Fehlen von blkid
in der AVM-Firmware (wo es ansonsten für die NAS-Mounts auch benötigt würde) ... aber warum das dann in Freetz-NG nicht eingebaut wird (daß man es immer mal brauchen könnte, zeigt ja dann schon dieser Fall hier und die Größe des Applets (die auch nicht überwältigend ist), sollte hier ja nun auch keine entscheidende Rolle spielen), weiß ich auch nicht.
Zwar könnte man auch zu Fuß durch die Block-Devices ziehen, aber irgendetwas in der Richtung blkid
oder auch fdisk
ist deutlich einfacher. Wobei hier auch wieder blkid
vorzuziehen wäre, denn damit kann man nicht soviel Unsinn anrichten wie mit einem falsch bedienten fdisk
- daher würde ich verstehen, wenn es dieses Applet in Freetz-NG auch nicht gibt.
Als ersten Test könnte man noch ein ls -l /dev/mmc*
verwenden, um überhaupt erst einmal zu prüfen, daß der eMMC-Speicher tatsächlich als partitioniertes Block-Device genutzt wird. Dem Environment nach zu urteilen, gibt es (mind.) fünf Partitionen im Flash:
mtd0 0x0,0x0
mtd1 0x3000000,0x8000000
mtd2 0x0,0x2000000
mtd3 0x2000000,0x3000000
mtd4 0x8000000,0xD000000
mtd5 0xD000000,0x75BFC000
mtd0
kann man sicherlich ignorieren (von Adresse 0x0 bis 0x0 ist nicht wirklich viel Speicher zu erwarten), ansonsten sind da 32 MB als mtd2
, in denen vermutlich - wie bei AVM üblich - wieder der Bootloader EVA stehen wird. mtd1
und mtd4
sind jeweils 60 MB groß und nehmen vermutlich die FIT-Images auf (die Nummerierung ist die Sicht des Bootloaders, bitte nicht mit den Nummern im laufenden System verwechseln). Was sich hinter mtd3
in den dort vorhandenen 16 MB verbirgt, kann man (vorerst) nur raten - und offenbar liegen beim FR6000 dann die knapp 1,7 GB, die oben in mtd5
verwurstet wären, brach, denn bei dem wird auch kein UBI-Layer für diesen Teil verwendet (wie bei der 7530ax) und es fehlt praktisch alles beim udev
(inkl. /etc/hotplug
), da sonst noch so gebraucht würde.
Mir fällt im Moment auch nichts besseres als blkid
ein (von den Applets/Paketen, die m.W. in Freetz enthalten sind), was man zum näheren Erkunden der verwendeten Partitionierung im Flash benutzen könnte - lsblk
gibt es m.W. nicht und udisks
ebenfalls nicht.
Aber ich habe dann doch noch einmal genauer in die Firmware gesehen ... immerhin gibt es noch den udevadm
und mit dem sollte sich - in Kombination mit dem sysfs
- dann doch noch eine Liste erstellen lassen und zwar so:
for n in /sys/class/block/mmc*; do echo ">>> $n <<<"; udevadm info -q property -n ${n##*/}; done
Mal sehen, ob man da dann etwas mehr ablesen kann.
Und für die Frage, ob das FIT-Image 1:1 in die Partitionen kopiert wird, gibt es auch noch eine andere Lösung. Dazu muß man allerdings wissen, welche Datei fit-image
installiert ist und deren Länge ermitteln. Zusätzlich läßt man dann ein md5sum
über diese Datei laufen und merkt sich den Hash.
Danach kann man die beiden FIT-Partitionen dann mit einem dd if=<input_device> bs=256 count=$(( <fit-image-size> / 256 )) | md5sum
(in der Annahme, daß die Image-Datei "aligned" ist und eine durch 256 teilbare Größe hat) traktieren ... dabei sollte eine der beiden (bei den Parametern für das dd
aufpassen, sonst ist da auch mal schnell Unfug angerichtet) dann einen Hash-Wert liefern, der mit dem der Image-Datei übereinstimmt. Ist das nicht der Fall, kann man eine 1:1-Kopie ausschließen und muß sich näher damit befassen, was da wie von bootslotctl
in den eMMC-Speicher geschrieben wird.
Bei AVM ist blkid normal eine binary, und das Applet in Freetz nicht auswählbar weil es weniger Parameter kennt die die AVM Scripte benötigen: https://github.com/Freetz-NG/freetz-ng/blob/master/make/busybox/generate.sh#L176 Ausser man ersetzt auf altem FOS das mounting komplett mit FREETZMOUNT
Um es aktivierbar zu machen müsste man diese Zeile löschen: https://github.com/Freetz-NG/freetz-ng/blob/master/make/busybox/Config.in.busybox.1_35#L4341 bzw in der 1_34 Datei
Allerdings gibt es in NG mittlerweile einen Mechanismus dass BB-Applets automatisch umbenannt werden falls es die Datei schon gibt: https://github.com/Freetz-NG/freetz-ng/blob/master/fwmod#L1291 https://github.com/Freetz-NG/freetz-ng/blob/master/make/busybox/Config.in#L570
grep linux_fs /proc/sys/urlader/environment
linux_fs_start 1
linux_fs_status 1
bootslotctl get_active
1
bootslotctl activate_other
grep linux_fs /proc/sys/urlader/environment
linux_fs_start 0
linux_fs_status 1
bootslotctl get_active
0
bootslotctl activate_other
grep linux_fs /proc/sys/urlader/environment
linux_fs_start 0
linux_fs_status 1
bootslotctl get_active
0
ls -l /var/bootedslot
-rw-r--r-- 1 root root 1 Jan 1 1970 /var/bootedslot
ls -l /dev/mmc*
brw------- 1 root root 179, 0 Jan 1 1970 /dev/mmcblk0
brw------- 1 root root 179, 1 Jan 1 1970 /dev/mmcblk0p1
brw------- 1 root root 179, 10 Jan 1 1970 /dev/mmcblk0p10
brw------- 1 root root 179, 11 Jan 1 1970 /dev/mmcblk0p11
brw------- 1 root root 179, 12 Jan 1 1970 /dev/mmcblk0p12
brw------- 1 root root 179, 13 Jan 1 1970 /dev/mmcblk0p13
brw------- 1 root root 179, 14 Jan 1 1970 /dev/mmcblk0p14
brw------- 1 root root 179, 15 Jan 1 1970 /dev/mmcblk0p15
brw------- 1 root root 179, 16 Jan 1 1970 /dev/mmcblk0p16
brw------- 1 root root 179, 17 Jan 1 1970 /dev/mmcblk0p17
brw------- 1 root root 179, 18 Jan 1 1970 /dev/mmcblk0p18
brw------- 1 root root 179, 19 Jan 1 1970 /dev/mmcblk0p19
brw------- 1 root root 179, 2 Jan 1 1970 /dev/mmcblk0p2
brw------- 1 root root 179, 20 Jan 1 1970 /dev/mmcblk0p20
brw------- 1 root root 179, 3 Jan 1 1970 /dev/mmcblk0p3
brw------- 1 root root 179, 4 Jan 1 1970 /dev/mmcblk0p4
brw------- 1 root root 179, 5 Jan 1 1970 /dev/mmcblk0p5
brw------- 1 root root 179, 6 Jan 1 1970 /dev/mmcblk0p6
brw------- 1 root root 179, 7 Jan 1 1970 /dev/mmcblk0p7
brw------- 1 root root 179, 8 Jan 1 1970 /dev/mmcblk0p8
brw------- 1 root root 179, 9 Jan 1 1970 /dev/mmcblk0p9
brw------- 1 root root 179, 32 Jan 1 1970 /dev/mmcblk0rpmb
for n in /sys/class/block/mmc; do echo ">>> $n <<<"; udevadm info -q property -n ${n##/}; done
>>> /sys/class/block/mmcblk0 <<<
DEVNAME=/dev/mmcblk0
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0
DEVTYPE=disk
MAJOR=179
MINOR=0
NPARTS=20
SUBSYSTEM=block
>>> /sys/class/block/mmcblk0p1 <<<
DEVLINKS=/dev/disk/by-partlabel/alignto512
DEVNAME=/dev/mmcblk0p1
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p1
DEVTYPE=partition
MAJOR=179
MINOR=1
PARTN=1
PARTNAME=alignto512
SUBSYSTEM=block
USEC_INITIALIZED=5066369
>>> /sys/class/block/mmcblk0p10 <<<
DEVLINKS=/dev/disk/by-partlabel/0:RPM_1
DEVNAME=/dev/mmcblk0p10
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p10
DEVTYPE=partition
MAJOR=179
MINOR=10
PARTN=10
PARTNAME=0:RPM_1
SUBSYSTEM=block
USEC_INITIALIZED=5065152
>>> /sys/class/block/mmcblk0p11 <<<
DEVLINKS=/dev/disk/by-partlabel/0:CDT
DEVNAME=/dev/mmcblk0p11
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p11
DEVTYPE=partition
MAJOR=179
MINOR=11
PARTN=11
PARTNAME=0:CDT
SUBSYSTEM=block
USEC_INITIALIZED=5065361
>>> /sys/class/block/mmcblk0p12 <<<
DEVLINKS=/dev/disk/by-partlabel/0:CDT_1
DEVNAME=/dev/mmcblk0p12
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p12
DEVTYPE=partition
MAJOR=179
MINOR=12
PARTN=12
PARTNAME=0:CDT_1
SUBSYSTEM=block
USEC_INITIALIZED=5063198
>>> /sys/class/block/mmcblk0p13 <<<
DEVLINKS=/dev/disk/by-partlabel/0:APPSBL
DEVNAME=/dev/mmcblk0p13
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p13
DEVTYPE=partition
MAJOR=179
MINOR=13
PARTN=13
PARTNAME=0:APPSBL
SUBSYSTEM=block
USEC_INITIALIZED=5062040
>>> /sys/class/block/mmcblk0p14 <<<
DEVLINKS=/dev/disk/by-partlabel/0:APPSBL_1
DEVNAME=/dev/mmcblk0p14
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p14
DEVTYPE=partition
MAJOR=179
MINOR=14
PARTN=14
PARTNAME=0:APPSBL_1
SUBSYSTEM=block
USEC_INITIALIZED=5062039
>>> /sys/class/block/mmcblk0p15 <<<
DEVLINKS=/dev/disk/by-partlabel/0:CONFIG
DEVNAME=/dev/mmcblk0p15
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p15
DEVTYPE=partition
MAJOR=179
MINOR=15
PARTN=15
PARTNAME=0:CONFIG
SUBSYSTEM=block
USEC_INITIALIZED=5062593
>>> /sys/class/block/mmcblk0p16 <<<
DEVLINKS=/dev/disk/by-partlabel/0:CONFIG_1
DEVNAME=/dev/mmcblk0p16
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p16
DEVTYPE=partition
MAJOR=179
MINOR=16
PARTN=16
PARTNAME=0:CONFIG_1
SUBSYSTEM=block
USEC_INITIALIZED=5062099
>>> /sys/class/block/mmcblk0p17 <<<
DEVLINKS=/dev/disk/by-partlabel/fit0
DEVNAME=/dev/mmcblk0p17
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p17
DEVTYPE=partition
MAJOR=179
MINOR=17
PARTN=17
PARTNAME=fit0
SUBSYSTEM=block
USEC_INITIALIZED=5062599
>>> /sys/class/block/mmcblk0p18 <<<
DEVLINKS=/dev/disk/by-partlabel/tffs
DEVNAME=/dev/mmcblk0p18
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p18
DEVTYPE=partition
MAJOR=179
MINOR=18
PARTN=18
PARTNAME=tffs
SUBSYSTEM=block
USEC_INITIALIZED=5062589
>>> /sys/class/block/mmcblk0p19 <<<
DEVLINKS=/dev/disk/by-partlabel/fit1
DEVNAME=/dev/mmcblk0p19
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p19
DEVTYPE=partition
MAJOR=179
MINOR=19
PARTN=19
PARTNAME=fit1
SUBSYSTEM=block
USEC_INITIALIZED=5067733
>>> /sys/class/block/mmcblk0p2 <<<
DEVLINKS=/dev/disk/by-partlabel/0:SBL1
DEVNAME=/dev/mmcblk0p2
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p2
DEVTYPE=partition
MAJOR=179
MINOR=2
PARTN=2
PARTNAME=0:SBL1
SUBSYSTEM=block
USEC_INITIALIZED=5069494
>>> /sys/class/block/mmcblk0p20 <<<
DEVLINKS=/dev/disk/by-partlabel/data
DEVNAME=/dev/mmcblk0p20
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p20
DEVTYPE=partition
MAJOR=179
MINOR=20
PARTN=20
PARTNAME=data
SUBSYSTEM=block
USEC_INITIALIZED=5066961
>>> /sys/class/block/mmcblk0p3 <<<
DEVLINKS=/dev/disk/by-partlabel/0:BOOTCONFIG
DEVNAME=/dev/mmcblk0p3
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p3
DEVTYPE=partition
MAJOR=179
MINOR=3
PARTN=3
PARTNAME=0:BOOTCONFIG
SUBSYSTEM=block
USEC_INITIALIZED=5069028
>>> /sys/class/block/mmcblk0p4 <<<
DEVLINKS=/dev/disk/by-partlabel/0:BOOTCONFIG1
DEVNAME=/dev/mmcblk0p4
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p4
DEVTYPE=partition
MAJOR=179
MINOR=4
PARTN=4
PARTNAME=0:BOOTCONFIG1
SUBSYSTEM=block
USEC_INITIALIZED=5063488
>>> /sys/class/block/mmcblk0p5 <<<
DEVLINKS=/dev/disk/by-partlabel/0:QSEE
DEVNAME=/dev/mmcblk0p5
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p5
DEVTYPE=partition
MAJOR=179
MINOR=5
PARTN=5
PARTNAME=0:QSEE
SUBSYSTEM=block
USEC_INITIALIZED=5063535
>>> /sys/class/block/mmcblk0p6 <<<
DEVLINKS=/dev/disk/by-partlabel/0:QSEE_1
DEVNAME=/dev/mmcblk0p6
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p6
DEVTYPE=partition
MAJOR=179
MINOR=6
PARTN=6
PARTNAME=0:QSEE_1
SUBSYSTEM=block
USEC_INITIALIZED=5063593
>>> /sys/class/block/mmcblk0p7 <<<
DEVLINKS=/dev/disk/by-partlabel/0:DEVCFG
DEVNAME=/dev/mmcblk0p7
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p7
DEVTYPE=partition
MAJOR=179
MINOR=7
PARTN=7
PARTNAME=0:DEVCFG
SUBSYSTEM=block
USEC_INITIALIZED=5063922
>>> /sys/class/block/mmcblk0p8 <<<
DEVLINKS=/dev/disk/by-partlabel/0:DEVCFG_1
DEVNAME=/dev/mmcblk0p8
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p8
DEVTYPE=partition
MAJOR=179
MINOR=8
PARTN=8
PARTNAME=0:DEVCFG_1
SUBSYSTEM=block
USEC_INITIALIZED=5063926
>>> /sys/class/block/mmcblk0p9 <<<
DEVLINKS=/dev/disk/by-partlabel/0:RPM
DEVNAME=/dev/mmcblk0p9
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p9
DEVTYPE=partition
MAJOR=179
MINOR=9
PARTN=9
PARTNAME=0:RPM
SUBSYSTEM=block
USEC_INITIALIZED=5063949
>>> /sys/class/block/mmcblk0rpmb <<<
DEVNAME=/dev/mmcblk0rpmb
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0rpmb
DEVTYPE=disk
MAJOR=179
MINOR=32
NPARTS=0
SUBSYSTEM=block
OK, dann fasse ich mal zusammen, was sich an Erkenntnissen für den FR6000 hier ergeben hat.
eMMC-Speicher mit 2 GB Gesamtkapazität unter /dev/mmcblk0
, partioniert folgendermaßen:
part.no. | device | name | start | size |
---|---|---|---|---|
1 | /dev/mmcblk0p1 | alignto512 | ? | ? |
2 | /dev/mmcblk0p2 | 0:SBL1 | ? | ? |
3 | /dev/mmcblk0p3 | 0:BOOTCONFIG | ? | ? |
4 | /dev/mmcblk0p4 | 0:BOOTCONFIG1 | ? | ? |
5 | /dev/mmcblk0p5 | 0:QSEE | ? | ? |
6 | /dev/mmcblk0p6 | 0:QSEE_1 | ? | ? |
7 | /dev/mmcblk0p7 | 0:DEVCFG | ? | ? |
8 | /dev/mmcblk0p8 | 0:DEVCFG_1 | ? | ? |
9 | /dev/mmcblk0p9 | 0:RPM | ? | ? |
10 | /dev/mmcblk0p10 | 0:RPM_1 | ? | ? |
11 | /dev/mmcblk0p11 | 0:CDT | ? | ? |
12 | /dev/mmcblk0p12 | 0:CDT_1 | ? | ? |
13 | /dev/mmcblk0p13 | 0:APPSBL | ? | ? |
14 | /dev/mmcblk0p14 | 0:APPSBL_1 | ? | ? |
15 | /dev/mmcblk0p15 | 0:CONFIG | ? | ? |
16 | /dev/mmcblk0p16 | 0:CONFIG_1 | ? | ? |
17 | /dev/mmcblk0p17 | fit0 | ? | ? |
18 | /dev/mmcblk0p18 | tffs | ? | ? |
19 | /dev/mmcblk0p19 | fit1 | ? | ? |
20 | /dev/mmcblk0p20 | data | ? | ? |
Was diese ganzen Partitionen jetzt beinhalten und wie groß sie jeweils sind, muß weiter geprüft werden.
Für die Größen wäre folgendes Kommando notwendig:
for n in /sys/block/mmcblk0/mmcblk0p*; do echo ">>> $n <<<"; cat $n/start; cat $n/size; done
Aber bei den Partitionen 17 und 19 kann man wohl zu Recht davon ausgehen, daß das diejenigen sind, wo die FIT-Images hineinkopiert werden. Nur die Frage, wie genau das geschieht, ist weiterhin offen. Der nächste Schritt wäre also, mit diesen beiden Partitionen mal den oben schon erwähnten Test des Inhalt durch md5sum
zu machen (installiertes fit-image
ansehen und Größe + MD5-Hash ermitteln, danach in der passenden Länge die Daten aus den beiden Partitionen kopieren und gleich über eine Pipe nach md5sum
verwursten).
Das Umschalten des aktiven Systems ist - zumindest wenn man ausschließlich bootslotctl
verwendet - dann offenbar doch eine Einbahnstraße, wie die Ergebnisse oben gezeigt haben. Nun wäre es halt noch interessant zu wissen, was beim bootslotctl get_fw_version <0|1>
heraus kommt - dann kann man zumindest einschätzen, ob man diese Daten dazu verwenden kann, in der Anzeige eine Unterscheidung zwischen den installierten Systemen zu machen.
Ich würde zwar immer noch versuchen wollen, den Inhalt der SquashFS-Images für das aktuell laufende (das findet man ja unter /
gemountet vor) und das "andere" System (das findet man dann in dessen FIT-Image) zu analysieren (weil nur dann die "Quelle" von Modifikationen und die alternativen Formen für das Ändern des Brandings erkannt werden können und das baue ich ja gerade für die bisher unterstützten Modelle ein), aber als "erster Schritt" wäre es ja schon mal hilfreich, wenn man irgendeine Versionsnummer auch ohne Zerlegen des FIT-Images auslesen könnte.
for n in /sys/block/mmcblk0/mmcblk0p*; do echo ">>> $n <<<"; cat $n/start; cat $n/size; done
>>> /sys/block/mmcblk0/mmcblk0p1 <<<
34
990
>>> /sys/block/mmcblk0/mmcblk0p10 <<<
20992
512
>>> /sys/block/mmcblk0/mmcblk0p11 <<<
21504
512
>>> /sys/block/mmcblk0/mmcblk0p12 <<<
22016
512
>>> /sys/block/mmcblk0/mmcblk0p13 <<<
22528
1024
>>> /sys/block/mmcblk0/mmcblk0p14 <<<
23552
1024
>>> /sys/block/mmcblk0/mmcblk0p15 <<<
24576
1024
>>> /sys/block/mmcblk0/mmcblk0p16 <<<
25600
1024
>>> /sys/block/mmcblk0/mmcblk0p17 <<<
98304
163840
>>> /sys/block/mmcblk0/mmcblk0p18 <<<
65536
32768
>>> /sys/block/mmcblk0/mmcblk0p19 <<<
262144
163840
>>> /sys/block/mmcblk0/mmcblk0p2 <<<
1024
1024
>>> /sys/block/mmcblk0/mmcblk0p20 <<<
425984
3432416
>>> /sys/block/mmcblk0/mmcblk0p3 <<<
2048
512
>>> /sys/block/mmcblk0/mmcblk0p4 <<<
2560
512
>>> /sys/block/mmcblk0/mmcblk0p5 <<<
3072
8192
>>> /sys/block/mmcblk0/mmcblk0p6 <<<
11264
8192
>>> /sys/block/mmcblk0/mmcblk0p7 <<<
19456
512
>>> /sys/block/mmcblk0/mmcblk0p8 <<<
19968
512
>>> /sys/block/mmcblk0/mmcblk0p9 <<<
20480
512
Wie schaut dann genau der Befehl aus für 17 und 19 ( dd if=
bootslotctl get_fw_version 1
07.29-93257
get_fw_version 0
07.29-93257
07.29-93257
Ich hoffe mal, das liegt daran, daß da in beiden Slots dieselbe Version installiert ist.
Für den genauen Aufruf zum Testen der FIT-Partitionen müßte ich erst einmal wissen, WELCHES Image da installiert wurde:
ls -l fit-image
md5sum fit-image
Wo genau die Datei fit-image
jetzt bei Dir liegt, kann ich nicht sagen. Wenn Du das System über ein (Freetz-NG-)TAR-Image installiert hast (das ginge ja erst ab dem zweiten Update, wenn das erste den passenden Key bereitgestellt hat), dann kannst Du diese Datei beim Entpacken des TAR-Images finden. Wenn Du das System über EVA installiert hast, ist es ja genau diese Datei, die dabei ins RAM geschrieben wurde - das ist praktisch wie beim Recovery-Programm für den FR6000.
Die Tabelle mit den Partitionen mache ich später neu und füge dabei die Angaben zu start
und size
hinzu. Die Werte stellen jeweils die Nummer des ersten (bei start
) bzw. die Anzahl der zugeordneten Blöcke (bei size
) dar, wobei ein Block 512 Byte umfaßt. Die Partitionen fit0
und fit1
wären dann jeweils 163.840 * 512 = 83.886.080 Byte
groß oder auch 163.840 / 2 = 81.920 KByte
bzw. exakt 80 MByte (jeweils mit 1024 als Faktor).
So groß sind aber auch die bisher aufgetauchten FIT-Images nicht und daher muß man auch die Überprüfung des Inhalts der Partitionen auf die Größe der darin gespeicherten Daten begrenzen.
Ja es wurde schon 2 oder 3-mal das Image neu geflasht, weil ja noch Fehler drin waren in freetz-ng die behoben worden und ich es testen sollte. Daher immer Version 07.29-93257
Das erste Mal habe ich es über push geflasht und jetzt kann ich nur noch über die AVM Webseite falshen. Da es über das freetz nicht ging. Daher ist das zurzeit auch deaktiviert
ls -l fit-image ls: fit-image: No such file or directory
Edit ls -l /dev/mmcblk0p19 brw------- 1 root root 179, 19 Jan 1 1970 /dev/mmcblk0p19 md5sum /dev/mmcblk0p19 03ff39fcd11c2e3d7d34f497749c5695 /dev/mmcblk0p19
ls -l /dev/mmcblk0p17 brw------- 1 root root 179, 17 Jan 1 1970 /dev/mmcblk0p17 md5sum /dev/mmcblk0p17 b99a762496766b2722994672ed7cdf41 /dev/mmcblk0p17
Aktiv ist zur Zeit linux_fs_start 1 also /dev/mmcblk0p19 sehe ich das richtig
Daher wollte ich mir noch eine weitere Box kaufen zB die 7530AX
jetzt kann ich nur noch über die AVM Webseite falshen.
Ich hoffe mal, daß hier anstelle von "nur noch" eigentlich "auch" gemeint ist - oder spricht irgendetwas dagegen, weiterhin Firmware über den Bootloader zu installieren? Der Mechanismus, das Image in den RAM zu laden und mit einer passenden "kernel command line" (wo hier ja sogar die "Anweisung" zu Installation eingeschlossen wird mit dem avm_fwupdate
, was enthalten sein muß) dessen Installation anzustoßen, sollte ja als Alternative auch weiterhin funktionieren.
Damit findest Du aber die gesuchte Datei fit-image
auf jeden Fall in der Verzeichnisstruktur Deines Freetz-NG-Builds ... irgendwo unterhalb von <freetz_ng_dir>/build/modified
sollte die fertige Image-Datei liegen (und liegen bleiben, wenn das make
fertig ist), denn von dort sollte sie in das TAR-File für die Image-Datei (auch wenn da vieles "image" heißt, ist der Inhalt doch jedesmal ein anderer) kopiert werden.
Die Prüfung, ob dieses Image dann 1:1 in die Partition (fit0
oder fit1
, Du müßtest beide testen, solange Du nicht genau weißt, wo die Image-Datei vom LETZTEN Freetz-NG-Build installiert wurde) kopiert wurde, braucht die genaue Größe dieser Datei fit-image
, weil dann auch nur in genau dieser Länge der Inhalt der Partition herauskopiert und ebenfalls an das md5sum
weitergegeben werden kann. Stimmen die Daten (in der angegebenen Länge in der Partition) überein, sollte die Ausgabe von md5sum
denselben Wert ergeben.
dd if=/dev/mmcblk0p17 bs=256 count=$(( <hier die Größe von fit-image eintragen> / 256 )) 2>/dev/null | md5sum
Die Zeile dann noch einmal für fit1
(das wäre dann mmcblk0p19
anstelle von mmcblk0p17
) ausführen und die Ergebnisse aller Kommandos (beginnend mit denen für fit-image
irgendwo unterhalb von Freetz-NG) dann bitte hier einstellen. Damit sollten langsam aber sicher die Angaben beisammen sein, um zumindest eine Umschaltung schon mal zu implementieren, auch wenn die Bedeutung und Verwendung vieler anderer Partitionen (im Bootprozess dieser Geräte) noch unklar ist.
So ich habe ein neues Image gebaut mit Freetz-NG habe dann das fit-image was unter build/modified/firmware/var/tmp dann liegt. md5sum fit-image
0e5098920d4dccb852c0c8d5c6e0e745 fit-image
Habe nun per push_firmware das Image geflasht und da wird mir ja gesagt das der nächste sttart dann auf linux_fs_start 1 ist. Damit weiß ich ja jetzt das ich mmcblk0p19 benutzen muss. Zur Sicherheit hab ich noch mal grep linux_fs /proc/sys/urlader/environment gemacht und es kommt linux_fs_start 1
dd if=/dev/mmcblk0p19 bs=256 count=$(( 22282240 / 256 )) 2>/dev/null | md5sum
8e958a84b94be4c8037fa87dda2f730f
Was aber dann die falsche md5sum Nummer ist.
dd if=/dev/mmcblk0p17 bs=256 count=$(( 22282240 / 256 )) 2>/dev/null | md5sum
0e5098920d4dccb852c0c8d5c6e0e745
Was ja jetzt die gleiche md5sum Nummer ist. Damit wird es dann doch 1zu1 kopiert. Verstehe ich das jetzt richtig.
Was mich aber wundert, wie kommt es, dass ich mmcblk0p17 benutzen muss
fit-image.zip hat eine neue md5sum 5a983bbbe85db87b2bdac340e7cb841d fit-image da ich das total überlesen habe das die haben willst. Und ich noch mal ein Image gebaut hatte. Soll ich die auch noch mal Flashen zur Sicherheit
Was mich aber wundert, wie kommt es, dass ich mmcblk0p17 benutzen muss
Das finde ich jetzt nicht so überraschend, das gehört auch zu dem Teil, den ich verstehen wollte, bevor ich etwas implementiere.
Auf den Boxen ohne bootslotctl
wird bei einem Update über AVM-GUI der "andere" Slot verwendet, während bei der Installation über den Bootloader/aus dem Hauptspeicher (das läuft auf dasselbe hinaus, denn über EVA wird das Image ja auch nur ins RAM geladen) der Inhalt von linux_fs_start
gar nicht interessiert (zumindest an diesem Punkt nicht mehr, weil das alles schon im Kernel bei der Initialisierung ausgewertet wurde und auf der Basis von linux_fs_start
die MTD-Namen entsprechend gesetzt sind) und immer nach kernel
und filesystem
(also ins aktive System) installiert wird.
Im Gegensatz dazu sieht das bei diesen Modellen hier so aus:
#! /bin/sh
set -e
. /etc/boot.d/msg
bootslotctl on_boot
if grep -q "\( \|^\)avm_fwupdate\( \|\$\)" /proc/cmdline
then
echo "found update request"
if update_mtd=$(grep \"fit-image\" /proc/mtd)
then
update_mtd="/dev/$(echo "$update_mtd" | sed "s/:.*//")"
echo "Updating $update_mtd -> other slot"
. /etc/boot.d/major_nr
modprobe led_module || true
mknod -m 666 /dev/led c "$(major_nr led)" 0 || true
trap /bin/update_led_off EXIT
/bin/update_led_on || true
bootslotctl program_other $update_mtd "${CONFIG_VERSION}-$(/etc/version --project)"
bootslotctl commit_other
_programmed=1
fi
fi
Die Installation erfolgt hier also IMMER in das "andere" System (program_other
) und ich würde zunächst mal vermuten (ich schaue jetzt aber nicht nach), daß sich @fda77 bisher damit nicht befaßt hat (irgendetwas in der Richtung hatte ich iirc hier auch gelesen) und daher auch die "Aussage" von push_firmware
für diese Modelle so nicht paßt. Das MTD als "Quelle" der Installation (das hat ja dann offenbar den MTD-Namen fit-image
) dürfte wieder der Kernel anhand der "command line" einrichten, darum braucht sich das bootslotctl
nicht mehr zu kümmern.
Auch beim Update über das GUI (egal ob mit AVM- oder eigener Signatur) erfolgt in der /var/install
die Installation dann mit program_other
- hier erfolgt dann die Angabe des FIT-Images als Datei und nicht als (character-)MTD:
/sbin/bootslotctl program_other /var/tmp/fit-image "${ver}-$(grep ^Build /var/content | cut -f2 -d=)" || exit 6
/sbin/bootslotctl "$_activate_action" || exit 6
was zwar am Ende zu demselben Ergebnis führt, wie bei anderen Modellen, aber der Weg dorthin unterscheidet sich schon deutlich.
Was mir hier auch zum ersten Mal aufgefallen ist, ist ein Unterschied beim Aufruf von /var/install
beim "Downgrade" ... mit der Option -d
bleiben die vorhandenen Einstellungen erhalten, während bei der Option -f
die Box auf Werkseinstellungen zurückgesetzt wird. Auch die Option -t
für /var/install
gibt es bei anderen Plattformen nicht, wobei hier offenbar nur eine Umschaltung von linux_fs_start
erfolgt, weil anstelle von commit_other
dann nur ein activate_other
verwendet wird.
Diese Abfolge program_other
-> commit_other
halte ich für eine transaktionssichere Installation des FIT-Images - vielleicht werden aber auch nur weitere Aktionen wie das Berechnen von Hash-Werten dadurch angestoßen und damit dann die Installation "abgeschlossen". Komisch ist jedenfalls, daß auch bei -t
vor dem activate_other
noch ein Aufruf von program_other
erfolgt - wenn das schon ein Programmieren der Flash-Partition auslösen sollte, aber dann wegen des fehlenden commit_other
die Änderungen nicht abgeschlossen werden, wäre das ja eine unnötige Belastung des Flash-Speichers (und würde obendrein die Integrität der anderen Angaben (slotX=...
in firmware_version
) durcheinander würfeln).
Daher tendiere ich eher dazu, daß sich das bootslotctl
beim program_other
die Angaben nur merkt (und ggf. eine Kopie des Images irgendwo ablegt) und sie auf Plausibilität/Gültigkeit prüft und erst beim commit_other
dann tatsächlich in die Partition (und die anderen Stellen) geschrieben wird. Dann wäre das program_other
nur die Vorbereitung des Flashens und Prüfung der Angaben und ohne commit_other
ist das nur heiße Luft.
Das hat dann natürlich auch noch Auswirkungen darauf, wie man aus dem laufenden System "von Hand" die Image-Dateien ersetzen kann - ich würde hier (solange man nicht wirklich untersucht und verstanden hat, was das bootslotctl
ggf. noch alles an zusätzlichen Schritten unternimmt, wenn es ein commit_other
ausführen soll) auf das Kopieren der Datei fit-image
von Hand in eine der Partitionen erst einmal verzichten - schließlich kann man ja das AVM-Programm auch gut "nachnutzen" (solange das im Rahmen eines AVM-Images erfolgt, denn ein Herauskopieren und die Verwendung an anderer Stelle, ist sicherlich wieder nicht von der AVM-Lizenz gedeckt).
Aber damit steht dann ja jetzt im Ergebnis auch fest, daß tatsächlich nur das Image 1:1 in die Partition kopiert wird ... das hilft schon mal weiter.
Ich würde mal versuchen (aber erst, wenn ich mit bootmanager 0.8.2
fertig bin), zunächst eine Version zusammen zu klöppeln, bei der zumindest die Anzeige der AVM-Version und die Umschaltung funktioniert, wobei das Ermitteln von Modifikationsdatum und -quelle erst mal unter den Tisch fällt - zumindest für das inaktive System, denn dafür muß man dann ins SquashFS-Image für dieses System schauen und dazu das FIT-Image erst einmal zerlegen. Dasselbe gilt für die Erkennung aller Infos hinsichtlich des Brandings, daher wird das zunächst auch nichts werden.
Wenn ich die vorläufige Version fertig habe, melde ich mich hier wieder ... der erste Test bräuchte ohnehin nur das Kopieren der Skript-Datei und den Aufruf aus einer Shell heraus - dafür muß man nicht jedesmal ein neues Image bauen.
Hier noch der Vollständigkeit halber die Partitionierung des eMMC-Speichers:
part.no. | device | name | start (block) | size (blocks) | size (kB) |
---|---|---|---|---|---|
1 | /dev/mmcblk0p1 | alignto512 | 34 | 990 | 495 |
2 | /dev/mmcblk0p2 | 0:SBL1 | 1024 | 1024 | 512 |
3 | /dev/mmcblk0p3 | 0:BOOTCONFIG | 2048 | 512 | 256 |
4 | /dev/mmcblk0p4 | 0:BOOTCONFIG1 | 2560 | 512 | 256 |
5 | /dev/mmcblk0p5 | 0:QSEE | 3072 | 8192 | 4.096 |
6 | /dev/mmcblk0p6 | 0:QSEE_1 | 11264 | 8192 | 4.096 |
7 | /dev/mmcblk0p7 | 0:DEVCFG | 19456 | 512 | 256 |
8 | /dev/mmcblk0p8 | 0:DEVCFG_1 | 19968 | 512 | 256 |
9 | /dev/mmcblk0p9 | 0:RPM | 20480 | 512 | 256 |
10 | /dev/mmcblk0p10 | 0:RPM_1 | 20992 | 512 | 256 |
11 | /dev/mmcblk0p11 | 0:CDT | 21504 | 512 | 256 |
12 | /dev/mmcblk0p12 | 0:CDT_1 | 22016 | 512 | 256 |
13 | /dev/mmcblk0p13 | 0:APPSBL | 22528 | 1024 | 512 |
14 | /dev/mmcblk0p14 | 0:APPSBL_1 | 23552 | 1024 | 512 |
15 | /dev/mmcblk0p15 | 0:CONFIG | 24576 | 1024 | 512 |
16 | /dev/mmcblk0p16 | 0:CONFIG_1 | 25600 | 1024 | 512 |
17 | /dev/mmcblk0p17 | fit0 | 98304 | 163840 | 81.920 |
18 | /dev/mmcblk0p18 | tffs | 65536 | 32768 | 16.384 |
19 | /dev/mmcblk0p19 | fit1 | 262144 | 163840 | 81.920 |
20 | /dev/mmcblk0p20 | data | 425984 | 3432416 | 1.716.208 |
Einigermaßen "straight forward" und mit einer Lücke von 26624 bis (inkl.) 65535 vor dem von AVM festgelegten Teil, nur bei den FIT-Partitionen und der Partition für die Speicherung der TFFS-Daten geht die Nummerierung etwas durcheinander, denn die TFFS-Partition liegt ja offenbar VOR der Partition fit0
.
Nur die Frage, welche dieser Partitionen jetzt den Bootloader von AVM enthält, ist irgendwie noch offen. Dem Namen nach kämen da für mich die Partitionen 2, 13 oder 14 in Frage - das SBL
wird vermutlich wieder ein "secondary boot loader" sein. Und da gäbe es ja mehrere Optionen ... entweder SBL1
ist direkt eine einzige Kopie von EVA oder die steht doch in APPSBL
oder APPSBL_1
- da wäre dann die nächste Frage, ob tatsächlich zwei Kopien vorliegen und diese 1:1 übereinstimmen. Bei zwei Kopien könnte man ja auch wieder (sichere) Updates des EVA-Codes machen - wobei m.W. bisher noch keines dieser Modelle irgendein urlader_update
in den AVM-Images hatte (zumindest die 7530ax nicht).
Wenn Du noch weitermachen willst, könntest Du noch ein grep wlan_key /dev/mmcblk0pX
für die Partitionen 2, 13 und 14 machen - da, wo ein Treffer auftritt (das könnten auch mehrere sein), ist mit einiger Wahrscheinlichkeit auch EVA zu finden. Sollten es die beiden Partitionen 13 und 14 sein, kann man die noch einmal mittels cmp -l /dev/mmcblk0p13 /dev/mmcblk0p14
vergleichen, ob es Unterschiede gibt und welche das dann sind bzw. wie umfangreich sie wären.
Auch würde ich Dir durchaus eine Kopie des Bootloaders (einfach mit cat /dev/mmcblk0pX > <output_file>
) abnehmen, die aber bitte NICHT hier veröffentlichen (das ist (C) AVM), sondern mir ggf. per E-Mail (Adresse steht im GPG-Key in diesem Repository) schicken. Mich interessiert in erster Linie, ob da auch ein "klassischer" Konfigurationsbereich mit den "Geburtsdaten" der Box existiert und wenn ja, wie man ihn findet und welches Format er genau hat.
Ich gehe zwar ohnehin davon aus, daß auch hier der Wert für firmware_version
im nicht-änderbaren Teil der TFFS-Einstellungen abgelegt ist (bzw. genauer in dem, der bei jedem Booten neu aus den hinterlegten Werten erzeugt wird) und damit das Ändern des Brandings auf "klassischem" Weg auch nicht funktionieren wird, aber wenn er sich lokalisieren und prüfen ließe, dann wäre das (für die spätere Implementierung, die auch die Behandlung von Brandings ermöglichen soll) weiterhin eine einheitliche Behandlung aller Modelle und man muß keine Sonderbehandlung auch noch an dieser Stelle einbauen ... der Rest ist schon "absonderlich" genug und verlangt schon eine andere Behandlung als bei anderen Plattformen.
Wenn ich aus dem Bauch heraus raten sollte, würde ich aber auf EINE Kopie in SBL1
tippen - es gibt zwar bei Modellen mit NAND-Speicher für den Bootloader auch mal zwei Kopien (in einer einzigen MTD-Partition), aber die sind 1:1 identisch und bei eMMC-Speicher kümmert sich ja auch dessen Controller um die Behandlung von potentiellen Flash-Fehlern - im Gegensatz zu (dummem) NAND-Speicher.
grep wlan_key /dev/mmcblk0p2
kommt nichts
grep wlan_key /dev/mmcblk0p13
wlan_key
grep wlan_key /dev/mmcblk0p14
wlan_key
cmp -l /dev/mmcblk0p13 /dev/mmcblk0p14
kommt nichts
Mail ist raus
Das sieht nach zwei identischen Kopien des Bootloaders in 13 und 14 aus (wenn's beim cmp
keine Unterschiede gibt) - da war mein Bauch dann im Irrtum.
Ich bin gerade mit der Implementierung der nächsten Version des Boot-Managers fertig geworden (https://github.com/PeterPawn/YourFritz/commit/a58c174b25371038dc2837d601d2673098ed8ecd - noch ohne Unterstützung für IPQ501x, IPQ8074 (Hawkeye) oder PRX300) und teste die jetzt noch ausführlich auf den Boxen, die ich in meiner Reichweite habe (VR9, GRX5 und Puma6) - das dauert also noch ein wenig, weil es mehrere Fälle pro Box zu testen gilt.
Danach geht's an die nächste Version, die dann zumindest IPQ8074-Boxen unterstützen soll.
Wenn noch was brauchst einfach sagen, werde es dann ausführen.
Du bist der Erste, der eine Version für IPQ8074 von mir zum Testen kriegt - da zähle ich dann wieder auf Dich. Bis hierher - nochmal danke.
Hihi danke, werde ich dann auch gerne, machen das Testen. Ich glaube, ich bin auch der Erste, der eine Fit Box gefreetzt hat.
Kann sein das ich nachher von einem Bekannten noch eine FRITZ!Box 7530AX und ein 1200AX bekomme zum Testen
Mail ist raus
Die habe ich mir jetzt angesehen, da tauchen dann aber noch ein paar Fragen auf.
Bisher war es üblicherweise so, daß der Konfigurationsbereich für den Bootloader auch Bestandteil des Bootloader-Codes und irgendwo in einer der Bootloader-Kopien zu finden war - m.W. galt das auch noch für IPQ4019-Boxen (7520/7530), selbst wenn der da etwas weiter hinten in der Partition stand.
Hier sieht es aber so aus, als wäre dort nur der "Standardblock" als Fallback enthalten (dabei wird als maca
immer 00:04:0E:FF:FF:01
verwendet) und damit müßten die anderen Daten der Box (WLAN-Key, Start-SSID, GUI-Kennwort, etc.) an anderer Stelle gespeichert sein.
Nun ist es ja glücklicherweise nicht so, daß es bei diesem Modell an potentiellen Kandidaten in Form von Partitionen unbekannten Inhalts mangelt - irgendwo MUSS AVM die Daten ja gespeichert haben. Da müßtest Du noch einmal nach der korrekten Partition suchen, z.B. so:
for n in $(seq 1 16); do grep -ao "<value>" /dev/mmcblk0p$n && echo "/dev/mmcblk0p$n"; done
Für <value>
kannst Du irgendeinen Wert nehmen, der für genau den Gerät spezifisch ist - ein Auswahl denkbarer Merkmale habe ich oben aufgezählt. Da das Gesuchte eigentlich nicht in den letzten vier Partitionen stehen kann (und die auch noch die größten sind, wo die Suche am längsten bräuchte), habe ich die ausgelassen (nur 1 bis 16).
Solltest Du Partitionen mit dem gesuchten Inhalt finden, bräuchte ich davon auch mal einen Dump - wenn Du die Daten des Geräts schützen willst (das Urlader-Environment weiter vorne hast Du ja auch maskiert), dann aber besser wieder per Mail (den Inhalt, nicht unbedingt die Fundstelle - die kann ja ruhig öffentlich bekannt sein, damit andere die Info auch nutzen können).
So ist per Mail raus. Es sind 3 Dumps, und zwar 14, 15 und 16
So, ich habe mal einen Entwurf eingecheckt: https://github.com/PeterPawn/YourFritz/blob/bootmanager_0.8.3/bootmanager/bootmanager
Zum Ausprobieren kann man diese Datei mittels wget
auf die Box laden, wobei auch noch das Message-File benötigt wird:
https://raw.githubusercontent.com/PeterPawn/YourFritz/bootmanager_0.8.3/bootmanager/bootmanager https://raw.githubusercontent.com/PeterPawn/YourFritz/bootmanager_0.8.3/bootmanager/bootmanager.msg
Beide Dateien irgendwo ablegen, wo Du sie wiederfinden kannst - dann zum Test mal sh <path>/bootmanager debug verbose
aufrufen und das Ergebnis bitte hier posten - ebenso die Ausgabe von bootmanager get_values
.
Anschließend ein ls -l /var/tmp/bootmanager*
und für jede dabei gefundene Datei (außer der .boot
, das ist nur eine Kopie des Urlader-Environments beim Start des OS) deren Inhalt noch mit cat
anzeigen lassen. Die .dev
sollte etwas wie immutable=avm
enthalten und eine .data
sollte die Ausgabe vom get_values
-Aufruf anzeigen.
switch_to
ist noch nicht implementiert - erst mal sichergehen, daß alle Daten richtig ermittelt werden.
Und "for the records" - beim 6000 (und vermutlich auch bei anderen IPQ8074-basierten Modellen) steht die Urlader-Konfiguration in der eMMC-Partition mit dem Label 0:CONFIG
(0:CONFIG_1
ist eine 1:1-Kopie davon), der Bereich hat immer noch die Versionsnummer 3 und beginnt am Offset 0x5e00.
sh /var/mod/root/bootmanager debug verbose
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = IPQ8074
system selector = 0
system is switched = false
device branding =
device branding is changeable =
current branding = avm
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
inactive system is installed = false
>>>>>>>>>>>>>>>>>>>> running system <<<<<<<<<<<<<<<<<<<<
active kernel =
active filesystem =
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
active system version = 253.07.29
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
active system date = 08.12.2021, 16:53:31 Uhr (epoch: 1638978811)
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
active system modification date = 25.02.2022, 16:40:16 Uhr (epoch: 1645803616)
active system modification source = Freetz-NG
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
brandings supported on active system = avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
inactive kernel =
inactive filesystem =
inactive filesystem could not be mounted
sh /var/mod/root/bootmanager get_values
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
ls -l /var/tmp/bootmanager*
-rw-r--r-- 1 root root 906 Feb 28 19:35 /var/tmp/bootmanager.boot
Dämlicher Fehler meinerseits - falscher Name der Funktion.
Neue Version ist eingecheckt, nur der Download für bootmanager
muß noch einmal ausgeführt werden.
sh /var/mod/root/bootmanager debug verbose
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = IPQ8074
system selector = 0
system is switched = false
device branding =
device branding is changeable =
current branding = avm
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
active system version = 07.29-93257
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
active system date = 08.12.2021, 16:53:31 Uhr (epoch: 1638978811)
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
active system modification date = 25.02.2022, 16:40:16 Uhr (epoch: 1645803616)
active system modification source = Freetz-NG
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
brandings supported on active system = avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
inactive system checks skipped
sh /var/mod/root/bootmanager get_values
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
active_version="07.29-93257"
active_date_epoch="1638978811"
active_date="08.12.2021, 16:53:31 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1645803616"
active_modified_at="25.02.2022, 16:40:16 Uhr"
active_brandings="avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="missing"
device_branding=
device_branding_changeable=
switch_branding_support=true
current_switch_value=0
system_is_switched=false
cat /var/tmp/bootmanager.data
active_version="07.29-93257"
active_date_epoch="1638978811"
active_date="08.12.2021, 16:53:31 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1645803616"
active_modified_at="25.02.2022, 16:40:16 Uhr"
active_brandings="avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="missing"
device_branding=
device_branding_changeable=
switch_branding_support=true
current_switch_value=0
system_is_switched=false
neue Version - wobei die Ausgabe in bootmanager.data
dem vorläufig erwarteten Ergebnis schon recht nahe kommt.
sh /var/mod/root/bootmanager debug verbose
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = IPQ8074
system selector = 0
system is switched = false
device branding =
device branding is changeable =
current branding = avm
active system version = 07.29-93257
active system date = 08.12.2021, 16:53:31 Uhr (epoch: 1638978811)
active system modification date = 25.02.2022, 16:40:16 Uhr (epoch: 1645803616)
active system modification source = Freetz-NG
brandings supported on active system = avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive system checks skipped
sh /var/mod/root/bootmanager get_values
active_version="07.29-93257"
active_date_epoch="1638978811"
active_date="08.12.2021, 16:53:31 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1645803616"
active_modified_at="25.02.2022, 16:40:16 Uhr"
active_brandings="avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="missing"
device_branding=
device_branding_changeable=
switch_branding_support=true
current_switch_value=0
system_is_switched=false
cat /var/tmp/bootmanager.data
active_version="07.29-93257"
active_date_epoch="1638978811"
active_date="08.12.2021, 16:53:31 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1645803616"
active_modified_at="25.02.2022, 16:40:16 Uhr"
active_brandings="avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="missing"
device_branding=
device_branding_changeable=
switch_branding_support=true
current_switch_value=0
system_is_switched=false
device branding = device branding is changeable =
Das sollte so nicht aussehen, der Rest gefällt mir schon ganz gut.
Da einige Operationen des Skripts recht aufwändig sind, werden einige Ergebnisse gecacht:
/var/tmp/bootmanager.boot
- Kopie des Urlader-Environments beim Systemstart
/var/tmp/bootmanager.dev
- hier sollte in Abhängigkeit von der Möglichkeit, da Branding dauerhaft zu ändern, in der Datei ein changeable=<original_value>
oder ein immutable=<original_value>
stehen
/var/tmp/bootmanager.data
- eine Kopie der Ausgabe eines get_values
-Aufruf
Die letzte Datei oben kann/muß durch den Aufruf von bootmanager clear_cache
gelöscht werden vor weiteren Test, ansonsten werden einfach nur wieder die zuvor dort gespeicherten Daten ausgegeben. Die letzten zwei Dateien werden gelöscht, wenn man hinter das clear_cache
noch ein with_eva_config
setzt.
Beim nächsten Aufruf - der dann natürlich länger braucht, wenn die Daten erst wieder zusammen gesucht werden müssen - werden diese Dateien dann neu angelegt.
Warum die zwei fehlenden Zeilen oben zustande kommen (da sollte der Inhalt des Konfigurationsbereichs von EVA ausgewertet werden - das ist dann das, was in bootmanager.dev
gecacht würde), muß ich mir erst mal genauer ansehen ... ggf. checke ich dann eine Version ein, die ein paar mehr Ausgaben erzeugt, damit ich erkennen kann, wo ein Problem aufgetreten ist.
Bei weiteren Tests dann bitte immer erst bootmanager clear_cache with_eva_config
aufrufen, damit nicht nur dieselben (ggf. fehlerhaften) Daten erneut ausgegeben werden.
Um das Problem mit der EVA-Konfiguration einzugrenzen, reicht dann jeweils die Ausgabe von bootmanager debug verbose
.
sh /var/mod/root/bootmanager clear_cache with_eva_config
sh /var/mod/root/bootmanager debug verbose
system type = IPQ8074
system selector = 0
system is switched = false
device branding =
device branding is changeable =
current branding = avm
active system version = 07.29-93257
active system date = 08.12.2021, 16:53:31 Uhr (epoch: 1638978811)
active system modification date = 25.02.2022, 16:40:16 Uhr (epoch: 1645803616)
active system modification source = Freetz-NG
brandings supported on active system = avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive system checks skipped
Das sollte ich nur machen sehe ich das richtig
Ja, das reicht ab jetzt erst einmal. Aber ich muß erst mal schauen, was da beim Zerlegen der EVA-Konfiguration nicht funktioniert für dieses Modell und erst mit einer neuen Version macht ein weiterer Test Sinn. Ich melde mich, kann aber jetzt mal 30 Minuten dauern - erst mal etwas essen.
Lass es dir schmecken. Bis später
Ich habe das hier nicht vergessen, aber der Aufbau des Konfigurationsbereichs ist hier ein anderer und da muß ich erst mal ein paar größere Umbauten vornehmen.
Das ist hier das erste Mal, daß mir ein Konfigurationsbereich in EVA unterkommt, wo die Daten in LE-Byte-Order gespeichert sind. Bisher war ich (mangels Masse bei den untersuchten Daten, jenseits von MIPS- und Puma-Chipsets) der Ansicht, daß die Daten einheitlich gespeichert würden, weil auch die (LE-)Plattform des ATOM-Cores im Puma6 die Daten im BE-Format gespeichert hat. Dabei hatte ich aber nicht bedacht, daß das ja nur mit Rücksicht auf den ebenfalls vorhandenen ARM-Core der Fall sein könnte, denn den betreibt AVM ja wiederum im BE-Modus.
Jetzt muß ich erst mal die Stellen, wo Daten in Abhängigkeit von der Byte-Order anders gespeichert werden müsse, überarbeiten - das betrifft den gesamten Teil in check_urlader_configuration
und es sind im Ergebnis sehr umfangreiche Änderungen. Das dauert etwas - ich werde auch in den kommenden Tagen nicht so richtig dafür Zeit haben.
Ich habe es also weiterhin auf dem Zettel, aber es kann gut bis zur nächsten Woche dauern, bis ich da wieder dran bin.
So bin dann wieder am Rechner, wenn also was getestet haben willst einfach melden
Neuer Versuch ... immer noch ohne FIT-Zerlegen, aber beim EVA-Konfigurationsbereich sollte das jetzt klappen.
Mich würde auch mal interessieren, wie lange das Zerlegen des Bootloaders braucht - bitte setze mal ein time
vor den Aufruf des Skripts mit dem debug
-Parameter. Bei einem weiteren Aufruf desselben Kommandos sollte es dann deutlich schneller gehen, dank der gecachten Infos (die bei diesem zweiten Versuch natürlich nicht gelöscht werden sollten).
time sh /var/mod/root/bootmanager debug verbose
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = IPQ8074
system selector = 0
system is switched = false
device branding = avm
device branding is changeable = false
current branding = avm
active system version = 07.29-93257
active system date = 08.12.2021, 16:53:31 Uhr (epoch: 1638978811)
active system modification date = 25.02.2022, 16:40:16 Uhr (epoch: 1645803616)
active system modification source = Freetz-NG
brandings supported on active system = avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive system checks skipped
real 0m 0.34s
user 0m 0.01s
sys 0m 0.00s
sh /var/mod/root/bootmanager get_values
active_version="07.29-93257"
active_date_epoch="1638978811"
active_date="08.12.2021, 16:53:31 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1645803616"
active_modified_at="25.02.2022, 16:40:16 Uhr"
active_brandings="avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="missing"
device_branding=avm
device_branding_changeable=false
switch_branding_support=true
current_switch_value=0
system_is_switched=false
ls -l /var/tmp/bootmanager*
-rw-r--r-- 1 root root 906 Mar 3 04:29 /var/tmp/bootmanager.boot
-rw-r--r-- 1 root root 462 Mar 3 04:31 /var/tmp/bootmanager.data
-rw-r--r-- 1 root root 14 Mar 3 04:29 /var/tmp/bootmanager.dev
cat /var/tmp/bootmanager.data
active_version="07.29-93257"
active_date_epoch="1638978811"
active_date="08.12.2021, 16:53:31 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1645803616"
active_modified_at="25.02.2022, 16:40:16 Uhr"
active_brandings="avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="missing"
device_branding=avm
device_branding_changeable=false
switch_branding_support=true
current_switch_value=0
system_is_switched=false
cat /var/tmp/bootmanager.dev
immutable=avm
Danke, die Erkennung der Bootloader-Konfiguration funktioniert jetzt offenbar auch. Da muß ich aber noch nacharbeiten, weil auch die Puma-Modelle (zumindest die 6er, also 6490, 6590 und 6430) auf dem ATOM-Core mit LE-Byte-Order arbeiten und dennoch die Daten im Konfigurationsbereich in BE gespeichert sind.
Danach schaue ich mir das Zerlegen der FIT-Images mal an, Vorlagen habe ich in den AVM-Downloads ja genug dafür.
Das kann dauern, daher ist hier die "akute Phase" dann erst einmal beendet. Wer will, kann derweil ja mal versuchen, den aktuellen Stand des Skripts auch in Verbindung mit dem GUI in einer Box zu benutzen. Je nachdem, ob/wann der akt. Stand des main
-Branchs in Freetz-NG verfügbar wird, muß nur das "Haupt-Skript" noch zusätzlich ersetzt werden.
Und auch noch einmal "for the records" ... im Konfigurationsbereich für EVA beim FRITZ!WLAN-Repeater 6000 gibt es NUR NOCH Einträge für Werte, die bei jedem Systemstart auch restauriert werden - die bei anderen Geräten noch vorhandenen Einträge, die nur einen Standardwert festlegen, wenn es noch keine entsprechende Einstellung gibt, fehlen hier bzw. es sind ALLE Einträge im festen Teil der Konfiguration.
Vielleicht baut @fda77 es zum Testen ja ein.
Und @PeterPawn dafür doch nicht, denn wir haben zu danken, dass du dir die Mühe und Arbeit überhaupt machst.
Bootmanager funktioniert nicht mit "FIT" Geräten: https://github.com/Freetz-NG/freetz-ng/issues/465#issuecomment-1046472498 Hast du geplant das zu unterstützen?