[skippy]

Hallo zusammen,

ich habe jetzt meinen MLD-WoZi (Client) mit dem Netinstall-ISO und der zuvor erstellten Config-Datei neu abgebaut. Zumindest habe ich schon einmal ein Bild. Folgende Dinge sind mir bei einem ersten Test aufgefallen:

1. Beim Start des installierten Netinstall-ISO gibt es Fehler beim Mounten - siehe Screenshot

2. Die Ausgabe nach dem Laden endet mit "Configuring xorg-nvidia." Für mich ist nicht ersichtlich, dass die Installation fertig ist. Ist sie überhaupt bis zum Ende durchgelaufen? Gesammte Logausgaben => s. Anlage

3. Nach einem Neustart fällt mir zunächst auf, dass die Boot-Zeit auf dem Standardwert (5 Sekunden) steht. In der rc.config war bei mir 1 Sekunde eingestellt. Hier müsste also noch der Wert ins Bootmenü übernommen werden. Finde gerade die Datei nicht, wo das rein muss - habe aber bei der Suche gesehen, dass die Datei /boot/syslinux.cfg Windows Zeilenumbrüche enthält.

Code: [Select]

include style.cfg

label quiet
        menu default
        kernel /boot/kernel
        append root=/dev/sda1 rootwait vga=0x314 splash=silent quiet apm=off nodialog hpet=disable

label verbose
        kernel /boot/kernel
        append root=/dev/sda1 rootwait vga=0x314 splash=verbose apm=off nobg hpet=disable

DEFAULT loadconfigM
M
LABEL loadconfigM
  CONFIG /syslinux/isolinux.cfgM
  APPEND /syslinux/M

Weiß nicht, ob das irgendwo zu einem Fehler führen kann.

4. Die Datenpartition /dev/sdb1 ist nicht gemountet, obwohl ich die fstab mit in der Conif-Datei hatte

Code: [Select]

MLD-WoZi> mount
rootfs on / type rootfs (rw)
/dev/sda1 on / type btrfs (rw,relatime,ssd,noacl,space_cache)
proc on /proc type proc (rw,relatime)
sys on /sys type sysfs (rw,relatime)
tmp on /tmp type tmpfs (rw,relatime)
run on /run type tmpfs (rw,relatime)
dev on /dev type devtmpfs (rw,relatime,size=1026988k,nr_inodes=256747,mode=755)
log on /var/log type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
/dev/sda1 on /var/cache type btrfs (rw,relatime,ssd,noacl,space_cache)
/etc/auto.dvd on /mnt/autofs type autofs (rw,relatime,fd=6,pgrp=2057,timeout=3,minproto=5,maxproto=5,indirect)
-hosts on /net type autofs (rw,relatime,fd=12,pgrp=2057,timeout=60,minproto=5,maxproto=5,indirect)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
-hosts on /net/Diskstation/volume1/video type autofs (rw,relatime,fd=12,pgrp=2057,timeout=60,minproto=5,maxproto=5,offset)
-hosts on /net/MLD-Server/mnt/data type autofs (rw,relatime,fd=12,pgrp=2057,timeout=60,minproto=5,maxproto=5,offset)

5. Der Ton fehlt, weil die Soundkarte gemutet ist. Konnte es im alsamixer bereinigen.

6. TV-Guide war nicht mehr als Progammmenü voreingestellt. Aus meiner Sicht liegt es daran, dass das Programmmenü durch Remotetimers ersetzt wird. Das ist die Voreinstellung bei einer Clientneuinstallation. Ich hatte das bei mir geändert. Hier scheinen die Werte aus dem Config-File durch die Paketinstallation überschrieben zu werden.

Soweit ein erster Test von mir.

Viele Grüße skippy

[MegaX]

Hi skippy

ich versteh das nicht warum das bei dir so herum zickt, denn ich habs hier mehrfach getestet und keine Probleme gehabt weder in der VM noch auf der real Hardware.

Hast du das ganze zum ersten mal probiert oder lässt sich das ganze bei dir reproduzieren?

[clausmuus]

Hi,

da stecken wir in nem kleinem Dilemma. Zum einen spielen wir die alte Konfig am Anfang ein, damit z.B. der VDR nicht nach der auszuwählenden Kanalliste fragt, zum anderen ändern aber diverse install scripte pauschal die Konfiguration ohne zu schauen ob bereits ne individuelle Konfiguration vorgenommen wurde. Und dann gibt's noch solche Sonderfälle wie die bootmenü Zeit, die nur dann übernommen werden, wenn diese über das Setup eingestellt werden.
Und dann gibt's noch solche Sachen wie die fstab, wo die UUID eingetragen ist, welche sich jedoch bei ner neu installation ändert. sowas kann nur schief gehen.

Da müssen also einige postinstall Scripte überarbeitet werden und solche Besonderheiten wie die fstab müssen beim einspielen der alten Konfiguration aufwendig analysiert und überarbeitet werden.

Alles in allem steht da noch ne Menge Arbeit an ;( und einiges davon muss gründlich durchdacht werden, wenn wir da nicht immer wieder in neue Fallen Tappen wollen...

Claus


Problemfälle sind nach derzeitigen Erkenntnisstand:
- bootmenüzeit
- fstab
- /etc/vdr/setup.conf.add

Wobei es sicher einige Abarten davon mit ähnlicher Auswirkung gibt.

Eventuell wäre nen "UPGRADE" Flag hilfreich, das vom postinstall Script ausgewertet werden kann. Das könnte dann einige Upgrade Probleme beheben und würde auch hier helfen, da es ja aus technischer Sicht so ne Art upgrade ist.

[MegaX]

So...ich hab nun auch nochmal neu das netinstall gezogen und kann nun auch die Probleme von skippy nachstellen.
Ich weiß nicht warum aber so wie es aussieht hatte ich vorhin ein netinstall ISO wo noch das alte backup config drinnen war, warum auch immer 

Das Problem mit der nicht übernommenen Bootzeit besteht schon seit der 3er und ja es ist ein Bug, wobei ich mir denke es ist gar nicht so schlecht wenn nach der Installation die Zeit erstmal bei 5 sec. steht.
Sollte irgendwas schief gehen dann hat man genügend Zeit im Bootmenü das passende zu wählen.

Wegen der fstab hatten wir schonmal das Problem mit der uuid und haben damals umgestellt.

Wenn wir nun die configfiles schon vor der eigentlichen Installation einfügen dann müssten wir auch die /etc/vdr/setup.conf.add wieder in setup.conf ändern.
Da diese vor der eigentlichen Installation hinzu gefügt wurde sollte sie auch nicht mehr verändert werden egal welche Pakete installiert werden.
Mit den anderen Configs verhält es sich genauso, denn opkg prüft ja ob die conf als geschützt deklariert ist(control/conffiles) und überschreibt diese dann nicht sondern legt die neue conf mit dem Zusatz "-opkg" an.

[clausmuus]

Das Problem mit der /etc/vdr/setup.conf.add ist, das die beim Installieren der Pakete erstellt bzw. gefüllt wird. Der richtige Weg wäre, das in dem postinstall Scripten geprüft wird, ob die jeweilie Option bereits gesetzt ist, und die /etc/vdr/setup.conf.add nur erweitert, wenn das nicht der Fall ist, das Plugin also noch nie installiert war.
Eigendlich nichts großes, muss halt nur gemacht werden, und da mehr als 25 Pakete betroffen sind, artet das in echte Fleiß Arbeit aus...
Eine Alternative wäre, dass einfach im runvdr Script nur die Werte hinzugefügt wedren, die noch nie gesetzt waren. Ich werde der Einfachkeit halber diese Variante implementieren.

Claus

[clausmuus]

Damit es weiterhin möglich ist, bei einem upgrade eines Plugins ein update eines setup Wertes zu erzwingen, kann am anfang der jeweiligen Zeile ein Ausrufezeichen geschrieben werden. Das sieht dann z.B. so aus:

Code: [Select]

cat >> /etc/vdr/setup.conf.add <<- EOF
    rpihddevice.AudioPort = 1
    !streamdev-client.Timeout = 15
EOF
Dies sorgt dafür das bei einem Upgrade der bestehende Konfigurationswert für "streamdev-client.Timeout" überschrieben wird. Der wert für "rpihddevice.AudioPort" wird hingegen unverändert gelassen.

Claus

[MegaX]

Für was der riesen Aufwand?

Machen wir es doch einfacher und sichern die setup.conf einfach mit in den tmp Ordner wo sich die installed-packages.list befindet.
Wenn dann die Configs eingespielt werden befindet sich die gesicherte setup.conf im /tmp/ Verzeichnis.

Nun muß eigentlich nur noch das Start Skript vom VDR so angepasst werden das nachdem er installiert wurde die setup.conf, falls in /tmp/ vorhanden nach /etc/vdr/ kopiert wird wird bevor der VDR gestartet wird.
Die Reihenfolge wie die Pakete dann installiert werden ist egal, da diese ja eine setup.conf.add anlegen und der VDR beim starten eh prüft ob die Einstellungen die hinzu gefügt werde sollen schon in der setup.conf vorhanden sind.

[clausmuus]

Hi,

da liegst Du daneben. Das Problem ist nicht, das die setup.conf nicht gesichert und zurück gespielt wird, sondern das die beim installieren der Pakete erstellte setup.conf.add die Einstellungen aus dem Backup überschreiben. Und genau das wird durch meine Änderung unterbunden. Damit es nun weiterhin möglich bleibt, im postinst Script festzulegen, dass ein neuer Wert auf jedenfall übernommen werden soll, habe ich die Möglichkeit mit dem ! eingefügt.

Im übigen sind die anderen Probleme mit etwas Glück nun auch behoben.
- Sofern das Mount Problem auf ne fehlerhafte UUID zurück zu führen ist, sollte das nun nicht mehr auftreten.
- Das Alsa Problem verstehe ich nicht, da die Soundkarten Konfiguration ja nicht mit gesichert wird (bzw. werden sollte. Überprüfe mal ob ne /etc/asound.state im Backup enthalten ist)
- Warum die Installation mit dem xorg-nvidia Setup endet erschließt sich mir nicht. Danach sollten noch die init Scripte der installierten Pakete gestartet werden.

[MegaX]

da liegst Du daneben. Das Problem ist nicht, das die setup.conf nicht gesichert und zurück gespielt wird, sondern das die beim installieren der Pakete erstellte setup.conf.add die Einstellungen aus dem Backup überschreiben

Das passiert aber nur wenn wir die setup.conf weiterhin als setup.conf.add sichern.
Wenn wir diese nun als setup.conf sichern und diese bevor der VDR gestartet wird ins System kopieren dann wird da gar nix von den anderen Plugins überschrieben.

[skippy]

Hallo ihr 2,

ups, da habe ich ja eine lebhafte Diskussion erzeugt. Insgesamt finde ich schon, dass das ganze prima funktioniert. So schnell hatte ich mein System noch nie neu aufgesetzt und "konfiguriert". Aus meiner Sicht finde ich den Weg mit der Unterscheidung, ob es sich um eine Erstinstallation oder um ein Zurückspielen der Backup-Config handelt, schon den saubereren Weg. Ihr schafft das schon .

- Sofern das Mount Problem auf ne fehlerhafte UUID zurück zu führen ist, sollte das nun nicht mehr auftreten.

Hier ist mir die Ursache noch nicht so ganz klar. Ich hatte eine manuelle Installation gewählt und nur die Systempartition ausgewählt und formatieren lassen. Bekommt dann die Datenpartition auch eine neue UUID? Nach den Tests und einem Neustart habe ich dann probiert, die meine Datenpartition über das WebIf zu mounten. Das geht jedoch auch schief. Auch hier habe ich keine Ahnung, was das noch mit dem Backup zu tun haben könnte.
Ah doch, er mountet jetzt das Verzeichnis vom Server nach /mnt/data,

Code: [Select]

Sep 26 18:01:04 (MLD) daemon.notice rpc.mountd[4827]: authenticated mount request from 10.132.128.100:839 for /mnt/data (/mnt/data)Das war bei mir vorher auch anders bei mir konfiguriert.

- Das Alsa Problem verstehe ich nicht, da die Soundkarten Konfiguration ja nicht mit gesichert wird (bzw. werden sollte. Überprüfe mal ob ne /etc/asound.state im Backup enthalten ist)

Die Datei ist nicht in der Backup-Config vorhanden.

Jetzt habe ich den MLD-WoZi nach längerem shutdown mal wieder neu gestartet, habe Ton und das MLD-Hintergrundbild mit Cursor ... - hab mal das Debug-Log angehängt, muss erst mal wieder los.
//edit: Stop und Start des x-servers hat wieder ein Bild gebracht.

Danke euch und viele Grüße skippy

[clausmuus]

Hi MegaX,

Du hast natürlich Recht. Ich hatte nur vergessen, dass die VDR Setup.conf umbenannt wurde. Das habe ich nun entfernt. Die wird nun also mit dem original Namen gesichert.

@Skippy,

Dein problem ist, dass das daten Laufwerk /dev/sdb1 nicht gemountet werden konnte. Dadurch konnte auch das /var/cache nicht gemountet werden, was zu größeren Problemen führt.

Claus

[skippy]

Dein problem ist, dass das daten Laufwerk /dev/sdb1 nicht gemountet werden konnte. Dadurch konnte auch das /var/cache nicht gemountet werden, was zu größeren Problemen führt.

Hi Claus,

hast du gesehen, woran es liegt - an dem Upload der Config-Datei, daran dass das Datenlaufwerk vom Server nach /mnt/data gemountet ist oder habe ich ein Hardwareproblem?

Viele Grüße skippy

[clausmuus]

Ne, warum das nicht erfolgreich war, konnte ich nicht sehen. Du kannst ja mal versuchen, ob Du das /dev/sdb1 von Hand mounten kannst.

Claus