Gefiltert nach Kategorie System Filter zurücksetzen

Toller Support findet DAU-problem

07. December 2025, Falko - System

Vielen Dank an den Tuxedo-Support!

Hier kann ich nur mal sagen: vielen Dank Tuxedo Support, dass ihr dran geblieben seid
und das "Problem" am Ende identifiziert habt.

Das (vermeintliche) Symptom:

- sobald ich meinen Laptop, ein Tuxedo Infinitybook v14 Gen 7, im Akku-Betrieb verwende ...

- und der Akku nicht mehr ganz voll ist ...

- wird mitten im Betrieb kurz der Bildschirm schwarz und 

- ich muss mich wieder neu anmelden

Technisch passiert:

- es wird das Schließen des Deckels getriggert

- im Log ist z.B. der schnelle Wechsel zu suspend und wieder aufwachen zu sehen:

 

Nov 13 23:00: Starting System Suspend...
Nov 13 23:00: Successfully froze unit 'user.slice'.
Nov 13 23:00: Performing sleep operation 'suspend'...
Nov 13 23:00: System returned from sleep operation 'suspend'.
Nov 13 23:00: Successfully thawed unit 'user.slice'.
Nov 13 23:00: systemd-suspend.service
Nov 13 23:00: Finished System Suspend.

 

Was wir alles versucht haben

- log (vom Support) analysieren (lassen)

- Installation des Tuxedo-OS auf einer eigenen Partition (basiert auf KDE Plasma)

- dabei genau das Iso erwischt, in dem ein Fehler betreffs LVM und Verschlüsselung war ...

- dann endlich: Batterie-Kapazitäts-Test (weil das Diagnose-Script mit NixOS nicht so richtig lief)

- auch beim Test lief nicht alles glatt, weil sich anfangs der Laptop doch erstmal von selbst schlafen gelegt hatte

- NVRAM Reset (also einmal CMOS-Knopfzelle raus und BIOS neu einstellen)

Nichts hat geholfen.

Der entscheidende Hinweis

- kam dann vom Support:

 

vielen Dank für Ihre E-Mail.

Schade, dass der Reset nichts bewirkt hat.

Ihre Logs sind aber durchaus interessant, und hat mich an einen ähnlichen Fall erinnert. Bei diesem war der Fall, dass der Kunde eine Smartwatch mit magnetischem Armband hatte. Dadurch wurde der Lid-Sensor immer wieder ausgelöst, was im Log als Lid-Event auftauchte und das Gerät darauf immer wieder in den Suspend schickte.

Sollte bei Ihnen der Lid-Switch so eingestellt sein, dass dieser das Gerät nur im Akkubetrieb in den Suspend schickt (wenn z.B. ein Dock verwendet wird, o.Ä.) könnte das einen Teil des Verhaltens erklären.

Darf ich fragen, ob Sie zufällig irgendwas Magnetisches am Arm haben, wie eine Armbanduhr/Smartwatch mit Magnet im Armband, magnetische Manschettenknöpfe, a.Ä?

 

Des Rätsels Lösung

Tatsächlich: ich hatte mir im März für meine FitBit Charge 2 ein neues Armband geholt.

Was auch gut funktioniert.

Aber ... ich trage die Uhr am rechten Arm. Manchmal. 

Und ... das Armband hat einen (recht kräftigen) Magnetverschluss ...

 

Das heißt: sobald ich am Laptop arbeite (üblicherweise dann im Akku-Betrieb, sonst hab ich ja eine extra Tastatur)

UND der Akku schon etwas weniger voll ist (ob letzteres stimmt, ist nicht ganz klar)

UND die Uhr am rechten Arm habe (was nicht immer der Fall ist, aber oft) ...

... dann wird der Sensor, der sich an der vorderen rechten Ecke des Laptops befindet und auf das Schließen des Laptop-Deckels reagiert, ausgelöst. 

Da der Laptop sich beim Deckel-Schließen sperren sollte (ok, das kann ausgeschaltet werden) ... hat der Sensor "beim Vorbeikommen" des Magnets halt gemacht, was er soll ... nämlich den Bildschirm gesperrt ;)

Verrückte Sache - aber Ende gut, alles gut :)


Ein altes Gigabyte-Mainboard und die host protected area

31. October 2020, Falko - Linux, System

  • Lizenz: https://creativecommons.org/licenses/by-sa/3.0/ Quelle: https://en.wikipedia.org/wiki/BIOS_boot_partition#/media/File:GNU_GRUB_components.svg

