[gelöst] Kein ACPI wakeup nach Neuinstallation auf Debian Stretch

  • Hallo, liebes Forum,

    vielleicht (bestimmt) könnt Ihr mir wieder mal helfen. Ich habe ca 2. Jahre einen VDR auf einem Elitegroup A780GM-A laufen. Jetzt habe ich den vdr neu aufgesetzt mit Debian Stretch mit systemd. Die alte Installation steht noch zur Verfügung als Referenz.

    Mit der alten Installation wacht das Board

    Code
    echo 0 > /sys/class/rtc/rtc0/wakealarm
    echo 1514806200 > /sys/class/rtc/rtc0/wakealarm

    wie gewünscht auf. Bei der Neuen tut sich schlicht nichts. Debian läuft auf UTC, Bios-Uhr ist eine Stunde zurück. Heruntergefahren habe ich das Board mit

    Code
    shutdown -h now und
    systemctl hibernate oder
    systemctl suspend (jeweils testweise)

    Hat jemand eine Idee?

    Danke schon mal im Voraus.

  • Debian läuft auf UTC, Bios-Uhr ist eine Stunde zurück.

    Das BIOS sollte immer mit UTC laufen.

    Aber nehmen wir mal an, das wäre der Fall:

    Dann wäre deine Systemzeit jetzt z.B. 11:52:00 und dein BIOS wäre bei 10:52:00 - dann musst du noch warten, damit das um 12:30 Uhr aufwacht...

    Meine VDRs

    VDR 1: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce GT 1030, Ubuntu 24.04 (yavdr-ansible), VDR 2.7.4, CIR-Empfänger
    VDR 2: Acer Revo 3610, Pinnacle PCTV SAT 452e, Medion X10, yaVDR 0.6
    Client 1: Raspberry Pi 2, Ubuntu 22.04 (yavdr-ansible), VDR 2.6.1

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Vielen Dank, seahawk1986,

    ich habe brav noch eine Stunde gewartet, aber er wacht nicht auf. Meines Wissens unterscheidet sich aber auch die Systemzeit von der Bioszeit, da ja UTC die allgemeine Zeit ist.

    Nichts desdo trotz gibt ein

    und das ist so ziemlich das gleiche wie bei der alten Installation. :(

    Noch irgendjemand eine Idee?

  • Meines Wissens unterscheidet sich aber auch die Systemzeit von der Bioszeit, da ja UTC die allgemeine Zeit ist.

    Also normalerweise sollte das so aussehen:

    Die RTC läuft in UTC, das System nutzt für die Anzeige die eingestellte Zeitzone - das wäre hierzulande im Winter CET aka MEZ, wie einem z.B. date verrät:

    Code
    $ date
    Mo 1. Jan 14:18:32 CET 2018
    $ date -u
    Mo 1. Jan 13:18:35 UTC 2018
    $ date +%s
    1514812723

    Probier es mal mit relativen Zeitangaben:

    Code
    echo 0 > /sys/class/rtc/rtc0/wakealarm
    echo $(date -d "now +10 min" +%s) > /sys/class/rtc/rtc0/wakealarm
    poweroff
    Meine VDRs

    VDR 1: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce GT 1030, Ubuntu 24.04 (yavdr-ansible), VDR 2.7.4, CIR-Empfänger
    VDR 2: Acer Revo 3610, Pinnacle PCTV SAT 452e, Medion X10, yaVDR 0.6
    Client 1: Raspberry Pi 2, Ubuntu 22.04 (yavdr-ansible), VDR 2.6.1

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Code
    root@vdr4:/home/vdr# date
    Mo 1. Jan 14:29:35 CET 2018
    root@vdr4:/home/vdr# date -u
    Mo 1. Jan 13:29:53 UTC 2018
    root@vdr4:/home/vdr# date +%s
    1514813415

    Test mit relativen Zeitangaben läuft.

  • Ich habe den Fehler gefunden: Kernel Parameter!

    Die waren vom System wie folgt gesetzt:

    Code
    GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
    GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi=noirq"

    und ich habe diese abgeändert in:

    Code
    GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
    GRUB_CMDLINE_LINUX_DEFAULT="quiet"
    GRUB_CMDLINE_LINUX="hpet=disable"

    danach lief es dann. Ich hätte nur in meiner alten Installation nachschauen müssen. Aber man muss ja erst mal drauf kommen, das es an den Kernelparametern liegt.

    Vielen Dank, seahawk1986, für deine Antwort.

  • Ja, aber "hpet" ist schon lange bekannt als ACPI Wakeup "Killer" ...

    HowTo: APT pinning

    Click for my gear

    [¹] Intel NUC Kit NUC7i5BNH, Akasa Newton S7, 8GB DDR4, WD Black SN700 500GB NVMe, Crucial MX500 2TB, CIR, SAT>IP, Ubuntu LTS 18.04.5, VDR 2.4.1 (15W)
    [²] Intel NUC Kit NUC7i3BNH, 8GB DDR4, WD PC SN520 250GB NVMe, Crucial MX500 1TB, CIR, SAT>IP, Ubuntu LTS 20.04.1, VDR 2.4.1 (13W)
    [³] BQ500, Asrock X470D4U, AMD Ryzen 5 5600, 32GB DDR4 ECC, 2x WDC SN750 512GB, 4x Samsung SSD 4TB, 1x Samsung SSD 8TB, 1x Crucial MX500 500GB, 1x WDC Blue SSD 500GB, Windows Server 2019 Hyper-V (35W)
    [⁴] Jultec JPS0501-12AN, JPS0501-8M2, Octopus Net (DVBS2-8) & openHABian 3.3.0

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!