extract_version_values: grep-Fehler

[fda77]

Es gibt da noch 2 Schönheitsfehler abhängig von der libc in https://github.com/PeterPawn/YourFritz/blob/master/toolbox/image/extract_version_values#L166

7590 7.19:
applying patch file ./patches/scripts/800-modfs_boot_manager.sh
  adding modfs boot-manager
    adding boot-manager front end to branding "all"
Autodetection of target system version: 154.07.19
      Patching file 'usr/www/all/system/reboot.js' ...
      Patching file 'usr/www/all/system/reboot.lua' ...
    adding boot-manager back end script

7590 7.12:
applying patch file ./patches/scripts/800-modfs_boot_manager.sh
  adding modfs boot-manager
    adding boot-manager front end to branding "all"
grep: : Datei oder Verzeichnis nicht gefunden
grep: : Datei oder Verzeichnis nicht gefunden
Autodetection of target system version: 154.07.12
      Patching file 'usr/www/all/system/reboot.js' ...
      Patching file 'usr/www/all/system/reboot.lua' ...
    adding boot-manager back end script

Die kommen wohl von der libc-Erkennung

set -x
+++ find build/modified/filesystem/lib -maxdepth 1 -name 'libc.so*'
+++ sed -n -e 1p
++ readlink -f ''
+ libc_file=
++ printf %s '}'
++ sed -n -e 's|^.*/libuClibc-\([0-9\.]*\)\.so.*$|\1|p'
+ libc_version=
+ '[' -z '' ']'
++ grep -ao 'glibc [0-9]\+\.[0-9]\+' ''
grep: : Datei oder Verzeichnis nicht gefunden
+ check_glibc=
+ '[' -n '' ']'
++ grep -ao 'musl libc (' ''
grep: : Datei oder Verzeichnis nicht gefunden
+ check_musl=
+ '[' -n '' ']'
+ libc_project=unknown
+ libc_version=unknown
+ libc_ident=unknown

[PeterPawn]

Das muß aber auch mit Freetz zusammenhängen ... wenn ich das "normal" für eine 154.07.12 aufrufe, sieht das so aus:

vidar:/home/FritzBox/FB7590 $ /home/GitHub/YourFritz/toolbox/image/extract_version_values 154.07.12-69995/
Model="Fritz_Box_HW226"
Product="FRITZ!Box 7590"
Date="08.07.2019 12:08:01"
Version="154.07.12"
Subversion="-69995"
Buildnumber="69995"
Buildtype="1"
Brandings="1und1 avm"
Release="1"
BetaRelease="0"
LaborName=""
DirtyBuild=""
InstallType="mips34_512MB_grx5_dect446_5geth_2ab_isdn_nt_te_pots_2usb_host3_2wlan11n_hw226_29616"
KernelVersion="3.10.104"
LibraryProject="uClibc-ng"
LibraryVersion="1.0.14"
LibraryIdent="uClibc-ng-1.0.14"
BootType="rc.S"
PublicKey1="00e2d85346653d3e7f82d89857a300bd0714ca40bd5ef1e8bd2a43f6c42168f1aa1672d3b833eda7fd014460c9e2abc1f5c239f86dc7b18a7433102356e34e8e1a7cab229bdbad03d36a3c8ddd10d51a324f91d2132c7813bbfd07fce3c8b31f3f008eb5fe89dd7f9f5870500da8dbd91a749231ad6b3b4d6abc47545438f07f2b"
HWRevision='226' VersionMajor='154' Model='FRITZ!Box 7590' Name='avm_firmware_public_key1' Source='vendor' Modulus='00e2d85346653d3e7f82d89857a300bd0714ca40bd5ef1e8bd2a43f6c42168f1aa1672d3b833eda7fd014460c9e2abc1f5c239f86dc7b18a7433102356e34e8e1a7cab229bdbad03d36a3c8ddd10d51a324f91d2132c7813bbfd07fce3c8b31f3f008eb5fe89dd7f9f5870500da8dbd91a749231ad6b3b4d6abc47545438f07f2b' Exponent='010001'
PublicKey2="009e953a7bbfec194e66992b0f7d673c4a02c678c7a3f9ca70ee1f7c637aee3d849a81cd936e7bbdef34df19413aa5aff0798e37e33e3aa79a5b3c2e4b277e3f19aecb0111a73ee78a6db0c98b43081c3dbb2b9b86518297c7619f7df8b3c2436ef04e64c92fc9162223abb594cdc3d820ac422f42d78b423099d17d797a703acb"
HWRevision='226' VersionMajor='154' Model='FRITZ!Box 7590' Name='avm_firmware_public_key2' Source='vendor' Modulus='009e953a7bbfec194e66992b0f7d673c4a02c678c7a3f9ca70ee1f7c637aee3d849a81cd936e7bbdef34df19413aa5aff0798e37e33e3aa79a5b3c2e4b277e3f19aecb0111a73ee78a6db0c98b43081c3dbb2b9b86518297c7619f7df8b3c2436ef04e64c92fc9162223abb594cdc3d820ac422f42d78b423099d17d797a703acb' Exponent='010001'
PublicKey3="00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849"
HWRevision='226' VersionMajor='154' Model='FRITZ!Box 7590' Name='avm_firmware_public_key3' Source='vendor' Modulus='00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849' Exponent='010001'
vidar:/home/FritzBox/FB7590 $

Stellt sich halt die Frage, warum es im lib-Verzeichnis des neuen Dateisystems keinen Symlink für libc.so* gibt ... was nichts daran ändert, daß ich durchaus noch die Fehlermeldung unterdrücken könnte.

Wobei das bei mir (bzw. bei AVM) eben nie vorkommt, weil es immer mindestens eine libc.so gibt (durchaus auch mal zwei, nämlich .0 und .1 - daher noch das sed, um das auf eine Zeile zu beschränken).

Allerdings vermute ich fast, daß auch das hier eher ein "Folgefehler" aus der Verwendung von sed ist (und das find wahrscheinlich sogar funktioniert) - was dann wieder das Argument mit der "Ungewißheit", wer das noch alles benutzt, aus dem anderen Kommentar bestärken würde.

[fda77]

Ich habs. build/modified/filesystem/lib wird von deinem Script untersucht. Dieses Verzeichnis ist später das freetz-image. In build/original/filesystem/lib liegt die unveränderte avm-Firmware! Während "make" werden "Patches" (bootmanager!) angewendet und SPÄTER "libs" installiert (ruf einfach mal make auf) Aber für bootmanager sollte die libc egal sein

[PeterPawn]

Dann reicht der Patch, den ich schon eingecheckt habe, ohnehin aus - dann bleibt's eben bei "unknown" für die Libs.

Wobei das nichts daran ändert, daß in extract_version_values nach wie vor sed verwendet wird ... und das Skript ändere ich auch definitiv nicht ab, das wird an viel zu vielen Stellen verwendet und ich habe auch nicht die Absicht, bei jeder weiteren Änderung an diesem Skript, die dann ggf. wieder den Einsatz eines sed erfordert, daran zu denken, daß ich anstelle von sed jetzt eine Variable nehmen soll/muß.

Ich würde also fast wetten, daß auch die Verwendung von sed im Rest von extract_version_values scheitert - dann mußt Du Dir eben einen Weg überlegen, wie Du das in dem Patch-File (800-irgendwas in scripts bei Freetz) passend setzt. Das wäre auch die Stelle, wo man das Ganze dann auf das "original"-Directory ansetzen müßte - das hat mit dem YourFritz-Repo nichts mehr zu tun.

--

Da beim Kopieren nach modified auch die originalen Libraries von AVM mitkopiert werden, sollten die auch IMMER schon vorhanden sein für den Test - damit würde ich eher Wetten abschließen, daß auch hier eben sed das Problem ist und nicht das Verzeichnis, in dem die Variablen ermittelt werden und daß sich nichts ändert, wenn man da das originale Verzeichnis verwenden würde.

[fda77]

Die uClib mitkopiert? Freetz ersetzt die doch normal* Deshalb spielt die Reihenfolge Patches > libs ne Rolle :D Die seds sind okay, da nur "sed -i" problematisch ist

*freetz=immer ng=manchmal

[PeterPawn]

Die uClib mitkopiert? Freetz ersetzt die doch normal*

Wo siehst Du hier denn den "Ausschluß" irgendeiner Library oder gar des ganzen lib-Verzeichnisses beim Kopieren nach modified?

https://github.com/Freetz/freetz/blob/master/fwmod#L680

Dann müßte man eben doch noch einmal nachsehen, warum da auf einmal $libc_file leer ist - bei der AVM-Firmware gibt es die Symlinks jedenfalls (s.o.) und ein anderer Grund als "fehlende Dateien" fiele mir dann nicht mehr ein, denn das anschließende sed ist auch nichts anderes als ein head -n 1 (nur daß ich auf das Kommando head bewußt verzichte).

[fda77]

 l patches/scripts/*ucli*
-rw-r--r--. 1 user users 1460 14. Mai 18:52 patches/scripts/140-remove_uclibc.sh

140 ist kleiner als die 800 von 800-modfs_boot_manager.sh

Den vermeiden von head -n1 fiel mir schon auf, und hab mich gefragt ob du das nicht kennst :D

[PeterPawn]

Ich weiß schon, warum ich kein Freetz-Image verwende ... was soll denn der Unsinn?

Ich würde es ja noch verstehen, wenn man das unmittelbar vor dem Kopieren der eigenen Libraries macht, weil man sich nicht traut, da einfach zu ersetzen und nur das, was über ist, zu löschen (was genau 0 Dateien zum Löschen ergeben sollte, weil die AVM-Komponenten ja immer noch eine der Bibliotheken verwenden könnten, die Freetz nicht ersetzt).

Aber das vom Rest "abzusetzen", macht für mich so gar keinen Sinn und ich bin mal auf eine plausible Erklärung gespannt, warum das nun genau da erfolgt.

Wobei dieses Löschen ja dann zu Deiner vorherigen Frage:

Die uClib mitkopiert?

genausowenig paßt, wie zu meiner Annahme, daß die Library noch die aus "original" wäre - denn mitkopiert werden sie ja tatsächlich.

Aber es ist ohnehin egal ... die neue Version von extract_version_values kann auch damit umgehen, daß das find gar keine Datei findet: https://github.com/PeterPawn/YourFritz/commit/8d6ece9d7a7901bd0eb216a1e890ba3f0220e336 und eigentlich sollte das sogar zuvor schon funktioniert haben, wenn man mal von den zwei Fehlermeldungen absieht, die aber am Ende keine Auswirkungen haben sollten.

Und daß ich in der add_to_system.sh das extract_version_values auf das angegebene Zielverzeichnis ansetze und nicht auf irgendein anderes, ist ja sicherlich auch mehr als nachvollziehbar - dieses Verhalten von Freetz, daß zum Zeitpunkt des Patches das lib-Verzeichnis am Ziel nicht komplett ist, ist ja wohl kaum als Normalfall anzusehen. Wenn das unbedingt erforderlich sein sollte, die "alten" Bibliotheken vorher zu löschen, dann macht das als 999-irgendwas vielleicht mehr Sinn - aber ich lasse mich ja auch noch von einer guten Begründung für den Zeitpunkt und warum das genau da sein muß, überraschen.

EDIT: Wenn ich Freetz auf "musl" anpassen müßte (für die 154.07.19), würde ich mir solche Späße in jedem Falle schenken - immer noch unter der Annahme, daß das "halt nun mal so ist" und es ansonsten eigentlich keinen Grund dafür gibt, diesen 140-irgendwas-Patch zu haben.

[PeterPawn]

Den vermeiden von head -n1 fiel mir schon auf, und hab mich gefragt ob du das nicht kennst

Hast Du schon mal eine BusyBox von AVM gesehen, wo ein head-Applet enthalten war?

Das soll/muß nun mal auch auf der Box funktionieren und mit originaler Firmware von AVM - ein paar der letzten Änderungen daran waren sogar explizit für den Fall, daß das System unter / untersucht werden soll: https://github.com/PeterPawn/YourFritz/commit/b2e55943d33d81318c5624202a03f2f3c53e038b

Da kann das head noch so POSIX-kompatibel sein ... solange es bei AVM nicht zu finden ist, kann/will ich es auch nicht verwenden.

Wie auch immer ... das Thema ist nun auch für mich gegessen und ich mache hier mal zu. Der Patch ist online und wenn $libc_file leer ist, wird gar nicht weiter versucht, die C-Library irgendwie festzustellen, geschweige denn, ihre Version zu ermitteln.

Das ist bei der Installation des Boot-Managers auch nicht notwendig - es wird nur die (exakte) Version des Ziels gebraucht und da es dieses Ermitteln schon gab und es bei mir auch schon oft eingesetzt wurde (auch in unveröffentlichten Skripts, daher manchmal auch ein Update "aus dem Nichts" und nur dafür, weil das praktisch ein "Vorabdruck" ist/war), wird es hier wiederverwendet. Zu viele Daten kann man ignorieren, nur zu wenige sind ein Problem.

[fda77]

Danke! Warum die mit dem Script gelöscht werden? Keine Ahnung, ich war das nicht :) Bei der Labor gab es keine grep-Fehler, da bei diesen die libc erhalten bleibt (LIBCTEST) Wie im OP geschrieben "Schönheitsfehler", funktioniert hat es ja, Ich geh solchen Fehlermeldungen halt nach AVM's busybox hat kein head? Hab ich nie bemerkt, ich benutze immer die von Freetz

[PeterPawn]

Die seds sind okay, da nur "sed -i" problematisch ist

Hättest Du das gleich deutlich geschrieben, hätte ich es auch gleich anders gelöst.

Ich bin mit einen sed -i ohnehin nicht immer glücklich, weil das keine POSIX-kompatible Syntax ist - dort gibt es kein -i: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html#tag_20_116

Das war also ohnehin ein Kandidat für eine der nächsten Runden, wenn es um bessere POSIX-Kompatibilität geht und ich immer mal wieder Kleinigkeiten ändere (bis hin zum echo -e, weil das auch nicht POSIX ist).

Dann sollte die jetzt eingecheckte Version ja auch funktionieren, ohne daß ich die SED-Variable verwenden muß bzw. ohne daß ich überhaupt den sed ersetzbar mache. Am mv danach wird's ja hoffentlich nicht scheitern und am Ende ist das sed -i intern ja auch nichts anderes, weil das erst mal die neue Datei schreiben muß, während die alte noch existiert und erst hinterher wieder "Ordnung" gemacht wird.

[fda77]

Dachte du weisst das :) Nicht in die 2 Links zu den alten Fehlerbeschreibungen im Trac und freetz-Github geschaut? "sed -i" erstellt ne neue Datei, schiebt sie über die alte >und stellt den se-context wieder her< der nicht gelesen werden konnte, das fakeroot gibt nichts zurück. Lösung: sed mit ohne-selinux compilieren oder pseudo nehmen, das selinux unterstützt

$ echo abc > x

$ getenforce
Enforcing

$ ls -lZ x
-rw-r--r--. 1 user users unconfined_u:object_r:user_home_t:s0 4 30. Mai 00:45 x

$ fakeroot ls -lZ x
-rw-r--r-- 1 root root ? 4 30. Mai 00:45 x

$ sed 's/x/y/' -i x

$ fakeroot sed 's/x/y/' -i x
sed: Warnung: Sicherheitskontext von x konnte nicht ermittelt werden: Keine Daten verfügbar$

Wie ich das sed in fwmod+co ersetze muss ich noch schauen, Variable, hash, path,...