[BobW]

Hallo,

ich habe mir in meiner 64-bit Trusty Tahr Entwicklungsumgebung mehrere ISOs bauen lassen und anschließend versucht, diese unter VMware zu installieren. Kein Erfolg, das Netzwerk kam nicht hoch, kein eth0.
Auch das Hinzufügen der network-drivers brachte keinen Erfolg.

Zunächst dachte ich, VMware wäre schuld, aber der Installationsversuch eines heruntergeladenen Standard-ISOs funktionierte einwandfrei.

Dann habe ich es auch ncoh auf unter MLD-4 funktionierender Hardware mit meinem Standard-ISO versucht, ebenfalls ohne Erfolg, kein Netzwerk.

Mit der Option "textmode" beim Booten kam dann folgende Fehlermeldung bei jedem Versuch eine Bibliothek zu installieren:

Not selecting libc6 2.19 as it would break existing dependencies

Mein Entwicklungssystem ist auf aktuellem Stand, die MLD-4 habe ich heute Morgen neu geholt.
gcc: gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2

Schöne Grüße aus Wien
BobW

[MegaX]

Hi

Das liegt anscheinend an der libc6.

Schau mal welche Version auf deiner Devel installiert ist und versuch danach mal raus zu bekommen ob irgendein MLD Paket vielleicht eine andere Version der libc6 braucht.

[clausmuus]

Hi,

Du kannst nicht einfach nur ein Teil der Pakete bauen, daraus iso auf Deinem Devel PC bauen und anschließend Pakete vom MLD Server installieren. Das ist nur dann möglich, wenn Du zuvor nen upgrade durchführst, damit alle nötigen Pakete vom MLD Server kommen.
Als Alternative könntest Du einstellen, das die zusätzlichen Pakete nicht vom MLD Server, sondern von Deinem Devel PC kommen sollen.

Claus

[BobW]

Hallo Claus,

willst Du damit sagen, dass ein

make collection=standard

im ISO-Verzeichnis zwar ein Image erstellt, dieses dann aber nicht zur Installation verwendet werden kann?

Denn genau so habe ich das image bauen lassen. Ich hoffe doch, dass wir einander hier bloß missverstanden haben.

BobW

[clausmuus]

Du hast recht, da hatte ich Deinen ersten Post falsch verstanden.

Nun habe ich allerdings keine Idee was da schief gelaufen sein könnte. Bisher gab's so nen Problem noch nicht.
In diesem Fall mach mal was megax geschrieben hat. Im Ordner MLD/libs/libc6 schauen welche Version das Paket hat, und dann unter MLD/initramfs/package/data/usr/lib/opkg/status schauen welche libc6 Version bei den Paketen erwartet wird und welche Version die dort eingetragene libc6 hat.

Claus

[BobW]

Hallo,

ich habe die Versionsnummer der libc6 nach MegaX/Claus' Angaben überprüft und festgestellt, dass diese nicht mit
MLD/initramfs/package/data/usr/lib/opkg/status übereinstimmt.

status verlangt: 2.19-10
generiert wurde: 2.19-11

Ich habe mittlerweile eine weitere Kopie aus dem git ausgecheckt, jetzt stimmt die Version überein und der Bootvorgang läuft weiter.

ABER Ich habe nach wie vor kein Netzwerk.

Ich habe dann die Dateien der beiden ISOs verglichen und festgestellt, dass auf dem lokal generierten ISO im Directory opkg eine Datei fehlt: libdbus-glib-1-2.opk.
Dieses Paket ist auf dem Entwicklungs-PC zwar vorhanden, wird aber nicht in das generierte ISO mitaufgenommen.

BobW

[clausmuus]

OK, ich hab ne neue Vermutung.

Wenn Du im Order ISO nen "make collection=standard" machst, wird die initramfs nicht neu gebaut. Sollte sich nun aber seit dem letzten bauen der initramfs ein paket das in der initramfs enthalten ist geändert haben, so wird in dem ISO weiterhin die alte Version dieses Paketes enthalten sein. Am ehsten fällt das negativ auf, wenn eines der lib pakete inzwischen um weitere libs erweitert wurde. Dann ändert sich die Version dieses lib Paketes und alle neuen Pakete die von dieser neuen lib Version abhängen lasen sich nicht installieren.
Dies dürfte Deinen Fehler erklären. Du musst also entweder im Ordner MLD ein "make iso" machen (das baut auch die initramfs neu), oder vor dem bauen eines bestimmten ISOs die initramfs neu bauen lassen.
Ich werde mal schauen ob ich das neu bauen der initramfs in das ISO Makefile mit einbauen kann, ohne den gesammten Build Prozess erheblich auszubremsen.

Uns ist dieses Problem bisher nicht aufgefallen, da wir meist im ersten Schritt alle Pakete bauen lassen, oder wenn ich gezielt ein bestimmtes ISO baue, auch (aus Erfahrung) weiß ob die initramfs aktualisiert werden muss, und dies dann gegebenenfalls manuell erledige.

Claus

[BobW]

Hallo,

ich habe in der Zwischenzeit nach Claus' letztem Post weitergemacht mit folgenden Schritten:

1. Neues git clone der MLD-4.0.1
2. Auflösen der Abhängigkeiten, wie im Wiki Entwicklung beschrieben.
3. Kompilierung der gesamten MLD mit make all

Dabei konnten 3 Pakete nicht kompiliert werden, nämlich das Plugin, über dasc wir hier nicht sprechen, vdr-plugin-dfatmo und makemkv. Immer war der Grund, dass die Quellen nicht verfügbar waren.
War nicht weiter schlimm, sie alle kommen in den ISO-collections nicht vor.

Das so entstandene standard ISO bootet nun, das Netzwerk wird eingebunden, der Webserver startet, VDR startet, nur das Frontend vdr-sxfe will nicht. Der Vorgang endet mit einem laufenden X-Server, wo ich über Rechtsklickmenü ein xterm starten kann.
Ein kurzer Test mit dem lokal erzeugten Server-ISO hat geklappt, das Problem liegt wohl irgendwo beim X-Server und seinen Treibern.

Im Anhang findet ihr die Logs aus /var/log für das lokale und das heruntergeladene Standard-ISO.

Ich hoffe, das hilft weiter.

Schöne Grüße aus Wien
BobW

[clausmuus]

Hi,

ich weiß ja nicht was Du da gemacht hast, aber vdr-sxfe will nicht starten, weil es nen Problem mit vdpau gibt. Normalerweise braucht xineliboutput kein vdrpa, sondern nimmt das nur wenn's auch verfügbar ist.

Claus

[BobW]

Hallo,

anscheinend resultieren die Probleme mit dem zickigen vdr-sxfe aus einem fehlenden Eintrag für die ffmpeg-Libraries in /etc/ld.so.conf.d. Mein Bug-Report #150 beschreibt das Problem für das standard-shd ISO, es gilt aber genauso für das standard ISO.

Der Vergleich mit dem heruntergeladenen standard ISO zeigt, dass im o.a. directory im lokal erstellten ISO die Datei ffmpeg.conf fehlt.

Nach der kleinen Änderung und einem make clean und make all funktionieren nun standard- und xbmc-ISO in der VM und standard-shd auf der VDPAU-Hardware wie erwartet.

Schöne Grüße aus Wien
BobW

[clausmuus]

Hi,

Welche libavutil Version verwendest Du? Auf unserem Devel Server ist das die Version libavutil52-ffmpeg. Solltest Du ne andere Version verwenden, so wird der ldconfig Eintrag leider nicht automatisch hinzugefügt.
Die Abhängigkeit von einer bestimmten Version ist nun behoben.

Claus

[BobW]

Hallo Claus,

erstmal Danke für die Reparatur. Jetzt funktioniert die Sache wie erwartet.

Und ja, Du hast recht, auf meinem Entwicklungssystem ist bereits die libavutil54-ffmpeg installiert.

Nachmals Danke.

Schöne Grüße aus Wien
BobW

[clausmuus]

Danke für die Analyse. So haben wir wieder einen Fehler weniger im System bzw. Makefile.

Claus