Notebook Akku Entlädt sich obwohl heruntergefahren , Linux

[Börge L. (coollooc)]

Hallo Forengemeinde,

ich brauche mal Hilfe von den Linux Profis, bitte !

Ich habe ein HP Notebook im Dual Boot mit WIN 10 und Kubuntu 16.04 LTS 
installiert. Im UEFI Mode. Läuft alles gut, ABER…

Wenn ich Linux herunterfahre, und dann das Notebook stehen lasse, 
entlädt sich der Akku sehr schnell, pro Std. ca 1 %, sprich 24 Std 
später ca 24%, das ist nicht normal.

Wenn ich Linux  herunterfahre und den Akku kurz rausziehe , so das das 
Gerät komplett Stromlos ist, und dann den Akku wieder einsetzte und 
stehen lasse ,entlädt sich der Akku nicht.

Im BIOS gibt es keinerlei Powermanagment Einstellungen oder sonst was.
Es sind auch keine USB Geräte angeschlossen.
Wake on Lan habe ich schon mit ETHTOOL deaktiviert

Der Witz an der Sache ist, wenn ich den Rechner mit WIN 10 starte und 
wieder herunterfahre,
bleibt die Akkuladung erhalten, sprich keinerlei Entladung.

Es muss irgendwo ein Linux Problem sein, da unter WIN 10 sich der 
Akku/Notebook vollkommen normal verhält.

Im I-Net habe ich auch schon viele Beiträge gelesen, die meisten 
verweisen auf Wake on LAN, wie oben schon gesagt, ist WOL aus.

Was ich noch gefunden habe, ist dieses hier:

„I finally found the cause of the issue: the command "hwclock --systohc 
--local" causes the battery to drain when the laptop is off.
This command is executed by the /etc/init.d/hwclock script.
If I set clock_hctosys="NO" in /etc/conf.d/hwclock, that command does 
not get executed anymore, and the battery does not drain.“

Nur irgendwie scheiter ich gerade daran, das umzusetzen, weil ich nicht 
weis wo ich das
clock_hctosys="NO" einsetzen soll. Scheint ein anderes oder älteres 
Linux Derivat zu sein.
So tiefe System Kenntnisse habe ich nun auch nicht.

Ich weis nun nicht mehr weiter  und hoffe auf Hilfe innerhalb dieses 
Forum

Gruß Börge

[Nick S. (c0re)]

Börge L. schrieb:
> /etc/init.d/hwclock

WAs passiert denn, wenn du in die CMD/Kommandozeile 'sudo nano 
/etc/init.d/hwclock' eingibst?

Der Befehl würde das hwclock script mit einem textbasierten Editor(nano) 
öffnen. Falls dann ein leeres Fenster aufgeht gibt es dieses Script bei 
dir nicht, falls dann da Text steht suche nach dem Eintrag 
'clock_hctosys ="YES"' oder füge ihn ans Ende der Datei an. Mit STRG+X 
kannst du den Editor verlassen,falls du was geändert hast mit 'y' 
bestätigen oder mit 'n' verwerfen


Börge L. schrieb:
> So tiefe System Kenntnisse habe ich nun auch nicht.

Wofür benutzt du denn das Linux?

[Jupp (Gast)]

Ubuntu hat da leider einiges Chaos mit verschiedenen init-Systemen 
angerichtet. Finde heraus, weches verwendet wird:

cat /proc/1/comm

Die jeweligen Scripte finden sich hier:

SysVinit: alle Dateien im Ordner /etc/init.d/
Upstart: .conf-Dateien im Ordner /etc/init/
systemd: /etc/systemd/system/ bzw. /lib/systemd/system/

[Jupp (Gast)]

PS: Wenn das manuelle Navigieren oder Bearbeiten zu mühsam oder zu 
unbekannt ist, mc installieren. Optik entspricht ungefähr dem alten 
Norton Commander.

[Börge L. (coollooc)]

wo soll ich denn da clock_hctosys="NO" einsetzen ? siehe code unten
und löst das überhaupt das Akku Problem?

cat /proc/1/comm ergibt systemd

#!/bin/sh
# hwclock.sh  Set and adjust the CMOS clock.
#
# Version:  @(#)hwclock.sh  2.00  14-Dec-1998  [e-mail]
#
# Patches:
#    2000-01-30 Henrique M. Holschuh <[e-mail]>
#     - Minor cosmetic changes in an attempt to help new
#       users notice something IS changing their clocks
#       during startup/shutdown.
#     - Added comments to alert users of hwclock issues
#       and discourage tampering without proper doc reading.
#               2012-02-16 Roger Leigh <[e-mail]>
#                - Use the UTC/LOCAL setting in /etc/adjtime rather than
#                  the UTC setting in /etc/default/rcS.  Additionally
#                  source /etc/default/hwclock to permit configuration.

### BEGIN INIT INFO
# Provides:          hwclock
# Required-Start:    mountdevsubfs
# Required-Stop:     mountdevsubfs
# Should-Stop:       umountfs
# Default-Start:     S
# X-Start-Before:    checkroot
# Default-Stop:      0 6
# Short-Description: Sync hardware and system clock time.
### END INIT INFO

# These defaults are user-overridable in /etc/default/hwclock
BADYEAR=no
HWCLOCKACCESS=yes
HWCLOCKPARS=
HCTOSYS_DEVICE=rtc0

# We only want to use the system timezone or else we'll get
# potential inconsistency at startup.
unset TZ

hwclocksh()
{
    [ ! -x /sbin/hwclock ] && return 0
    [ ! -r /etc/default/rcS ] || . /etc/default/rcS
    [ ! -r /etc/default/hwclock ] || . /etc/default/hwclock

    . /lib/lsb/init-functions
    verbose_log_action_msg() { [ "$VERBOSE" = no ] || log_action_msg "$@"; }

    case "$BADYEAR" in
       no|"")  BADYEAR="" ;;
       yes)  BADYEAR="--badyear" ;;
       *)  log_action_msg "unknown BADYEAR setting: \"$BADYEAR\""; return 1 ;;
    esac

    case "$1" in
  start)
      # If the admin deleted the hwclock config, create a blank
      # template with the defaults.
      if [ -w /etc ] && [ ! -f /etc/adjtime ] && [ ! -e /etc/adjtime ]; then
          printf "0.0 0 0.0\n0\nUTC\n" > /etc/adjtime
      fi

      if [ -d /run/udev ] || [ -d /dev/.udev ]; then
    return 0
      fi

      if [ "$HWCLOCKACCESS" != no ]; then
    log_action_msg "Setting the system clock"

    # Just for reporting.
    if sed '3!d' /etc/adjtime | grep -q '^UTC$'; then
        UTC="--utc"
    else
        UTC=
    fi
    # Copies Hardware Clock time to System Clock using the correct
    # timezone for hardware clocks in local time, and sets kernel
    # timezone. DO NOT REMOVE.
    if /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --hctosys $HWCLOCKPARS $BADYEAR; then
        #  Announce the local time.
        verbose_log_action_msg "System Clock set to: `date $UTC`"
    else
        log_warning_msg "Unable to set System Clock to: `date $UTC`"
    fi
      else
    verbose_log_action_msg "Not setting System Clock"
      fi
      ;;
  stop|restart|reload|force-reload)
      #
      # Updates the Hardware Clock with the System Clock time.
      # This will *override* any changes made to the Hardware Clock.
      #
      # WARNING: If you disable this, any changes to the system
      #          clock will not be carried across reboots.
      #

      if [ "$HWCLOCKACCESS" != no ]; then
    log_action_msg "Saving the system clock"
    if /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --systohc $HWCLOCKPARS $BADYEAR; then
        verbose_log_action_msg "Hardware Clock updated to `date`"
    fi
      else
    verbose_log_action_msg "Not saving System Clock"
      fi
      ;;
  show)
      if [ "$HWCLOCKACCESS" != no ]; then
    /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --show $HWCLOCKPARS $BADYEAR
      fi
      ;;
  *)
      log_success_msg "Usage: hwclock.sh {start|stop|reload|force-reload|show}"
      log_success_msg "       start sets kernel (system) clock from hardware (RTC) clock"
      log_success_msg "       stop and reload set hardware (RTC) clock from kernel (system) clock"
      return 1
      ;;
    esac
}

hwclocksh "$@"

[Börge L. (coollooc)]

Soll ich den Wert clock_hctosys="NO"
in die /etc/init/hwclock.conf schreiben,
wenn ja wo genau?

Sorry für mein Unwissen, nur ändere ich eher gar nichts an System 
internen scripten.

# hwclock - adjust system clock and timezone
#
# The hwclock task adjusts the system clock when the hardware clock is
# set to localtime (e.g. when dual-booting with Windows), and also
# ensures that the system timezone is set so that timestamps are written
# to FAT devices.

description  "adjust system clock and timezone"

start on starting mountall

task

script
    # BADYEAR can be in either file
    . /etc/default/rcS
    [ ! -r /etc/default/hwclock ] || . /etc/default/hwclock
    grep -qw LOCAL /etc/adjtime 2>/dev/null && tz="--localtime" || tz="--utc"
    [ "$BADYEAR" = "yes" ] && badyear="--badyear"
    exec hwclock --systz $tz --noadjfile $badyear
end script

[Nop (Gast)]

Eine interessante Frage ist natürlich auch, warum man überhaupt erst mit 
irgendwelchen Scripten rumfrickeln muß, um ein Verhalten zu bekommen, 
was selbstverständlich sein sollte.

[npn (Gast)]

Nop schrieb:
> Eine interessante Frage ist natürlich auch, warum man überhaupt
> erst mit
> irgendwelchen Scripten rumfrickeln muß, um ein Verhalten zu bekommen,
> was selbstverständlich sein sollte.

Jupp schrieb:
> Ubuntu hat da leider einiges Chaos mit verschiedenen init-Systemen
> angerichtet.

[Nop (Gast)]

npn schrieb:
> Jupp schrieb:
>> Ubuntu hat da leider einiges Chaos mit verschiedenen init-Systemen
>> angerichtet.

Das ist halt eine Umstellung, aber das Ergebnis wirkt doch so, daß 
ambitioniert herumgebastelt wurde, ohne aber dann auch die nötige 
Testtiefe zu fahren. Sprich, mehr abgebissen als man kauen konnte. Das 
ist insbesondere bemerkenswert, weil Ubuntu ja nicht Arch ist und sich 
ausdrücklich als nutzerfreundliche Distri versteht.

Sieht so aus, als wenn "it just works" immer noch kein sonderlich 
wichtiges Feature ist.

[g457 (Gast)]

> Sorry für mein Unwissen, nur ändere ich eher gar nichts an System
> internen scripten.

Du sollst ja auch nix an den Skripten ändern, sondern wenn dann dadort:

> [ ! -r /etc/default/hwclock ] || . /etc/default/hwclock
                                     ^^^^^^^^^^^^^^^^^^^^

(sorry für die überflüssigen 'code' Tags, die Forensoftware macht bei 
mir irgendwie lustige Sachen wenn ich sie weglasse..)

[npn (Gast)]

g457 schrieb:
> (sorry für die überflüssigen 'code' Tags, die Forensoftware macht bei
> mir irgendwie lustige Sachen wenn ich sie weglasse..)

Weshalb "überflüssig"?
Die sind genau für diesen Zweck da.
btw.: [pre] tut's auch

[Börge L. (coollooc)]

Habe nun die Datei /etc/default/hwclock angelegt
und den Wert clock_hctosys=no eingetragen.

War das so gemeint?

Zumindest starte ich die Kiste mal neu und fahre sie wieder runter.

Dann sehe ich ja, ob sich der Akku bis heute Abend entlädt oder nicht.

[g457 (Gast)]

> Weshalb "überflüssig"?

Die Forensoftware sollte den geposteten Inhalt nicht willkürlich 
sinnentfremden. Egal ob 'code' oder 'pre', sie sollten hier nicht nötig 
sein. Das nenne ich 'überflüssig'.

[g457 (Gast)]

> War das so gemeint?

Im Prinzip ja. Obs die richtige Variable war oder ob diese veraltet ist 
oder ob Du überhaupt auf dem richtigen Dampfer bist wird sich 
hoffentlich bald zeigen. Wenn nicht heissts weitersuchen :-)

[npn (Gast)]

g457 schrieb:
>> Weshalb "überflüssig"?
>
> Die Forensoftware sollte den geposteten Inhalt nicht willkürlich
> sinnentfremden. Egal ob 'code' oder 'pre', sie sollten hier nicht nötig
> sein. Das nenne ich 'überflüssig'.

Das liegt daran, daß die Software verschiedene Zeichen als Steuerzeichen 
bzw. Formatierungszeichen interpretiert. Das heißt, für denjenigen, der 
sie benötigt, sind sie eben nicht überflüssig, sondern sogar notwendig. 
Wenn man solche Dinge nicht benötigt, schließt man seinen Text in die 
bekannten Tags ein und ist damit sicher, daß der Text so erscheint, wie 
man möchte.

[Börge L. (coollooc)]

Börge L. schrieb:
> Habe nun die Datei /etc/default/hwclock angelegt
> und den Wert clock_hctosys=no eingetragen.
>

oder muss der Wert clock_hctosys="NO" sein ?

[(prx) A. K. (prx)]

Börge L. schrieb:
> Wenn ich Linux herunterfahre, und dann das Notebook stehen lasse,
> entlädt sich der Akku sehr schnell, pro Std. ca 1 %, sprich 24 Std
> später ca 24%, das ist nicht normal.

Das Gerät schaltet möglicherweise nicht vollständig ab. Das kann diverse 
Ursachen haben, vom Grafiksystem bis zum BIOS-Fehler. BIOS aktuell?

[npn (Gast)]

A. K. schrieb:
> BIOS aktuell?

Aber wenn er vorher Windows gestartet hatte, ist dieser Effekt nicht 
vorhanden. Dann kann's doch nicht am BIOS liegen, oder?
Wenn hingegen Linux nicht alle Komponenten sauber runterfährt bzw. 
beendet, dann ist das schon eine Möglichkeit.

[Börge L. (coollooc)]