Stell dir vor, du aktualisierst dein (Server-) System ... und dann lassen sich auf keiner Festplatte mehr Partitionen einhängen - außer vom System selbst.

Schreck lass nach: alle Daten weg?

Bei fdisk -l sieht das dann z.B. so aus:

 

Disk /dev/sdb: 2,75 TiB, 3000591900160 bytes, 5860531055 sectors
Disk model: Hitachi HUS72403
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start        End    Sectors Size Id Type
/dev/sdb1           1 4294967295 4294967295   2T ee GPT

 

gdisk findet die Partitionen noch, meldet aber Fehler mit der GPT:

 

~:# gdisk -l /dev/sdb
Main header: OK  
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Disk /dev/sdb: 5860531055 sectors, 2.7 TiB
Model: Hitachi HUS72403
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): xxxxxxxxxxxxxxxxxxxxxxxxxx
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 0 sectors (0 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      2147485695   1024.0 GiB  8300  
   2      2147485696      4294969343   1024.0 GiB  8300  
   3      4294969344      4303357951   4.0 GiB     8200  
   4      4303357952      5860533134   742.5 GiB   8300  

 

Erstmal suchen wir nach möglicherweise geänderten BIOS-Einstellungen, ohne Erfolg.

Die Logik sagt: da fehlt ein Stückchen am Ende der Festplatte,
Backup-Partitionstabelle und -Header scheinen daher weg zu sein.

Was war passiert: wir hatten die Vermutung, dass beim Update auf
Ubuntu 20.04 eine alte Einstellung wieder reaktiviert wurde,
die, solange Ubuntu 18.04 installiert war, keine Beachtung fand:
die Host Protection Area (HPA).

In einer Log-Datei von vor zwei Tagen - manchmal ist es ganz gut, seine
Aktionen mitzuschreiben - finden wir die bisherigen Sektorgrößen der
Festplatten wieder:

 

root@server:~# grep TiB logs/sicherung.txt
Disk /dev/sdb: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
Disk /dev/sdc: 2,7 TiB, 3000592982016 bytes, 5860533168 sectors

root@server:~# hdparm -N /dev/sdb
/dev/sdb:
 max sectors   = 5860531055/5860533168, HPA is enabled

root@server:~# hdparm -N /dev/sdc
/dev/sdc:
 max sectors   = 7814035055/7814037168, HPA is enabled

 

Die Vermutung bestätigt sich durch Aufruf von hdparm: die erste Zahl
ist geringfügig kleiner (2113 bytes) als die eigentliche Festplattengröße.

Weitere Informationen zu HPA finden sich im Thomas-Krenn-Wiki sowie bei Wikipedia

Das System ist offensichtlich so eingestellt, dass die HPA nicht ignoriert wird:

 

~:# cat /sys/module/libata/parameters/ignore_hpa
0

 

Wir testen das Gegenteil der bei Thomas Krenn erwähnte Lösung, indem wir dem Kernel beim Booten (in /etc/default/grub)
einen neuen Parameter mitgeben:

 

libata.ignore_hpa=1

 

Was letztlich die "Erlösung" bringt: alle Daten-Partitionen sind wieder da und können
auch - als wäre nix gewesen - wie immer eingehangen werden.

Unklar bleibt, wieso das passiert ist - und ob es wirklich mit dem Upgrade auf Ubuntu 20.04 zusammenhängt. Zeit für's Feierabend-Bier ...

Update: es scheint ehr mit dem Versuch, von der falschen Festplatte zu booten, zusammen zu hängen - siehe https://superuser.com/questions/1282451/sudden-decrease-of-hard-drive-sectors

 

"... if you are using a Gigabyte motherboard manufactured before 2010 then you should definitely check to see 
if you have HPA on any of your drives.  Also, it is definitely possible to have an HPA from a previous motherboard.  
If a drive has at any point in time been used with one of these HPA-inducing boards, then there's a good chance 
that it still has a vestigial HPA, even if it has been formatted since."

 

PS: du kennst das Problem auch - und hast eine Erklärung? Schreib uns gern in den Kommentaren dazu.

PPS: Die GUID-Partition-Table wird hier gut erklärt. Quelle für das Aufmacher-Bild.


Ubuntu Desktop mit verschiedenen Hintergründen

20. February 2010, Falko - Linux, System

Ubuntu+Compiz: verschiedene Hintergründe pro Arbeitsfläche

  • Desktop umschalten
  • 3D-Würfel

Quelle u.a.: Anurag Bansal

Voraussetzung: Compiz aktiviert, Compiz Config Manager ist installiert.

Sinnvoll: Würfel drehen, Desktop Würfel sind aktiviert, dabei muss man evtl. unter "Würfel drehen -> Bindings -> Rotate to cube" die Arbeitsflächen-Umschalttasten ersetzen gegen die Würfel-Umschalttasten (z.B. Alt-1, Alt-2,...)

Im Compiz Manager: Werkzeuge -> Hintergrundbilder (ggf. aktivieren) -> Neu, dann Image auswählen

Dann z.B. mit Alt+F2 den gconf-editor starten, dort unter apps/nautilus/preferences bei "show desktop" den Haken weg. Danach gibt es keine Desktop-Icons mehr! Will man trotzdem auf die laufenden Programme umschalten, empfiehlt sich die Installation des Avant Window Navigator mittels "sudo apt-get install avant-window-navigator". Dort kann man z.B. "places" als Applet einschalten, wo man schnell auf die Lesezeichen bzw. den Desktop Zugriff hat.

Wie ich die Bilder gemacht habe? Gimp -> neu erstellen -> ganzer Bildschirm und "Auslösen nach 5 s". Dann die mit der mittleren Maustaste auf den Hintergrund den Würfel drehen bzw. mit Strg+Alt+PfeilUnten die Desktop-Übersicht anzeigen.


Lenny = Debian 5.0

21. April 2009, Falko - Linux, System

... lässt sich wie immer problemlos aktualisieren. Das übliche "apt-get -u dist-upgrade" macht ganz einfach aus der Vorgängerversion ein aktuelles System, ohne CD/DVD einzulegen, ohne Klimmzüge auf der Konsole. Dabei ist auch gleich noch Zeit zum Entrümpeln - Dienste, die nicht länger verwendet werden, kann man ausschalten oder gleich ganz deinstallieren, wenn man sich sicher ist, dass man sie nicht mehr braucht. Die fallen z. B. dann auf, wenn man routinemässig mittels "netstat -ntl" (tcp) bzw. "netstat -nul" (udp) nachsieht, welche Ports offen und damit Dienste erreichbar sind.

Beispiel: Port 20012 zeigt an, dass ein isdnvboxserver läuft. Da dieser gar nicht (mehr) verwendet wird, wird er mittels "update-inetd --disable vboxd" deaktiviert bzw. per "apt-get remove isdnvboxserver" einschliesslich isdnutils komplett entsorgt.

Nach der Aktualisierung wird nochmal die Funktion aller Dienste überprüft. Wurde der Kernel aktualisiert, sollte vorher ein Neustart durchgeführt werden.

Wenn da nicht ... nach dem Booten ein Fehlerchen zu sehen wäre: "no devices found for /dev/md0" mit anschliessendem "Dropping to shell", wonach uns eine "busybox" shell angrinst. Glücklicherweise haben wir uns gemerkt, welcher Linux-Kernel vorher am Wirken war (2.6.18) und können durch Start desselben über das Grub-Bootmenü das System wieder reaktivieren. Nun heißt es, den Fehler zu suchen - erster Verdacht ist die mdadm.conf Datei für's RAID, danach kommt die initrd dran. Irgendwann fällt dann z.B. auf, dass bei den Ausgaben beim Booten ein Modul nicht geladen wird. Das trägt man in die /etc/initramfs-tools/modules Datei ein, und schon läuft wieder alles.


Bloggen mit t3blog von snowflake

21. October 2008, Falko - System

Schnell mal ein neues Blog ...

Es klingt fantastisch, aber mit der neuen t3blog-Extension von blog.snowflake.ch ist die Umstellung von meinem alten "ee_blog" (alte Beiträge siehe "Archiv") auf ein modernes Blog eine Sache von wenigen Minuten. Drei Extensions installieren, im Template die statischen Includes hinzufügen, eine Seite mit t3blog als Erweiterung sowie einige Kategorien anlegen, schon kann der erste Eintrag verfasst werden :)

Dann kommt zwar noch dazu, dass Vieles angepasst und erweitert werden will - aber man muss ja nicht ... Die Dokumentation lesen ist daher zu empfehlen, z. B. zwecks RealURL: einfach die Datei RealURLConfiguration.txt in der Wurzel der Extension lesen und in die localconf.php übernehmen, schon fertig.