GRUB (efi-System): halt ≠ poweroff | shutdown -h now

[ingo2]

Ich habe meine /etc/grub.d/040_custom um die Befehle "reboot und "halt" ergänzt.
Die funktionieren auch, "reboot" ist problemlos, nur bei "halt" loggt meine MVNe-SSD jedes Mal einen "unsafe shutdown" in dem eintspechenden SMART-Attribut.

Das gibt mir zu denken - sollte doch eigentlich nicht sein und es besteht langfristig sicher auch die Möglichkeit von Datenverlust. Ist das eventuell ein Bug in GRUB - dann würde ich das reporten? Zu GRUB gehören ja die Module reboot.mod und halt.mod. Die Aussicht auf ein Fix ist für Bookworm wahrscheinlich nicht mehr möglich.

Gruß, Ingo

[rjh]

Meiner Meinung nach liegt das "Problem" da nicht bei grub. Da passiert doch rein physisch auch nichta auf dem Datenträger. Man kann auch einfach den Stecker ziehen.

[ingo2]

So, habe jetzt noch hier https://www.gnu.org/software/grub/manual/grub/grub.html# in der Dokumentation zu GRUB 2.06 unter Kapitel16.3.31 die Beschreibung zu "halt", so wie sie GRUB impementiert (halt.mod), gefunden:

The command halts the computer. If the --no-apm option is specified, no APM BIOS call is performed. Otherwise, the computer is shut down using APM.

Generell sollte ACPI das System aber sauber ausschalten, denn GRUB selbst hat ja gerade erst selbst auf die SSD zugegriffen, um über shim auf der EFI-Partition sich selbst sowie seine Konfiguration (grub.cfg) und seine Module (*.mod) von der Systempartition zu laden. Dazu kommt noch, das die NVMe-SSD "HBM" (Host Memory Buffer) nutzt, also auch Daten im RAM des Hosts syncen muß. Die erste Aufgabe wäre also, dass GRUB die SSD - ich schreibe mal "detached" und dann via ACPI (Modul "acpi.mod" in [deb][grub-efi-amd64-bin/deb] das System ausschaltet.

Ob das überhaupt machbar ist? Damit kenne ich mich zu wenig aus, weiß Jemand da mehr?
Ingo

[fischig]

Was hat eigentlich ein bootloader mit Ausschalten/neu Starten zu tun? Bin wahrscheinlich zu lange dabei, um sowas zu wissen.

[rjh]

Ich verstehe es ja auch nicht und dachte bislang, dass man da ein und ausschalten kann, wie man lustig ist. Werde es auch weiterhin so machen. Ja, man kann die Befehle natürlich auch in grub mit zum Auswählen auflisten lassen, man kann aber auch einfach ctr-alt-del drücken zum neustarten aus grub heraus. Sollte dem Datenträger eigentlich schnurzpiepegal sein.

[ingo2]

... man kann aber auch einfach ctr-alt-del drücken zum neustarten aus grub heraus. Sollte dem Datenträger eigentlich schnurzpiepegal sein.

Der Vergleich hinkt:
ctr-alt-del geht hier auch - genauso geht ein "reboot" in der command shell von GRUB hier, das schaltet den Rechner auch nicht aus. Es geht hier um den Befehl zum Ausschalten. Ist euch noch nie passiert, dass man aus Versehen "reboot" gewählt hat, aber eigentlich "poweroff" wollte. Da muß man ansonsten bei einem Minimalsystem oder Server erst wieder als root einloggen um dann "poweroff" auszuführen, oder bei einem Desktopsystem bis zum Login-Manager (z.B. lightdm) booten um dann "Herunterfahren" anzuklicken.

[fischig]

Loginmanager benutze ich keinen. Ich habe sowohl für reboot als auch für shutdown ein kleines super-script (geht aber auch mit sudo) und dafür 'nen Starter im tint2-panel. Ich frage nochmal, warum Bootloader? Mag ja was für sich haben, aber auf die Idee bin ich in 20 Jahren Debian halt noch nie gekommen.

Da muß man ansonsten bei einem Minimalsystem oder Server erst wieder als root einloggen

Also ich nicht. Ach ja, ich glaub', ich kapier's jetzt. Du willst, wenn du versehentlich reboot statt poweroff gewählt hast, bereits beim bootloader, also ohne Einloggen, ausschalten können? Nun ja, wenn's beliebt.

[Livingston]

@fischig: Klassischer Anwendungsfall - man startet fälschlicher- und tüddeligerweise 30 Kisten mit Hilfe von Wake On LAN, die schön unzugänglich verbaut sind (z.B. im Schulungsraum oder ne Serverbatterie). Griffbereit sind nur Monitor, Tastatur und Maus. Das will man so weit wie möglich abkürzen.
Alles schon erlebt. Da fällst Du vor gut eingerichteten GRUBs auf die Knie.

[fischig]

@fischig: Klassischer Anwendungsfall - man startet fälschlicher- und tüddeligerweise 30 Kisten mit Hilfe von Wake On LAN, die schön unzugänglich verbaut sind (z.B. im Schulungsraum oder ne Serverbatterie).

Einleuchtend! Leider ist das jenseits des Horizontes meines einfältigen single-user-Hirns mit spartanischer GUI.

Da fällst Du vor gut eingerichteten GRUBs auf die Knie.

Gefällt mir sehr!

[rjh]

Zurück zum Problem:
Macht nun dieser GRUB halt/poweroff Datenträger kaputt?

[ingo2]

Schade, dass sich hier niemand meldet - so selten sind NVMe-SSD's ja nicht mehr
Ist doch keine Mühe im GRUB-Menu mit "c" mal auf eine Befehlszeile zu gehen und

Code: Alles auswählen

halt

auszuführen und checken, ob dabei das SMART-Attribut "Unsafe Shutdowns" hochgezählt wird.

Im gebooteten System gibt's dafür den Befehl

Code: Alles auswählen

nvme flush /dev/nvme0

aber den kennt die GRUB-Shell natürlich nicht, ein gebootetes System jedoch - und da klappt das Ausschalten ja auch sauber. Wäre also Aufgabe von GRUB oder dem Befehl "halt" selbst bevor der Strom ausgeknipst wird.

[KP97]

Hm, Ingo, so richtig wird Dir meine Antwort nicht helfen, aber bei mir funktioniert das, allerdings:

auf meinem Netbook HP 2170p habe ich eine SSD aber kein EFI ( mit Bookworm)
auf meinem Intel NUC habe ich eine HDD mit EFI (mit Sid)

Beide haben Grub Version 2.06-12.

[KP97]

Macht nun dieser GRUB halt/poweroff Datenträger kaputt?

Seltsame Frage, warum sollte das passieren? Die Software führt die Anweisung aus, oder eben nicht, und das war's auch schon.

[rjh]

Ist doch keine Mühe im GRUB-Menu mit "c" mal auf eine Befehlszeile zu gehen und

Code: Alles auswählen

halt

auszuführen und checken, ob dabei das SMART-Attribut "Unsafe Shutdowns" hochgezählt wird.

Wo bzw. wie kann ich denn dieses "SMART-Attribut" auslesen?

Edit:

Habe es herausgefunden und mir nvme-cli installiert. Kann Deine Beobachtung zumindest bestätigen. Der Wert für unsafe_shutdowns wird durch das Ausführens des halt Befehls in GRUB um jeweils 1 erhöht.

[ingo2]

Kann Deine Beobachtung zumindest bestätigen. Der Wert für unsafe_shutdowns wird durch das Ausführens des halt Befehls in GRUB um jeweils 1 erhöht.

Na, vielen Dank - das ist schon mal ein Hinweis, dass es wohl ein Bug ist, den man melden sollte.
Jetzt dann noch eine Frage/Bitte:
Wie sieht es denn bei einem normalen "poweroff" bei dir aus - ich gehe mal davon aus, dass das sauber läuft?
(das mit "halt" anstatt "poweroff" zu testen bringt nix, das "halt" ist nicht identisch mit dem im GRUB)

Wenn du jetzt auch bestätigst, das es bei dir ebenfalls ein EFI-System ist, geht der Bug gegen grub-efi-amd64

Ach ja, noch zur Vollständigkeit hier: Die SSD ist eine DRAM-lose "Samsung 980 NVMe".

Ingo

[rjh]

Ja, ist hier ein EFI System. Normales

Code: Alles auswählen

shutdown -h now

läuft sauber.

Hardware auch hier: Samsung NVMe SSD 980 500GB

Habe eben auch noch die neueste Firmware (3B4QFXO7) für die Samsung installiert. Weiterhin gleiches Verhalten, also unsafe shutdown nach halt aus GRUB.

[ingo2]

So, für alle, die mitlesen und vielleicht noch was ergänzen wollen:

Der Fall ist als 1035665 aktenkundig - mal sehen ob's darauf eine Reaktion gibt.

@rjh

Habe eben auch noch die neueste Firmware (3B4QFXO7) für die Samsung installiert. Weiterhin gleiches Verhalten, also unsafe shutdown nach halt aus GRUB.

Die Firmware war bei mir absolut nötig. Mit der Originalversion 2B4QFXO7 hatte die SSD Probleme, wenn sie zum Stromsparen in die idle-Powerstates wechselte (s. https://forum.proxmox.com/threads/smart ... ost-509668). Deswegen hat die SSD auch hohe Werte für "Thermal Temp. 2 Transition Count:" und "Thermal Temp. 2 Total Time:" bei mir, immer kurze Spikes auf 84°C und zurück. Hatte zum Umschiffen die "non-operational-states" "3" und "4" deaktiviert mit dem Kernel-Parameter in /etc/default/grub:

Code: Alles auswählen

GRUB_CMDLINE_LINUX="nvme_core.default_ps_max_latency_us=1350"

Mit der neuen Firmware 3B4QFXO7 ist der Spuk vorbei.

Gruß, Ingo