A. K. schrieb:
> Börge L. schrieb:
>> Wenn ich Linux herunterfahre, und dann das Notebook stehen lasse,
>> entlädt sich der Akku sehr schnell, pro Std. ca 1 %, sprich 24 Std
>> später ca 24%, das ist nicht normal.
>
> Das Gerät schaltet möglicherweise nicht vollständig ab. Das kann diverse
> Ursachen haben, vom Grafiksystem bis zum BIOS-Fehler. BIOS aktuell?

BIOS hat neusten Stand.

Wie geschrieben, nachdem man WIN 10 gestartet und beendet hat, entlädt 
sich der Akku nicht.
Genauso entlädt sich der Akku nicht, wenn man Linux beendet , den akku 
kurz rausnimmt und wieder einsteckt.

Genauso konnte ich mit einem Leistungmessgerät ermitteln,
das wenn ich den Notebook ohne Akku betreibe und dann herunterfahre,
das immer nur beim beenden vom Linux noch ein kleiner Verbrauch da ist.
Bei WIN 10 nicht.

[R. M. (Gast)]

Probiere doch mal, vor dem Herunterfahren, WOL zu deaktivieren:
sudo /sbin/ethtool -s eth0 wol d
(eth0 muss eventuell durch den realen Netzwerkadapter ersetzt werden).

Beitrag "gelöst: Laptop Netzwerkkarte bleibt aktiv nach herunterfahren, ubuntu"

Wenn die Ursache hier liegt, erkennst du es daran, das die Linkanzeige 
am Switch nach Herunterfahren aktiv bleibt. Selbst wenn kein LAN 
angeschlossen ist, verbraucht der Adapter Energie im Ruhezustand, wenn 
WOL aktiv ist.

[Börge L. (coollooc)]

R. M. schrieb:
> Probiere doch mal, vor dem Herunterfahren, WOL zu deaktivieren:

Danke für den Hinweis, aber WOL habe ich schon aus.

Habe nun nochmal mit dem Leistungsmessgerät gemessen,
egal ob ich clock_hctosys="NO" oder clock_hctosys=no
eintrage,
das Notebook verbraucht nach dem heruntefahren von Linux Strom.

[(prx) A. K. (prx)]

npn schrieb:
> Aber wenn er vorher Windows gestartet hatte, ist dieser Effekt nicht
> vorhanden. Dann kann's doch nicht am BIOS liegen, oder?

ACPI ist berüchtigt für Fehler, die überall auftreten, nur nicht in 
Windows. Welcher BIOS Programmierer bringt schon ein Board raus, das in 
Windows nicht sauber funktioniert?

[Daniel A. (daniel-a)]

Börge L. schrieb:
> cat /proc/1/comm ergibt systemd

OMG.

Naja, dann müsste man dass ja theoretisch mit "systemctl disable 
hwclock" oder "systemctl mask hwclock" ausschalten können. Aber warum 
beim Starten die Uhrzeiteinstellungen anzupassen das Verhalten nach dem 
Ausschalten des PCs beeinflussen sollte ist mir schleierhaft. (und ich 
habe das Kommando nicht getestet).

Tritt das Verhalten auch bei anderen Distros auf, die z.B. ein anderes 
init system nutzen? (Void, Devuan, TinyCore)

Vor dem Testen jeweils das mit dem Akku rausnehmen machen, damit das 
Problem nicht vom letzten Start übernommen wird.

[c.m. (Gast)]

ich glaube da auch eher an ein nicht sauber implementiertes BIOS/ACPI.
"hwclock --systohc" schreibt die kerneltimer zeit in den clock-chip - 
fertig.
nach herunterfahren des betriebssystems hat dieser chip halt eine 
aktualisierte zeit und läuft weiter vor sich hin, wie immer.
hwclock auszuschalten bringt nichts, da hwclock bei heruntergefahrenem 
betriebssystem nichts machen kann.

mal was anderes: typische stromverbraucher, eventuell auch im 
ausgeschaltenen zustand, sind USB-geräte (tastaturen, mäuse, webcams - 
auch die im deckel).
eventuell werden die energieversorgungen der USB-anschlüsse nicht 
abgeklemmt.
mit powertop mal prüfen was alles kein power management aktiviert hat, 
manuell aktivieren, runterfahren und schauen ob der verbrauch dann 
immernoch auftritt.
wenn nein, die einstellungen übernehmen (in rc.local z.b.).

[Börge L. (coollooc)]

c.m. schrieb:
> mit powertop mal prüfen was alles kein power management aktiviert hat,
> manuell aktivieren, runterfahren und schauen ob der verbrauch dann
> immernoch auftritt.

Habe nun mal Powertop installiert und im Menü dann alle Einstellungen 
auf Gut übernommen und neu gestartet.
Leider kein Erfolg.

Was mir augefallen ist, sobald ich im powertop nur EINE Änderung 
vornehme und dann herunter fahre, verbraucht das Notebook mehr Strom wie 
ohne Änderung

[bingo. (Gast)]

Sehr merkwürdig, ich habe hier 2 Notebooks mit Ubuntu 16.04 und beide 
brauchen absolut nix, wenn runtergefahren.

Fährst Du wirklich den Rechner echt runter oder ist das evtl. eine 
Bereitschaft: das Verhalten, dass der Rechner erst nach dem Abklemmen 
des Akkus wirklich aus ist, spricht sehr dafür.

[Rolf M. (rmagnus)]

A. K. schrieb:
> npn schrieb:
>> Aber wenn er vorher Windows gestartet hatte, ist dieser Effekt nicht
>> vorhanden. Dann kann's doch nicht am BIOS liegen, oder?
>
> ACPI ist berüchtigt für Fehler, die überall auftreten, nur nicht in
> Windows. Welcher BIOS Programmierer bringt schon ein Board raus, das in
> Windows nicht sauber funktioniert?

ACPI ist der letzte Schrott. Und es ist designt dafür, nur mit Windows 
vernünftig zusammen zu arbeiten. Bill Gates hat da ganze Arbeit 
geleistet…
Siehe 
https://de.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Kritik

[g457 (Gast)]

> Das liegt daran, daß die Software verschiedene Zeichen als Steuerzeichen
> bzw. Formatierungszeichen interpretiert.

Echt? Ich dachte Leerzeichen(!) sind dazu da um leer zu sein und die 
Forensoftware sollte sie in Ruhe lassen. Tuts sie hier aber leider nicht 
-> ich musste überflüssige(!) 'code' Tags einfügen, damit die 
Forensoftware keinen Schmarrn macht.

EOD

[npn (Gast)]

g457 schrieb:
> Echt? Ich dachte Leerzeichen(!) sind dazu da um leer zu sein und die
> Forensoftware sollte sie in Ruhe lassen. Tuts sie hier aber leider nicht

Es gibt verschiedene Schriftarten.
Wenn du mit [pre] formatierst, wird eine monospace Schriftart verwendet. 
In der Vorschau dagegen eine proportionale Schriftart. Das sieht dann 
nur so aus, als wenn Leerzeichen fehlen. Sie sind halt viel schmaler als 
ein Buchstabe. Bei Monospace ist jedes Zeichen (egal ob Leerzeichen oder 
Buchstabe) gleich breit.
Die Tags bewirken, daß der Text als monospace ausgegeben wird.

[Börge L. (coollooc)]

bingo. schrieb:
> Fährst Du wirklich den Rechner echt runter oder ist das evtl. eine
> Bereitschaft: das Verhalten, dass der Rechner erst nach dem Abklemmen
> des Akkus wirklich aus ist, spricht sehr dafür.

Ich fahre Über das Verlassen / Herunterfahren Menü in der 
Anwendungsstarter Leiste herunter.
Oder mit dem Befehl halt -p
Immer der gleiche Effeckt, der Rechner zieht weiterhin Strom , zwar nur 
minimal, aber es reicht um den Akku Leer zu saugen.

Das Ausschalten mit halt -f und dann 3 sec. drücken des Netzschalters 
schaltet die Kiste zumindest richtig aus.

Das kann ja nicht so richtig sein.

[knollo (Gast)]

A. K. schrieb:
> Das Gerät schaltet möglicherweise nicht vollständig ab

Darauf tippe ich auch. Mein Laptop z.B. fährt, obgleich anders 
eingestellt, nach dem Deckel zu machen in einen Suspend-Modus.

https://de.wikipedia.org/w/index.php?title=Bereitschaftsbetrieb&oldid=161712965

Deshalb muß ich immer "ordentlich" ausschalten und ich warte bis Ruhe 
ist!
Andernfalls ist der Akku andertags leer (ist auch schon etwas älter).
MfG

[Daniel A. (daniel-a)]

A. K. schrieb:
> ACPI ist berüchtigt für Fehler, die überall auftreten, nur nicht in
> Windows.

Was passiert, wenn du das System mit acpi=off startest? 
(https://askubuntu.com/a/160056)

[Thomas S. (doschi_)]

Börge L. schrieb:
> Ich fahre Über das Verlassen / Herunterfahren Menü in der
> Anwendungsstarter Leiste herunter.
> Oder mit dem Befehl halt -p

es könnte sein, dass der Befehl 'poweroff' (bzw. 'shutdown -P now')
"etwas mehr" ausschaltet.
Siehe z.B. 
https://serverfault.com/questions/191537/shutdown-what-is-difference-between-power-off-and-halt
Das wäre evtl. einen Versuch wert.

[Börge L. (coollooc)]

Daniel A. schrieb:
> Was passiert, wenn du das System mit acpi=off startest?
> (https://askubuntu.com/a/160056)


Das scheint wohl die Lösung zu sein :-) Dankeschön

Habe den Eintrag auch schon fest in Grub eingetragen.

Schade nur das dadurch ein paar einfache Funktionen des Notebook fehlen, 
die da wären z.B. Klappe schliessen und in Standby wechseln...
Oder kann man das noch Feintunen ?

Werde das jetzt noch genau über Nacht testen, ob der Akku auch wirklich 
hält..
Werde hier berichten..

Schon mal Danke an alle die hier mit Vorschlägen teilgenommen haben.

[Börge L. (coollooc)]

Na ja das gelbe vom Ei ist das auch nicht.

Nun habe ich ja keinerlei Anzeige zum Akku Ladestand.

Das geht gar nicht...

Da muss ich eine andere Lösung suchen

[Thomas S. (doschi_)]

'poweroff' ausprobiert?

[Börge L. (coollooc)]

Thomas S. schrieb:
> 'poweroff' ausprobiert?

Leider bringt das auch nichts...

Die Suche geht weiter...

Kann man denn beim ACPI nur teile ausschalten?

[JJ (Gast)]

Du kannst nochmal acpi=force probieren

[Jupp (Gast)]

Was sagt dmesg? Igendwelche ACPI-bezogenen Meldungen?

Die Wahrscheinlichkeit, dass ACPI bei diesem Gerät nicht wirlich 
Standardkonform ist, ist hoch. Google ist voll davon. Das wäre dann 
Sache des BIOS. Ich vermute, das Gerät geht in S5 statt komplett aus.

Viel Spaß mit dem HP-Support, vor allem, wenn es ein Consumergerät ist 
;)

Hier mal querlesen:

https://wiki.ubuntuusers.de/Energiesparmodi_mit_ACPI/

Das wird das Problem nicht lösen, aber vielleicht ist der richtige 
Zaunpfahl dabei.

[Börge L. (coollooc)]

Gibt es die Möglichkeit irgendwo einen aller letzten Befehl aus 
zuführen.
z.B. KILL -9 -1
oder welches script / Befehl wird zu aller Letzt ausgeführt ?
Würde das überhaupt was bringen?

Die Frage ist auch, was kann WIN besser als Linux ?
Weil unter WIN, fährt der Rechner einwandfrei runter.

Als Workaround habe ich zur Zeit folgendes.
1. Linux herunterfahren
2. Akku entfernen
3. Akku wieder einsetzen.

oder

1. Linux herunterfahren
2. Windows starten
3. Windows herunterfahren

Beides machbar nur nervig. Favorit ist erst genanntes , da schneller.

[Sheeva P. (sheevaplug)]

Börge L. schrieb:
> Gibt es die Möglichkeit irgendwo einen aller letzten Befehl aus
> zuführen.

Was gibt denn

systemctl status hwclock.service

aus? Hast Du den Ratschlag von Daniel Albrecht ausprobiert und

systemctl disable hwclock.service
systemctl mask hwclock.service

ausgeführt? Auf meinen Systemen mit Kubuntu 16.04 zeigt sich das von Dir 
beschriebene Verhalten nämlich nicht, da ist hwclock.service maskiert, 
also /lib/systemd/system/hwclock.service auf /dev/null gelinkt.

[bingo (Gast)]

Sollte das wirklich nur die hwclock sein? Immerhin zieht der mysteriöse 
Prozess 1%/Std. vom Akku, für die hwclock ist das erstaunlich viel.

Ich tippe ja immer noch auf ein ACPI-Problem, das zum S3 oder S5 führt. 
Blöd, dass das BIOS da nichts anzeigt.

Zeig das Problem doch mal im Ubuntu-Forum https://forum.ubuntuusers.de, 
da sitzen die Ubuntu-Cracks

[Sheeva P. (sheevaplug)]

bingo schrieb:
> Sollte das wirklich nur die hwclock sein? Immerhin zieht der mysteriöse
> Prozess 1%/Std. vom Akku, für die hwclock ist das erstaunlich viel.
>
> Ich tippe ja immer noch auf ein ACPI-Problem, das zum S3 oder S5 führt.
> Blöd, dass das BIOS da nichts anzeigt.

Jetzt laß' uns die Sache doch mal systematisch angehen, statt 
irgendwelche Vermutungen ins Blaue hinein zu starten. Also: hwclock 
disablen und masken und dann erst einmal schauen, ob das Problem behoben 
ist.

> Zeig das Problem doch mal im Ubuntu-Forum https://forum.ubuntuusers.de,
> da sitzen die Ubuntu-Cracks

Hier gibt es auch genügend Leute mit Debian- und Ubuntu-Erfahrung, 
glaube ich. Daniel Albrecht zum Beispiel ist ein sehr kompetenter 
Mensch.

[Börge L. (coollooc)]

Sheeva P. schrieb:
> Hast Du den Ratschlag von Daniel Albrecht ausprobiert und
> systemctl disable hwclock.service
> systemctl mask hwclock.service

Habe beide Befehle ausgeführt und es wird folgender Status angezeigt.
So richtig ?

systemctl status hwclock.service
Warning: hwclock.service changed on disk. Run 'systemctl daemon-reload' 
to reload units.
● hwclock.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)

[Rolf M. (rmagnus)]

Börge L. schrieb:
> Die Frage ist auch, was kann WIN besser als Linux ?
> Weil unter WIN, fährt der Rechner einwandfrei runter.

Wie oben schon gesagt, haben ACPI-Implementationen oft Bugs. Für Windows 
wurde dann ein Work-Around in den Treiber eingebaut. Wenn der gleiche 
Work-Around nicht in den Linux-Treiber auch integriert wurde, 
funktioniert es nicht richtig.

[Börge L. (coollooc)]

Rolf M. schrieb:
> Für Windows
> wurde dann ein Work-Around in den Treiber eingebaut.

Das ist natürlich ein Erklärung.

Aber kann man denn in Linux irgendwo am Ende des herunter fahren Prozess 
noch ein z.B. Killall oder sonstwas mitgeben?
Mir doch völlig egal, ob der letzte Process daduch stirbt !
So lange alle wichtigen Daten sicher auf der HD gelandet sind, kann der 
Rest doch einfach weg gehauen werden...

Ps. Die systemctl Dinge wie oben angegeben haben kein Änderung gebracht

[Rolf M. (rmagnus)]

Es ist ja kein Prozess, der weiterläuft, sondern irgendeine Hardware, 
die nicht ausgeschaltet wird. Die kann man nicht mit killall 
ausschalten.

[Börge L. (coollooc)]

Rolf M. schrieb:
> Es ist ja kein Prozess, der weiterläuft, sondern irgendeine Hardware,
> die nicht ausgeschaltet wird. Die kann man nicht mit killall
> ausschalten.

Klingt logisch, aber besteht vielleicht die Möglichkeit ein Signal an 
die Hardware zu senden, unter den Motto jetzt geh aus

[lalala (Gast)]

Nick S. schrieb:
> Börge L. schrieb:
>> So tiefe System Kenntnisse habe ich nun auch nicht.
>
> Wofür benutzt du denn das Linux?

Naja, bei so einer Einstellung muss man sich ja nicht wundern, das Linux 
sich auf dem Desktop nicht durchsetzt.

[Börge L. (coollooc)]

lalala schrieb:
> Naja, bei so einer Einstellung muss man sich ja nicht wundern, das Linux
> sich auf dem Desktop nicht durchsetzt.

Ich nutze Linux, da es in meinen Augen, sehr viel sicherer als Windows 
ist.
Z.B kommen fast täglich Updates, die ich direkt einspiele.. bei WIN 
muste warten.

[pingponguin (Gast)]

Sheeva P. schrieb:

>
> Jetzt laß' uns die Sache doch mal systematisch angehen, statt
> irgendwelche Vermutungen ins Blaue hinein zu starten. Also: hwclock
> disablen und masken und dann erst einmal schauen, ob das Problem behoben
> ist.


Wie kommt ihr überhaupt auf die Idee das es daran liegen sollte?

Auch ohne irgendwelche Ubuntu-Kenntnisse zu haben würde ich erstmal 
vermuten das das System zwar einen 'halt' aber keinen poweroff macht.

Mal angenommen die shutdown Prozedur bliebe beim sichern der Systemzeit 
stehen dann waeren immer noch alle Dateisysteme eingehängt, nach 
unterbrechen der Versorgung kriegt man das spätestens beim nächsten 
Start mit wenn sich e2fsck meldet es müsse da mal was prüfen ...


---

Abgesehen davon kann man doch die Meldungen vefolgen welche beim 
Ausschalten kommen. Entweder man startet ahlt einen Durchlauf ohne X, 
(k.a. welcher runlevel das bei Ubuntu ist) oder man wechselt mit 
alt+ctrl+f1 in die virt. console killed evtl. den Displaymanager
(sudo) service gdm/lightdm/.. stop , (sudo) halt
wenn das Teil durchlauft bis zur Meldung 'system halted' dann kann man 
das mit der systemzeit schon mal abhaken und sich dem /nicht 
unwahrscheinlich schuldigen/ Powermangement widmen

[Sheeva P. (sheevaplug)]

Börge L. schrieb:
> Habe beide Befehle ausgeführt und es wird folgender Status angezeigt.
> So richtig ?
>
> systemctl status hwclock.service
> Warning: hwclock.service changed on disk. Run 'systemctl daemon-reload'
> to reload units.
> ● hwclock.service
>    Loaded: masked (/dev/null; bad)
>    Active: inactive (dead)

Ja, genau so. Jetzt bitte einmal ausprobieren und schauen, ob das 
Gewünschte dadurch erreicht worden ist.

Ach ja: hat er diesen Status schon vor dem Ausführen der "disable"- 
und "mask"-Befehle angezeigt, oder erst hinterher?

[Sheeva P. (sheevaplug)]

pingponguin schrieb:
> Wie kommt ihr überhaupt auf die Idee das es daran liegen sollte?

Aussage des TO.

> Auch ohne irgendwelche Ubuntu-Kenntnisse zu haben würde ich erstmal
> vermuten das das System zwar einen 'halt' aber keinen poweroff macht.

Daran habe ich auch schon gedacht, aber TO schreibt weiter oben, daß er 
"halt -p" benutzt. Das sollte dasselbe wie "poweroff" bewirken.

> Abgesehen davon kann man doch die Meldungen vefolgen welche beim
> Ausschalten kommen. Entweder man startet ahlt einen Durchlauf ohne X,

Unter Linux gibt es das Programm dmesg(1), das die Bootmeldungen 
(genauer: den Ringpuffer) des Kernels ausgibt.

[Börge L. (coollooc)]

Sheeva P. schrieb:
> Ja, genau so. Jetzt bitte einmal ausprobieren und schauen, ob das
> Gewünschte dadurch erreicht worden ist.

Tja leider keinen unterschied...

Sheeva P. schrieb:
> Ach ja: hat er diesen Status schon vor dem Ausführen der "disable"-
> und "mask"-Befehle angezeigt, oder erst hinterher?

Ich bin ehrlich, habe vorher nicht geschaut, von daher weis ich das 
nicht.

pingponguin schrieb:
> Wie kommt ihr überhaupt auf die Idee das es daran liegen sollte?

Börge L. schrieb:
> Was ich noch gefunden habe, ist dieses hier:
>
> „I finally found the cause of the issue: the command "hwclock --systohc
> --local" causes the battery to drain when the laptop is off.
> This command is executed by the /etc/init.d/hwclock script.
> If I set clock_hctosys="NO" in /etc/conf.d/hwclock, that command does
> not get executed anymore, and the battery does not drain.“

[bingo (Gast)]

Hast Du bei Deinem Rechner den Splashscreen an oder aus? Wenn der aus 
ist, kannst Du beobachten, ggf. mit dem Handy filmen, was beim Rauf- 
bzw. Runterfahren passiert. Ggf. ergeben sich da Erkenntnisse.

Noch eine Frage: Wenn Du mit Windows bwz. Akku weg richtig runter 
gefahren hast und danach Linux startest, dauert das genauso (!) lange 
wie wenn Du nur von Linux runtergefahren hast. Wenn letzteres schneller 
geht, spricht das für einen Ruhezustand statt echtem 'off'

[lalala (Gast)]

Börge L. schrieb:
> lalala schrieb:
>> Naja, bei so einer Einstellung muss man sich ja nicht wundern, das Linux
>> sich auf dem Desktop nicht durchsetzt.
>
> Ich nutze Linux, da es in meinen Augen, sehr viel sicherer als Windows
> ist.
> Z.B kommen fast täglich Updates, die ich direkt einspiele.. bei WIN
> muste warten.

Du warst mit der Aussage von mir ja gar nicht gemeint. Ich finde jeder 
darf Linux auch ohne irgendeinen Grund benutzen. Nur der Nick war da 
wohl anderer Meinung, und dessen Einstellung habe ich kritisiert.

[Meister Röhricht (Gast)]

Was u.U. helfen koennte, waere den Netzwerktreiber vor dem
Herunterfahrem mit rmmod zu entladen.

In frueheren Zeiten haben noch "warme" Netzwerkkarten auch
bei Desktops regelmaessig Aerger beim Reboot gemacht.
3Coms 900er z.B.

[pingponguin (Gast)]

Sheeva P. schrieb:

> Unter Linux gibt es das Programm dmesg(1), das die Bootmeldungen
> (genauer: den Ringpuffer) des Kernels ausgibt.


Und, Nutzen hier?

Nutzt wenig in der shutdown-prozedur weil das nicht gelogged wird.
So ziemlich als erstes werden sighups versendet und auch ein dmesg 
gekilled, wohin sollten Meldungen a la unmounting filessystems , 
remounting root fs readonly , shutdown sdX ... auch gespeichert werden 
;)

halt,reboot, poweroff setzen ldgl. eine Meldung nach /var/log/wtmp ab 
,mit eg. last -x shutdown gibt Auskunft, das sagt aber nichts über den 
Erfolg.
Die letzte Aktion zum Systemhalt ist immer das abschalten der Laufwerke, 
das sagt nat. nicht das auch alle Hardware ausgeschaltet wurde ldlg. das 
keine Software mehr läuft.



---
> Börge L. schrieb:
>> Was ich noch gefunden habe, ist dieses hier:
>>
> „I finally found the cause of the issue: the command "hwclock ....

Ruf halt mal man hwclock auf.

Das Prog. liest oder setzt die RTC Zeit.

Entweder das klappt oder auch nicht dann stimmt halt ggf. die Uhrzeit 
nicht. Aber sonst?

[Börge L. (coollooc)]

bingo schrieb:
> Hast Du bei Deinem Rechner den Splashscreen an oder aus? Wenn der aus
> ist, kannst Du beobachten, ggf. mit dem Handy filmen, was beim Rauf-
> bzw. Runterfahren passiert. Ggf. ergeben sich da Erkenntnisse.
>
> Noch eine Frage: Wenn Du mit Windows bwz. Akku weg richtig runter
> gefahren hast und danach Linux startest, dauert das genauso (!) lange
> wie wenn Du nur von Linux runtergefahren hast. Wenn letzteres schneller
> geht, spricht das für einen Ruhezustand statt echtem 'off'

Splashscreen mal aktiviert, auf den ersten Blick alles grüne OK,
sieht meiner Meinung nach alles gut aus, nur so schnell gucken kann ich 
auch nicht. In der /var/log/boot.log sieht auch alles gut aus.

Handy filmen kann ich nicht, habe kein modernes Handy, wozu auch ! ;-)

Zur zweiten Frage, es ändert sich gar nichts an der Geschwindigkeit.

[Börge L. (coollooc)]

pingponguin schrieb:
> Die letzte Aktion zum Systemhalt ist immer das abschalten der Laufwerke,
> das sagt nat. nicht das auch alle Hardware ausgeschaltet wurde ldlg. das
> keine Software mehr läuft.

Und wo wird diese Aktion ausgeführt? Welches script ?
Kann man da evtl. noch ein Kill - sonstwas Signal für alles reinsetzen?

Irgendwo muss ja auch gesteuert sein, das die CPU usw. Stromlos 
geschaltet wird.

[qwertz (Gast)]

Hallo,
mal eine sehr dumme Frage, wartest du mit dem Zuklappen, bis er wirklich 
heruntergefahren ist, oder klappst du direkt zu?
Des weiteren kennen wir die Ursache doch: ACPI, hat er doch ausprobiert.

qwertz

[(prx) A. K. (prx)]

Börge L. schrieb:
> Kann man da evtl. noch ein Kill - sonstwas Signal für alles reinsetzen?

Ein "kill" tötet Prozesse, keine Prozessoren. Wenn alle Prozesse weg 
sind, schaltet sich der Rechner nicht von alleine ab. Das ist ein aktiv 
gesteuerter Vorgang.

[Börge L. (coollooc)]

Konnte gerade feststellen, das wenn ich den Rechner runterfahr,
verbraucht er weiterhin Strom.

Wenn ich dann den Power-Knopf für ca. 5-6 sec gedrückt halte schaltet 
sich der Rechner richtig aus.

Workaround Nr 3:

1. Linux runterfahren, warten bis fertig
2. Power Knopf 5-6 sec. gedrückt halten.

erspart mir immerhin schon mal den ausbau des Akkus

qwertz schrieb:
> oder klappst du direkt zu?

Ich klappe gar nicht zu.

[pingponguin (Gast)]

Börge L. schrieb:

> Irgendwo muss ja auch gesteuert sein, das die CPU usw. Stromlos
> geschaltet wird.

Was du evtl. mal probieren könntest, (ungetest)
dem bockigen efi/Bios vorgaukeln es deale mit windows ;)


acpi_os_name=   [HW,ACPI] Tell ACPI BIOS the name of the OS
                 Format: To spoof as Windows 98: ="Microsoft Windows"




http://redsymbol.net/linux-kernel-boot-parameters/

[bingo (Gast)]

Wie sieht denn die Datei /etc/default/grub bei Dir aus? Bei meinen 
Notebooks gibt es u.a. die Zeile

GRUB_CMDLINE_LINUX_DEFAULT="noplymouth acpi_osi=Linux"

'noplymouth' zeigt mir die Boot- und Shutdown-Meldungen an (da muss auch 
'quiet' und 'splash' weg) und 'acpi_osi' bringt verbesserte 
Kompatibilität zum genannten OS.

Wenn Du die Datei geändert hast, musst Du mit 'sudo update-grub' den 
GRUB neu konfigurieren, erst dann werden die Änderungen wirksam.

[pingponguin (Gast)]

bingo schrieb:


>
> 'noplymouth' zeigt mir die Boot- und Shutdown-Meldungen an (da muss auch
> 'quiet' und 'splash' weg) und 'acpi_osi' bringt verbesserte
> Kompatibilität zum genannten OS.


Das setzt aber vorraus das das BIOS des Rechners bzw. dessen ACPI 
Tabellen DSDT, SSDT den Kernel-xy kennen bzw. dazu passen . Sagt man dem 
Kernel er soll sich diesbzgl. wie windows (z.B. 8 , muesste ~'windows 
2012' sein) verhalten dann ist das wahrscheinlicher alle acpi-Funktionen 
nutzen zu können, wenn das Teil eben auch diese Funktionen im 
entsprechenden Win alle unterstützt.

_osi=Linux extra anzugeben ist eigentlich überflüssig.

[bingo (Gast)]

pingponguin schrieb:
> _osi=Linux extra anzugeben ist eigentlich überflüssig.

Nein, das ist es nicht.

Es ist bekannt, dass viele Funktionen bei Notebooks unter Linux nicht 
laufen, weil die BIOSe auf Windows otptimiert sind. Bekannt sind z.B. 
die Helligkeitssteuerung des LCD und die Umschaltung LCD vs. 
Monitor-Buchse, manchmal auch das Sound-System. Weiteres siehe 
https://unix.stackexchange.com/questions/110624/what-do-the-kernel-parameters-acpi-osi-linux-and-acpi-backlight-vendor-do, 
dort heisst es u.a.

'acpi_osi=Linux makes Linux answer yes again when asked if it's "Linux" 
by the ACPI code, thus allowing the ACPI code to enable workarounds for 
Linux and/or disable workarounds for Windows.'

[Börge (Gast)]

GRUB_CMDLINE_LINUX_DEFAULT="acpi_os_name=Microsoft Windows XP"

Habe das mal so in die grub eingetragen
Danach Update-grub
reboot
kein Erfolg
Welche Windows Versionen kann man alle mal testen?

[pingponguin (Gast)]

bingo schrieb:
> pingponguin schrieb:
>> _osi=Linux extra anzugeben ist eigentlich überflüssig.
>
> Nein, das ist es nicht.
>
> Es ist bekannt, dass viele Funktionen bei Notebooks unter Linux nicht
> laufen, weil die BIOSe auf Windows otptimiert sind. Bekannt sind z.B.
> die Helligkeitssteuerung des LCD und die Umschaltung LCD vs.
> Monitor-Buchse, manchmal auch das Sound-System. Weiteres siehe
> 
https://unix.stackexchange.com/questions/110624/what-do-the-kernel-parameters-acpi-osi-linux-and-acpi-backlight-vendor-do,
> dort heisst es u.a.
>
> 'acpi_osi=Linux makes Linux answer yes again when asked if it's "Linux"
> by the ACPI code, thus allowing the ACPI code to enable workarounds for
> Linux and/or disable workarounds for Windows.'

Das ist aber "verkehrt herum" und bedeuted dann eben auch man braucht 
einen passenden linuxtreiber

 "acpi_backlight=vendor will prefer vendor specific driver"

 der dann einspringt, denn

 [...] BIOS's usually disable functionality if Windows is not detected [...]

bleibt ja wahr und desshalb kann man dem dem kernel sagen sich wie 
windows zu verhalten.


kanns aber leider nicht testen, von daher probierst und berichtet.
have fun.

[pingponguin (Gast)]

Börge schrieb:
> GRUB_CMDLINE_LINUX_DEFAULT="acpi_os_name=Microsoft Windows XP"
>

Das muss wohl in Anführungszeichen

> Habe das mal so in die grub eingetragen
> Danach Update-grub
> reboot
> kein Erfolg
> Welche Windows Versionen kann man alle mal testen?

https://wiki.archlinux.org/index.php/DSDT

other strings to test:

    * "Microsoft Windows XP"
    * "Microsoft Windows 2000"
    * "Microsoft Windows 2000.1"
    * "Microsoft Windows ME: Millennium Edition"
    * "Windows 2001"
    * "Windows 2006"
    * "Windows 2009"
    * "Windows 2012"
    * when all that fails, you can even try "Linux"
---

Was das Bios kennt kann man herausfinden aber das artet dann wohl etwas 
aus.

https://wiki.ubuntu.com/FirmwareTestSuite/Reference

[bingo (Gast)]

Börge schrieb:
> GRUB_CMDLINE_LINUX_DEFAULT="acpi_os_name=Microsoft Windows XP"
>
> Habe das mal so in die grub eingetragen

Nein, Du musst es andersherum machen:

GRUB_CMDLINE_LINUX_DEFAULT="acpi_os_name=Linux"

[bingo (Gast)]

bingo schrieb:
> Nein, Du musst es andersherum
> machen:GRUB_CMDLINE_LINUX_DEFAULT="acpi_os_name=Linux"

KORREKTUR:

GRUB_CMDLINE_LINUX_DEFAULT="acpi_os=Linux"

war leider ein Schnellschuss mit copy&paste

[pingponguin (Gast)]

bingo schrieb:
> bingo schrieb:
>> Nein, Du musst es andersherum
>> machen:GRUB_CMDLINE_LINUX_DEFAULT="acpi_os_name=Linux"
>
> KORREKTUR:
>

> GRUB_CMDLINE_LINUX_DEFAULT="acpi_os=Linux"
>

>
> war leider ein Schnellschuss mit copy&paste

Auf noch ein Versuch,

es gibt acpi_os_name und die Liste acpi_osi aber kein acpi_os

[bingo (Gast)]

pingponguin schrieb:
> es gibt acpi_os_name und die Liste acpi_osi aber kein acpi_os

stimmt ... scheiss Schnelltipperei :(

GRUB_CMDLINE_LINUX_DEFAULT="acpi_osi=Linux"

bingo!!!

[Börge (Gast)]

bingo schrieb:
> GRUB_CMDLINE_LINUX_DEFAULT="acpi_osi=Linux"

Habe das nun so eingetragen, Leider bringt das keinen Erfolg.

[bingo (Gast)]

Da Du mit Ubuntu 16.04 schon systemd benutzt, solltest Du Dir mal die 
Manpages zur Datei /etc/systemd/logind.conf ansehen:

man logind.conf

Da gibt es allerlei Möglichkeiten, z.B. mit HandlePowerKey= etc. das 
Verhalten zu steuern.

[Sheeva P. (sheevaplug)]

Börge schrieb:
> bingo schrieb:
>> GRUB_CMDLINE_LINUX_DEFAULT="acpi_osi=Linux"
>
> Habe das nun so eingetragen, Leider bringt das keinen Erfolg.

Vielleicht magst Du mal sagen, was das genau für ein Laptop ist (oder 
hast Du das bereits getan und ich habe es übersehen?). Dann könnte man 
mal schauen, was für Hardware darin verbaut ist und vielleicht so 
herausfinden, warum das Gerät sich so merkwürdig verhält.

Hat das Ding vielleicht eine Möglichkeit, Musik-CDs oder andere Medien 
ohne Betriebssystem abspielen zu können? Ich habe hier irgendwo noch 
einen alten ASUS-Schleppi, der das konnte.

[Börge (Gast)]

Sheeva P. schrieb:
> Vielleicht magst Du mal sagen, was das genau für ein Laptop ist

HP 15-bs036ng Notebook 15.6 Zoll

nichts Hochwertiges, güngstig bei der Cyber Monday Woche gekauft.
Für einfache Dinge vollkommen ausreichend

[K. J. (Gast)]

Kannst versuchen im Bios "S3" auszuschalten dann sind die ganzen Supend 
Modis weg, vielleicht liegt es an einer davon

[Stefan F. (Gast)]

Ich hatte das Problem vor etwa zwei Jahren mit einem HP350 Modell, 
betraf aber Windows und Linux. Der Fehler wurde durch ein Bios Update 
behoben.

Nachtrag:
> BIOS hat neusten Stand.

Ach so, na dann... schade

[Börge (Gast)]

K. J. schrieb:
> Kannst versuchen im Bios "S3" auszuschalten dann sind die ganzen Supend
> Modis weg, vielleicht liegt es an einer davon

Das BIOS bietet dafür keine Möglichkeit,
das BIOS ist recht dürftig, was Einstellungen angeht

[Sheeva P. (sheevaplug)]

Börge schrieb:
> K. J. schrieb:
>> Kannst versuchen im Bios "S3" auszuschalten dann sind die ganzen Supend
>> Modis weg, vielleicht liegt es an einer davon
>
> Das BIOS bietet dafür keine Möglichkeit,
> das BIOS ist recht dürftig, was Einstellungen angeht

Könnte es sein, daß Wake-On-LAN für WLAN aktiviert bleibt? Hat das Gerät 
eventuell sogar einen externen Schalter für WLAN?

[Karl II (Gast)]

Wie bingo weiter oben schon schrieb, würde ich mal im Forum von 
ubuntuusers.de nachfragen, die haben mir schon oft geholfen.

[Börge (Gast)]

Sheeva P. schrieb:
> einen externen Schalter für WLAN?

Nein

Karl II schrieb:
> Wie bingo weiter oben schon schrieb, würde ich mal im Forum von
> ubuntuusers.de nachfragen, die haben mir schon oft geholfen.

Werde es mal da versuchen...

[Börge L. (coollooc)]

Zuerst, danke an alle,
die mir bisher mit Rat und Tat zu Seite standen.
Die letzten Tage hatte mich die Grippe Kampfunfähig gemacht,
so das ich zu nichts gekommen bin.

Nun aber wieder Fit ;-)

Das Problem konnte ich weiter einkreisen und habe festgestellt , das ein 
blödes Modul/Treiber die Ursache ist.

Mit dem Befehl sudo modprobe -r r8169 (ist ein Realtek Treiber) kann ich 
das Modul entladen.

Wenn ich dann den Rechner herunter fahre, ist das Problem gelöst.
Der Akku wird nicht entladen :-)

