grub deinstallieren?

[fischig]

In der Paketsuche zu grub2 (bullseye) lese ich:

Dies ist ein Übergangspaket, das Upgrades von GRUB 2 unterstützt. Es kann problemlos entfernt werden.

Das habe ich (wie auch von deborphan vorgeschlagen) gemacht.

Nun erscheint beim Versuch eines dist-upgrades u.a.:

Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
grub-common grub-pc grub-pc-bin grub2-common ...

Irgendwie weigere ich mich, das zu glauben! Trügt mein Glaube?

Ich habe nicht vor, einen alternativen Bootmanager zu installieren. Ich fühle mich bemüsigt, mich mit dem ungeliebten Teil zu beschäftigen.

[JTH]

Ein flinkes

Code: Alles auswählen

apt-mark manual grub-pc

lässt dich GRUB behalten.

Für ein amd64-UEFI-System wärs

Code: Alles auswählen

apt-mark manual grub-efi-amd64

[fischig]

Das heißt dann aber doch, dass die Infos irreführend sind oder wie habe ich das zu verstehen?

[JTH]

Hmm, eigentlich sollte das nicht so sein. Man sollte den GRUB auch behalten, wenn er als automatisch installiert markiert ist. Die Kernelpakete, wie linux-image-5.10.0-7-amd64, schlagen einen Bootloader vor (als Suggests). Damit würde er, als Abhängigkeit, durch apt autoremove u.ä. nicht zum Entfernen vorgeschlagen. War zumindest bei mir grad testweise nicht der Fall.

Hast du evtl. einen Eigenbaukernel?

[fischig]

Hast du evtl. einen Eigenbaukernel?

Ja. Und zwar als einzigen (5.10 Vanilla, Übungsssystem). Recommends und Suggests sind abgeschaltet.

Nichtsdestotrotz: Es kann doch nicht sein, dass Debian den einzigen im System vorhandenen Bootloader deinstallieren will?

[schwedenmann]

hallo

Nichtsdestotrotz: Es kann doch nicht sein, dass Debian den einzigen im System vorhandenen Bootloader deinstallieren will?

Wieso, das kann doch ein zweitlnux sein,ohne bootloader,ist für debian doch nicht ersichtlich und wird vom bootloader einens 2.OS gebootet.


mfg
schwedenmann

[fischig]

Wieso, das kann doch ein zweitlnux sein, ohne bootloader, ist für debian doch nicht ersichtlich und wird vom bootloader einens 2.OS gebootet.

Das halte ich für eine arg sophistische Argumentation.

[JTH]

Ja. Und zwar als einzigen (5.10 Vanilla, Übungsssystem).

Dann ist das wohl die Ursache. Falls du den als deb-Paket installiert hast (ich bin nicht aktuell, wie man sich so üblicherweise einen eigenen Kernel baut), fehlt eine passende Abhängigkeit, wie sie die „original“ Pakete haben. Falls der einfach so gebaut ist, gibts einfach keine Abhängigkeit, die Grub festhalten würde.

Es kann doch nicht sein, dass Debian den einzigen im System vorhandenen Bootloader deinstallieren will?

Offensichtlich schon Die Grub-Pakete bzw. alle mir grad eingefallenen Bootloader sind sogar nur „optionale“ Pakete. Ein required und essentielles Paket, das garantiert einen Bootloader installiert hält, wäre vllt auf manchen* Systemen nicht verkehrt. So wie es init tut. Du kannst ja mal einen Bugreport anlegen, dann erfahren wir, warum es sowas für den Bootloader nicht gibt

Edit: * Außer auf Dual-Installationen, wie schwedenmann schreibt.

[DeletedUserReAsG]

Wieso, das kann doch ein zweitlnux sein, ohne bootloader, ist für debian doch nicht ersichtlich und wird vom bootloader einens 2.OS gebootet.

Das halte ich für eine arg sophistische Argumentation.

Das ist eigentlich ein sehr verbreitetes Setup.

[fischig]

Falls du den als deb-Paket installiert hast

Habe ich, nicht nur installiert, sondern auch mit mit bindeb-pkg bebaut.
Ich verwende seit deutlich mehr als 10 Jahren vorwiegend Vanilla-Eigenbaukerne (mit lilo). Das hier war eine Premiere, und keine besonders schöne.

[DeletedUserReAsG]

Dann gib halt ’nen Bootloader als Abhängigkeit von deinem Kernel-Paket an, und gut?

[KP97]

Wenn Du ein EFI auf Deinem System hast, brauchst Du diese vier Pakete:

grub-common
grub2-common
grub-efi-amd64
grub-efi-amd64-bin

Da Du ein altes Paket grub-pc entfernt hast, war als Abhängigkeit auch grub-common vermerkt. Das ist leider auch immer noch bei dem "neuen" grub-efi als Abhängigkeit
vorhanden, obwohl es ein grub2-common gibt. Wenn nun das "alte" common entfernt wird, zieht es den Rest mit.
Mußt Du also markieren, wie schon geschrieben.

Mit dem Kernel hat das nichts zu tun, ich habe auch einen Selbstkompilierten im Einsatz.

[fischig]

Dann gib halt ’nen Bootloader als Abhängigkeit von deinem Kernel-Paket an

Habe ich noch nie gemacht/machen müssen, weiß also nicht, wie das funktioniert und eigentlich brauche ich das auch nicht. Ich weiß, dass ich mir meinen einzigen bootloader nicht deinstallieren darf. Mich ärgert, dass es hier offenbar keine worst-case-Sicherung gibt. Ich find's verbesserungswürdig/reparaturbedürftig.

Ich habe kein efi. Und grub-pc habe ich auch nicht deinstalliert, sondern ausschießlich grub2.

[DeletedUserReAsG]

Es gibt auch keine „Worst-Case-Sicherung“ gegen: Entfernen des Kernels, Löschen systemrelevanter Dateien, Beschädigen von Konfigurationsfiles, Löschen wichtiger Daten, uvm.

Wenn du ’n System willst, bei dem du schon großen Aufwand betreiben musst, um was kaputtzumachen: hast du dir mal MacOS angeschaut? Dem Vernehmen nach ist’s so konzipiert, dass es den User vor sich selbst schützt.

[fischig]

Es gibt auch keine „Worst-Case-Sicherung“ gegen: Entfernen des Kernels

Gibt es sehr wohl.

es (schützt) den User vor sich selbst.

Früher oder später musste das wohl kommen.

[DeletedUserReAsG]

Gibt es sehr wohl.

Grad durchgespielt: der Kernel würde entfernt, und im Anschluss wäre das System unbootbar. Ist auch sinnvoll, wenn man ’n System im Container (systemd-nspawn oder sowas) haben will, das keinen eigenen Kernel braucht.

[fischig]

im Anschluss wäre das System unbootbar.

Darauf wurde jedenfalls ich bisher immer hingewiesen.

[JTH]

Grad durchgespielt: der Kernel würde entfernt, und im Anschluss wäre das System unbootbar.

In welcher Umgebung? In ’ner „normalen“ Benutzerinstallation und ohne DEBIAN_FRONTEND=noninteractive sollten dich doch /var/lib/dpkg/info/linux-image-*-*.prerm und linux-check-removal mit der Warnung und Frage

You are running a kernel (version ${running}) and attempting to remove the same version.

This can make the system unbootable […]

begrüßen. Ansonsten: Ja, sowas würde ohne irgendeine Warnung durchlaufen:

Code: Alles auswählen

~# DEBIAN_FRONTEND=noninteractive apt-get purge 'linux-image-*'

Mich ärgert, dass es hier offenbar keine worst-case-Sicherung gibt. Ich find's verbesserungswürdig/reparaturbedürftig.

Ich schließ mich da niemand an: Wenn du deinen eigenen Kernel baust und damit die regulären, gewarteten Pakete links liegen lässt, bist du auch für solche Punkte verantwortlich. Die Debian-gebauten Kernel hätten wie gesagt diese „Sicherung“.

[fischig]

Wenn du deinen eigenen Kernel baust und damit die regulären, gewarteten Pakete links liegen lässt, bist du auch für solche Punkte verantwortlich.

Das weiß ich, s.o.
Aber darum geht's gar nicht. Es geht darum, dass das System ein automatisches Entfernen des Bootloaders vorschlägt, aus dem einzigen Grund, dass ich vorher ein als überflüssig installiertes „Übergsangspaket" deinstalliert habe - was im vorliegenden einfachen Fall zu einem unbrauchbaren System führen würde. Das finde ich heftig.

Ich werde mal testen, was passiert, wenn ich versuche, grub-pc zu purgen, ob wenigstens dann ein Warn-Hinweis kommt. Einen autoremove-Versuch werde ich nicht starten.

edit: er macht das Purgen, ohne einen Hinweis auf die Notwendigkeit eines Bootloaders für das OS.

[JTH]

Ich werde mal testen, was passiert, wenn ich versuche, grub-pc zu purgen, ob wenigstens dann ein Warn-Hinweis kommt.

Wenn ich mir die Maintainerskripte aus den Grub-Paketen so angucke: Nein, da wird keine Warnung kommen. Nevermind.

[JTH]

edit: er macht das Purgen, ohne einen Hinweis auf die Notwendigkeit eines Bootloaders für das OS.

Tatsächlich? Ich bekomme in einer VM mit grub-pc zumindest die abschließende Frage

Do you want to have all GRUB 2 files removed from /boot/grub?

This will make the system unbootable unless another boot loader is installed.

Die Pakete sind allerdings trotzdem gepurget. Wenn man die Frage verneint, kommt das System aber zumindest noch einmal wieder hoch.

[fischig]

Tatsächlich?

Nein. Ich habe mich nur getraut, das anzustoßen, nicht es auch real durchzuziehen. Sowas realiter durchzuziehen kannst du beherrschen, ich nicht! Danke für eure Mitwirkung!

Wie gesagt, für mich ist und bleibt es strange: Ich will das System aktualisieren und stoße deswegen deborphan an, um eventuelle Leichen zu beseitigen. deborphan sagt mir: grub2 kann weg. grub, denkt sich der nicht ganz unbedarfte Laie, das kann nicht sein, das ist der Bootloder, ergo: mal schauen, was die Paketinfo dazu sagt: indeed, kann weg. Gemacht. Dann dist-upgrade und jetzt der Hinweis: Das ganze grub kann weg.

edit:
Ich habe jetzt spaßeshalber mal grub2 reinstalliert. jetzt will er grub-pc, etc. nicht mehr autoremoven. Will mir wirklich jemand einreden, das sei alles völlig ok?

[JTH]

grub, denkt sich der nicht ganz unbedarfte Laie, das kann nicht sein, das ist der Bootloder, ergo: mal schauen, was die Paketinfo dazu sagt: indeed, kann weg. Gemacht. Dann dist-upgrade und jetzt der Hinweis: Das ganze grub kann weg.

Wie gesagt: Sorge dafür, dass dein Kernel von einem Boottloader abhängt oder ihn zumindest empfiehlt. Das musst der Laie dann halt auch bedenken Ein gänzlich unbedarfter Benutzer hat mindestens eins der linux-image-* installiert und behält durch dessen Abhängigkeiten bei autoremove seinen Bootloader.

Ich habe jetzt spaßeshalber mal grub2 reinstalliert. jetzt will er grub-pc, etc. nicht mehr autoremoven. Will mir wirklich jemand einreden, das sei alles völlig ok?

So funktionieren eben Abhängigkeiten, grub2 hängt von grub-pc oder grub-efi-amd64 ab. Alles okay auf einem System, auf dem nur „offiziell“ gebaute Pakete installiert sind. Wie soll man das Vorhandensein eines Bootloaders sicherstellen, wenn du am vorgesehenen Weg vorbeigehst – außer durch oben erwähnte, allerletzte Fragen bei Deinstallation.

Ich glaube, wir drehen uns im Kreis

[DeletedUserReAsG]

Ich habe jetzt spaßeshalber mal grub2 reinstalliert. jetzt will er grub-pc, etc. nicht mehr autoremoven. Will mir wirklich jemand einreden, das sei alles völlig ok?

Doch, natürlich – wenn du’s manuell installierst, wird’s als manuell installiert markiert und daher bei autoremove nicht entfernt.

Ansonsten: du nutzt Testing, du verlässt den Debian-Weg, indem du ’nen eigenen Kernel drauftust, du machst suggestions und recommends raus (was nur für fortgeschrittene User empfohlen wird), und dann beschwerst du dich, dass sich ’n unbedarfter (sprich: weniger fortgeschrittener) User das System reversibel unbootbar machen könnte?

[fischig]

Wenn ich, so wie schon im 1. Beitrag von JTH vorgeschlagen, grub-pc als zentralen (?) Bestandteil meines Bootloaders grub als manuell, nicht automatisch installiert deklariere, bewahrt das diesen Bootloader vorm Angebot einer automatischen Deinstallation. Das hatte ich nicht bedacht, sondern mir das hier eingebildet:

Hmm, eigentlich sollte das nicht so sein. Man sollte den GRUB auch behalten, wenn er als automatisch installiert markiert ist.

Mit dem Kernel hat das gar nichts zu tun (jedenfalls hier nicht). Unsere (Eigenbau-)Kernel-Ausflüge hätten wir uns sparen können. Ich habe nicht dafür gesorgt,

dass (mein)ein Kernel von einem Bootloader abhängt

Ist das eigentlich jetzt so: Ist der Debian-Kern mittlerweile nicht nur von udev (via initrd) sondern auch von grub abhängig?