Grub Boot Loader on Arch und Derivate

[BBig]

Moin zusammen,
wie viele sind hier eigentlich mit Arch (oder einem Derivat) unterwegs?

Es gibt Sachen, die können mal schief laufen - auch wenn man vorher auf die News-Seite von Arch geschaut hat.
Aber wenn der Boot Loader aussteigt, dann ist das nochmal eine andere Liga. Zumindest für mich, denn dann muss man einen Live-USB-Stick da haben und chrooten (https://wiki.archlinux.org/title/Chroot).
Sicherlich können das einige ohne "Anleitung", ich muss ins Wiki schauen.

==

Was war passiert?
Bei Grub gab es ein Commit der fwsetup --is-supported einführt, und wenn die installierte Version dies nicht unterstützt, dann steigt Grub aus.

Da hat es das erste mal klick gemacht bei mir: Wenn ich das richtig verstehe, dann hat das updaten des Grub-Paketes keine wirklichen Auswirkungen auf das System, solange man nicht grub-install ausführt, oder?
Wo ist dann der Sinn, das Grub-Paket aktuell zu halten ohne einen Hook post-install der auch dann grub-install ausführt? Erschließt sich mir nicht.

Dementsprechend ist die Lösung:
Nach dem letzten Update von Grub grub-install (https://wiki.archlinux.org/title/GRUB#Installation) && grub-mkconfig (https://wiki.archlinux.org/title/GRUB#Generated_grub.cfg) nochmal druchlaufen zu lassen.

==

Arch (und Derivate) sind Rolling-Release-Distros; das es mal zu Ungereimtheiten kommt, nimmt man im Kauf um ein System zu haben, was ohne Neuinstallation alle Jahre auskommt und man immer aktuelle Software hat.

Es gibt aber zwei Sachen, die mir dabei sauer aufstoßen:

- Warum schafft es eine Downstream-Distro wie Endeavouros sich der Sache einen Tag nach dem Update (https://endeavouros.com/news/full-transparency-on-the-grub-issue/) anzunehmen, aber auf der Arch-News-Seite kommt ein Hinweis erst 5 Tage (https://archlinux.org/news/grub-bootloader-upgrade-and-configuration-incompatibilities/) später?
Dazu kommt, das es nicht irgendein Paket ist, sondern Grub. Da finde ich die ausführlicheren Informationen von Endeavouros schon angebracht, statt dem 5-Zeiler von Arch.

- Wenn ich mir den Bug-Report (https://bugs.archlinux.org/task/75701) dazu anschaue und denn "Fix" dazu (https://github.com/archlinux/svntogit-packages/commit/a244970746180238030a4c724ca8196246f554d2), dann stelle ich mir doch die Frage, wo ist das ein Fix oder wo ist das kein Bug, wie Arch das Paket Grub behandelt. Denn so wie es ausschaut, bleibt alles beim Alten.
Es gibt keinen dauerhaften Fix (wie z.B. einen speziellen Hook post-install für Grub). Der "Fix" ist ein Notiz mit dem Hinweis, man solle grub-install & grub-mkconfig ausführen "due to potential configuration incompatibilities". Sorry, dass reicht nicht, oder seht ihr das anders?
Beim nächsten Feature-Update von Grub, stehen wir nämlich genau da, wo wir jetzt stehen. Und da Arch nur einen 5-Zeiler auf ihrer News-Seite produziert hat, weiß der "Normalo-Arch-User" auch nicht warum.


Sehe ich da was verkehrt, seht ihr das anders?


P.S.: Auch wenn ihr schon geupdatet habt und euer System läuft: Beim nächsten grub-mkconfig ohne das ihr vorher grub-install gemacht habt, kann es gut ein, dass dann Grub aufgibt.
Da ja der neue Eintrag /etc/grub.d/30_uefi-firmware auf fwsetup --is-supported zurückgreift.

[Berniyh]

Aber wenn der Boot Loader aussteigt, dann ist das nochmal eine andere Liga. Zumindest für mich, denn dann muss man einen Live-USB-Stick da haben und chrooten (https://wiki.archlinux.org/title/Chroot).
Sicherlich können das einige ohne "Anleitung", ich muss ins Wiki schauen.
Einen Live-USB Stick zu haben ist immer eine gute Idee, aber das nur am Rande. ;)
Generell ist so ein Problem natürlich schon sehr ärgerlich. Ein paar Dinge kann man aber auch ohne Live-USB Stick beheben bzw. umgehen, indem man eine command line aufmacht, oder die Zeile editiert.
Das kann z.B. dann hilfreich sein, wenn GRUB ein kernel image booten will, das nicht existiert, aber andere vorhanden sind.
Da hat es das erste mal klick gemacht bei mir: Wenn ich das richtig verstehe, dann hat das updaten des Grub-Paketes keine wirklichen Auswirkungen auf das System, solange man nicht grub-install ausführt, oder?
Wo ist dann der Sinn, das Grub-Paket aktuell zu halten ohne einen Hook post-install der auch dann grub-install ausführt? Erschließt sich mir nicht.
Da hast du die Funktionsweise von GRUB falsch verstanden. GRUB ist in sogenannte "Stages" unterteilt:
Stage 1: 512 Bytes groß, passt in den MBR. Hat nur die Funktion Stage 1.5 aufzurufen
Stage 1.5: Enthält zusätzlich Unterstützung für das Dateisystem von Stage 2 und lädt diese dann
Stage 2: Kann sich irgendwo befinden. Stellt das Menü bereit, lädt ggf. Dateisystemmodule, initrd sowie das Kernel image etc.

Stage 1 und Stage 1.5 sind quasi unveränderlich (solange man den Ort und/oder das Dateisystem von Stage 2 nicht verändert). Im Prinzip installiert grub-install hauptsächlich die Stage 1. Da sich diese dann nicht mehr ändert, muss man später im Normalfall auch nie wieder grub-install ausführen. Ausnahmen sind, wenn die Stage 1 aus irgendeinem Grund kaputt geht (ignorantes Windows z.B.).
Das was die Stage 2 dann aber lädt ist konfigurierbar (typischerweise über die Dateien in /boot/grub). Wenn man da inkompetent rumfingert, dann kann man sich durchaus auch das System so zerschießen, dass es nicht mehr bootet.
Änderungen passieren zum Beispiel auch dann, wenn neue Kernel Versionen installiert werden, damit diese von GRUB auch geladen werden können.

Der Vorteil von dieser (recht komplizierten) Struktur ist, dass GRUB eine große Anzahl an Features unterstützen kann, z.B. verschiedene Dateisysteme, RAID, verschlüsselte Laufwerke.
Das war insbesondere früher mit dem legacy BIOS wichtig. Heute mit EFI kann man natürlich in vielen Fällen auch mit simpleren Lösungen auskommen.

Bei EFI schadet es übrigens auch nicht mit --removable (ggf. zusätzlich) zu installieren. Dadurch wird auf esp/EFI/Boot noch ein image für EFI abgelegt, welches das UEFI automatisch finden sollte, auch nach einem UEFI Update.
- Warum schafft es eine Downstream-Distro wie Endeavouros sich der Sache einen Tag nach dem Update (https://endeavouros.com/news/full-transparency-on-the-grub-issue/) anzunehmen, aber auf der Arch-News-Seite kommt ein Hinweis erst 5 Tage (https://archlinux.org/news/grub-bootloader-upgrade-and-configuration-incompatibilities/) später?
Dazu kommt, das es nicht irgendein Paket ist, sondern Grub. Da finde ich die ausführlicheren Informationen von Endeavouros schon angebracht, statt dem 5-Zeiler von Arch.
Gut, die Frage musst du wohl nicht hier, sondern eher im Arch Forum stellen.
Aber ja, das ist ein klarer Fehler des Maintainers und sollte nicht vorkommen. Extrem ärgerlich.
- Wenn ich mir den Bug-Report (https://bugs.archlinux.org/task/75701) dazu anschaue und denn "Fix" dazu (https://github.com/archlinux/svntogit-packages/commit/a244970746180238030a4c724ca8196246f554d2), dann stelle ich mir doch die Frage, wo ist das ein Fix oder wo ist das kein Bug, wie Arch das Paket Grub behandelt. Denn so wie es ausschaut, bleibt alles beim Alten.
Es gibt keinen dauerhaften Fix (wie z.B. einen speziellen Hook post-install für Grub). Der "Fix" ist ein Notiz mit dem Hinweis, man solle grub-install & grub-mkconfig ausführen "due to potential configuration incompatibilities". Sorry, dass reicht nicht, oder seht ihr das anders?
Da verstehe ich nicht genau worauf du hinaus willst. Was würdest du dir denn vorstellen, dass gemacht werden sollte?
Beim nächsten Feature-Update von Grub, stehen wir nämlich genau da, wo wir jetzt stehen. Und da Arch nur einen 5-Zeiler auf ihrer News-Seite produziert hat, weiß der "Normalo-Arch-User" auch nicht warum.

Sehe ich da was verkehrt, seht ihr das anders?
Sehr unwahrscheinlich. GRUB ist ein systemrelevantes Tool, da wird im Normalfall schon genauer hingeschaut.
Ich nutze GRUB seit über 15 Jahren und so ein Fehler ist mir bisher noch nicht untergekommen. Auch nicht über Berichte und so ein Bug schlägt schon Wellen (d.h. es ist sehr wahrscheinlich, dass es bei mir angekommen wäre).
Dass es jetzt passiert ist ist natürlich extrem ärgerlich und ich stimme dir absolut zu, dass es bei so einem systemrelevanten Tool nicht passieren darf.
Aber letztendlich arbeiten da auch nur Menschen dran und Fehler kann man eben nie ganz ausschließen.
Es gab ja auch in ext4 schon mal einen absolut kritischen Bug, der auch ziemlich Wellen geschlagen hat. Und auch da darf das nicht passieren.
Wie gesagt, sind halt auch nur Menschen …

[Ganon]

Ich persönlich habe privat Grub nun schon seit Jahrzehnten nicht mehr verwendet. Zu BIOS Zeiten habe ich syslinux benutzt. Zu anfänglichen EFI-Zeiten (damals noch auf einem MacBook) dann rEFInd und auf aktueller Hardware nur noch systemd-boot.

Grub ist zwar der Standard-Bootloader in vielen automatisierten Distributions-Installern, aber der gewöhnliche Vanilla-ArchLinux Nutzer hat nicht zwangsläufig Grub. Darum fällt das Problem halt auch hauptsächlich dort zuerst auf, wo alle Nutzer das automatisch installiert und ggf. via Auto-Updater das auch gleich Day-1 das Update bekommen haben.

[aufkrawall]

Bin sehr froh, dass Arch standardmäßig keine Pacman-Hooks zur Erneuerung des Grub-Bootloaders oder der Config nutzt. Die ganze Problematik ist mir so komplett erspart geblieben.

[Berniyh]

Bin sehr froh, dass Arch standardmäßig keine Pacman-Hooks zur Erneuerung des Grub-Bootloaders oder der Config nutzt. Die ganze Problematik ist mir so komplett erspart geblieben.
???

Die grub Config wird doch automatisch aktualisiert? Zumindest auf dem Arch PC hier ist das definitiv so.

[Ganon]

Die grub Config wird doch automatisch aktualisiert? Zumindest auf dem Arch PC hier ist das definitiv so.

Gerade mal nachgesehen. Das vanilla ArchLinux Grub Paket installiert weder pacman-hooks, noch steht sowas in der grub.install Datei.

Ansonsten aus dem verlinkten Bug-Report:



Now...

This issue is only ever relevant if you run `grub-mkconfig` without doing a `grub-install`. The reason why this issue is never really encountered on Arch Linux is because there is nothing that runs these things after kernel updates nor grub updates. So who does these things?

- https://gitlab.com/garuda-linux/packages/stable-pkgbuilds/garuda-hooks/-/blob/4f4da043088f45372877e9154fec36aa3f605d6b/grub-update.hook
- https://gitlab.manjaro.org/packages/core/grub/-/blob/master/update-grub
- https://github.com/endeavouros-team/PKGBUILDS/blob/a50b847e982c62f53f9858eea219927bb6498656/grub-tools/eos-grub-update-after-kernel.hook

So while it's great that people blame Arch for moving forward with a git release, it's quite shitty when dependant distros do not look at their own hooks. Arch users shouldn't be hitting this issue, if at all. While this would probably break most of the derivative distros that updated linux along with grub on older machines without `reboot into firmware` setups.

tl;dr: Das Ding ist wohl hauptsächlich ein Bug in Arch-Derivaten.

[BBig]

...
Da hast du die Funktionsweise von GRUB falsch verstanden. GRUB ist in sogenannte "Stages" unterteilt:
Stage 1: 512 Bytes groß, passt in den MBR. Hat nur die Funktion Stage 1.5 aufzurufen
Stage 1.5: Enthält zusätzlich Unterstützung für das Dateisystem von Stage 2 und lädt diese dann
Stage 2: Kann sich irgendwo befinden. Stellt das Menü bereit, lädt ggf. Dateisystemmodule, initrd sowie das Kernel image etc.

Stage 1 und Stage 1.5 sind quasi unveränderlich (solange man den Ort und/oder das Dateisystem von Stage 2 nicht verändert). Im Prinzip installiert grub-install hauptsächlich die Stage 1. Da sich diese dann nicht mehr ändert, muss man später im Normalfall auch nie wieder grub-install ausführen. Ausnahmen sind, wenn die Stage 1 aus irgendeinem Grund kaputt geht (ignorantes Windows z.B.).
Das was die Stage 2 dann aber lädt ist konfigurierbar (typischerweise über die Dateien in /boot/grub). Wenn man da inkompetent rumfingert, dann kann man sich durchaus auch das System so zerschießen, dass es nicht mehr bootet.
Änderungen passieren zum Beispiel auch dann, wenn neue Kernel Versionen installiert werden, damit diese von GRUB auch geladen werden können.

Der Vorteil von dieser (recht komplizierten) Struktur ist, dass GRUB eine große Anzahl an Features unterstützen kann, z.B. verschiedene Dateisysteme, RAID, verschlüsselte Laufwerke.
Das war insbesondere früher mit dem legacy BIOS wichtig. Heute mit EFI kann man natürlich in vielen Fällen auch mit simpleren Lösungen auskommen.

Bei EFI schadet es übrigens auch nicht mit --removable (ggf. zusätzlich) zu installieren. Dadurch wird auf esp/EFI/Boot noch ein image für EFI abgelegt, welches das UEFI automatisch finden sollte, auch nach einem UEFI Update.

...

Da verstehe ich nicht genau worauf du hinaus willst. Was würdest du dir denn vorstellen, dass gemacht werden sollte?

…

Das Grub Stages hat, hatte ich schon mal gelesen; wenn ich das auf "deine" Stages anwende:
Wenn ich das richtig verstanden habe, dann benutzt das neue Paket von Grub fwsetup --is-supported, was die alte installiere Version nicht versteht und Grub steigt aus.
Sprich in der Stage 2 ist dann die alte Version installiert, die die neu generierte grub.conf nicht versteht.

Da liegt doch die Crux.
Klar führt man nicht alle Nase lang grub-mkconfig aus.
Aber du sitzt vor einem System, was demnächst oder irgendwann mal ein Problem hat. Ob du nun in einem Jahr oder nächste Woche beschließt, ein neues BS zu installieren, dann generierst du einen neue grub.conf mit grub-mkconfig ohne grub-install und schon stehste da.
Nach ein paar Monaten nachdem ein neues Grub-Paket kam, wird die Spurensuche sicher interessant, :freak:

...

Da verstehe ich nicht genau worauf du hinaus willst. Was würdest du dir denn vorstellen, dass gemacht werden sollte?

Sehr unwahrscheinlich. GRUB ist ein systemrelevantes Tool, da wird im Normalfall schon genauer hingeschaut.
Ich nutze GRUB seit über 15 Jahren und so ein Fehler ist mir bisher noch nicht untergekommen. Auch nicht über Berichte und so ein Bug schlägt schon Wellen (d.h. es ist sehr wahrscheinlich, dass es bei mir angekommen wäre).
Dass es jetzt passiert ist ist natürlich extrem ärgerlich und ich stimme dir absolut zu, dass es bei so einem systemrelevanten Tool nicht passieren darf.
Aber letztendlich arbeiten da auch nur Menschen dran und Fehler kann man eben nie ganz ausschließen.
Es gab ja auch in ext4 schon mal einen absolut kritischen Bug, der auch ziemlich Wellen geschlagen hat. Und auch da darf das nicht passieren.
Wie gesagt, sind halt auch nur Menschen …

Ich habe keine Ahnung, wie ausgefeilt das post-install Hook-System von Arch ist, war ja nur eine Idee. Aber so ist es kein "Fix" imo.
Ich kann mir schon vorstellen, dass einige (vll auch aufkrawall), davon ausgehen: "Naja, Update lief ja ohne Probs durch; ergo alles in Butter." und vergessen den ganzen Kram bis zum nächsten grub-mkconfig.

Bin sehr froh, dass Arch standardmäßig keine Pacman-Hooks zur Erneuerung des Grub-Bootloaders oder der Config nutzt. Die ganze Problematik ist mir so komplett erspart geblieben.


P.S.: Auch wenn ihr schon geupdatet habt und euer System läuft: Beim nächsten grub-mkconfig ohne das ihr vorher grub-install gemacht habt, kann es gut ein, dass dann Grub aufgibt.
Da ja der neue Eintrag /etc/grub.d/30_uefi-firmware auf fwsetup --is-supported zurückgreift.

Wenn es einen "Mismatch" zwischen der installierten Version und der Version, die "grub-mkconfig" ausführt gibt, dann sind die Chancen gut, dass das nicht hinhaut.

Ich persönlich habe privat Grub nun schon seit Jahrzehnten nicht mehr verwendet. Zu BIOS Zeiten habe ich syslinux benutzt. Zu anfänglichen EFI-Zeiten (damals noch auf einem MacBook) dann rEFInd und auf aktueller Hardware nur noch systemd-boot.

Grub ist zwar der Standard-Bootloader in vielen automatisierten Distributions-Installern, aber der gewöhnliche Vanilla-ArchLinux Nutzer hat nicht zwangsläufig Grub. Darum fällt das Problem halt auch hauptsächlich dort zuerst auf, wo alle Nutzer das automatisch installiert und ggf. via Auto-Updater das auch gleich Day-1 das Update bekommen haben.

Ich weiß nicht was der Normalo-Arch-User hat; ich benutze Grub, weil ich ihn schon seit Ewigkeiten kenne. Bis jetzt auch ohne Probleme.

Aber du hast recht, alle meine Systeme laufen mit UEFI, vll sollte ich mir mal rEFInd / systemd-boot anschauen.

[BBig]

Gerade mal nachgesehen. Das vanilla ArchLinux Grub Paket installiert weder pacman-hooks, noch steht sowas in der grub.install Datei.

Ansonsten aus dem verlinkten Bug-Report:



tl;dr: Das Ding ist wohl hauptsächlich ein Bug in Arch-Derivaten.

Ich glaube da hat Ganon recht; meine Uralt Antergos-Install hat definitiv einen Hook zu grub-mkconfig jedesmal nachdem ein neuer Kernel installiert wird.

Mein Laptop (mit Vanilla-Arch) hat das imo nicht gemacht.
( - da hat sich aber gerade die SSD verabschiedet, so kann ich nicht gucken.)

===

Ändert aber nichts an der Tatsache, dass bei jedem Archsystem und Derivat, wenn du nicht grub-install nun ausführst und eine neue grub.conf generierst, du blöd dastehen kannst.

Bei den Derivaten mit Hook haste das Problem sofort, bei Arch dann später...

[Watson007]

Bei den automatischen Updates meines Proxmox-Systems hat es diese Woche auch den Grub-Bootloader bei mir zerschossen, wegen eines Bugs bei Grub

[Berniyh]

Gerade mal nachgesehen. Das vanilla ArchLinux Grub Paket installiert weder pacman-hooks, noch steht sowas in der grub.install Datei.
Hm, hast recht. Ich hab da bei Arch ehrlich gesagt nie genau hingeschaut.

Die klatschen einfach das aktuelle Kernel image mit einem statischen Namen in /boot, d.h. die alte Version wird überschrieben. Der statische Namen wird dann über die grub.cfg geladen.

Finde ich ehrlich gesagt auch sehr zweifelhaft, denn es ist eigentlich immer gut, noch einen älteren Kernel zur Verfügung zu haben, falls der aktuell installierte mal gegen die Wand läuft (das ist mir jedenfalls schon wesentlich häufiger passiert als ein Problem mit GRUB).

Andere Distros haben da bessere Vorgehensweisen und lassen noch 2-3 ältere Versionen in /boot. Da wird dann halt auch die grub.cfg aktualisiert, aber das ist halt praktisch nie ein Problem.
Noch besser ist es 1 oder 2 LTS Versionen als Backup zu haben. So mache ich das auf meinem Desktop. Allerdings händisch verwaltet.

Das Grub Stages hat, hatte ich schon mal gelesen; wenn ich das auf "deine" Stages anwende:
Wenn ich das richtig verstanden habe, dann benutzt das neue Paket von Grub fwsetup --is-supported, was die alte installiere Version nicht versteht und Grub steigt aus.
Sprich in der Stage 2 ist dann die alte Version installiert, die die neu generierte grub.conf nicht versteht.
Ne, die Stage 2 ist neu, die Stage 1.5 ist die alte und die kennt halt den Parameter --is-supported für fwsetup nicht.
Hab es mir jetzt mal etwas genauer angeschaut. Ganz ehrlich: das war eine Scheiß Idee seitens GRUB.
Man kann sich nicht darauf verlassen, dass Distributionen bei einem GRUB Update auch ein grub-install ausführen. Letztendlich könnte ja genau der Befehl durchaus auch dazu führen, dass man die Installation kaputt macht, wenn da (aus welchen Gründen auch immer) irgendwas schief geht.
Meiner Meinung nach ist es zudem auch eine total absurde Idee aus GRUB heraus ins UEFI Menü zu wollen. Kann man dafür nicht einfach die Entfernen Taste drücken (oder welche auch immer das Boardeigene UEFI haben will)?
Ok, ich verstehe, dass z.B. Bluetooth Tastaturen da Probleme machen, aber die funktionieren in GRUB doch vermutlich auch nicht?
Aber du sitzt vor einem System, was demnächst oder irgendwann mal ein Problem hat. Ob du nun in einem Jahr oder nächste Woche beschließt, ein neues BS zu installieren, dann generierst du einen neue grub.conf mit grub-mkconfig ohne grub-install und schon stehste da.
Nach ein paar Monaten nachdem ein neues Grub-Paket kam, wird die Spurensuche sicher interessant, :freak:
Ja, ich kann das schon verstehen, dass man frustriert und genervt ist, wenn das System nicht mehr startet und vor allem wenn es in so einer Dauer-Reboot Schleife gefangen zu sein scheint, wie das in diesem Fall ist.

Aber Kopf hoch, denn zum Einen hat man heutzutage ja zumindest (fast) immer das Internet in greifbarer Nähe und zum anderen lassen sich Probleme mit GRUB letztendlich meistens recht schnell beheben.
Aus so einer Situation habe ich sogar schon meinen Eltern rausgeholfen und die verstehen echt nicht viel von Computern. (In dem Fall hatte sich aus einem unbekannten Grund das UEFI reset damit dann auch die Linux Installation vergessen, da mir damals das mit dem extra Eintrag in esp/EFI/BOOT noch nicht bekannt war.)
Da hatte ich in meiner langen Linux und Windows Laufbahn schon andere Probleme, die wesentlich hartnäckiger und schlimmer waren. Gerade ein Windows, welches nicht mehr starten mochte war teilweise die Hölle. Das hatte ich mal mit XP, da habe ich glaube ich 2 Tage gebraucht, bis ich es wieder hinbekommen habe.

[Rumbah]

Ich hatte auch schon 2-3 Updateunfälle mit Arch, seitdem lese ich immer die Pacman Warnungen.
Ich halte mich nicht unbedingt dran, aber falls dann doch mal was nicht funktioniert, dann weiß ich wenigstens, wo ich gucken muss.

Abseits davon hatte ich mit dem Update von Grub von vor ca. 2 Wochen Probleme. Mein headless Server hat nur noch gebootet, wenn ein Monitor angeschlossen war. Das musste ich dann eine Woche aushalten und zum Reboot einen Monitor anschließen, dann wurde Grub noch einmal aktualisiert, dann gings wieder.

[Berniyh]

Abseits davon hatte ich mit dem Update von Grub von vor ca. 2 Wochen Probleme. Mein headless Server hat nur noch gebootet, wenn ein Monitor angeschlossen war. Das musste ich dann eine Woche aushalten und zum Reboot einen Monitor anschließen, dann wurde Grub noch einmal aktualisiert, dann gings wieder.
huh? :eek:

Das hört sich eigentlich eher nach einem Kernel Problem an. Kann mir kaum vorstellen, dass GRUB so etwas macht.
Aber selbst beim Kernel fände ich das sehr seltsam. :confused: