[purzel]

Hallo Entwickler!

Ich habe mir im Wiki den Artikel "Aufsetzen der Entwicklungsumgebung x86-64 =64 Bit und i686 =32 Bit (PC)" angesehen.
Da heißt es unter Anderem:

Tipp    Beim Paket vdr und kernel ist es möglich, die vom vdr oder kernel abhängigen Pakete (z. B. beim vdr die plugins) neu bauen zu lassen, ohne dass diese neu kompiliert werden müssen (Beispiel vdr):

cd vdr
make all_depends

Da ich ja immer noch auf das Plugin RCU hoffe, habe ich mir mal die Sourcen von VDR von Klaus' Seite geladen. Das Target 'all_depends' gibt es in seinem Makefile gar nicht. Habt Ihr für MLD was gravierendes geändert?

In Klaus' Makefile werden offenbar mit make all auch die "VDR-eigenen" Plugins (epgtableid0, dvbsddevice, servicedemo, pictures, svdrpdemo, status, dvbhddevice, hello, osddemo, skincurses, rcu) gebaut.

Ich habe ehrlich gesagt zu wenig Ahnung von C/C++ um "richtiger" Entwickler zu werden (nur ein paar Grundkenntnisse); System-Kram könnte ich ggf. schon beisteuern. Da ich also erstens kein Entwickler werden will bzw. kann und zweitens mir nur sehnlich das RCU-Plugin wünsche, hier meine Bitte an die "echten" Entwickler: Packt es doch in ein (OPKG-)Paket, es scheint ja ohnehin mitcompiliert zu werden... (Oder habe ich irgendwas grundlegend falsch interpretiert?)

Herzlichen Dank im Voraus sagt

  purzel

[clausmuus]

Hi,

das Plugin wird nicht sowieso mit kompiliert. Wir lassen nur das bauen, was auch als Paket angeboten wird.
Und das vdr Makefile ist nen anderes, als die Makefiles, welche für jedes einzelne Paket existieren. Unsere Makefiles, rufen also wieder andere Makefiles auf, wie z.B. das VDR Makefile, damit dieses wiederum en Makefiel für nen Plugin aufruft.

Was das rcu betrifft. Da das für die MLD-3 bereits existierte, haben wir Hilfsmittel erstellt, mit denen sich das größtenteils automatisch in ein MLD-4 Paket übertragen lässt. Ich hab das nun mal eben gemacht. Das Paket steht nun zur Verfügung.

Claus

[purzel]

Herzlichen Dank Claus!

Ich wollte es installieren, das System mäkelt aber dependencies an:

Code: [Select]

Not selecting vdr 2.1.10.159 as installing it would break existing dependencies.
Not selecting vdr 2.1.8.153 as installing it would break existing dependencies.
Not selecting vdr 2.1.10.159 as installing it would break existing dependencies.
Not selecting vdr 2.1.8.153 as installing it would break existing dependencies.
Ich traue mich aber noch nicht so recht, auf AKTUALISIERUNG [ x ] Alle Pakete zu klicken, wegen der eventuell auftretenden Probleme. Zunächst will ich ein Backup machen...

Ist es übrigens ein Bug im WebIf, dass teilweise SYSTEM PAKETE und VDR PLUGINS doppelt angezeigt werden? Es handelt sich um solche, die ich installiert habe. Beispiel:

[ x ] osdteletext

[  ] osdteletext
Teletext via OSD

Nachdem ich beispielsweise das Paket "USB" wieder deinstalliert hatte, war es auch nur noch einmal in der Liste.

Gruß
purzel

[clausmuus]

Ne, die doppelten Pakete sind nen Fehler im opkg Paketmanager. Falls mein hot fix funktioniert, sollte nen update der Paketliste die doppelten Einträge aus der Liste entfernen.

Claus

[purzel]

So....

Erstmal das Positive des Upgrade: die doppelten Einträge sind (bzw, waren, bitte weiterlesen) in der Tat verschwunden.
 
Ich habe vor dem Upgrade ein Backup gemacht (mit Clonezilla, ob das eine Sch*** Idee war, zeigt sich gleich) und "Update alle Pakete" im WebIf angeklickt. DAS war anscheinend ein Fehler:
Es kamen etliche Fehler, wenn gewünscht poste ich die mal alle, hier eine kleine Auswahl:
/etc/opkg.d/opkg-fixes: line 14: /etc/opkg-fixes.d/*: not found
Not selecting  <mehrere>  as installing it would break existing dependencies.
Removing obsolete file <etliche>
* opkg_lock: Could not lock /var/run/opkg.lock: Resource temporarily unavailable.
Irgendwann schien es aber geklappt zu haben, das die Liste endete (nach diversen downloads und Upgrades mit
Configuring <ein ganzes Rudel>.

Ich startete MLD neu und siehe da, die Option "Update alle Pakete" war immer noch möglich. Also nochmal. Dies' Mal bedeutend weniger Fehler(meldungen), jedoch des Öfteren
* opkg_lock: Could not lock /var/run/opkg.lock: Resource temporarily unavailable.
Irgendwas hat er aber geladen und installiert, anschließend konfiguriert. "Hurra!" dachte ich mir...

Leider kommen jetzt erstens beim Booten immer
grep: /etc/modprobe.d/nvidia-graphics-drivers.conf   No such file or directory
zweitens
opkg_lock: Could not lock /var/run/opkg.lock: Resource temporarily unavailable
und drittens bleibt die OSD-Anzeige des aktuellen Senders (die ja immer beim Start kommt) gefühlt "ewig" stehen - das war vor den Upgrades nennenswert kürzer. "Wegdrücken" (Backspace) kann ich es auch nicht.

Nun hoffe ich, dass ich mein Clonezilla-Backup wieder aufgespielt kriege - und bitte so, dass es auch bootet. Beim ersten Versuch klappte das nämlich nicht, der Bottsektor wurde anscheinend nicht wiederhergestellt (gesicht hat ihn Clonezilla aber, das habe ich gesehen)

Nun mal sehen, ob ich ein Restore hin kriege oder MLD neu installieren "darf"...

purzel

[pbriesch]

Hallo purzel,

hast du keine Snapshots im System? Die werden bei Updates normalerweise automatisch gemacht. Wenn MLD beim Hochfahren auf einen Tastendruck wartet, dann drück auch mal auf eine drauf. Dann kannst du einen älteren Systemstand auswählen und damit dann fortfahren.

Paul

[purzel]

Hallo Paul,

hast du keine Snapshots im System?

Nicht mehr, in diesem Fall: leider.
Ich habe die Snapshots ausgeschaltet, weil sie mir die Systempartition stetig voll laufen liessen. Bei jeder Installation und Deinstallation wird ja so ein Snapshot angelegt - was im Grunde 'ne sehr gute Idee ist (besonders in meinem jetzigen Fall).
Aber meine System-Partition ist nur 1GB und da musste ich etwas mit dem Platz geizen. Beim Experimentieren mit Plugins usw. ("Will ich das haben?") erschienen mir die Snapshots überflüssig. OK, ich wurde eines Besseren belehrt

Da nun aber weder das Upgrade noch das Zurückspielen den Clonezilla-Backups erfolgreich war, ich also neu installieren muss, kann ich auch neu partitionieren.
Kein Vorteil ohne Nachteil - und natürlich umgekehrt.

Bis dann,
purzel

[clausmuus]

Hi,

das einzige was mir hier Kopfzerbrechen macht, ist die Meldung "Could not lock /var/run/opkg.lock". Die sollte nie kommen. Die restlichen sind mehr oder weniger normal und sollten nach wiederholtem Ausführen des Upgrades nicht mehr auftreten.

Claus

[mikeM]

Hallo Claus,
die Meldungen mit dem "Could not lock /var/run/opkg.lock" hatte ich beim letzten Update meines "Haupt" VDRs auch. Da war das letzte Update schon etwas her (November). Ich musst auch mehrfach aktualisieren (auf der Console) und hatte am Ende doch noch ein paar Probleme:
1. Fernbedienung war nicht mehr funktionsfähig (lirc serial)
2. XBMC wurde nicht aktualisiert. Kodi tauchte zwar als App auf, aber nicht mal das alte .xbmc Verzeichnis war gelöscht. Gescheige denn lies sich Kodi starten.

Die FB habe ich nur durch das komplette entfernen und anschliessende neuinstallieren aller dazu gehörender Komponenten zum laufen bekommen. (MLD-Remote, lirc, eventlircd, lircd2uinput). Bei Kodi war es ähnlich.Auch hier opkg remove kodi, install kodi.

Ich denke, ich werde Updates künftig einfach häufiger auf dem Haupt VDR machen, damit sich die Versionen nicht so stark unterscheiden. Zumindest, bis es keine Devel mehr ist 

Gruß
Michael

[clausmuus]

Ich hab die Ursache für die "Could not lock /var/run/opkg.lock" Fehlermeldungen, bei der Suche nach nem anderen Fehler, gefunden, und auch behoben. Der Fehler konnte durchaus bei nem Upgrade dafür sorgen, dass anschließend die VDR Ausgabe nicht mehr funktioniert.

Claus

[purzel]

Guten Morgen allerseits.

Das ist ja schön, dass der Fehler mit dem lockfile auch behoben werden konnte. Herzlichen Dank.

Ich habe nun neu installiert (mit dem ISO vom 15.2.) und - wie es scheint - auch alle "meine" Plugins und Systempakete wieder drin, auch RCU. Irgendwas macht es wohl auch schon, im Log taucht auf, dass es /dev/ttyS0 nicht findet (was ja im Moment noch richtig ist). Ich hoffe, nachher mal Zeit für weitere Versuche zu haben...
Derzeit habe ich auch die Snapshots aktiviert
Der o.g. Fehler mit dem "ewigen" Stehenbleiben der Kanalinfo ist weg, ebenso wie die diversen anderen beschriebenen Fehler. Super, danke nochmal!

Einen kleinen Fehler beim Booten gibt es allerdings noch: er mäkelt immer noch eine fehlende Datei an, die beim Abarbeiten von /etc/init.d/modules erwartet wird:
grep: /etc/modprobe.d/nvidia-graphics-drivers.conf   No such file or directory
Das liegt wohl daran, dass der Symlink /etc/modprobe.d/nvidia-graphics-drivers.conf auf die nicht existente /etc/alternatives/i386-linux-gnu_nvidia_modconf zeigt.

Kann/sollte man den Symlink einfach löschen oder besser wo anders hin zeigen lassen?

Und noch eine andere Frage: In welchem Startscript wären eigene Dinge am Besten (z.B. halbwegs update-sicher) aufgehoben? Es gibt ja keine /etc/rc.local und /etc/rc.config wird bei jeder Klickerei im WebIf-Config modifiziert. Könnte ich bespielsweise /etc/init.d/example benutzen (natürlich umbenennen bzw. kopieren)? Welche Namen-Konvention müsste ich dann einhalten?

Gruß
purzel

[clausmuus]

Hi purzel,

genau dafür ist die example gedacht. Du darfst davon ne Kopie mit beliebigem Inhalt anlegen, nur darf der Name nicht mit "rc." anfangen.

Der /dev/ttyS0 dürfte auftauchen, weil Du eingestellt hast, dass Du nen Lirc Empfänger am COM Port hast, aber Dein System Keinen COM Port hat. Zumindest keinen COM1.

Hast Du nen 32Bit System, bzw. ne 32Bit Installation gemacht?

Claus

[purzel]

Hallo Claus,
schönen Dank für die schnelle Antwort.

• Hat der Name meiner Kopie der example eine Auswirkung darauf, WANN sie ausgeführt wird? Ist das so wie bei "normalen" Scripts in /etc/init.d also dass erstens eine bestimme Reihenfolge benutzt wird und zweitens mein Script auch beim 'runterfahren (z.B. `script.sh stop`) ausgeführt wird?
• LIRC habe ich noch gar nicht konfiguriert (ist "aktiv auf /dev/ttyS0" default nach einer frischen Installation?) und /dev/ttyS0 ist das DEFAULTDEVICE in RCU. "Echte" COM-Schnitstellen hat mein Board leider gar keine, so dass ich ihm einen FTDI oder so spendieren muss (/dev/ttyUSB0 o.ä.). Kommt demnächst.
• Ich habe die 32Bit Version installiert, Atom 330 CPU.

Hast Du noch eine Idee bzw. einen Tipp für den o.g. Nvidia-Symlink(-Fehler)?

TIA
purzel

[clausmuus]

Wegen des ttyS0 Fehlers bräuchte ich mal den Auszug aus dem Log mit nen paar Zeilen davor und dahinter.

Der Name hat (fast) keinen Einfluss auf die Abarbeitungs Reihenfolge des Init Scripts. Entscheidend ist, was da eingetragen ist, vor bzw. nach welchem anderem init Script das gestartet werden soll. Beim runterfahren wird diese Reihenfolge rückwärts abgearbeitet.

Claus

[clausmuus]

Die /etc/modprobe.d/nvidia-graphics-drivers.conf kann gelöscht werden. In den neuen Kernel Paketen ist die nicht mehr enthalten.

Claus