Posts by kls

    Bei LCARS ist es so, das da das OSD selbst der "Arbeitsbereich" ist, also direkt in das OSD gezeichnet wird (es wird also nicht mit Pixmaps gearbeitet).

    Hier muss der Renderer also selbst herausfinden, was sich im Gesamt-OSD geändert hat.

    Siehe dazu osd.h:

    Die OSD-Implementierung bekommt also über RenderPixmaps() nur den Bereich, der sich verändert hat.

    wirbel : Ich habe das Problem dadurch gelöst, dass ich auf dem PC2 auch Leap 15.3 installiert habe. Damit klappt es jetzt in beide Richtungen, und beide Rechner kommen ans Netzwerk.


    Jetzt habe ich nur noch das Problem, den sendmail zu stoppen bevor ich das System von PC1 auf PC2 "umziehe". Es sollen ja während des rsync keine Emails auf PC1 mehr angenommen werden, da diese ja u.U. nicht mehr auf PC2 kopiert würden.

    Wie man sieht wird sendmail immer wieder sofort neu gestartet, obwohl ich dem systemctl explizit sage, dass er stoppen soll.

    Was mache ich falsch?

    Das "Hin" hat mit der gestrigen Version des Skripts schon gut geklappt, aber des "Her" (--back) noch nicht. Ich musste noch auf dem lokalen Rechner "mkinitrd" und "update-bootloader" aufrufen, damit das root-Volume erkannt wurde.

    Hier eine neue Version, mit einigen weiteren Verbesserungen/Fixes.

    Das --back dient dazu, die beiden Rechner "auszutauschen", d.h. jeder übernimmt die Rolle des anderen.


    Was bei --back noch nicht funktioniert ist der Netzwerk-Adapter. Für "Hin" reichte ein


    cp /etc/udev/rules.d/70-persistent-net.rules /mnt/etc/udev/rules.d


    für das "Her" leider nicht. Da bin ich noch am Debuggen...

    Files

    Zum Abschluss noch die Erklärung, wozu ich das brauche.

    Ich möchte meinen Haupt-Rechner dahingegend absichern, dass ich im Falle eines Hardwaredefekts so schnell wie möglich auf einen Backup-Rechner umsteigen kann. Das beiliegende Skript erledigt diese Aufgabe vollständig und automatisch, so dass im Fall der Fälle nichts übersehen werden kann. Ich lasse das jede Nacht laufen und kann so maximal einen Tag zurückfallen. Konkret muss ich momentan den Hauptrechner einem längeren Speichertest unterziehen, da er sich schon mehrmals urplötzlich aufgehängt hat, was vermutlich an einem defekten RAM liegt. Mit dem Skript kann ich alles schnell auf einen zweiten Rechner "umziehen", den ersten runter- und den zweiten mit dem kopierten System hochfahren und fertig.


    Ich poste es nur der Vollständigkeit halber und für den Fall, dass sich jemand auch für sowas interessiert. Ich habe versucht, es so allgemein wie möglich zu gestalten, die Kommandos unter "Stop processes on HOST1" sind evtl. den lokalen Gegebenheiten entsprechend anzupassen.


    Falls jemand einen Fehler entdeckt oder ich irgend etwas übersehen habe, bin ich natürlich für Rückmeldungen dankbar.

    (Die ".txt" Extension ist nur wegen der Portal-Software)


    Benutzung natürlich auf eigene Gefahr! ;-)


    <edit>

    Achtung: Neue Version im nächsten Post!

    </edit>

    Files

    Die UUIDs müssten noch in der grub.cfg stehen und werden von mkinitrd angepast. Ich würde folgendes probieren...

    Das hab ich jetzt gemacht und damit stehen die richtigen UUIDs in der /mnt/boot/grub2/grub.cfg.

    Allerdings stehen in dieser Datei keine 'menuentry' Zeilen für Leap 15.3, sondern nur die für 15.0.

    Beim Reboot wird mir aber 15.0 und 15.3 angeboten. Wähle ich dann 15.3, verhält es sich immer noch so wie oben beschrieben (Timeout und Not-Shell). Wie bekomme ich denn die menuentrys-Zeilen für 15.3 in die grub.cfg?

    Nächster Stolperstein ist dann vermutlich die Datei /etc/udev/rules.d/70-persistent-net.rules wo der Netzwerkadapter per MAC Adresse gemappt wird

    Da kann ich ja einfach diese Datei kopieren.

    Ich habe einen PC ("PC1") mit openSUSE Leap 15.3, dessen System ich auf einen anderen PC ("PC2") (mit fast identischer Hardware) kopieren möchte. Auf dem anderen Rechner läuft openSUSE Leap 15.0.

    PC1 hat das System in /dev/sda1, PC2 in /dev/sda2. /dev/sda3 ist auf beiden PCs als /boot/efi gemountet.

    Auf PC2 ist /dev/sda1 als /sys1 gemountet.

    Wenn ich auf PC1 folgendes mache


    rsync -aHSx --numeric-ids --delete --force / PC2:/sys1

    ssh PC2 update-bootloader


    und dann PC2 boote, dann kann ich im Boot-Menü zwar das System in /dev/sda1 auswählen und es startet auch, kommt aber nicht weit. Irgendwann, nach längerem Timeout, kommt dann ein Prompt, das root-Passwort einzugeben und ich lande in einer Not-Shell.

    Kann es sein, dass ich ausser update-bootloader noch etwas machen muss? Ramdisk neu generieren oder so? Die Devices haben natürlich andere UUIDs, kann es vielleicht daran liegen?

    Ich möchte das Ganze per Script machen, um es im Falle eines Falles automatisch ablaufen lassen zu können.

    Gibt es eigentlich einen Grund warum man das nicht im VDR bzw. in einer *.conf konfigurieren kann.

    Es schien mir nicht notwendig. 1GB ist ja doch eine ganze Menge ;-).

    Ich glaube der VDR prüft/löscht nur Aufnahmen wenn eine Aufnahme gestartet wird oder läuft.

    Das ist richtig.

    Wenn keine Aufnahme ansteht und die Festplatte läuft wie bei mir mit Non-VDR Daten unter das MinDISKSPACE dann kann die Platte voll sein bevor Aufnahmen gelöscht werden.

    Ich finde es besser, wenn VDR seine eigene Platte bzw. Partition hat. Videos und andere Daten zu mischen ist keine gute Idee.

    Seit mindestens 15. April findet von der IP-Nummer 91.64.90.61 alle paar Minuten ein Download von git.tvdr.de statt:

    Code
    1. Apr 24 17:20:25 racoon git-daemon[19143]: Connection from 91.64.90.61:42956
    2. Apr 24 17:20:25 racoon git-daemon[19143]: Extended attribute "host": git.tvdr.de
    3. Apr 24 17:20:25 racoon git-daemon[19143]: Request upload-pack for '/vdr.git'
    4. Apr 24 17:20:25 racoon git-daemon[556]: [19143] Disconnected

    Gut, kann man machen, muss man aber nicht.

    Die IP-Nummer gehört zu Vodafone und ist in der Gegend Otterndorf in Niedersachsten beheimatet.

    Hat vielleicht zufällig irgend jemand hier einen Job aufgesetzt, der das alle drei Minuten macht und irgendwie aus dem Ruder gelaufen ist?

    @lnj: I think you're on to something here.

    As a quick test, please apply this:

    This will prevent VDR from waiting for more index data in case a recording is still active.

    If this solves the problem, I'll see how I can use the ".timer" file for this, which tells exactly whether or not a recording is still active.