Nur eine frage bleibt über, wie mach ich das automatisch ?
Sprich vor jedem beenden , dieses Modul entladen.

Ich komm nicht drauf, wer kann mir da nochmal einen kleinen Tipp geben?

[Stefan F. (Gast)]

Mein Debian Linux hat das Script /etc/init.d/networking. Dort gibt es 
einen Abschnitt "stop" wo man den Befehl eintragen könnte. Ich hab's 
nicht ausprobiert.

[Loacal Area Notwork (Gast)]

> Das Problem konnte ich weiter einkreisen und habe festgestellt , das ein
> blödes Modul/Treiber die Ursache ist.
>
> Mit dem Befehl sudo modprobe -r r8169 (ist ein Realtek Treiber) kann ich
> das Modul entladen.

Da wird wohl noch dranrum optimiert, korrigiert, ...
* 
https://www.systutorials.com/linux-kernels/27842/r8169-dont-enable-rx-when-shutdown-linux-3-1/

[Local Area Notwork (Gast)]

und
* 
https://www.systutorials.com/linux-kernels/32260/r8169-fix-driver-shutdown-wol-regression-linux-3-1/

[Jupp (Gast)]

Börge L. schrieb:
> Mit dem Befehl sudo modprobe -r r8169 (ist ein Realtek Treiber) kann ich
> das Modul entladen.

Also doch WOL. Versuche:

sudo ethtool -s eth0 wol d

[Börge L. (coollooc)]

Stefan U. schrieb:
> Dort gibt es
> einen Abschnitt "stop" wo man den Befehl eintragen könnte.

Könnte man versuchen, doch beim nächsten Update ist das wieder weg ?
Ich glaube das ist der falsche Weg.

Loacal Area Notwork schrieb:
> Da wird wohl noch dranrum optimiert, korrigiert, ...

Das ganze Netzwerk Gelumpe in dieser Kiste scheint noch Experimente 
Status zu haben.
Den WLAN Treiber musste ich auch mit git , make , make install lauffähig 
machen.

[Jupp (Gast)]

Börge L. schrieb:
> Das ganze Netzwerk Gelumpe in dieser Kiste scheint noch Experimente
> Status zu haben.

Naja, Realtek & Co...

Das nächste mal bitte ein Business-Gerät mit Intel-LAN/WLAN ;)

[Börge L. (coollooc)]

Jupp schrieb:
> Also doch WOL. Versuche:

Ja auch, WOL habe ich schon permanent ausgeschaltet.

Doch nur wenn ich das Modul r8169 entlade geht die Kiste komplett aus.
Zumindest wird dann der Akku nicht mehr entladen.

Deswegen möchte ich jetzt gerne das Modul bei jeden ausschalten 
automatisch entladen, nur wie mach ich das ?

[Local Area Notwork (Gast)]

um dir selbst ein Workaround zu schnitzen, bis die o.g. Korrekturen z.B 
in/nach 18.04 LTS  (ev. 16.04.x) greifen werden, suchst Du: *systemd 
startup & shutdown services*

E.g. * 
https://unix.stackexchange.com/questions/284598/systemd-how-to-execute-script-at-shutdown-only-not-at-reboot

Spezialhinweise:
*man systemd.special*
*Before=poweroff.target*

[Börge (Gast)]

Um der ganzen Sache jetzt ein Ende zu setzten, habe ich ein 
Desktop-Sysmbol angelegt, das das entsprechende Modul entlädt und dann 
den Rechner herunter fährt.

Bis irgendwann in 16.04 oder 18.04 ein funktionierender Treiber 
vorhanden ist, ist das erst mal die Übergangslösung.

Kann ich mit leben.

Danke nochmal an alle

Gruß Börge

[bastel_ (Gast)]

Jupp schrieb:
> Börge L. schrieb:
>> Das ganze Netzwerk Gelumpe in dieser Kiste scheint noch Experimente
>> Status zu haben.
>
> Naja, Realtek & Co...
>
> Das nächste mal bitte ein Business-Gerät mit Intel-LAN/WLAN ;)

Achso?
https://answers.microsoft.com/en-us/windows/forum/windows_10-networking/wifi-issues-with-creators-update/4a20ba4f-33dc-4397-9823-e12dcb2607ba?auth=1
Hab hier zwei Dell Latitudes, da fliegen die tollen Intel WiFi Karten 
raus, und Atheros kommen rein. Zum Glück kein BIOS Lock.

Intel LAN, das ist ok.