Bootmanager und FIT?

[fda77]

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?

[PeterPawn]

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:

• irgendetwas für die zuverlässige Identifikation des Modells/Prozessors, um daraus die Infos zum Aufbau des Systems abzuleiten
• Ausgabe von /proc/cpuinfo
• Ausgabe von /proc/mtd
• gibt es (analog zu den Puma-Modellen mit ihrem /proc/avm_partitions) irgendwelche zusätzlichen Pseudo-Files, die nahrhafte Informationen zum laufenden und zum inaktiven System liefern könnten?
• irgendwo war mir mal eine neue Environment-Variable für EVA untergekommen (linux_fs_status), die ich mit Aussagen zu den installierten Systemen in Verbindung gebracht hatte - ist so etwas bei diesen Modellen vorhanden im Environment?
• am besten gleich auch noch eine vollständige (ggf. maskierte) Kopie des Urlader-Verzeichnisses aus dem TFFS-Treiber, wenn AVM auch da weiterhin mit /proc/sys/urlader arbeiten sollte
• Was macht eigentlich das bootslotctl 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?
• In diesem Skript sieht es auch so aus, als würde in eine Partition mit dem Namen 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?
• Eigentlich sieht es in diesem Skript sogar so aus, als würde das 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.

[fda77]

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

[PeterPawn]

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.

[fda77]

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

[PeterPawn]

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.

[freetz-ng-mod]

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

[fda77]

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

[freetz-ng-mod]

Wie rufe ich denn genau ab

[PeterPawn]

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.

[PeterPawn]

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" 😁), 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.

[PeterPawn]

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.

[freetz-ng-mod]

/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

[PeterPawn]

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.

[freetz-ng-mod]

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

[PeterPawn]

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.

[fda77]

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

[freetz-ng-mod]

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

[PeterPawn]

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.

[freetz-ng-mod]

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=<input_device> bs=256 count=$(( / 256 )) | md5sum )

bootslotctl get_fw_version 1

07.29-93257

get_fw_version 0

07.29-93257

[PeterPawn]

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.

[freetz-ng-mod]

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

[PeterPawn]

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.

[freetz-ng-mod]

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

[freetz-ng-mod]

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

[PeterPawn]

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.

[PeterPawn]

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.

[freetz-ng-mod]

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

[PeterPawn]

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 (a58c174 - 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.

[PeterPawn]

Erinnert mich an die Probleme mit defekten NAND-Blöcken ... der verbliebene Code in bootmanager (der ist ja auf minimale Laufzeit getrimmt) bietet da keine weiteren Möglichkeiten der Analyse.

Dafür müßte man es noch einmal mit fitdump.sh und der Partition /dev/mtdblock0 als Eingabe probieren (fitdump.sh -d /dev/mtdblock0) ... wobei die 7530AX ja auch das Modell war, wo das mit defekten NAND-Blöcken erstmals aufgefallen ist. Ist das zufällig noch dasselbe Gerät?

Eigentlich sollte das ja jetzt mit nanddump ausgelesen werden und damit defekte Blöcke übersprungen werden ... ich bin also (so ohne Kontext) mal wieder etwas überfordert.

[freetz-ng-mod]

Ist dasselbe Gerät.
Gehe ich zurück zur FW 7.31geht es ja wieder

Ich sollte dazu auch sagen, dass die FW 7.39 ein ganz neuen Kernel hat
Freetz-NG/freetz-ng#483 (comment)

[PeterPawn]

Ich schaue es mir mal an ... das Zerlegen des Images sollte ja auch auf einem x64-System funktionieren. Wobei ich vorher noch einmal ganz konkret nachfrage: Welche Version hat das System (bzw. das FIT-Image) im inaktiven Slot, wenn das Problem auftritt?

Wenn das laufende eine 07.39 ist (so habe ich das verstanden) tritt dieses Problem auf, ansonsten nicht. Korrekt? Dann wäre ja das eigentliche Problem, mit einer 07.39 ein älteres Image zu zerlegen.

Wenn ich nichts finde beim Zerlegen der originalen AVM-Datei auf einem x64-System, müßte ich ggf. noch mal selbst auf die Box ... dann würde ich mich aber melden.

[freetz-ng-mod]

Im aktiven slot ist 7.39 und im inaktiven 7.31. Da tritt der Fehler auf. Ich schaue nachher noch mal nach wie es anderes rum ausschaut.

[freetz-ng-mod]

Ich bekomme hier noch ein Föhn
Ich kann es wieder mal nicht weiter testen, denn
https://github.com/Freetz-NG/freetz-ng/blob/a7873b20344703a1cc63821f46a0a7cc7fbc4e59/tools/make/yf-bootmanager-host/yf-bootmanager-host.mk

OK ich habe ein weg nun gefunden das ich erst mal die Testversion wieder habe.

So wenn in beiden Slots 7.31 ist, geht der BM

bootmanager debug verbose

yf_bootmanager version = 0.8.6-202204152119
>>>>>>>>>> device configuration from EVA loader <<<<<<<<<<
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = BCM963
model = AVM FRITZ!Box 7530 AX
chipset manufacturer = brcm
compatible = BCM963178
system selector = 1
system is switched = false
device branding = avm
device branding is changeable = false
current branding = avm
inactive slot contains a FIT image = true
>>>>>>>>>>>>>>>>>>>> running system <<<<<<<<<<<<<<<<<<<<
active slot = /dev/mtdblock4
active system version = 256.07.31-94779
active system date = 23.02.2022, 16:19:25 Uhr (epoch: 1645629565)
active system modification date = 24.05.2022, 06:09:35 Uhr (epoch: 1653365375)
active system modification source = Freetz-NG
brandings supported on active system = 1und1 avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive slot = /dev/mtdblock1
rootfs_type = squashfs
rootfs_offset = 2847304 (0x2b7248)
rootfs_size = 35622912 (0x21f9000)
inactive system version = 256.07.31-94779
inactive system date = 23.02.2022, 16:19:25 Uhr (epoch: 1645629565)
inactive system modification date = 24.05.2022, 21:13:56 Uhr (epoch: 1653419636)
inactive system modification source = Freetz-NG
brandings supported on inactive system = 1und1 avm avme
branding used by inactive system = avm (immutable)

cat /proc/mtd

dev:    size   erasesize  name
mtd0: 02171000 00001000 "rootfs_ram"
mtd1: 03200000 00020000 "fit0"
mtd2: 00200000 00020000 "urlader"
mtd3: 00800000 00020000 "nand-tffs"
mtd4: 03200000 00020000 "fit1"
mtd5: 00100000 00020000 "nvram"
mtd6: 01000000 00020000 "ubi"
mtd7: 0020f000 0001f000 "config"
mtd8: 00c79000 0001f000 "nand-filesystem"

So wenn in beiden Slots 7.39 ist, geht der BM nicht

bootmanager debug verbose
yf_bootmanager version = 0.8.6-202204152119
>>>>>>>>>> device configuration from EVA loader <<<<<<<<<<
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = BCM963
model = AVM FRITZ!Box 7530 AX
chipset manufacturer = brcm
compatible = BCM963178
system selector = 1
system is switched = false
device branding = avm
device branding is changeable = false
current branding = avm
inactive slot contains a FIT image = false
>>>>>>>>>>>>>>>>>>>> running system <<<<<<<<<<<<<<<<<<<<
active slot = /dev/mtdblock3
active system version = 256.07.39-96436
active system date = 10.05.2022, 09:29:50 Uhr (epoch: 1652167790)
active system modification date = 24.05.2022, 22:55:20 Uhr (epoch: 1653425720)
active system modification source = Freetz-NG
brandings supported on active system = 1und1 avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive slot = /dev/mtdblock0
FIT image not found for inactive slot

cat /proc/mtd

dev:    size   erasesize  name
mtd0: 03200000 00020000 "fit0"
mtd1: 00200000 00020000 "urlader"
mtd2: 00800000 00020000 "nand-tffs"
mtd3: 03200000 00020000 "fit1"
mtd4: 00100000 00020000 "nvram"
mtd5: 01000000 00020000 "ubi"
mtd6: 02600000 00001000 "rootfs_ram"
mtd7: 0020f000 0001f000 "config"
mtd8: 00c79000 0001f000 "nand-filesystem"

FW 7.31
mtd0: 02171000 00001000 "rootfs_ram"
mtd1: 03200000 00020000 "fit0"
FW 7.39
mtd0: 03200000 00020000 "fit0"
mtd6: 02600000 00001000 "rootfs_ram"

[fda77]

Dieses komische bootslotctl funktioniert übrigens nur wenn CONFIG_ENVIRONMENT_PATH gesetzt ist. Ansonsten kommen ohne Fehlermeldung falsche Werte!

Hab den BM mit der neuesten stable release von 7530ax+5530 getestet. Für die eine hab ich ein Freetz loop Module mitgebaut, die andere hat loop im kernel. 5590 geht mangels sourcen für das Modul nicht.

Ich hätte gerne in "/tmp/bootmanager.data" zu "inactive_modified_by" noch ein "inactive_modified_version" mit dem Inhalt der "/etc/.freetz-version". Soll ich PR machen oder machst du das lieber selbst?

[PeterPawn]

Seit wann ist das denn in Freetz-NG überhaupt wieder auswählbar?

Ich frage nur so dumm, weil von der Antwort irgendwie ja auch abhängt, wieviel Aufwand ich da für Anpassungen (für Freetz(-NG)) noch investiere. Bleibt das jetzt auch auswählbar und auch jeweils die (von mir freigegebene) aktuelle Version?

Wenn ja, baue ich das ein ... wobei es dann (einfach wg. der Tatsache, daß es eigentlich keine Property für das AKTIVE System geben kann, die sich nicht ermitteln läßt) auch für die aktive Partition einen entsprechenden Wert geben muß/wird, selbst wenn der ebenso durch direktes Auslesen der jeweiligen Datei ermittelt werden könnte.

Was hast Du Dir denn überlegt, wie man das handhaben sollte, wenn es gar keine Modifikation des inaktiven Systems gab? Da gäbe es ja die Option, den Wert dann einfach gar nicht zu setzen (wie als Beispiel bei inactive_modified_at_epoch) oder ihn mit einem festen Wert, der für "nicht modifiziert" steht (wie der Bindestrich bei inactive_modified_by), zu belegen.

Außerdem würde dann natürlich auch der zum jeweiligen Projekt, das zum Modifizieren genutzt wurde, gehörende Wert an dieser Stelle verwendet - die "Zuordnung" zwischen Framework und Anzeige steht hier:

YourFritz/bootmanager/bootmanager

Line 189 in ce04c85

readonly version_files="$yourfritz_version_file $freetz_ng_version_file $freetz_version_file $modfs_version_file"

und damit würde bei Freetz-NG dann auch der Inhalt von /etc/.freetz-ng-version ausgegeben und nicht der von /etc/.freetz-version. Da die Inhalte aber ohnehin identisch sein sollten, dürfte das ja kein Problem darstellen.

Dieses komische bootslotctl funktioniert übrigens nur wenn CONFIG_ENVIRONMENT_PATH gesetzt ist. Ansonsten kommen ohne Fehlermeldung falsche Werte!

Das steht/stand ja zu erwarten ... wenn Du das irgendwo aus einem CGI-Skript mit "bereinigtem" Environment verwenden willst, dann MUSST Du halt dafür sorgen, daß da ein passendes Environment vorhanden ist - das gilt für viele andere Utilities von AVM ebenso und es gibt ja einen Grund, WARUM da am Beginn ein passendes Environment präpariert und als Datei unterhalb von /var gespeichert wird. Das kann/muß man dann eben in eigene Skripte (sofern die über CGI aufgerufen werden, was praktisch beim gesamten Freetz-Interface der Fall ist) einschließen - das finde ich jetzt nicht SO überraschend, das gilt für anderes (inkl. /var/install, wenn es aus einem Freetz-Skript gestartet werden soll) schon seit langem.

[fda77]

Klar kann man das auswählen, es ist nur die Version vor deinem "funktlonen dürfen nichst sonstwo genutzt werden", oder so ähnlich. Keine Ahnung was der Zweck davon ist! Man kann ja einfach den git-hash in der .mk ändern: https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/yf-bootmanager-host/yf-bootmanager-host.mk#L1

Ich hab das mal kurz so geschrieben, aber nicht getestet! modver.patch.txt Ja, ich hatte das einfach analog zu den "date" gemacht

Das freetz-webif hat ein verringertes env, da ist mir das mit bootslotclt aufgefallen: Freetz-NG/freetz-ng@e95f102

Wenn der service noch nicht fertig ist steht im 2. einfach "unknown"

[PeterPawn]

es ist nur die Version vor deinem

Und Du denkst jetzt ernsthaft, daß ich - wenn ich die von Dir erwartete Änderung umsetze - bei dem Stand ansetze, der bisher in Freetz-NG auswählbar ist/war? Doch hoffentlich nicht ernsthaft ... zumal ich (nicht umsonst) betont habe, daß ICH für die korrekte Position des freetz-ng-version-Tags die Verantwortung übernehmen würde - und damit dann auch bereit wäre, mich für dabei noch vorhandene Probleme zu interessieren.

Du willst das künftig selbst machen? Steht Dir frei, aber warum das Ganze? Als "Trotz-Reaktion", weil ich (wie mehrfach erläutert) nicht will, daß man irgendwelche alten Stände unter die Leute bringt, daran dann noch herumschraubt und dennoch nicht bereit ist, durch entsprechende Kennzeichnung SELBST Verantwortung zu übernehmen für Fehler, die sich dabei ggf. erst "einschleichen"?

Außerdem kommt dann eben noch das Problem hinzu, daß auf diese Weise auch ältere, fehlerbehaftete Versionen weiterhin im Umlauf sein und Probleme bei deren Einsatz nun mal auf den ursprünglichen Autoren (oder die Autorin) zurückfallen.

Daher ist der Versuch, Änderungen durch Dritte an den "eingebetteten Funktionen" zu verhindern, am Ende nichts weiter, als das verzweifelte Bemühen, die jeweiligen Benutzer IMMER mit den neuesten Versionen zu versorgen und sich selbst den Ärger mit alten, lange überholten Versionen aus Quellen, die das ohne JEDWEDE Notwendigkeit, letztlich nur aus "Spaß an der Freude", verbreiten, zu ersparen. Das wende ich auch (absichtlich) nicht auf alles an - auch im Code des Boot-Managers ist (durch entsprechende Kommentare) sehr deutlich markiert, WELCHE Teile des Codes genau von dieser Beschränkung betroffen sind.

Für diese möchte ich einfach, daß jemand, der sie verwenden WILL, auch jeweils auf die "originale Quelle" zurückgreift und nicht auf irgendwelche Modifikationen, die bei manchen "Co-Autoren" nun mal leider auch hin und wieder von deutlich zu wenig Kenntnis der Materie beeinflußt werden und dann WOLLEN diese anderen offensichtlich noch nicht einmal die Verantwortung für ihre eigenen Änderungen übernehmen. Wenn ich an diesen eingebetteten Funktionen etwas ändere und diese Änderungen dann auch in meine eigenen Dateien übernehme, dann SOLL es nicht durch fremde Änderungen an DIESEN Funktionen einen Grund dafür geben, daß irgendwo weiterhin alte und fehlerbehaftete Implementierungen herumschwirren. Ist das tatsächlich so schwer zu verstehen?

Auch wenn Deine Antwort darauf "ja" lauten sollte: Sorry ... so nicht, jedenfalls nicht mit mir.

Und wenn jetzt durch die Verwendung Deiner gepatchten Version (des YourFritz-Repos) in Freetz-NG-Images Versionen meines Boot-Managers landen, die NICHT (und zwar 1:1) der von mir implementierten Version entsprechen (und diese Änderungen sind dann auch eindeutig dauerhaft und nicht nur zeitweilig, wie man es vielleicht noch für Patches annehmen könnte, die NUR auf dem Build-Host eine Wirkung entfalten - weil die nur "zeitweilig" sind, obwohl das nach den Lizenzbedingungen keinen Unterschied macht), dann HAST Du (schon nach der GPLv2:

You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

oder auch nach der GPLv3:

The work must carry prominent notices stating that you modified it, and giving a relevant date.

The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”.

eine Kennzeichnung anzubringen. Da findest Du in der GPLv3 dann auch gleich noch die Information, daß es DURCHAUS zulässig ist, diese Bedingungen durch "Additional terms" (Abschnitt 7 der GPLv3) - und zwar "permissive or non-permissive" - zu ergänzen.

Das heißt dann im Endergebnis, daß Du für Deinen Patch (https://github.com/fda77/YourFritz/commit/ba1c6404752d6d2c0a323cd05b63d90414f66ff3) - bzw. mit diesem - freundlicherweise auch noch eine "Änderungsnotiz" hinzufügst und zwar so, daß - im "fertigen Produkt" - für Dritte beim Lesen problemlos zu erkennen ist, daß es sich hierbei um eine GEÄNDERTE Version handelt und wer diese Änderungen (bestenfalls sogar noch wann, wenn es eine Änderung an einer bestehenden Datei und nicht das Hinzufügen einer neuen ist) vorgenommen hat.

DER ist dann nämlich auch (egal, wie umfangreich so eine Änderung am Ende sein mag, solange sie nicht nur eine "Fehlerkorrektur" an der ursprünglichen Arbeit ist) der ERSTE Ansprechpartner für jemanden, der auf eine Fehlfunktion trifft. Warum sollte der URSPRÜNGLICHE Autor dafür gerade stehen, wenn nicht ZUVOR geklärt wurde, ob das bereits in seiner Version ein Problem ist oder ob das erst durch die nachträglichen Modifikationen zu einem wurde? Lange nicht jeder Patch wird auch so ausgeführt, daß die ursprüngliche Funktion davon nicht verschlechtert wird.

Das alles hat - wie gesagt - auch NICHTS mit meinen Zusätzen zu den Lizenzbedingungen zu tun ... das steht bereits in der GPL, wie ich oben gezeigt habe. Und auf die als "Minimalkonsens" sollte man sich ja einigen können, oder?

[fda77]

Das heißt dann im Endergebnis, daß Du für Deinen Patch (https://github.com/fda77/YourFritz/commit/ba1c6404752d6d2c0a323cd05b63d90414f66ff3) - bzw. mit diesem

Du hast schon gesehen dass der in meinem Repo ist? Hab leider vergessen das auch auf privat zu stelln.
Tja, umsonst aufgeregt ;-) In Freetz ist nach wie vor die gpl2 version weil ich nicht genau weiss wie du das meinst mit deiner lizenz.

Wie gesagt war der patch nicht getestet. Wollte ich eigentlich, aber fitdump will nicht: PeterPawn/dtc@4cf7eaf

[fda77]

Du willst das künftig selbst machen?

Gleiche antwort wie gestern oder vorgestern: Ne. Davon kannst du fast immer ausgehen

"eingebetteten Funktionen"

worin? ein einem script? einem repo? eine einzelne funktion??
Nichts genaues weiss niemand. Und genau da ist das Problem

[PeterPawn]

worin? ein einem script? einem repo? eine einzelne funktion??
Nichts genaues weiss niemand. Und genau da ist das Problem

Probleme mit dem "verstehenden Lesen"?

Hier:

YourFritz/bootmanager/bootmanager

Line 251 in ce04c85

# imported from framework - it's not allowed to copy the functions below (up to the next comment box) #

beginnt der Bereich, der nicht aus diesem Skript in andere "Werke" übernommen werden soll (was nicht heißt, daß er im Rahmen der Benutzung in ebendiesem Skript nicht auch weiterhin kopiert und genutzt werden kann) und hier:

YourFritz/bootmanager/bootmanager

Line 303 in ce04c85

# end of functions imported from YF framework #

endet er auch schon wieder (der ist eben eher "kurz", weil das Skript praktisch gar kein eigenes UI hat und es nur "der Vollständigkeit halber" überhaupt einen "usage screen" gibt).

Was genau daran verstehst Du denn nicht? Ich würde mich ja - wenn Du das tatsächlich ernst meinst und die bisherigen Erklärungen für Dich noch nicht ausreichten - sogar noch bemühen, ein Verständnis dafür sogar bei Dir zu wecken. Nur glaube ich eben nicht mehr, daß Du das ernst meinst und gehe davon aus, daß es eher provokativ gedacht ist.

Und unter dieser Annahme bin ich es mittlerweile auch leid ... wäre nett, wenn Du mich in Ruhe lassen würdest, sofern Du ohnehin immer dasselbe behaupten möchtest.

Wenn Du gar nicht planst, das selbst in Freetz-NG (in gepatchter Version) einzubauen (der Eigentümer eines GitHub-Repos kriegt m.W. schon immer eine Benachrichtigung beim Forken und ich sehe bei mir da gar keine Option, so einen Fork schon dabei auf "private" zu setzen) und gleichzeitig aber von mir nur Versionen BIS zum Commit 9a1d3b8 den Freetz-NG-Benutzern "freigeben" willst, warum sollte ich dann IRGENDETWAS an dem Skript ändern? Oder erwartest Du ERNSTHAFT, daß ich das an einem dermaßen alten Stand ändere?

---

Wie geschrieben ... es bringt vermutlich nichts, wenn wir uns hier weiterhin auseinandersetzen. Du schaffst es ja bei der "Fehlermeldung", die Du in Kommentaren zu meinem Commit für das fitdump.c "versteckst" (ich habe den Verdacht, der RICHTIGE Platz für Fehlermeldungen ist das nicht), noch nicht einmal, wenigsten einen "Hinweis" zu geben, um was für ein System es sich dabei vielleicht handeln könnte, geschweige denn, den Aufruf des gcc, der diesen Fehler meldet (und das ist nun mal von den jeweils verwendeten Optionen zu den "warnings" abhängig: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html), näher zu benennen.

Da meine Glaskugel gerade zur Inspektion ist und es bei mir unter openSUSE Tumbleweed mit diesem gcc:

vidar:~/._github/dtc $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit --enable-offload-targets=nvptx-none,amdgcn-amdhsa, --without-cuda-driver --enable-host-shared --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp --disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin --with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-libphobos --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-11 --without-system-libunwind --enable-multilib --with-arch-32=x86-64 --with-tune=generic --with-build-config=bootstrap-lto-lean --enable-link-mutex --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20220316 [revision 6a1150d1524aeda3381b2171712e1a6611d441d6] (SUSE Linux)

beim simplen Aufruf von make mit diesen zwei Kommandos für das betreffende File:

echo "  " CC fitdump.o
cc -I libfdt -I . -DFDT_ASSUME_MASK=0 -DNO_VALGRIND -g -Os -fPIC -Werror -Wall -Wpointer-arith -Wcast-qual -Wnested-externs -Wsign-compare -Wstrict-prototypes -Wmissing-prototypes -Wredundant-decls -Wshadow  -DNO_YAML -o fitdump.o -c fitdump.c
echo "  " LD fitdump
cc -g -Os -fPIC -Werror -Wall -Wpointer-arith -Wcast-qual -Wnested-externs -Wsign-compare -Wstrict-prototypes -Wmissing-prototypes -Wredundant-decls -Wshadow  -DNO_YAML -I libfdt -I . -DFDT_ASSUME_MASK=0 -DNO_VALGRIND   -o fitdump fitdump.o util.o

(ermittelt mit make -n) problemlos zu übersetzen ist (ja, es sind nicht mal Warnungen zu sehen), hätte ich nicht mal eine IDEE, wie ich da weiterhelfen könnte.

Es KANN ja nicht so simpel sein, daß da einfach der Rückgabewert von chdir (https://man7.org/linux/man-pages/man2/chdir.2.html) IRGENDEINER (Integer-)Variablen zugewiesen werden sollte, damit diese Warnung (und das ist eigentlich nur eine solche, zum Fehler wird es erst, wenn andere Optionen noch gesetzt werden - und DA hat der gcc auf unterschiedlichen Plattformen dann auch mal unterschiedliche Standardeinstellungen, was worin ein- oder ausgeschlossen ist) nicht mehr ausgegeben wird.

Nun ... Du kannst ja jetzt oben lesen, mit welchen Compiler-Settings auf welcher Architektur das bei mir funktioniert und da sollte es ja dann (wenn man nicht doch einfach den Rückgabewert zuweist, denn SOOO smart ist der gcc dann wahrscheinlich auch wieder nicht) ein leichtes sein, die "schuldige" Option zu identifizieren und sie ggf. durch das "entgegengesetzte" Setting zu neutralisieren - und sei es mit einer #pragma-Direktive, wenn einem sonst nichts weiter einfällt.

---

Wobei ich jetzt ohnehin SCHON WIEDER irritiert bin ... nachdem Du das, was fitdump.c bietet, nun in Deinem fit.sh schon implementiert hast, willst Du jetzt DOCH wieder auf das C-Programm zurückgreifen? Ich blicke da einfach nicht mehr durch ... und da Du es ja nur selten (oder eher nie) schaffst, auch mal ein paar Worte der "Erklärung" abzusondern (weder vorher noch nachher in Commit-Kommentaren), bin ich vermutlich nicht der Einzige, dem es so ergeht. Nur habe ich KEINE Lust mehr auf solche Spielchen ... egal, ob Du die absichtlich initiierst oder ob es nur "Kommunikationsprobleme" sind, die leider immer wieder aufs Neue auftreten.

[fda77]

In Zeile 3 steht "do not use in other places", Freetz könnte so einer sein. Vielleicht meinst du aus ausserhalb deines Wohnortes, das ist Auslegungssache und über solches kann man sich recht lanke streiten, und damit meine ich nicht auf Github.
Dann weiter "for functions imported" könnte zb das nutzen der bootmanager.data sein. Oder einfach Shell Funktionen? Wer weiss. Dann "from YourFritz shell framework".
Da hab ich nicht wirklich eine Idee was das sein könnte, vielleicht meinst du das Script selbst. Oder das ganze Repo? Keine Ahnung!

"imported from framework - it's not allowed to copy the functions below (up to the next comment box) # " ist klar, um ehrlich zu sein hatte ich das mitten in der Datei noch nicht entdeckt.
Was hast du gegen ein paar sed und printf und Farbdefinitionen? Ich muss ja nicht verstehen weshlab, dein Code, deine Sache. Du willst diese 30 Zeilen Code schützen? Gehts nur um die?

Wie schon merhfach gesagt were ich daran nichts patchen (pr oder patch selbst ausgenommen).
ICH werde auch keine neuere Version fest einbauen da ich mit dieser Lizenz nichts anfagen kann.
Deshlab, eine einfache Lösung: Dein Code, du wiesst wie das in Freetz eingebaut ist und weisst ob du es da haben willst.

---

Daher gehst DU hier hin: https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/yf-bootmanager-host/yf-bootmanager-host.mk#L1=
gehst oben auf das Striftchen, setzt in die 1. Zeile den git-hash den du für gut hälst und fertig. Dadurch gibt es keine Zweifel dass du damit enverstanden bist. Ganz einfach

---

Die Tage hab ich während ich mit hippie lustig im irc geschrieben hab entdeckt, dass er wieder mal scheisse auf sein Seite verbreitet:
"Please at least be so fair to rename my long lasting work and add some change info and add your copyright to it instead of redistributing an intentionally broken version under my name!"
Das war nicht das 1. mal das er nicht so ganz rund läuft und ich hab keine Ahnung warum es dies mal war. Das ist aber egal, wenn er nicht will dass sein tool genutzt wird fliegt es halt raus. Hätte er mir auch einfach selbst sagen können
Genau deshalb hab ich dich auch vorher mit fit_tools gefragt

fitdump ist klar, nur nicht wie ich das integreien könnte vanilla + deinene 4-in-1 patch? Alledings hab ich auch dazu noch 4 kleine patches, ka wie ich die übermitteln könnte ohne dass du heut das 2. mal ne Krise hast!
Ich hab übrigens keine Ahnung was das für ein System mit dem Fehler ist, auf meinem Fedora gab es den Fehler nicht.
Im Grunde find ich das am besten, dass fitimg sehr flott ist. Allerdings ist das jedes mal ein Drama wenn die prerequisites nicht sofort 100% passen, sah man ja bereits
Wie fit am Ende wird weiss ich nicht, für die nestet muss jedenfalls noch was geändert wurden. 2x 3,5 Sekunden ist dann schon lange

Beim bootmanager-patch gibt es noch Fehler, es wird die Version des akuellen System angezegt. Die Uhrzeit passt dagegen
Mit den neuen 5590 sourcen sollte es hoffentlch bald auch damit funktionieren

[fda77]

Die "andere Version" könnte doch passen, wäre plausibel ^^

yf_bootmanager version = 0.8.6-202204152119
system type = BCM963
model = AVM FRITZ!Box 7530 AX
chipset manufacturer = brcm
compatible = BCM963178
system selector = 0
system is switched = false
device branding = avm
device branding is changeable = false
current branding = avm
inactive slot contains a FIT image = true
active slot = /dev/mtdblock1
active system version = 256.07.31-94779
active system date = 23.02.2022, 16:19:25 Uhr (epoch: 1645629565)
active system modification version = freetz-ng-19888MO-675d2b063
active system modification date = 23.06.2022, 15:26:23 Uhr (epoch: 1655990783)
active system modification source = Freetz-NG
brandings supported on active system = avm avme
branding used by active system = avm (immutable)
inactive slot = /dev/mtdblock4
rootfs_type = squashfs
rootfs_offset = 2847304 (0x2b7248)
rootfs_size = 34689024 (0x2115000)
inactive system version = 256.07.31-94779
inactive system date = 23.02.2022, 16:19:25 Uhr (epoch: 1645629565)
inactive system modification version = freetz-ng-19888MO-675d2b063
inactive system modification date = 23.06.2022, 15:00:33 Uhr (epoch: 1655989233)
inactive system modification source = Freetz-NG
brandings supported on inactive system = avm avme
branding used by inactive system = avm (immutable)

yf_bootmanager version = 0.8.6-202204152119
system type = PRX300
model = AVM FRITZ!Box 5530
chipset manufacturer = intel
compatible = PRX321-SFU-QSPI-PON
system selector = 0
system is switched = false
device branding = avm
device branding is changeable = false
current branding = avm
inactive slot contains a FIT image = true
active slot = /dev/mtdblock0
active system version = 257.07.29-93005
active system date = 02.12.2021, 12:35:28 Uhr (epoch: 1638444928)
active system modification version = freetz-ng-19888MO-675d2b063
active system modification date = 23.06.2022, 15:50:33 Uhr (epoch: 1655992233)
active system modification source = Freetz-NG
brandings supported on active system = avm avme
branding used by active system = avm (immutable)
inactive slot = /dev/mtdblock3
rootfs_type = ramdísk
rootfs_offset = 3341828 (0x32fe04)
rootfs_size = 38222119 (0x2473927)
inactive system version = 257.07.29-93005
inactive system date = 02.12.2021, 12:35:28 Uhr (epoch: 1638444928)
inactive system modification version = freetz-ng-19888MO-675d2b063
inactive system modification date = 23.06.2022, 15:43:34 Uhr (epoch: 1655991814)
inactive system modification source = Freetz-NG
brandings supported on inactive system = avm avme
branding used by inactive system = avm (immutable)

[PeterPawn]

setzt in die 1. Zeile den git-hash den du für gut hälst und fertig

Auch das gibt es schon ... nur sieht es (nachdem DU bei Deinen Änderungen ab hier: Freetz-NG/freetz-ng@43303ad darauf "verzichtet" hast, das Tag weiterhin zu unterstützen ... also erzähle mir nichts von "ich bin daran komplett unschuldig") jetzt eben etwas anders aus:
PeterPawn/YourFreetz@5b443aa

Freetz-NG-Benutzer möchten das gerne nutzen? Kein Problem ... wenn Du es nicht schaffst, das einigermaßen "normal" einzubauen (ich sehe irgendwie den Unterschied nicht, ob ich - JEDES MAL - da einen neuen Hash eintragen soll oder einfach nur das Tag neu setze), dann müssen/sollen sie eben den dafür benötigten Patch aus meinem YourFreetz-Repo laden.

---

Gehts nur um die?

Nein, geht es eben nicht. Das ist nur das (sehr kleine) Subset von Funktionen, die in diesem Skript-File genutzt werden (und das noch in einer älteren Version) - das (immer noch nicht fertige) Framework findet sich (als "Zwischenversion") z.B. hier: https://github.com/PeterPawn/YourFritz/tree/_scriptlib/scriptlib ... wobei die drei Dateien yf_template, yf_ui und yf_helpers per se schon unter einer Lizenz stehen, die zwar in weiten Teilen mit der GPL (2 oder 3) übereinstimmt, aber EXPLIZIT noch weitere Forderungen bei der "Nachnutzung" dort enthaltener Funktionen erhebt.

Und die Funktionen und Variablennamen in diesen Funktionen sind soo eng miteinander verflochten (bis hin zum "Löschen" verwendeter Variablen, bevor die Steuerung zurück geht an den Aufrufer - sonst hat man beim "Sourcen" ganz schnell eine riesige Liste von nicht länger benötigten Variablennamen in seiner Shell-Instanz, was auf "kleinen Systemen" auch schon mal zum Problem werden kann), daß schon minimale Änderungen (von jemandem, der das nicht WIRKLICH bis ins letzte Detail selbst untersucht hat) verheerende Auswirkungen haben können (bis hin zu Sicherheitslücken, eben WEIL da auch viel mit eval gearbeitet wird und dann jedes fehlende "quote" schnell zum Problem wird) ... daher der Versuch meinerseits, Änderungen an DIESEN Teilen zu verhindern.

Wenn man sich das tatsächlich mal durchliest und auch das Konzept hinter den "include"-Files, die damit auch generiert werden können, verstanden hat (

YourFritz/scriptlib/yf_template

Line 47 in 2c0a4b7

# This script may be used to create a sceleton of a new shell script, with code to include YourFritz #

), dann WILL man hoffentlich (sofern man diese Framework-Funktionen in eigenen Implementierungen nutzen will) diese Funktionen gar nicht mehr "integrieren", sondern sich lieber - mit der jeweils aktuellen Version - beim ersten/nächsten Zugriff auf das entsprechende Skript eine neue Version, die dann die tatsächlich benötigten "Features" enthält, generieren lassen.

Und da DAS der (von mir) präferierte Einsatzfall ist (weil ich dann in den Funktionen Korrekturen vornehmen kann und die geänderten Dateien nur noch auf das entsprechende System zu kopieren sind und ggf. eine alte "include"-Datei zu löschen wäre, damit sie automatisch neu generiert wird), sehe ich das als "Update-Strategie" für diese Funktionen ... nur müssen die dazu auch irgendwie "beieinander gehalten" werden und am besten auch noch durch bekannte "Trenner" vom restlichen Code abgegrenzt werden, DAMIT man den Teil zwischen diesen Trennern dann auch (automatisch) austauschen (und damit aktualisieren) kann. Alles das, was da jemand anderes "dazwischen schmiert", führt dieses Vorgehen ad absurdum.

Beim Boot-Manager sind diese Funktionen auch nur "ausnahmsweise" statisch inkludiert (wie gesagt, noch in einer älteren und sogar "von Hand" deutlich abgespeckten Version), aber hier war es mir einfach wichtiger, daß EINE Datei alles Notwendige enthält - immerhin sind es aber inzwischen auch so schon deutlich mehr Dateien, die das Gesamtergebnis darstellen. Daher könnte ich mir sogar vorstellen, das irgendwann noch mal auf "automatische Updates" umzustellen - wobei das NACH dem Erstellen eines Dateisystem-Images per se schon problematisch wird, WEIL die "script location" dann in aller Regel nicht mehr beschreibbar ist.

Daher war das HIER eigentlich auch keine "schwere Entscheidung", das ausnahmsweise statisch einzubauen - es ändert aber nichts an den Bedingungen, die für die "Quelle" dieser Funktionen von mir festgelegt wurden und ehe sich jetzt jemand an DIESEN Funktionen bedient (wie plausibel das ist, interessiert mich dabei gar nicht) und dann der Meinung ist, diese stünden ja unter "einfacher GPL", versuche ich dieses Vorgehen durch die entsprechenden Bedingungen "zu blockieren". Punkt.

Und WENN tatsächlich jemand daran interessiert ist, etwas von diesem Code (zwischen den Markierungen) in eigenen Skript-Dateien zu verwenden, dann KANN man wohl auch erwarten, daß derjenige sich eher "am Original" bedient (und das wäre - inkl. der dafür geltenden Lizenz - der Inhalt unterhalb von scriptlib ... wobei das z.Zt. noch gar nicht im main-Branch steht, sondern seinen eigenen hat, auch weil bisher immer wieder noch Änderungen (auch am "Interface") erfolgen) und sich damit Fehlerkorrekturen "schneller rumsprechen", anstatt nach dem Prinzip "Stille Post" weitergegeben und dabei meist auch noch verschlimmert zu werden.

Da, wo es eben KEINE so enge Verzahnung zwischen den Funktionen gibt (z.B. bei allem unterhalb von functions, wo POSIX-kompatibler Ersatz für "bashismen" (wie z.B. das "substring" durch ${name:start:size}", was es in POSIX eben nicht gibt) oder auch für komplette Kommandos, die NICHT im POSIX-Standard defiiniert sind (wie base64`) zu finden ist), da stelle ich das auch weiterhin unter "pure" GPL-Bedingungen ... warum das bei den anderen Teilen NICHT so ist, habe ich (nicht erstmalig) versucht zu erklären.

---

Gleiche antwort wie gestern oder vorgestern: Ne. Davon kannst du fast immer ausgehen

Du wirst mir meine Skepsis hoffentlich verzeihen, wenn Du Dir noch einmal Deine Commits ab hier: 7b0946a5 ansiehst (und ich kann gerne noch andere Beispiele raussuchen, wobei das nicht erforderlich sein sollte, solange Du nicht allzu vergeßlich sein solltest).

Aber vielleicht habe ich ja auch nur Deine Commit-Texte nicht richtig verstanden, was das anbelangt ... nein, warte mal, DA gab es auch AUCH WIEDER keine "Erleuchtung". Dann war das wohl einer der Fälle, der zu dem einschränkenden "fast" beim "immer" gehört(e)? Woran soll man die dann künftig selbst erkennen können? Und jetzt antworte bitte nicht: "Am Commit-Text.", denn da beißt sich die Katze dann in den Schwanz.

[fda77]

Aha. Was ist nun die Antwort?

[fda77]

5590:

[freetz-ng-mod]

@fda77

Ich weiß zwar nicht, was du geändert hast beim Bootmanager in freetz, aber der lauft nun nicht mehr auf der 6000.

root@6000-repeater:/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 = 24.06.2022, 12:37:04 Uhr (epoch: 1656067024)
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

root@6000-repeater:/var/mod/root# cd /var
root@6000-repeater:/var# rm /var/tmp/bootmanager.*
root@6000-repeater:/var# wget https://raw.githubusercontent.com/Peter
Pawn/YourFritz/freetz-ng-test/bootmanager/bootmanager
Connecting to raw.githubusercontent.com (185.199.108.133:443)
wget: note: TLS certificate validation not implemented
saving to 'bootmanager'
bootmanager          100% |*********************|  153k  0:00:00 ETA
'bootmanager' saved
root@6000-repeater:/var# wget https://raw.githubusercontent.com/Peter
Pawn/YourFritz/freetz-ng-test/bootmanager/bootmanager.msg
Connecting to raw.githubusercontent.com (185.199.108.133:443)
wget: note: TLS certificate validation not implemented
saving to 'bootmanager.msg'
bootmanager.msg      100% |*********************|  4710  0:00:00 ETA
'bootmanager.msg' saved
root@6000-repeater:/var# sh /var/bootmanager debug verbose
yf_bootmanager version = 0.8.6-202204152119
>>>>>>>>>> device configuration from EVA loader <<<<<<<<<<
'firmware_version' found in fixed values area.
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = IPQ8074
model = AVM FRITZ!Repeater 6000
chipset manufacturer = qcom
compatible = IPQ807X-HK01
system selector = 0
system is switched = false
device branding = avm
device branding is changeable = false
current branding = avm
inactive slot contains a FIT image = true
>>>>>>>>>>>>>>>>>>>> running system <<<<<<<<<<<<<<<<<<<<
active slot = /dev/mmcblk0p17
active system version = 253.07.29-93257
active system date = 08.12.2021, 16:53:31 Uhr (epoch: 1638978811)
active system modification date = 24.06.2022, 12:37:04 Uhr (epoch: 1656067024)
active system modification source = Freetz-NG
brandings supported on active system = avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive slot = /dev/mmcblk0p19
rootfs_type = squashfs
rootfs_offset = 3378120 (0x338bc8)
rootfs_size = 18878464 (0x1201000)
inactive system version = 253.07.29-93257
inactive system date = 08.12.2021, 16:53:31 Uhr (epoch: 1638978811)
inactive system modification date = 24.06.2022, 12:43:36 Uhr (epoch: 1656067416)
inactive system modification source = Freetz-NG
brandings supported on inactive system = avm avme
branding used by inactive system = avm (immutable)
root@6000-repeater:/var# 

[fda77]

Was hab ich damit zu tun???
Man sieht dass du von @PeterPawn was herunter lädst. Dafür ob Dinge aus anderen Repos funktionieren bin ich nicht auch noch zuständig
Ich hab jedenfalls 3 der aktuell 7 FIT Geräte getestet, die funktionieren alle. Siehe screenshots oben. Da du die gleiche Version wie ich oben (+X) verwendest, ist entweder Peter Script kaputt, oder du hast es falsch benutzt. Das ist euere Sache. Der Kreis schliesst sich,
-> ich hab nix damit zu tun.

Frag du doch mal den Peter was jetzt mit dem package bump und seiner lizenz ist, er schafft es nicht mir ne klar Antwort zu geben. Falls die in seine mehrseitigen Post drin stehen sollte, übersetz mir diese bitte. jo/nö würde reichen

[freetz-ng-mod]

Nein es liegt nicht an Peters Script. Es liegtr daran das Freetz mal wieder nur die 0.83 einbaut. Vor 2 Tagen wurde mir immer die 0.86 eingebaut. Jedes mal muss man schauen das man wieder zurück auf die 0.86 kommt.

So habe wieder die 0.8.6 drin
bootmanager debug verbose

yf_bootmanager version = 0.8.6-202204152119
>>>>>>>>>> device configuration from EVA loader <<<<<<<<<<
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = IPQ8074
model = AVM FRITZ!Repeater 6000
chipset manufacturer = qcom
compatible = IPQ807X-HK01
system selector = 1
system is switched = false
device branding = avm
device branding is changeable = false
current branding = avm
inactive slot contains a FIT image = true
>>>>>>>>>>>>>>>>>>>> running system <<<<<<<<<<<<<<<<<<<<
active slot = /dev/mmcblk0p19
active system version = 253.07.29-93257
active system date = 08.12.2021, 16:53:31 Uhr (epoch: 1638978811)
active system modification date = 24.06.2022, 14:01:27 Uhr (epoch: 1656072087)
active system modification source = Freetz-NG
brandings supported on active system = avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive slot = /dev/mmcblk0p17
rootfs_type = squashfs
rootfs_offset = 3378120 (0x338bc8)
rootfs_size = 18886656 (0x1203000)
inactive system version = 253.07.29-93257
inactive system date = 08.12.2021, 16:53:31 Uhr (epoch: 1638978811)
inactive system modification date = 24.06.2022, 12:37:04 Uhr (epoch: 1656067024)
inactive system modification source = Freetz-NG
brandings supported on inactive system = avm avme
branding used by inactive system = avm (immutable)

[fda77]

Freetz mal wieder nur die 0.83 einbaut. Vor 2 Tagen wurde mir immer die 0.86 eingebaut

bullshit

Kümmer dich darum das mit peter zu klären

[freetz-ng-mod]

Dann kümmer du dich mal um tools-2022-06-20.tar.xz da isdt schon mal BM 0.8.3 drin. Und von da kommt es das im 6000 nur die 0.8.3 ist. Das habe ich nun aber geändert bei mir

[fda77]

In Freetz ist die aktuellste 0.8.3 : https://github.com/PeterPawn/YourFritz/blob/main/bootmanager/TODO.md

Dann kümmer du dich mal

Mir fällt leider keine Antwort ein die man hier schreiben sollte

[freetz-ng-mod]

Willst du oder kannst du es nicht verstehen. Ich habe schon seit 19.5 schon den 0.8.6 drin was auch alles immer Topp gelaufen ist. ( #45 (comment) und #45 (comment) ). Aber jedes Mal änderst du was, das man immer wieder suchen muss das es wieder den 0.8.6 gibt

[fda77]

Bist du zu dumm um zu verstehen dass sich bezüglich BM seit 2 monaten nichts relevantes geändert hat?
Falls du weiter diesen Mist behaupten willst, verlink den commit

[freetz-ng-mod]

@PeterPawn
Hier mal eine Ausgabe von der 5590 ohne Änderungen von @FDA in freetz (dein Original BM)
bootmanager debug verbose

yf_bootmanager version = 0.8.6-202204152119
>>>>>>>>>> device configuration from EVA loader <<<<<<<<<<
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = GRX500
model = AVM7590ax (GRX550, HW259) Main model
chipset manufacturer = lantiq
compatible = GRX500
system selector = 0
system is switched = false
device branding = avm
device branding is changeable = false
current branding = avm
inactive system is installed = true
>>>>>>>>>>>>>>>>>>>> running system <<<<<<<<<<<<<<<<<<<<
active kernel = /dev/mtdblock0
active filesystem = /dev/mtdblock5
active system version = 259.07.31-94867
active system date = 28.02.2022, 12:06:22 Uhr (epoch: 1646046382)
active system modification date = 21.06.2022, 17:09:23 Uhr (epoch: 1655824163)
active system modification source = Freetz-NG
brandings supported on active system = 1und1 avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive kernel = /dev/mtdblock3
inactive filesystem = /dev/mtdblock6
inactive filesystem mounted on /var/tmp/27442_1656082215/alt_root
inactive system version = 259.07.31-94867
inactive system date = 28.02.2022, 12:06:22 Uhr (epoch: 1646046382)
inactive system modification date = 13.06.2022, 05:27:35 Uhr (epoch: 1655090855)
inactive system modification source = Freetz-NG
brandings supported on inactive system = 1und1 avm avme
branding used by inactive system = avm (immutable)
inactive filesystem dismounted

[fda77]

Vielleicht waren die doch nicht so schlecht?

[PeterPawn]

Ich lasse mich nicht länger "vorführen" - für diejenigen, die am Ende die VON MIR (für Freetz-NG) freigegebene Version benutzen wollen, weil ich diese als "tauglich" für die Verwendung ansehe, bleibt die (schon weiter oben von mir besxchriebene: #45 (comment)) Option, nach dem Aktualisieren event. Änderungen aus dem Freetz-NG-Repository einfach noch eine einzelne Zeile mit git pull aufzurufen ... wenn mein eigener Patch schon auf dem letzten Stand von Freetz-NG basieren sollte, kann man auch DIREKT den ng_yf_bootmanager-Branch aus meinem Repo klonen.

Ich mache da keine "Spielchen" mehr mit ... ich stelle mich hier hin, reiße mir den A**** auf in dem Bemühen, mit @fda77 sachlich und vernünftig zu "reden" und dann kommt am Ende doch nur "Wurstigkeit" (die Höflichkeit läßt mich stärkere Worte ebenso vermeiden wie einen Verweis auf den "Schwäbischen Gruß") dabei zurück?

Das das hier mittlerweile fast nicht mehr lesbar ist (man muß mehrfach "nachladen", um noch ältere Beiträge, auf die man verlinken möchte, zu finden), mache ich das auch zu (inkl. Schloß).

@freetz-ng-mod:
Mir ist bewußt, daß es bei einigen Modellen mit der Labor-Version 07.39 noch Probleme gibt, aber soweit ich das gesehen habe, basieren die alle nur darauf, daß in Freetz-NG AUCH keine funktionierenden loop-Treiber gebaut werden können. Ein paar (kleinere) Probleme könnten noch daran liegen, daß AVM die Struktur der FIT-Images (bzw. genauer die Verwendung von avm,kernel-args ) etwas geändert hat.

Das habe ich als "Aufgabe" also auch noch auf dem Schirm, aber nicht im Moment (ich muß erst mal mein fitdump in Shell reparieren und danach dann den analogen Code im Boot-Manager) mache ich da nichts. Für den größeren Teil der Freetz-NG-Benutzer (die nicht "nur spielen" wollen, sondern mit der Box auch noch "arbeiten" müssen) empfiehlt es sich ja ohnehin, nur sehr sparsam die Änderungen aus dem Freetz-NG-Master zu übernehmen und damit ist für solche Systeme die Empfehlung, doch lieber bei einer älteren Freetz-NG-Version zu bleiben (ggf. mit dem o.a. Patch, wenn man einen funktionierenden Boot-Manager (für Versionen bis 07.39 - aus der "Update-Runde" im März/April) haben möchte.

Daher kann ich mir auch gut vorstellen, weitere Änderungen am Boot-Manager noch eine Weile zu schieben (bis AVM sich dem Release nähert und/oder ich mit eigener Toolchain auch auf der Box wieder entpacken, ändern und packen kann) ... wenn ich da etwas machen will, melde ich mich (in MEINEM Repo, also HIER) dann auch wieder.

Bis dahin ist hier erst mal zu ... ich weiß nicht mehr sicher, ob ich mich schon mit meinem Wunsch, künftig "in Ruhe gelassen" zu werden an @fda77 gewandt habe (manchmal schreibe ich im ersten Impuls auch Texte, die ich später nicht absende - ggf. war diese "Bitte" auch ein solcher), aber es GIBT in meinen Augen einfach auch nichts mehr zu schreiben.