Posts by linuxdxs

    Ich habe die Lösung:


    Mein Testskript hat einen kleinen Zusatz bekommen:


    hwclock --systohc --localtime

    DEV=/sys/class/rtc/rtc0/wakealarm

    sudo chmod a+wr $DEV

    ethtool -s eth0 wol g


    # wakealarm löschen (wenn schon gesetzt, muss er gelöscht werden)

    echo 0 > $DEV

    #alarm setzen


    timedatectl set-local-rtc 0

    nextboot=`date --date "now +180 seconds" "+%s"`

    echo $nextboot > $DEV # Einige Mainboards sind etwas begriffsstutzig,

    echo $nextboot > $DEV # sie kapieren erst nach zwei Aufrufen, was Sache ist.


    echo "Aktuelle Zeit: "`date "+%Y-%m-%d %H:%M:%S"`

    echo

    cat /proc/driver/rtc

    echo

    echo "Fahre Rechner runter."


    shutdown -h now

    EXITSTATUS=0

    exit $EXITSTATUS


    Jetzt funktioniert das Skript


    Danke für Euro Denkanstöße

    Ich habe die Batterie ausgetauscht, Clear Cmos gemacht und die RTC auf UTC eingestellt. Jetzt ein paar aml ca. 2 Std gewartet. Aber das Bord will sich nicht einschalten.


    timedatectl gibt folgendes aus



    Local time: Sa 2021-09-18 12:40:58 CEST

    Universal time: Sa 2021-09-18 10:40:58 UTC

    RTC time: Sa 2021-09-18 12:40:58

    Time zone: Europe/Berlin (CEST, +0200)

    System clock synchronized: yes

    NTP service: active

    RTC in local TZ: yes

    Warning: The system is configured to read the RTC time in the local time zone.

    This mode cannot be fully supported. It will create various problems

    with time zone changes and daylight saving time adjustments. The RTC

    time is never updated, it relies on external facilities to maintain it.

    If at all possible, use RTC in UTC by calling

    'timedatectl set-local-rtc 0'.


    Hätte noch jmd eine Idee?

    timedatectl gibt folgendes aus:


    Local time: Fr 2021-09-17 18:10:52 CEST

    Universal time: Fr 2021-09-17 16:10:52 UTC

    RTC time: Fr 2021-09-17 18:10:52

    Time zone: Europe/Berlin (CEST, +0200)

    System clock synchronized: yes

    NTP service: active

    RTC in local TZ: yes


    Warning: The system is configured to read the RTC time in the local time zone.

    This mode cannot be fully supported. It will create various problems

    with time zone changes and daylight saving time adjustments. The RTC

    time is never updated, it relies on external facilities to maintain it.

    If at all possible, use RTC in UTC by calling

    'timedatectl set-local-rtc 0'.


    Was soll ich jetzt machen?

    Bei mir läuft openSUSE Leap 15.3. Das Bord selber könnte schon ca. zehn Jahre alt sein.

    Das Skript, welches den Timer programmiert sieht folgendermaßen aus;


    #!/bin/sh

    sudo hwclock --systohc --localtime

    DEV=/sys/class/rtc/rtc0/wakealarm

    sudo chmod a+wr $DEV


    # wakealarm löschen (wenn schon gesetzt, muss er gelöscht werden)

    echo 0 > $DEV


    #alarm setzen

    nextboot=`date --date "now +180 seconds" "+%s"`

    echo $nextboot > $DEV

    echo $nextboot > $DEV


    ethtool -s eth0 wol g

    echo "Aktuelle Zeit: "`date "+%Y-%m-%d %H:%M:%S"`

    echo

    cat /proc/driver/rtc

    echo

    echo "Fahre Rechner runter."

    poweroff

    #shutdown -h now

    EXITSTATUS=0

    exit $EXITSTATUS

    Hallo Forum,


    ich weiß, es ist ein altes Board, aber dieses Bord habe ich halt hier. Auf dem Bord läuft open Suse. Ich wollte dieses Bord per ACPI zum Aufnahmzeitpunkt starten. Es funktioniert weder durch ACPI noch durch nvram. Kann es sein, daß dieses Bord grundsätzlich nicht per Timer aktiviert werden kann?

    Was mir auch auffällt, obwohl die Alarmzeit richtig eingestellt wurde, steht diese nach einem händischen einschalten auf 00:00 Uhr und dem nächsten Tag.


    Einstellen der Weckzeit:

    Aktuelle Zeit: 2021-09-17 09:33:34

    rtc_time : 09:33:34

    rtc_date : 2021-09-17

    alrm_time : 09:38:34

    alrm_date : 2021-09-17

    alarm_IRQ : no

    alrm_pending : no

    update IRQ enabled : no

    periodic IRQ enabled : no

    periodic IRQ frequency : 1024

    max user IRQ frequency : 64

    24hr : yes

    periodic_IRQ : no

    update_IRQ : no

    HPET_emulated : no

    BCD : yes

    DST_enable : no

    periodic_freq : 1024

    batt_status : okay


    cat /proc/driver/rtc nach händischen neustart

    rtc_time : 09:47:29

    rtc_date : 2021-09-17

    alrm_time : 00:00:00

    alrm_date : 2021-09-18

    alarm_IRQ : no

    alrm_pending : no

    update IRQ enabled : no

    periodic IRQ enabled : no

    periodic IRQ frequency : 1024

    max user IRQ frequency : 64

    24hr : yes

    periodic_IRQ : no

    update_IRQ : no

    HPET_emulated : no

    BCD : yes

    DST_enable : no

    periodic_freq : 1024

    batt_status : okay


    Hättet ihr eine Idee wie man dieses Problem lösen könnte?

    Jetzt die Frage, wie kann man das nachvollziehen. Debugging habe ich versucht, aber ohne Anleitung für Deppen kann ich da nichts machen. Im IE habe ich nichts gefunden was mir weiterhilft.

    Ich bin noch überm schauen, aber jetzt ist der Server einfach beim Umschalten abgestürzt.



    Was soll das mit dem "Bad file descriptor"?

    Hab jetzt folgendes gemacht:
    Auf einem Client ARD, auf dem nächste RTL, dann im PIP Pro7 und auf dem letzten JAMFM. Es funktionieren alle vier Empfänger einwandfrei. Kann ich dann davon ausgehen, daß alle Empfanhsteile richtig arbeiten?

    Heute Morgern war folgende Fehlermeldung vor dem Absturz in der LOG-Datei:



    Wieß keiner woran das wohl liegt?

    Hallo Forum, ich schon wieder. Jetzt das nächste Problem. Ich habe diesen kopflosen Sever in dem die Empfängerkarten eingebaut sind, läuft ja auch relativ stabil, außer wenn z.B. sich ein neuer Klient anmeldet, dann stürzt der VDR einfach ab.


    Hier der Logbucheintrag


    Wo soll ich anfangen zu suchen? Soll ich eine andere Version des streamdev-Plugin probieren(zur Zeit ist vdr-plugin-streamdev-69b654d5393189c9c23dcc1241d8ab0588bae355.tar.gz installiert). Ich habe auch gelesen, daß solch eine Fehlermeldung bei falschen Dateirechten passieren kann. Darauf hin habe ich alle Dateirechte nach 666 getauscht. Hat aber auch nicht geholfen.


    Mal wieder ein dickes Danke für eure Hilfe.

    Hea super, muß ich sofort verfolgen. ;-) Ne Du, Spaß beiseite. Wie krieg ich den diese Fehlermeldung weg. Vorallem Kanal 1 nicht verfügbar? Ich habe mit w_scan cie channels.conf erstellt. Kene Ahnung.

    Hallo Forum bei mir kommt immer wieder folgende Meldung, Was soll mir diese Meldung sagen?


    Code
    1. 2013-10-24T12:18:03.526598+02:00 linux-pua3 vdr: [1293] switching to channel 1
    2. 2013-10-24T12:18:03.527011+02:00 linux-pua3 vdr: [1293] info: Channel not available!
    3. 2013-10-24T12:18:14.527923+02:00 linux-pua3 vdr: [1293] switching to channel 1
    4. 2013-10-24T12:18:14.528311+02:00 linux-pua3 vdr: [1293] info: Channel not available!
    5. 2013-10-24T12:18:25.530701+02:00 linux-pua3 vdr: [1293] switching to channel 1
    6. 2013-10-24T12:18:25.531095+02:00 linux-pua3 vdr: [1293] info: Channel not available!
    7. 2013-10-24T12:18:36.533176+02:00 linux-pua3 vdr: [1293] switching to channel 1
    8. 2013-10-24T12:18:36.533546+02:00 linux-pua3 vdr: [1293] info: Channel not available!
    9. 2013-10-24T12:18:47.534910+02:00 linux-pua3 vdr: [1293] switching to channel 1

    Ich habe den Fehler gefunden, man kann ja so blöd sein. Ich habe nach der Anleitung von Hubertus Sandmann gearbeitet. Die Anleitung ist einfach der Hammer, lesen machen funktioniert. Ich habe nur eins nicht beachtet, das eingebundene Plugin von Hr. Sandmann, dvbhddevice, ist für eine ganz andere Karte gedacht. EInfach das Plugin weglassen und schon klappts. Bei mir war es zumindest so.


    Für Eure Unterstützung bedanke ich mich.