Beiträge von davie2000

Ich hab das so gemacht (das timeout war schon auf 10) und sehe das gleiche Grub2-Menü wie immer.

Und erst jetzt fällt mir Deppen auf, dass da immer nur Bootoptionen angeboten werden, die auf sda liegen.

Natürlich gibt es dann unter "Ubuntu 18 erweitert" dann nicht die schönen neuen Kernelversionen, sondern nur die 51er.

Seltsam ist nur, dass ich offenbar immer schön auf der SSD (sdb) ändere und updates einspiele, aber dann offenbar von

der Festplatte (sda) gestartet wird - die Änderungen sehe bzw. spüre ich aber???

Wie kriege ich denn das jetzt so hin, dass ich standardmässig das richtige yaVDR-ansible von der SSD starte und trotzdem im

Bedarfsfall (aus Nostalgiegründen?) im Grub-Menu noch von den alten Partitionen (yaVDR 0.5, 0.6 und früher Ubuntu18-Versuch)

starten kann?

Wenn ich da einfach so drauflos probiere, habe ich Angst, dass der VDR dann nicht mehr läuft und dann krieg ich Ärger ...

Nein klappt nicht:

sudo efibootmgr  -v
sudo: efibootmgr: Befehl nicht gefunden

Die "wilde Mischung" kommt so zustande, dass ich yaVDR 0.6 auf HDD benutzte, dann parallel dazu auf Platte Ubuntu 18 installiert habe.

Beide teilen sich die /srv-Partition auf der Festplatte.

Dann kam eine SSD dazu auf der ich endgültig yaVDR-ansible installiert habe (das ich jetzt auch nutze).
Die HDD nutze ich jetzt eigentlich nur noch für die Aufnahmen und die Filme (/srv), alles andere sollte sich auf der SSD abspielen.

Kann sein, aber ich habe ehrlich gesagt keine Ahnung.

Wie finde ich das denn heraus bzw. wie kann ich das korrigieren?

Edit:

Festplatte /dev/sda: 2,7 TiB, 3000592982016 Bytes, 5860533168 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 9723F92E-DA5A-417A-A0C8-6396A3BA4667

Gerät          Anfang       Ende   Sektoren Größe Typ
/dev/sda1        2048       4095       2048    1M Linux-Dateisystem
/dev/sda2        4096   78129151   78125056 37,3G EFI-System
/dev/sda3  5852182528 5860532223    8349696    4G Linux Swap
/dev/sda4    78129152 5683597901 5605468750  2,6T Microsoft Basisdaten
/dev/sda5  5749782528 5852182527  102400000 48,8G EFI-System
/dev/sda6  5683599360 5749782527   66183168 31,6G EFI-System

Partitionstabelleneinträge sind nicht in Festplatten-Reihenfolge.


Festplatte /dev/sdb: 111,8 GiB, 120034123776 Bytes, 234441648 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x0feda8d5

Gerät      Boot    Anfang      Ende  Sektoren Größe Kn Typ
/dev/sdb1  *         2048 207544319 207542272   99G 83 Linux
/dev/sdb2       207544320 218030079  10485760    5G 82 Linux Swap / Solaris

sda müsste die allte 3 TB Festplatte sein (auf der u.a. yaVDR 0.6 liegt - sda5 glaub ich);

sdb ist die neue SSD-Festplatte mit dem aktuell laufenden yavdr-ansible - von der gebootet werden müsste (Boot-Flag *).

