Bootmanager und FIT? #45
Comments
- refs PeterPawn/YourFritz#45 - refs #465
|
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 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 Um das Einbauen zu können, braucht es folgende (Er-)Kenntnisse:
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 Gleichzeitig ist wohl das Binary Das Denn auch ein Blick in das Binary und damit vielleicht schon bei AVM eine neue "Abstraktionsschicht" bieten, hinter der Unterschiede der Modelle in der Zukunft mal verschwinden sollen. Aber das oben Geschriebene zeigt für mich auch deutlich, daß man noch viel zu wenig über den "inneren Aufbau" dieser Boxen weiß (das Zerlegen des AVM-Images ist das eine, das Verstehen der inneren Funktionen etwas anderes), um das mal eben aus dem Handgelenk zu schütteln. Ich bin auch nicht davon überzeugt, daß man das (in endlicher Zeit) implementieren bzw. erst mal richtig erkunden kann, wenn man keine eigene Box dazu hat. Die Kommunikation gestaltet sich da schon dann schwierig, wenn zwei Seiten in etwa auf demselben Stand der Skills sind - je weiter der auseinander liegt, um so schwieriger wird das am Ende auch. Aber man könnte es tatsächlich mal versuchen ... nur darf man die Erwartungen an (schnelle) Fortschritte dann auch nicht zu hoch hängen, außer jemand schafft es tatsächlich, das alles weitgehend selbständig zu ermitteln und die Erkenntnisse mit anderen zu teilen. Falls sich Boxen mit diesem Aufbau bei AVM mehren sollten (bisher sind es m.W. noch nicht soo viele und nach meinem Dafürhalten auch nicht unbedingt Geräte aus dem Mainstream), lohnt sich das sicherlich in jedem Falle, sich damit zu befassen. BTW ... die "Liste" oben, was man an Infos bräuchte, ist auch nur ein Anfang und erhebt keinerlei Anspruch auf Vollständigkeit - einiges an weiterem "Forschungsbedarf" ergibt sich auch erst aus den ersten Infos, die man dann erhält. |
|
Ohne eigenes Gerät ist es schwer das umzusetzen. Immerhin funktioniert Freetz überhaupt, finde ich überraschend :D Als Identifikation reicht SEPARATE_FILESYSTEM_IMAGE in Freetz, nur dann werden die Bootmanager installiert, aktuell für FIT nicht mehr. Falls das herkömmliche mounten der 2. Partition nicht funktioniert, probiert man einfach die noch nicht vorhandene fit-Methode... |
Ich warte im Moment noch auf positive Rückmeldungen für die Änderungen, damit das auch mit 07.39 funktioniert. Zwar habe ich das so umgesetzt, daß es auch mit früheren OS-Versionen genauso läuft (bei mir auf einer 7490 getestet), aber das sagt mir nur, daß das gewählte Prinzip so funktioniert und noch fehlt die Info, ob das dann auch schon alles war, was geändert werden mußte, damit es mit 07.39 und folgenden Versionen (erst mal) wieder klappt. Liegt also nur zum Teil in meinen Händen ... außer ich habe irgendwann genug vom Warten und mache auch ohne Feedback ein Merge - eigentlich nicht so ganz meins, wenn ich das nicht doch schon selbst getestet habe. |
|
Laut https://boxmatrix.info/wiki/FRITZ!Repeater_6000 gibt es um Urlader |
|
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 Wie geschrieben ... ohne passendes Gerät und immer nur aus zweiter Hand ist das einigermaßen schwierig. Mein Problem ist nur, daß ich keinen DSL-Anschluß mehr nutze und da man für schnelle Erfolge beim Untersuchen einer Box am besten auch gleich noch die Serielle bestückt, kann man die auch nicht einfach nur erwerben, mal 2 Wochen untersuchen und dann wieder gebraucht verkaufen (jedenfalls nicht ohne gehörigen Verlust). Abgesehen davon, sind das im Moment alles ohnehin Mondpreise, die ich schon aus Prinzip nicht zu zahlen bereit bin, nicht mal als Betriebsausgabe und dann müßte man das auch noch passend begründen, daß man mit dem Kauf eine Gewinnerzielungsabsicht hatte und es nicht nur "Hobby" ist, was bei OpenSource-Projekten schon schwierig ist. |
|
cat /proc/cpuinfo cat /proc/mtd cat /proc/avm_partitions cat /proc/sys/urlader da sind 4 datein drin aber alle leer |
|
Die Preise aktuell sind unmöglich, ich hätte gern noch einen Pi4, bin aber nicht bereit das doppelte wie vor 1 Jahr zu bezahlen. Für einen zb Repeater 6000 braucht man kein DSL ;-) Und die Ausgabe von "bootslotctl get_fw_version"? Schau mal was dieses Programm noch so hergibt |
|
Wie rufe ich denn genau ab |
??? Habe ich doch schon ... schließlich gibt's oben u.a. ein Einen Repeater brauche ich nicht ... in meine obere Etage führt ein GbE-fähiges UTP-Kabel und da gibt es einen weiteren AP bzw. Ethernet für Fernseher (RPi mit LibreElec) und alles das, was man sonst noch so braucht. Das ist also auch kein Argument gegenüber dem FA, einen Repeater als Betriebsausgabe geltend zu machen, auch wenn der heute noch bei unter 250 EUR liegt und sofort abgeschrieben werden kann. Bei den Boxen wird das dann schon schwerer ... ab 250 EUR netto sind bei manchen Modellen auch drin. |
|
OK, daß in Sind bei einem Wobei ich mich hier jetzt erst einmal ausklinke ... für so ein "Ping-Pong" fehlt mir im Moment mal wieder die Zeit (und auch etwas die Geduld, bitte nicht falsch verstehen) - ich muß mal wieder etwas "richtiges" machen. |
|
Korrektur oben bzgl. der Emulation für's TFFS Und wenn ich mich nicht schwer irre, sind 17 MB des vorhandenen Hauptspeichers schon mal dadurch belegt, daß hier das Wurzeldateisystem für das FRITZ!OS in den Hauptspeicher kopiert wurde (das dürften die etwas mehr als 17 MB in |
|
/proc/avm_partitions cat /sys/class/mtd/*/name mount df -h |
|
Danke. Blieben noch 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 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 Auch wäre dann interessant, ob ein wiederholter Aufruf immer wieder zwischen Da man durch diese Verwendung von |
|
blkid bootslotctl get_active 0/1 bootslotctl get_active 1/2 bootslotctl get_other bootslotctl is_active bootslotctl get_fw_version bootslotctl activate_other cat /proc/sys/urlader/environment reboot gemacht bootslotctl activate_other cat /proc/sys/urlader/environment bootslotctl activate_other cat /proc/sys/urlader/environment cat /var/bootedslot |
|
OK, nochmal danke. Ein paar Mißverständnisse gilt es auszuräumen ...
Das war so natürlich nicht gemeint ... und beim Aber die Ausgabe mit der Damit sollte aber auch die Frage beantwortet sein, was bei Beim Beim ... damit sollte einmal auf das alternative System umgeschaltet werden und einmal zurück - wenn dieses Bei der Wenn das ein Repeater ist, dann erklärt das ein Fehlen von Zwar könnte man auch zu Fuß durch die Block-Devices ziehen, aber irgendetwas in der Richtung Als ersten Test könnte man noch ein
Mir fällt im Moment auch nichts besseres als Aber ich habe dann doch noch einmal genauer in die Firmware gesehen ... immerhin gibt es noch den 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 Danach kann man die beiden FIT-Partitionen dann mit einem |
|
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 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 |
ls -l /var/bootedslot ls -l /dev/mmc* for n in /sys/class/block/mmc*; do echo ">>> |
|
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
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: 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 Das Umschalten des aktiven Systems ist - zumindest wenn man ausschließlich Ich würde zwar immer noch versuchen wollen, den Inhalt der SquashFS-Images für das aktuell laufende (das findet man ja unter |
|
for n in /sys/block/mmcblk0/mmcblk0p*; do echo ">>> $n <<<"; cat $n/start; cat $n/size; done 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 get_fw_version 0 |
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: Wo genau die Datei Die Tabelle mit den Partitionen mache ich später neu und füge dabei die Angaben zu So groß sind aber auch die bisher aufgetauchten FIT-Images nicht und daher muß man auch die Überprüfung des Inhalts der Partitionen auf die Größe der darin gespeicherten Daten begrenzen. |
|
Ja es wurde schon 2 oder 3-mal das Image neu geflasht, weil ja noch Fehler drin waren in freetz-ng die behoben worden und ich es testen sollte. Daher immer Version 07.29-93257 Das erste Mal habe ich es über push geflasht und jetzt kann ich nur noch über die AVM Webseite falshen. Da es über das freetz nicht ging. Daher ist das zurzeit auch deaktiviert ls -l fit-image Edit ls -l /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 |
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 Damit findest Du aber die gesuchte Datei Die Prüfung, ob dieses Image dann 1:1 in die Partition (
Die Zeile dann noch einmal für |
|
So ich habe ein neues Image gebaut mit Freetz-NG habe dann das fit-image was unter build/modified/firmware/var/tmp dann liegt. 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. dd if=/dev/mmcblk0p19 bs=256 count=$(( 22282240 / 256 )) 2>/dev/null | md5sum Was aber dann die falsche md5sum Nummer ist. dd if=/dev/mmcblk0p17 bs=256 count=$(( 22282240 / 256 )) 2>/dev/null | md5sum Was ja jetzt die gleiche md5sum Nummer ist. Damit wird es dann doch 1zu1 kopiert. Verstehe ich das jetzt richtig. Was mich aber wundert, wie kommt es, dass ich mmcblk0p17 benutzen muss |
|
fit-image.zip |
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 Im Gegensatz dazu sieht das bei diesen Modellen hier so aus: Die Installation erfolgt hier also IMMER in das "andere" System ( Auch beim Update über das GUI (egal ob mit AVM- oder eigener Signatur) erfolgt in der 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 Diese Abfolge Daher tendiere ich eher dazu, daß sich das 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 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 Wenn ich die vorläufige Version fertig habe, melde ich mich hier wieder ... der erste Test bräuchte ohnehin nur das Kopieren der Skript-Datei und den Aufruf aus einer Shell heraus - dafür muß man nicht jedesmal ein neues Image bauen. |
|
Hier noch der Vollständigkeit halber die Partitionierung des eMMC-Speichers:
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 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 Wenn Du noch weitermachen willst, könntest Du noch ein Auch würde ich Dir durchaus eine Kopie des Bootloaders (einfach mit Ich gehe zwar ohnehin davon aus, daß auch hier der Wert für Wenn ich aus dem Bauch heraus raten sollte, würde ich aber auf EINE Kopie in |
|
grep wlan_key /dev/mmcblk0p2 grep wlan_key /dev/mmcblk0p13 grep wlan_key /dev/mmcblk0p14 cmp -l /dev/mmcblk0p13 /dev/mmcblk0p14 Mail ist raus |
|
Erinnert mich an die Probleme mit defekten NAND-Blöcken ... der verbliebene Code in Dafür müßte man es noch einmal mit Eigentlich sollte das ja jetzt mit |
|
Ist dasselbe Gerät. Ich sollte dazu auch sagen, dass die FW 7.39 ein ganz neuen Kernel hat |
|
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. |
|
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. |
|
Ich bekomme hier noch ein Föhn 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 cat /proc/mtd So wenn in beiden Slots 7.39 ist, geht der BM nicht cat /proc/mtd FW 7.31 |
|
Dieses komische Hab den BM mit der neuesten 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? |
|
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 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 /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.
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 |
|
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" |
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 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:
oder auch nach der GPLv3:
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? |
Du hast schon gesehen dass der in meinem Repo ist? Hab leider vergessen das auch auf privat zu stelln. Wie gesagt war der patch nicht getestet. Wollte ich eigentlich, aber fitdump will nicht: PeterPawn/dtc@4cf7eaf |
Gleiche antwort wie gestern oder vorgestern: Ne. Davon kannst du fast immer ausgehen
worin? ein einem script? einem repo? eine einzelne funktion?? |
Probleme mit dem "verstehenden Lesen"? Hier: YourFritz/bootmanager/bootmanager Line 251 in ce04c85 YourFritz/bootmanager/bootmanager Line 303 in ce04c85 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 Da meine Glaskugel gerade zur Inspektion ist und es bei mir unter openSUSE Tumbleweed mit diesem beim simplen Aufruf von (ermittelt mit Es KANN ja nicht so simpel sein, daß da einfach der Rückgabewert von 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 Wobei ich jetzt ohnehin SCHON WIEDER irritiert bin ... nachdem Du das, was |
|
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. "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. Wie schon merhfach gesagt were ich daran nichts patchen (pr oder patch selbst ausgenommen). Daher gehst DU hier hin: https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/yf-bootmanager-host/yf-bootmanager-host.mk#L1= Die Tage hab ich während ich mit hippie lustig im irc geschrieben hab entdeckt, dass er wieder mal scheisse auf sein Seite verbreitet: 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! Beim bootmanager-patch gibt es noch Fehler, es wird die Version des akuellen System angezegt. Die Uhrzeit passt dagegen
|
|
Die "andere Version" könnte doch passen, wäre plausibel ^^ |
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: 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.
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 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 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 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 Da, wo es eben KEINE so enge Verzahnung zwischen den Funktionen gibt (z.B. bei allem unterhalb von
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. |
|
Aha. Was ist nun die Antwort? |
|
5590: |
|
Ich weiß zwar nicht, was du geändert hast beim Bootmanager in freetz, aber der lauft nun nicht mehr auf der 6000. |
|
Was hab ich 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 |
|
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. |
bullshit Kümmer dich darum das mit peter zu klären |
|
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 |
|
In Freetz ist die aktuellste 0.8.3 : https://github.com/PeterPawn/YourFritz/blob/main/bootmanager/TODO.md
Mir fällt leider keine Antwort ein die man hier schreiben sollte |
|
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 |
|
Bist du zu dumm um zu verstehen dass sich bezüglich BM seit 2 monaten nichts relevantes geändert hat? |
|
@PeterPawn
|
|
Vielleicht waren die doch nicht so schlecht?
|
|
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 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: Das habe ich als "Aufgabe" also auch noch auf dem Schirm, aber nicht im Moment (ich muß erst mal mein 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. |
Bootmanager funktioniert nicht mit "FIT" Geräten: Freetz-NG/freetz-ng#465 (comment)
Hast du geplant das zu unterstützen?
The text was updated successfully, but these errors were encountered: