Duo4K - NI-Buildsystem

[Janus]

Mit gerade aktualisiertem BS und neu angelegter config.local für die Duo 4K
während "make neutrino":

if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \
(cd ..; make libcrypto.so.1.0.0); \
fi
[ -z "" ] || arm-cortex-linux-gnueabihf-gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -pipe -O2 -g -march=armv7ve -mtune=cortex-a15 -mfpu=neon-vfpv4 -mfloat-abi=hard -I/home/janus/development/ni/build/root/include -DTERMIOS -fomit-frame-pointer -DOPENSSL_SMALL_FOOTPRINT -O2 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -Iinclude \
-DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso \
fips_premain.c fipscanister.o \
libcrypto.a -lcortex-strings -Wl,-O1 -Wl,-rpath,/home/janus/development/ni/build/root/lib -Wl,-rpath-link,/home/janus/development/ni/build/root/lib -L/home/janus/development/ni/build/root/lib -ldl
/home/janus/development/ni/build/cross/arm-linux-4.1.45-1.17/lib/gcc/arm-cortex-linux-gnueabihf/6.5.0/../../../../arm-cortex-linux-gnueabihf/bin/ld: cannot find -lcortex-strings
collect2: error: ld returned 1 exit status
Makefile.shared:169: recipe for target 'link_a.gnu' failed
make[5]: *** [link_a.gnu] Error 1
Makefile:358: recipe for target 'do_linux-shared' failed
make[4]: *** [do_linux-shared] Error 2
Makefile:311: recipe for target 'libcrypto.so.1.0.0' failed
make[3]: *** [libcrypto.so.1.0.0] Error 2
Makefile:111: die Regel für Ziel „shared“ scheiterte
make[2]: *** [shared] Fehler 2
Makefile:288: die Regel für Ziel „build_crypto“ scheiterte
make[1]: *** [build_crypto] Fehler 1
make/target-libs.mk:341: die Regel für Ziel „openssl“ scheiterte
make: *** [openssl] Fehler 2

[vanhofen]

Einmal "make clean" bitte. Dann werden die cortex-strings gebaut.

Eigentlich dachte ich, das schon vor Ewigkeiten repariert zu haben, aber es kommt 1. immer anders als man 2. denkt.

[Janus]

Danke, hat durchgebaut!

Bin ganz gespannt auf die neuen Treiber...

[Janus]

Gibt es im NI-BS eine Option in config.local mit der man die gewünschte Treiberversion vor dem Build festlegen kann ?
Ich wollte mal ein Image mit der 'neuen' Version estellen und damit die Probleme mit dem Sat-Scan und nachfolgendem Betrieb bei meinem S2X FBC-Tuner einkreisen.
(alte Treiber = alle TS außer Multistream > neue Treiber = Multistream aber nur 50 bis 75% der anderen TS)

Im DDT-BS gibt es per make.sh einen Code-Block wo man zwischen "old" und "new" wechseln kann.
BP stellt ein "experimental" Image mit den neuen Treibern online. Aus lauter Gewohnheit würde ich lieber im NI weiterwurschteln und dort die beiden Selfmade-Versionen im Log gegenüberstellen.

Besser wäre vielleicht eine Build-Konstante mit dem Driver-Datum.
DUO4K-DRIVERS=tt.mm.yy

Sonst würde ich das im BS in einem eigenen Branch editieren müssen...


Ach ja,
in dem Tool Komplett-Backup für das Image scheint ein Fehler zu sein.
rootfs.tar.gz2 wird zwar gebildet, aber zu guter Letzt nicht in die Gesamtdatei übernommen.
(Größe der Backup-Datei etwas über 4 MB - entspricht in etwa der Kernelgröße)

Bei Versuch des "Wiederherstellens" in einer anderen Partition wird nur halt nur der Kernel geflasht.

[BPanther]

Zum Full-Backup: Aktuelle Version 1.20 genommen? Ich mache das bei mir im Image alle paar Updates und es funktioniert. Oder es ist im NI was anders - ggf. serielles Log auch anschauen falls nicht schon im OSD dargestellt.

[Janus]

Wie der Thread-Titel nahelegt:
Ich habe den Fehlerhinweis absichtlich hier gepostet.

[vanhofen]

Ich schaue mir beides an. Backup-Script und Treiber im Buildsystem.

[vanhofen]

Gibt es im NI-BS eine Option in config.local mit der man die gewünschte Treiberversion vor dem Build festlegen kann ?

Ja, natürlich gibt es die. ... Seit ungefähr 5 Minuten.

In config.local folgende Zeilen hinzufügen:

Code: Alles auswählen

# use lastest VU+ drivers
VUPLUS-DRIVERS_LATEST = yes

[vanhofen]

in dem Tool Komplett-Backup für das Image scheint ein Fehler zu sein.
rootfs.tar.gz2 wird zwar gebildet, aber zu guter Letzt nicht in die Gesamtdatei übernommen.
(Größe der Backup-Datei etwas über 4 MB - entspricht in etwa der Kernelgröße)

Wir haben die letzte Version 1.20 im Image.

Code: Alles auswählen

# Script for complete image backup
# License: GPLv2 or later
Version="1.20 vom 20.03.2020"
Copyright="(C) 2018-2020 DboxOldie / BPanther / Frankenstone / Fritz"

Uns fehlen aber ein paar Tools, die das Script benötigt. Ich schaue mal, ob ich die heute noch hinzugefügt bekomme.

[vanhofen]

Nee, hab Quatsch erzählt. Das Script funktioniert hier auf der HD51. Ich war erst der Meinung, /bin/xxd fehlt, aber das Tool ist nicht zwingend nötig.
Das Archiv m1-imgbackup-hd51_23.07.2020-22.05.tgz, welches mir in /tmp erzeugt wurde, hat alles drin.

Starte doch mal bitte /share/tuxbox/neutrino/plugins/imgbackup.sh an der Konsole und poste die Ausgabe. Am TV ist das Script nicht besonders geschwätzig.

[BPanther]

Jupp, es werden hexdump und xxd abgefragt. Wir haben normalerweise hexdump in Neutrino mit bei, E2 hingegen nicht, daher hatte ich xxd noch hinzugefügt als Alternative, falls man unter E2 ein Backup machen will. Nur wenn beides nicht vorhanden ist, wird eine Kernel-Standardgröße von rund 5 MB angenommen. Fehlt hingegen bzip2 wird komplett abgebrochen.

[Janus]

imgbackup auf der HD51 => Okay (kernel und rootfs) auch über das UI
imgbackup auf der Duo4K => Nur Kernel --> identisch mit dem berichteten Ergebnis über UI

In beiden Fällen Partition 1 nach /tmp gesichert!
Im zip sind beide Logs:

ImgBakLogs.zip

(1.42 KiB) 220-mal heruntergeladen

Ich habe hier noch ein Log per setconsole und LogDetails="Informativ".
Das gibt aber nichts Weiteres her. Sind nur zusätzliche Ausgaben der Components drin.

[BPanther]

Die Ausgabe zeigt, daß bzip2 bei der Duo4K nicht packen kann, der Rest sind Folgemeldungen. Versuche das Image mal auf HDD/Stick zu erstellen.

EDIT: Habs gerade nochmal getestet, funktioniert hier problemlos mit der Duo4K. Ist also irgendwas mit bzip2.

[Janus]

Na ja, ich habe dann mal weiter getestet.
Mit dem BPanther experimentell 18737 geht es auch nicht!

Allerdings nur dann nicht, wenn man es wie ich nach /tmp sichert.
(weil ich es am Testplatz sowieso auf den PC kopiere)
Ich habe unter dem oben genannten - aktiven - BP-Image alle 4 Partitionen auf den USB-Flash gesichert.
Das hat dann einwandfrei funktioniert. Genauso, wie bei dieser Vorgehensweise auch mit dem NI.

Der Fehler scheint dann eher an der neueren Einstellungsoberfläche in der Option für /tmp zu liegen.
Mein Verdacht: Die zweite "Aufforderung" mit wiederum /tmp zu beantworten, führt in Folge zu Verwirrung des Scripts.
Und das in beiden Images...

p.s.
In der Einstellungsoberfläche #2 tauchen auch "Dateien" auf, nicht nur Ziel-Verzeichnisse.
Dadurch wird das ein wenig unübersichtlich. Vielleicht auch fehleranfällig ?!?

[BPanther]

Nach /tmp kann man kein E2 sichern, das passt da garnicht rein. Mein Neutrino hingegen läßt sich auch nach /tmp sichern, ohne Probleme. Natürlich aber auch dabei nur immer ein Image aus Platzgründen, dann aus /tmp wieder entfernen und dann das nächste sichern.

Achja - und nein, es werden nur Verzeichnisse gelistet, keine Dateien.
Org. Verzeichnisinhalt /tmp bei mir:

Code: Alles auswählen

vuultimo4k:~# ls -al /tmp
drwxrwxrwt    7 root     root           600 Jul 30 00:07 .
drwxr-xr-x   16 1000     1000          4096 Jul 29 23:44 ..
-rw-r--r--    1 root     root             0 Jan  1  1970 .clean
-rw-r--r--    1 root     root             1 Jul 29 23:47 .lcd4linux
drwxr-xr-x    2 root     root            40 Jul 29 23:47 .logo
drwxr-xr-x    2 root     root            80 Jul 29 23:53 .oscam
srwxrwxrwx    1 root     root             0 Jul 29 23:53 camd.socket
-rw-r--r--    1 root     root           208 Jul 30 00:07 ecm.info
-rw-r--r--    1 root     root            16 Jan  1  1970 ifstate
-rw-r--r--    1 root     root             5 Jan  1  1970 inetd.pid
drwxr-xr-x    2 root     root           620 Jul 30 00:06 lcd
-rw-r--r--    1 root     root             5 Jul 29 23:47 lcd4linux.pid
srwxr-xr-x    1 root     root             0 Jul 29 23:47 luaclient.sock
-rw-rw-rw-    1 root     root            55 Jan  1  1970 mdev.log
drwxr-xr-x    8 root     root           160 Jan  1  1970 mnt
-rw-r--r--    1 root     root             0 Jul 30 00:06 msgbox.tmp
srwxr-xr-x    1 root     root             0 Jul 29 23:47 neutrino.sock
srw-rw-rw-    1 root     root             0 Jan  1  1970 nxserver_ipc
-rw-r--r--    1 root     root           518 Jul 30 00:07 oscam.lcd
-rw-r--r--    1 root     root           518 Jul 30 00:07 oscam.lcd.tmp
-rw-r--r--    1 root     root             5 Jan  1  1970 portmap.pid
-rw-------    1 root     root             0 Jan  1  1970 portmap_mapping
-rw-r--r--    1 root     root             1 Jul 30 00:06 rc.locked
drwxr-xr-x    3 root     root            60 Jan  1  1970 rw
srwxr-xr-x    1 root     root             0 Jul 29 23:47 sectionsd.sock
srwxr-xr-x    1 root     root             0 Jul 29 23:47 timerd.sock
srwxr-xr-x    1 root     root             0 Jul 29 23:47 zapit.sock

Und hier die Auflistung von msgbox:

[Janus]

und nein, es werden nur Verzeichnisse gelistet, keine Dateien

Na ja, wenn bei Dir .oscam und .logo Verzeichnisse sind und ein sendsigs.omit.d?? keine Datei würde ich Dir in diesem Fall recht geben. Bei mir waren es - in einem speziellen Backup-Verzeichnis - die "gepackten" Files, die ja irgendiwe auch Verzeichnisse darstellen, wenn man sie auspackt. Sind aber trotzdem kein Zielverzeichnis für Backups...

Und ein E2 in einem Multiboot-System über ein Neutrino-Script zu sichern würde mir wirklich nicht einfallen. Schon garnicht, damit dann einen Fehler zu melden ohne das zu erwähnen.

Bleibt mein gescheiterter Versuch, ein Neutrino-Image aus der aktuellen Multiboot-Partition nach /tmp(/tmp) zu sichern. Das geht bei mir leider nicht! Aber vielleicht habe ich hier ja auch wieder mal alten Strom...

[BPanther]

Genau deswegen habe ich den Telnetbefehl zuvor mit gezeigt, denn dort sieht man doch auch, daß es Verzeichnisse sind. Kann man sich aber auch mit dem MC anschauen wenn man mit Telnet nicht viel anfangen kann. sendsigs.omit.d ist ein Verzeichnis, unter /tmp/rw zu finden wie man auch im msgbox-Shot sieht.

Und nochmal wegen dem scheinbaren 2x /tmp. Das erste mal ist das eigentliche Verzeichnis was gewählt wird, das 2. mal ist in dem Fall nur die Bestätigung das man das direkt will und nicht noch weiter darunter eins wählen will. Es wird also somit nur /tmp letztlich übergeben und kein /tmp/tmp. Wäre das nämlich so, würde das Backup aufgrund des nicht vorhandenen Verzeichnisses direkt scheitern und nicht erst später beim ein- bzw. umpacken. Ansosnten wäre beim 2. mal ein Unterverzeichnis in /tmp noch wählbar bevor es dann direkt zum Backup geht.

Ein E2 kann man durchaus sichern, nur eben nicht in /tmp, aber auf Stick/HDD. Auch das klappt ohne Probleme, sowohl von E2 aus (da aber nur E2 selbst) oder auch von Neutrino aus (hier alle 4 Partitionen möglich). Ich würde allerdings E2 nur von Neutrino aus sichern, damit es keine Fehlermeldung beim Start von E2 gibt weil es noch lief und nicht korrekt beendet war. Diese Meldung sieht man auch, wenn man mit E2 selbst sichert und es wieder zurückspielt.

Was da bei Dir nun das Problem ist kann ich leider nicht sagen, ich kann es hier nicht nachvollziehen.

[Janus]

auch mit dem MC anschauen, wenn man mit Telnet nicht viel anfangen kann

Leider kann ich mit mc nicht viel anfangen! Zu der Zeit bin ich längst im Bett.
Aber sonst komme ich eigentlich schon ganz gut zurecht.

Was da bei Dir nun das Problem ist kann ich leider nicht sagen, ich kann es hier nicht nachvollziehen.

Das habe ich schonmal irgendwo gelesen.

Aber vielleicht kann ich es im NI-BS selber fixen. Ist jetzt eh wieder auf der Box.
Wenn es nur Script ist: Schreiben kann ich ja...

[BPanther]

MC ist der Midnight Commander, so wie früher unter DOS (und später Win) der Norton Commander, Volcov Commander, File Commander, DOS Command Center, Total Commander oder wie auch immer sich die NC Derivate dann alle nannten. Sollte daher eigentlich alt bekannt sein.

Wenn es nur bei NI nicht gehen würde könnte man evtl. sagen, daß es Probleme mit bzip2 (z.b. das der BB) benutzt wird. Aber wenn auch ein Backup meines Neutrino oder OATV-E2 nicht funktioniert ist das Problem bei Dir eher ein anderes.

[vanhofen]

Wir haben das bzip2 der Busybox im Image. Auf der HD51 tut das bei Janus ja auch, was es soll. Vielleicht ist im RAM der VU einfach nicht mehr genug Platz. Hast du mal versucht, das Image auf einem Stick oder so zu packen, Janus?