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
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?
:
Bearbeitet durch User
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/
PS: Wenn das manuelle Navigieren oder Bearbeiten zu mühsam oder zu unbekannt ist, mc installieren. Optik entspricht ungefähr dem alten Norton Commander.
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
1 | #!/bin/sh
|
2 | # hwclock.sh Set and adjust the CMOS clock.
|
3 | #
|
4 | # Version: @(#)hwclock.sh 2.00 14-Dec-1998 miquels@cistron.nl
|
5 | #
|
6 | # Patches:
|
7 | # 2000-01-30 Henrique M. Holschuh <hmh@rcm.org.br>
|
8 | # - Minor cosmetic changes in an attempt to help new
|
9 | # users notice something IS changing their clocks
|
10 | # during startup/shutdown.
|
11 | # - Added comments to alert users of hwclock issues
|
12 | # and discourage tampering without proper doc reading.
|
13 | # 2012-02-16 Roger Leigh <rleigh@debian.org>
|
14 | # - Use the UTC/LOCAL setting in /etc/adjtime rather than
|
15 | # the UTC setting in /etc/default/rcS. Additionally
|
16 | # source /etc/default/hwclock to permit configuration.
|
17 | |
18 | ### BEGIN INIT INFO
|
19 | # Provides: hwclock
|
20 | # Required-Start: mountdevsubfs
|
21 | # Required-Stop: mountdevsubfs
|
22 | # Should-Stop: umountfs
|
23 | # Default-Start: S
|
24 | # X-Start-Before: checkroot
|
25 | # Default-Stop: 0 6
|
26 | # Short-Description: Sync hardware and system clock time.
|
27 | ### END INIT INFO
|
28 | |
29 | # These defaults are user-overridable in /etc/default/hwclock
|
30 | BADYEAR=no |
31 | HWCLOCKACCESS=yes |
32 | HWCLOCKPARS= |
33 | HCTOSYS_DEVICE=rtc0 |
34 | |
35 | # We only want to use the system timezone or else we'll get
|
36 | # potential inconsistency at startup.
|
37 | unset TZ
|
38 | |
39 | hwclocksh()
|
40 | {
|
41 | [ ! -x /sbin/hwclock ] && return 0 |
42 | [ ! -r /etc/default/rcS ] || . /etc/default/rcS |
43 | [ ! -r /etc/default/hwclock ] || . /etc/default/hwclock |
44 | |
45 | . /lib/lsb/init-functions
|
46 | verbose_log_action_msg() { [ "$VERBOSE" = no ] || log_action_msg "$@"; } |
47 | |
48 | case "$BADYEAR" in |
49 | no|"") BADYEAR="" ;; |
50 | yes) BADYEAR="--badyear" ;; |
51 | *) log_action_msg "unknown BADYEAR setting: \"$BADYEAR\""; return 1 ;; |
52 | esac
|
53 | |
54 | case "$1" in |
55 | start) |
56 | # If the admin deleted the hwclock config, create a blank
|
57 | # template with the defaults.
|
58 | if [ -w /etc ] && [ ! -f /etc/adjtime ] && [ ! -e /etc/adjtime ]; then |
59 | printf "0.0 0 0.0\n0\nUTC\n" > /etc/adjtime |
60 | fi
|
61 | |
62 | if [ -d /run/udev ] || [ -d /dev/.udev ]; then |
63 | return 0
|
64 | fi
|
65 | |
66 | if [ "$HWCLOCKACCESS" != no ]; then |
67 | log_action_msg "Setting the system clock" |
68 | |
69 | # Just for reporting.
|
70 | if sed '3!d' /etc/adjtime | grep -q '^UTC$'; then |
71 | UTC="--utc" |
72 | else
|
73 | UTC= |
74 | fi
|
75 | # Copies Hardware Clock time to System Clock using the correct
|
76 | # timezone for hardware clocks in local time, and sets kernel
|
77 | # timezone. DO NOT REMOVE.
|
78 | if /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --hctosys $HWCLOCKPARS $BADYEAR; then |
79 | # Announce the local time.
|
80 | verbose_log_action_msg "System Clock set to: `date $UTC`" |
81 | else
|
82 | log_warning_msg "Unable to set System Clock to: `date $UTC`" |
83 | fi
|
84 | else
|
85 | verbose_log_action_msg "Not setting System Clock" |
86 | fi
|
87 | ;;
|
88 | stop|restart|reload|force-reload)
|
89 | #
|
90 | # Updates the Hardware Clock with the System Clock time.
|
91 | # This will *override* any changes made to the Hardware Clock.
|
92 | #
|
93 | # WARNING: If you disable this, any changes to the system
|
94 | # clock will not be carried across reboots.
|
95 | #
|
96 | |
97 | if [ "$HWCLOCKACCESS" != no ]; then |
98 | log_action_msg "Saving the system clock" |
99 | if /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --systohc $HWCLOCKPARS $BADYEAR; then |
100 | verbose_log_action_msg "Hardware Clock updated to `date`" |
101 | fi
|
102 | else
|
103 | verbose_log_action_msg "Not saving System Clock" |
104 | fi
|
105 | ;;
|
106 | show)
|
107 | if [ "$HWCLOCKACCESS" != no ]; then |
108 | /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --show $HWCLOCKPARS $BADYEAR |
109 | fi
|
110 | ;;
|
111 | *) |
112 | log_success_msg "Usage: hwclock.sh {start|stop|reload|force-reload|show}"
|
113 | log_success_msg " start sets kernel (system) clock from hardware (RTC) clock"
|
114 | log_success_msg " stop and reload set hardware (RTC) clock from kernel (system) clock"
|
115 | return 1
|
116 | ;;
|
117 | esac
|
118 | }
|
119 | |
120 | hwclocksh "$@" |
:
Bearbeitet durch User
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.
1 | # hwclock - adjust system clock and timezone |
2 | # |
3 | # The hwclock task adjusts the system clock when the hardware clock is |
4 | # set to localtime (e.g. when dual-booting with Windows), and also |
5 | # ensures that the system timezone is set so that timestamps are written |
6 | # to FAT devices. |
7 | |
8 | description "adjust system clock and timezone" |
9 | |
10 | start on starting mountall |
11 | |
12 | task |
13 | |
14 | script |
15 | # BADYEAR can be in either file |
16 | . /etc/default/rcS |
17 | [ ! -r /etc/default/hwclock ] || . /etc/default/hwclock |
18 | grep -qw LOCAL /etc/adjtime 2>/dev/null && tz="--localtime" || tz="--utc" |
19 | [ "$BADYEAR" = "yes" ] && badyear="--badyear" |
20 | exec hwclock --systz $tz --noadjfile $badyear |
21 | end script |
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.
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.
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.
> 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:
1 | > [ ! -r /etc/default/hwclock ] || . /etc/default/hwclock |
2 | ^^^^^^^^^^^^^^^^^^^^ |
(sorry für die überflüssigen 'code' Tags, die Forensoftware macht bei mir irgendwie lustige Sachen wenn ich sie weglasse..)
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
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.
:
Bearbeitet durch User
> 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'.
> 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 :-)
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. schrieb: > Habe nun die Datei /etc/default/hwclock angelegt > und den Wert clock_hctosys=no eingetragen. > oder muss der Wert clock_hctosys="NO" sein ?
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?
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
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.
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.
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?
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.
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.).
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
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.
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
> 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
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.
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.
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
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)
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.
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.
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. schrieb: > 'poweroff' ausprobiert? Leider bringt das auch nichts... Die Suche geht weiter... Kann man denn beim ACPI nur teile ausschalten?
Du kannst nochmal acpi=force probieren
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.
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.
Börge L. schrieb: > Gibt es die Möglichkeit irgendwo einen aller letzten Befehl aus > zuführen. Was gibt denn
1 | systemctl status hwclock.service |
aus? Hast Du den Ratschlag von Daniel Albrecht ausprobiert und
1 | systemctl disable hwclock.service |
2 | 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.
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
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.
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)
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.
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
:
Bearbeitet durch User
Es ist ja kein Prozess, der weiterläuft, sondern irgendeine Hardware, die nicht ausgeschaltet wird. Die kann man nicht mit killall ausschalten.
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
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.
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.
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
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?
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.
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.“
:
Bearbeitet durch User
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'
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.
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.
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?
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.
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.
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
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.
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.
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/
Wie sieht denn die Datei /etc/default/grub bei Dir aus? Bei meinen Notebooks gibt es u.a. die Zeile
1 | 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.
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.
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.'
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?
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
1 | "acpi_backlight=vendor will prefer vendor specific driver" |
der dann einspringt, denn
1 | [...] 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.
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
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:
1 | GRUB_CMDLINE_LINUX_DEFAULT="acpi_os_name=Linux" |
bingo schrieb: > Nein, Du musst es andersherum > machen:GRUB_CMDLINE_LINUX_DEFAULT="acpi_os_name=Linux" KORREKTUR:
1 | GRUB_CMDLINE_LINUX_DEFAULT="acpi_os=Linux" |
war leider ein Schnellschuss mit copy&paste
bingo schrieb: > bingo schrieb: >> Nein, Du musst es andersherum >> machen:GRUB_CMDLINE_LINUX_DEFAULT="acpi_os_name=Linux" > > KORREKTUR: >
1 | > GRUB_CMDLINE_LINUX_DEFAULT="acpi_os=Linux" |
2 | > |
> > 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
pingponguin schrieb: > es gibt acpi_os_name und die Liste acpi_osi aber kein acpi_os stimmt ... scheiss Schnelltipperei :(
1 | GRUB_CMDLINE_LINUX_DEFAULT="acpi_osi=Linux" |
bingo!!!
bingo schrieb: > GRUB_CMDLINE_LINUX_DEFAULT="acpi_osi=Linux" Habe das nun so eingetragen, Leider bringt das keinen Erfolg.
Da Du mit Ubuntu 16.04 schon systemd benutzt, solltest Du Dir mal die Manpages zur Datei /etc/systemd/logind.conf ansehen:
1 | man logind.conf |
Da gibt es allerlei Möglichkeiten, z.B. mit HandlePowerKey= etc. das Verhalten zu steuern.
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.
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
Kannst versuchen im Bios "S3" auszuschalten dann sind die ganzen Supend Modis weg, vielleicht liegt es an einer davon
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
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
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?
Wie bingo weiter oben schon schrieb, würde ich mal im Forum von ubuntuusers.de nachfragen, die haben mir schon oft geholfen.
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...
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?
:
Bearbeitet durch User
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.
> 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/
und * https://www.systutorials.com/linux-kernels/32260/r8169-fix-driver-shutdown-wol-regression-linux-3-1/
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
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.
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 ;)
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 ?
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*
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.