Seit letztem Jahr habe ich wieder einen Desktop-PC, was sich durch die Homeofice-Situation in Corona-Zeiten gut ergeben hat. Da ich seit einigen Jahren alle Rechner im Haus mit Linux betreibe, habe ich ein Angebot von HP mit FreeDos kaufen können. Eine Windows-Lizenz zum Betrieb als VM, wenn ich mal wirklich Windows brauche, ist noch vorhanden.
Der Desktop hat eine SSD mit 128 GB und eine klassische Platte mit einem Terabyte. Die Aufteilung „Betriebssystem auf SSD, Daten auf Festplatte“ lag nahe, aber der Installer von Linuxmint (und anderen Distributionen, die ich ausprobiert habe) fand die SSD nicht.
Ich installierte ein Linuxmit 19 auf der Platte und wollte das bei Gelegenheit ändern. Dafür war jetzt die Zeit gekommen, da ich im Rahmen des Kommunalwahlkampfs reichlich „basteln“ musste und mir dabei die Chrome-Installation kaputt gemacht habe. Linuxmint 20 stand vor der Tür und eine Neuinstallation bot sich an.
Aber fangen wir vorne an.
Der PC wurde vor Weihnachten geliefert, ich erzeugte auf dem Notebook (mit Linuxmint) einen USB-Stick mit einem bootfähigen Image der Version 19 des Betriebssystems.
Ich boote den Rechner über den Stick und sehe eine 128GB-Platte, die ich für das Betriebssystem auswähle, und eine 1TB-Platte, die ich für die Userdaten unter /home einhängen werde.
Beim Formatieren der 128GB Platte bricht das Installationsprogramm ab. Das ganze Linux ist kaputt und verlangt als letztes Lebenszeichen noch, den Datenträger wieder einzulegen.
Ich prüfe den USB-Stick: der ist leer. Ich kopiere das Boot-Image nochmal drauf, boote nochmal, das gleiche Spiel, das gleiche Ergebnis.
Ein Blick auf den Stick verrät mir: Der hat 128 GB. Ich hab den USB-Stick formatiert, von dem ich gebootet habe. Zweimal.
Die SSD ist im Installer gar nicht zu sehen.
Im BIOS ist sie zu sehen. Ich schaue mal genauer hin.
Die verbaute SSD ist keine SSD, die wie eine Festplatte an den Festplattencontroller angeschlossen wird, sondern eine M.2-SSD, die direkt auf den PCI-Bus gesteckt wird. Dadurch spart man eine Hardwareschicht und damit Strom und Zeit, denn die SSD ist performanter als eine, die sich als Festplatte ausgibt.
Die SSD wird aber vom Betriebssystem dadurch eben nicht mehr als „emulierte“ Festplatte erkannt, das Betriebssystem kann dafür sehr viel mehr SSD-spezifische Parameter einstellen. Soweit die schnelle Recherche.
Der erste Parameter den ich teste, liegt im BIOS und ist die Emulation. AHCI ist ausgewählt, Advanced Host Controller Interface, und auch die einzige Option an der Stelle. Das ist für die M.2-SSD schon mal korrekt.
Beim Booten kann man Linux zusätzliche Befehle mitgeben. Einen, nvme_load=YES, probiere ich in allen Schreibweisen aus.
Unter Linux werden Hardwarekomponenten im Verzeichnis /dev aufgelistet. Während Festplatten dort /dev/sdx heipen (das „x“ wird durch einen fortlaufenden Buchstaben ersetzt, die erste Platte heißt /dev/sda) und ihre Partitionen dann durchnumeriert werden (/dev/sda hat als erste Partition /dev/sda1), werden M.2-SSDs als „nvme“ angezeigt und gleich durchnumeriert.
Also zum Beispiel als /dev/nvme0. In meinem Fall fehlten solche Einträge, wenn ich mit dem USB-Stick gebootet habe.
Ich entschließe mich, das System erstmal direkt auf der klassischen Festplatte zu installieren und mich später drum zu kümmern.
Bislang funktionierte alles gut. Vom Einschalten des PC bis zum Login lag ich bei knapp einer Minute, von der fast 20 Sekunden schon BIOS verbraucht wurden. Damit kann ich leben.
Nun war aber Google Chrome kaputt, genau genommen nicht nur kaputt, sondern führte zu Abstürzen der grafischen Oberfläche. Linuxmint 20 ist verfügbar, also wollte ich alles neu machen.
Möglichkeit 1: Ich sichere alle Userdaten und formatiere die Platte neu. Dann spiele ich die Userdaten zurück.
Das dauert.
Altenative: Auf einer zweiten Platte installiere ich die neue Linux-Version und mach sie lauffähig, danach hänge ich die alte Platte als /home ein.
Eine zweite Platte ist ja eingebaut: Die SSD, und da wollte ich das Betriebssystem ja eh drauf haben. Vor einem Dreivierteljahr.
Ein Blick ins Systemlog war daher interessant. Taucht die SSD darin auf? Man kann das grafische Tool nehmen, für mich ging die Kommandozeile schneller.
dmesg als Kommando listet das gesamte Log an. Das sind viele tausend Zeilen. Also filtert man mit grep alle Zeilen heraus, in denen der Plattentyp nvme vorkommt :
dmesg | grep nvme
Die Logsätze ergaben, dass beim Start von Linux eine M.2-SSD gefunden wurde, beim Versuch, sie zu nutzen, aber etliche Timeouts auftraten, weshalb das Betriebssystem sie im Weiteren ignoriert hat.
Die SSD wurde also gefunden, funktionierte nur nicht so wie geplant.
Mit etwas Suche kam ich auf die Vermutung, dass es mit dem Energiesparmodus der SSD zu tun haben könnte. Die SSD legt sich „schlafen“ und das Aufwachen dauert dem Betriebssystem zu lange, was den Timeout verursacht.
Zuerst recherchierte ich, ob die verbaute SSD überhaupt dieses Energiesparen, auch APST (Autonomous Power State Transition) genannt, beherrscht. Es handelt sich um die WD PC SN520 128 GB NVMe SSD und laut Datenblatt von Western Digital kann sie verschiedene Modi annehmen, für PS3 und PS4 (PS steht für Power Saving) sind auch Verbrauchsdaten angegeben.
Also ja: Sie kann Energie sparen.
Die Latenzzeit, nach der die SSD sich in den Energiesparmodus versetzt, kann man steuern. Dazu gibt es einen Systemparameter. Diese Parameter sind bei Linux auch wieder in (vorgetäuschten) Verzeichnissen abgespeichert und können so ausgelesen werden. Um diesen Parameter zu setzen, kann man in einem bestimmten der vielen Konfigurationsfiles folgendes eintragen:
nvme_core.default_ps_max_latency_us=5500
Dadurch würde der Wert auf 5500 Microsekunden gesetzt, also 5,5 Millisekunden.
Das stellt uns vor ein gravierendes Problem: Das Betriebssystem setzt nach dem Start die Parameter so, wie sie in den Konfigurationsdateien beschrieben sind. Hier ist ein Parameter jedoch schon erforderlich, um auf die Platte zuzugreifen, von der Linux booten will.
Ein Catch 22: Ich muss einen Parameter setzen, kann das aber erst, wenn der Parameter gesetzt ist.
Linux bootet nun über einen Bootmanager, heute nutzt man GRUB 2 dafür. Der Bootmanager weiß, welche Betriebssysteme vorhanden sind, und wenn mehr als eine Version vorhanden ist, bietet er eine Auswahl an. Verkürzt gesagt. Lustigerweise aktiviert GRUB 2 den Energiesparmodus nicht und kann daher problemlos mit der SSD arbeiten.
Zum Booten der Betriebssysteme gibt es auch eine Konfiguration, die man GRUB 2 mitteilen kann. In diesem Fall bootete ich vom USB-Stick und sah eine Auswahl an Startmöglichkeiten: Linuxmint als Live-Demo, Linuxmint im Recovery-Modus, einen automatischen Installer.
Wie genau gebootet wird kann man hier eintragen, indem man das System auswählt, das man haben möchte, und das „e“ drückt. Dann landet man in einem sehr rudimentären Editor.
Irgendwo im angezeigten Text findet sich eine Zeile, in der „quiet splash“ steht. Das ist die Anweisung, einen Splashscreen zu zeigen (das animierte Logo beim Start) und ansonsten möglichst wenig zu reden.
In dieser Zeile fügt man beispielsweise den obigen Parameter ein:
quiet splash nvme_core.default_ps_max_latency_us=0
Bei der Eingabe hat man allerdings eine US-Tastatur vor sich, ganz gleich, wie die Tasten beschriftet sind. Y und Z sind also vertauscht, der Unterstrich wird mit Shift+ß eingegeben, das „=“ liegt daneben auf der Akzent-Taste.
Hat man es eingegeben, drückt man die angegebene Taste (F10 oder Strg+X) um zu booten.
Ich probiere für den Parameter mehrere Werte aus, um schließlich mit dem (oben angegebenen) Wert „0“ den Energiesparmodus zu deaktivieren. Über 5000 wollte ich den Wert nicht ohne tiefere Recherche setzen, daher schaltete ich APST ab.
Und – huch – im Verzeichnis /dev findet sich ein Gerät namens nvme0.
Ich starte den Installer und wähle aus, das neuen Linux neben dem Alten zu installieren. So kann ich beim Start jedes Mal zwischen den Versionen wechseln, die GRUB 2 mir anzeigt.
Nach dem Installieren starte ich das neue Linux – es geht nicht. Klar: Der Parameter muss gesetzt werden. Ich starte nochmal, wähle das neue Linux aus, drücke „e“ und gebe ihn ein. Voilà: Es geht.
Um den Parameter bei jedem Booten zu setzen, kann ich den Eintrag im GRUB 2 persistent machen.
Als root-User öffnet man eine bestimmte Datei im Editor. Dort befinden sich die Parameter zum Booten.
sudo vi /etc/default/grub
Dort wird wieder in der Zeile mit „quiet splash“ der Parameter hinzugefügt. Danach muss das Bootmenü neu aufgebaut werden. GRUB 2 sucht dabei alle verfügbaren Betriebssysteme auf den diversen Platten zuammen und generiert aus den Parametern in der gerade geänderten Datei die Einträge:
sudo update-grub
Das wars. Ich installierte die basal für mich erforderliche Software, u.a. einen neuen google Chrome. Dann kopierte ich alle unter /home vorhandenen Dateien (in erster Linie Konfigurationsdateien) in eine Archivdatei und las über den Festplattenmanager die UUID (also den langen, numerischen IC-Code) der Terabyte-Festplatte aus, auf der das alte Linux lag.
Mit
sudo vi /etc/fstab
öffnete ich die Datei mit den Infos zu Plattensystemen und kopierte die Zeile mit dem root-Verzeichnis:
UUID=614959f7-d8b3-4a6e-8a15-68423772**** / ext4 errors=remount-ro 0 1
und ersetzte in der Kopie die UUID der SSD durch die UUID der Festplatte sowie den Mountpoint „/“ durch „/home“.
UUID=121905b6-9103-4f63-ab8e-4dcd85db**** /home ext4 errors=remount-ro 0 1
Danach habe ich den Rechner neu gebootet. Die Homedirectories der User waren jetzt unter /home/home, da die Platte ja ursprünglich selber eine Root-Platte war. Ich hab die User-Directories nach /home verschoben und die im Archiv gesicherten Dateien drüber kopiert. Den Rest hab ich danach gelöscht. Mit einem neuen update-grub hat GRUB 2 dann auch bemerkt, dass nur noch ein Linux vorhanden ist, und die anderen Einträge gelöscht.
Statt einer Minute braucht der Rechner jetzt 28 Sekunden. Die 20 Sekunden vom BIOS bleiben unverändert, Linux ist also in 8 Sekunden gebootet. Und zwar kalt, nicht, wie bei Windows, aus einer verkappten Hibernation.