Mit den Ausgaben kann ich leider nicht viel anfangen - schaut für mich aber eigentlich gut aus (bis auf die Tatsache, dass 58 nicht installiert ist).

Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
        | Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
                 Halb installiert/Trigger erWartet/Trigger anhängig
        |/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
        ||/ Name                                              Version                       Architektur                   Beschreibung
        +++-=================================================-=============================-=============================-=======================================================================================================
        un  linux-image                                       <keine>                       <keine>                       (keine Beschreibung vorhanden)
        rc  linux-image-4.15.0-20-generic                     4.15.0-20.21                  amd64                         Signed kernel image generic
        rc  linux-image-4.15.0-23-generic                     4.15.0-23.25                  amd64                         Signed kernel image generic
        ii  linux-image-4.15.0-45-generic                     4.15.0-45.48                  amd64                         Signed kernel image generic
        ii  linux-image-4.15.0-51-generic                     4.15.0-51.55                  amd64                         Signed kernel image generic
        ii  linux-image-4.15.0-52-generic                     4.15.0-52.56                  amd64                         Signed kernel image generic
        ii  linux-image-4.15.0-54-generic                     4.15.0-54.58                  amd64                         Signed kernel image generic
        ii  linux-image-4.15.0-55-generic                     4.15.0-55.60                  amd64                         Signed kernel image generic
        ii  linux-image-4.15.0-58-generic                     4.15.0-58.64                  amd64                         Signed kernel image generic
        ii  linux-image-generic                               4.15.0.58.60                  amd64                         Generic Linux kernel image
        un  linux-image-unsigned-4.15.0-20-generic            <keine>                       <keine>                       (keine Beschreibung vorhanden)
        un  linux-image-unsigned-4.15.0-23-generic            <keine>                       <keine>                       (keine Beschreibung vorhanden)
        un  linux-image-unsigned-4.15.0-45-generic            <keine>                       <keine>                       (keine Beschreibung vorhanden)
        un  linux-image-unsigned-4.15.0-51-generic            <keine>                       <keine>                       (keine Beschreibung vorhanden)
        un  linux-image-unsigned-4.15.0-52-generic            <keine>                       <keine>                       (keine Beschreibung vorhanden)
        un  linux-image-unsigned-4.15.0-54-generic            <keine>                       <keine>                       (keine Beschreibung vorhanden)
        un  linux-image-unsigned-4.15.0-55-generic            <keine>                       <keine>                       (keine Beschreibung vorhanden)
        un  linux-image-unsigned-4.15.0-58-generic            <keine>                       <keine>                       (keine Beschreibung vorhanden)

default         0
    
    timeout         0
    
    hiddenmenu
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    title           Ubuntu 18.04.3 LTS, kernel 4.15.0-58-generic
    root            (hd0)
    kernel          /boot/vmlinuz-4.15.0-58-generic root=UUID=8dab64b9-92a3-4571-981c-504887f45666 ro console=hvc0
    initrd          /boot/initrd.img-4.15.0-58-generic
    
    title           Ubuntu 18.04.3 LTS, kernel 4.15.0-58-generic (recovery mode)
    root            (hd0)
    kernel          /boot/vmlinuz-4.15.0-58-generic root=UUID=8dab64b9-92a3-4571-981c-504887f45666 ro  single
    initrd          /boot/initrd.img-4.15.0-58-generic
    
    title           Ubuntu 18.04.3 LTS, kernel 4.15.0-55-generic
    root            (hd0)
    kernel          /boot/vmlinuz-4.15.0-55-generic root=UUID=8dab64b9-92a3-4571-981c-504887f45666 ro console=hvc0
    initrd          /boot/initrd.img-4.15.0-55-generic
    
    title           Ubuntu 18.04.3 LTS, kernel 4.15.0-55-generic (recovery mode)
    root            (hd0)
    kernel          /boot/vmlinuz-4.15.0-55-generic root=UUID=8dab64b9-92a3-4571-981c-504887f45666 ro  single
    initrd          /boot/initrd.img-4.15.0-55-generic
    
    title           Ubuntu 18.04.3 LTS, kernel 4.15.0-54-generic
    root            (hd0)
    kernel          /boot/vmlinuz-4.15.0-54-generic root=UUID=8dab64b9-92a3-4571-981c-504887f45666 ro console=hvc0
    initrd          /boot/initrd.img-4.15.0-54-generic
    
    title           Ubuntu 18.04.3 LTS, kernel 4.15.0-54-generic (recovery mode)
    root            (hd0)
    kernel          /boot/vmlinuz-4.15.0-54-generic root=UUID=8dab64b9-92a3-4571-981c-504887f45666 ro  single
    initrd          /boot/initrd.img-4.15.0-54-generic
    
    title           Ubuntu 18.04.3 LTS, kernel 4.15.0-52-generic
    root            (hd0)
    kernel          /boot/vmlinuz-4.15.0-52-generic root=UUID=8dab64b9-92a3-4571-981c-504887f45666 ro console=hvc0
    initrd          /boot/initrd.img-4.15.0-52-generic
    
    title           Ubuntu 18.04.3 LTS, kernel 4.15.0-52-generic (recovery mode)
    root            (hd0)
    kernel          /boot/vmlinuz-4.15.0-52-generic root=UUID=8dab64b9-92a3-4571-981c-504887f45666 ro  single
    initrd          /boot/initrd.img-4.15.0-52-generic
    
    title           Ubuntu 18.04.3 LTS, kernel 4.15.0-51-generic
    root            (hd0)
    kernel          /boot/vmlinuz-4.15.0-51-generic root=UUID=8dab64b9-92a3-4571-981c-504887f45666 ro console=hvc0
    initrd          /boot/initrd.img-4.15.0-51-generic
    
    title           Ubuntu 18.04.3 LTS, kernel 4.15.0-51-generic (recovery mode)
    root            (hd0)
    kernel          /boot/vmlinuz-4.15.0-51-generic root=UUID=8dab64b9-92a3-4571-981c-504887f45666 ro  single
    initrd          /boot/initrd.img-4.15.0-51-generic
    
    title           Ubuntu 18.04.3 LTS, kernel 4.15.0-45-generic
    root            (hd0)
    kernel          /boot/vmlinuz-4.15.0-45-generic root=UUID=8dab64b9-92a3-4571-981c-504887f45666 ro console=hvc0
    initrd          /boot/initrd.img-4.15.0-45-generic
    
    title           Ubuntu 18.04.3 LTS, kernel 4.15.0-45-generic (recovery mode)
    root            (hd0)
    kernel          /boot/vmlinuz-4.15.0-45-generic root=UUID=8dab64b9-92a3-4571-981c-504887f45666 ro  single
    initrd          /boot/initrd.img-4.15.0-45-generic

An der Bootkonfiguration habe ich eigentlich nichts wissentlich geändert. Habe aber auf einer anderen Partition noch einen yaVDR 0.6 liegen.

Ich habe heute mit dem install-Skript das ansible-Playbook neu (drüber) installiert und dabei wurde - wie auch die letzten Male - ein update & dist-upgrade ausgeführt.

Jetzt wollte ich mal einige alte Kernel entfernen und habe dabei festgestellt, dass ich offenbar Version 4.15.0-51 benutze, obwohl eigentlich auf 4.15.0-58 upgedatet wurde. Ich finde insgesamt vier aktuellere Kernelversionen auf meinem System.

Jedenfalls liefert uname -a das hier

 Linux myVDR 4.15.0-51-generic #55-Ubuntu SMP Wed May 15 14:27:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Offenbar wurde seit Mai kein neuer Kernel eingespielt obwohl ich regelmässig das Skript laufen lassen habe.

Wie kann denn sowas passieren?

Und wie komme ich jetzt sauber auf den neuesten Kernel?

Danke schon jetzt für eure Hilfe!

Zitat von seahawk1986

Wenn man Variablen in der host_vars/localhost definiert, überlagert das die Variablen aus der group_vars/all - wenn etwas in der group_vars/all dazu kommt, sollte das eigentlich nicht stören (man muss nur bei verschachtelten Variablenstrukturen aufpassen, die Werte darin werden nicht zusammengeführt).

Stören tuts mich eh nicht

Aber ich würde gerne deine aktuellsten Änderungen (Verbesserungen) mitbekommen und das geht meines Wissens nach nur mit manuellem diff und da übersehe ich deine Änderungen leicht, weil mein Customizing natürlich als (sehr) viele Änderungen angezeigt wird. Aber bis jetzt habe ich - hoffentlich - alle Verbesserungen mitbekommen.

Wie zB letztens die Möglichkeit, das Ent-/Laden der DVB-Treiber customizable zu machen

Edit:

Zitat von Doc_Hollywood

Wenn es nun Änderungen bei seahawks git gibt, wechselst du zum master branch mit git checkout master und holst Dir alle Änderungen mit git pull.

Das hatte ich mehrmals so gemacht, aber es sind nie alle Änderungen (lt. Historie auf github im Browser) in meinen lokalen Dateien angekommen. Und gelöschte Dateien wurden nicht wieder neu geholt.

Aber ich bin gerade dabei das mit meinem eigenen Branch und merge (statt rebase) zu probieren. Sollte ich damit nicht das Auslangen finden, werde ich mich an der "upstream"-Methode versuchen.

Edit 2:

Ich hab jetzt einen eigenen branch "myvdr" eröffnet und dort meine Änderungen gemacht und schöne einzeln commited.

Dann habe ich das Install-Skript laufen lassen und updates wurden durchgeführt - soweit alles prima - Danke euch!

Jetzt warte ich gespannt auf die nächste Änderung von Seahawk und werde dann mal schauen obs mit pull und merge dann auch wirklich funktioniert ...

Ahhhhh ... ok. Das erklärt das ganze natürlich: die veraltete Version (von der ersten Installation) bleibt so natürlich auf ewig erhalten

Vielen Dank für die ausführliche Antwort!

Dann muss ich also für jede Datei, die überschrieben werden soll das no auf yes umstellen? Ok, mach ich.

Das werden dann wohl alle genannten sein, außer die channels.conf, da möchte ich die momentane behalten, weil die ja viell. seit

der letzten Installation während dem Fernsehen geändert wurde.

D.h. aber im Umkehrschluß, dass meine Vorgehensweise (siehe hier) nicht gerade optimal ist, um alle deine Änderungen mitzubekommen,

weil eben gar nicht alle Änderungen beim Drüber-Installieren ankommen?!

Edit:

Wäre es (einfach) möglich, die Entscheidung, ob die Datei überschrieben werde soll oder nicht, in die group_vars/all aufzunehmen?

Obwohl - andererseits - stehen ja bei weitem nicht alle o.a. Dateien in den group_vars - dzt. eigentlich nur die channels.conf *hmmm*

Wow ... vielen Dank für die zahlreichen guten Antworten!

Ich werde mich wohl die Tage mal hinsetzen und das komplett neu - aber richtig - aufziehen.

Hoffentlich werden dann auch ALLE Dateien in der neuesten Version installiert (siehe hier).

Danke für deine Antwort!

Ja, so habe ich das auch schon zig-mal gemacht und trotzdem endete ich am Schluss immer mit Löschen und Neuanfangen.

Weil beim PULL - trotz eindeutiger Änderungen im Browser auf github - sich nichts geändert hat, habe ich dann meist zum Zaubern begonnen und mir alles zerschossen, sodass ich von vorne angefangen habe.

Aber wenn der Weg eigentlich der richtige wäre, werde ich so weitermachen und mich vor dem nächsten Zaubern hier wieder melden.

Wenn wir schon so schön dabei sind:

Wie handelst du Änderungen/Neuerungen in der group_vars/all elegant - da sich diese ja nicht automatisch in der lokale Kopie (host_vars/localhost) niederschlagen?

Hallo!

Trotz der tollen Arbeit von Seahawk und der Möglichkeit fast alles in der eigenen host_vars/localhost zu customizen, muss ich zwei Dateien manipulieren, um unser yaVDR-Erlebnis perfekt zu machen:

In roles/yavdr-remote/templates/rc_maps.cfg.j2 benutzen wir für "nuvoton-cir" unsere eigene Keymap (mit unserer seit Jahren gewohnten Tastenbelegung)

In roles/yavdr-desktop/templates/.lircrc.j2 haben wir einen anderen Button als Kodi-Taste definiert (KEY_PROG2 statt KEY_HOME)

Statt regelmässigem update & dist-upgrade wird seit Ubuntu 18 (und Ansible) eigentlich immer eine Installation mittels sudo -H ./install-yavdr.sh durchgeführt.

Da laufend Verbesserungen in Seahawks GIT gemacht werden, möchte ich dafür immer seinen aktuellste Stand benutzen, angereichert um meine lokalen Einstellungen (host_vars/localhost) und meine "Manipulationen".

Ich habe einiges über GIT gelesen und vieles ausprobiert und bin dann immer wieder da gelandet, dass ich meine lokale Kopie komplett gelöscht und yavdr-ansible neu geladen habe.

Natürlich musste ich dann alle meine Änderungen immer wieder einpflegen, um schlußendlich das install-Skript ausführen zu können.

Ich möchte immer den aktuellsten Ansible-Stand vom Github, aber meine Änderungen sollen trotzdem erhalten bleiben - zumindest solange sich diese konkreten Dateien nicht komplett geändert haben.

Wie geht das bitteschön "in schön"?

Danke, Seahawk, für deine Antwort.

Ich habe mir den Inhalt der angegebenen Datei angeschaut und bin erschrocken, weil der Inhalt NICHT mit dem template übereinstimmt!

Obwohl ich gerade erst vor ein paar Tagen das install-Playbook laufen habe lassen damit ich deine Neuerungen mitbekomme!

Konkret fehlen alle deine letzten Anpassungen bzgl. "unload dvb drivers"! HILFE!

Kann es sein, dass die Datei /lib/systemd/system-sleep/yavdr bei sudo -H ./install-yavdr.sh nicht mehr überschrieben wird, wenn sie schon existiert?

Falls ja: bei welchen Dateien ist das noch passiert, dass der Inhalt jetzt veraltet ist?

Danke für den Tipp!

Ich werde also versuchen den Dienst (ich denke du meinst "oscar") beim Standby zu stoppen und beim Aufwachen wieder starten zu lassen.

Ich würde das eigentlich in "deiner" roles/yavdr-common/templates/system-sleep_yavdr.j2 machen und beim Entladen/Laden der DVB-Treiber abkupfern.

Aber jetzt mal vorab zum Ausprobieren ohne das Playbook neu zu installieren: in welcher Datei findet das Ergebnis des Templates denn Niederschlag?

Sprich, in welcher Datei kann ich (temporär) das Stoppen/Starten unterbringen?

Seltsam bleibt natürlich, dass es manchmal funktioniert und manchmal nicht???

Update:

Habe in meinen alten Aufzeichnungen recherchiert und mich "erinntert", dass ich damit nach Aufwachen unter yaVDR 0.6 auch schon Probleme hatte.

Nach einigen Versuchen mit /etc/yavdr/force-reload-services.list, die aber nicht fruchteten, hat mich damals /etc/init/wait-for-dvb.conf weitergebracht.

Das Warten auf die DVB-Devices ist aber bei yaVDR Ansible doch schon drin, oder?

Zitat von seahawk1986

Wenn der VDR nicht direkt auf ein CAM-Gerät mit der Smartcard zugreift

Wie finde ich denn heraus, ob mein VDR direkt oder indirekt aufs CAM zugreift?

Hallo!

Dank der tollen Bemühungen von seahawk nutze ich seit einigen Monaten yaVDR Ansible zu unser aller Zufriedenheit!

In letzter Zeit kommt es leider immer häufiger vor, dass die ORF-Sender nach dem Aufwachen des VDR aus dem Standbye

nicht mehr hell werden. Im Syslog findet sich dazu leider nichts - Bild bleibt einfach schwarz.

Ein beherzter Reboot des PCs behebt das Problem dann wieder.

Ich nutze die (neue) Möglichkeit, die DVB-Treiber nicht zu entladen (standby_reload_dvb: false in meiner host_vars/localhost),

weil es mit Entladen gar nicht klappt. Mit Nicht-Entladen haben wir zumindest einige Male nach dem Aufwachen ein Bild.

Hat da viell. jemand eine Idee woran das liegen könnte?

Im schlimmsten Fall müsste man einbauen, dass zB jedes 3 "Ausschalten" kein Standbye wird sondern ein echtes Herunterfahren.

Aber lieber würde ich die Ursache für das nicht korrekte Aufwachen finden ...

Danke!

I am not sure if this helps also for satip & unicable, but try searching for "systemctl enable wait-for-dvb@0.service" over all forums.

Ich habe die beiden Zeilen direkt in der yavdr-Datei (/lib/systemd/system-sleep) auskommentiert und rebootet.

Und was soll ich sagen: es funktioniert!!!

seahawk1986 du bist einfach der Wahnsinn - vielen Dank!

Jetzt haben wir ca 10 Sekunden nach dem Einschalten Bild und Ton und alles scheint zu funktionieren - ein Traum!

Wir lieben yaVDR-ansible

Werde das noch templaten und das install-Skript dann nochmal laufen lassen ...

Ich habe die beiden Ausgaben als "log1" (ab Ausschalten) bzw. "log2" (nach resume) angehängt.

Beim Resumen sieht man, dass offenbar mein dvb-Treiber nicht geladen werden kann???

Da fehlt mir wohl die Geschichte mit "waiting for dvb device", oder?

Ich habe gerade in meinen lokalen host_vars die Shutdownmethode umgestellt (wie im ersten Posting angegeben) und dann das install-Skript nochmal laufen lassen und den PC neu gestartet.

Das Ausschalten (jetzt Standby) geht jetzt gefühlt etwas schneller.

Nach dem Einschalten kommt sofort das yavdr-Logo (statt bisher Bootscreen und Bootmeldungen) und nach einigen Sekunden verschwindet es, aber der Bildschirm bleibt schwarz.

Ich werde wohl morgen mal deine neueste GIT-Version holen und das install-Skript nochmal laufen lassen.

Nach einigem GIT add, commit & Co und anschließendem sudo -H ./install-yavdr.sh wurde ein dist-upgrade durchgeführt und alles neu installiert und alle Änderungen blieben erhalten - juhu.

Vielen Dank für eure Unterstützung!

Funktioniert *freu*

Jetzt muss ich mich nur noch trauen das Installskript nochmal zu starten ?

bin ja eh dabei (rebootet gerade)

Möchte nur sichergehen, dass ich mir mit neuerlichem Drüberinstallieren nicht wieder alles vernichte.