Forum: PC-Programmierung Debian Bookworm ohne grub?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bauform B. (bauformb)


Lesenswert?

guten Abend,

die Frage ist nicht, wie bootet man ohne grub. Dank UEFI geht es ganz 
ohne Bootloader, oder mit systemd-boot oder efibootguard¹ oder... Die 
Frage ist, wie wird man grub los? Selbst ein ziemlich aktueller Tipp² 
funktioniert nicht
1
A user wanting to switch from GRUB to systemd-boot should do so by
2
removing the GRUB packages and installing systemd-boot at the same time:
3
4
# apt install systemd-boot grub-efi-amd64-signed-
5
E: Removing essential system-critical packages is not permitted.
6
   This might break the system.
Das kommt mir vor wie "I'm sorry, Dave. I'm afraid I can't do that." 
Warum ist grub immer noch essential, wenn gleichzeitig ein Ersatz 
installiert wird? Ahnt apt etwa, dass ich systemd-boot garnicht haben 
will sondern efibootguard? Aber der funktioniert schon. Zum Booten wird 
grub also nicht gebraucht, wofür denn sonst?

[1] https://github.com/siemens/efibootguard/blob/master/docs/USAGE.md
[2] https://wiki.debian.org/SecureBoot

von Sam H. (samhain)


Lesenswert?

# apt purge $(dpkg -l|awk '/grub-/ { print $2 }')

... und alle Warunngen ignorieren. Oder mit "equivs" einen gurb-dummy 
bauen. Du solltest dir aber schon sicher sein, dass dein System ohne 
GRUB noch bootet :)

von Bauform B. (bauformb)


Lesenswert?

Wo wäre der Unterschied? Die Chancen sind sogar schlechter, weil nicht 
gleichzeitig ein anderer Bootloader installiert wird.

von Daniel A. (daniel-a)


Lesenswert?

Auf meinem selbst gebootstrappten Devuan Daedalus kann ich das nicht 
reproduzieren:
1
dpa@dragonfly:~$ sudo apt-get install --autoremove systemd-boot grub-efi-amd64-signed-
2
Reading package lists... Done
3
Building dependency tree... Done
4
Reading state information... Done
5
The following additional packages will be installed:
6
  libip4tc2 libsystemd-shared systemd-boot-efi
7
The following packages will be REMOVED:
8
  grub-efi-amd64-signed libc++1-19 libc++abi1-19 libunwind-19
9
  linux-headers-6.1.0-22-amd64 linux-headers-6.1.0-22-common
10
  linux-headers-6.1.0-23-amd64 linux-headers-6.1.0-23-common
11
  linux-image-6.1.0-22-amd64 linux-image-6.1.0-23-amd64
12
  shim-helpers-amd64-signed shim-signed shim-signed-common shim-unsigned
13
The following NEW packages will be installed:
14
  libip4tc2 libsystemd-shared systemd-boot systemd-boot-efi
15
0 upgraded, 4 newly installed, 14 to remove and 0 not upgraded.
16
Need to get 1923 kB of archives.
17
After this operation, 955 MB disk space will be freed.
18
Do you want to continue? [Y/n] ^C

Das ist interessant, denn die meisten Pakete werden da direkt 
unverendert von Debian übernommen.

Bei z.B. libc-bin bekomme ich so eine Meldung aber. Ich hab mal in der 
manpage nachgeschaut, mit der Option "--allow-remove-essential" kann man 
apt sagen, dass es das erlauben soll.

von Εrnst B. (ernst)


Lesenswert?

Ein Vorteil von UEFI ist, dass du mehrere Bootloader parallel 
installieren kannst, und dann über das UEFI-Bootmenu auswählen kannst, 
welcher starten soll.

Also: einfach sd-boot parallel installieren, ohne grub-Deinstallation.

Ausprobieren. Wenn alles tut, im UEFI-Setup den default auf sd-boot 
ändern.
Dann (optional) grub deinstallieren.

EFI-Loader können sich auch ("Chainloading") gegenseitig starten, 
könntest also auch im Grub einen systemd-boot-Eintrag einbauen und 
umgekehrt.

von Bauform B. (bauformb)


Lesenswert?

Daniel A. schrieb:
> Auf meinem selbst gebootstrappten Devuan Daedalus kann ich das nicht
> reproduzieren:

Das "selbst gebootstrappt" dürfte der Unterschied sein. Die grub-Pakete 
selbst sind nicht essential. Anscheinend wird irgendwann bei der 
"offiziellen" Installation ein essential-Flag gesetzt. So weit so gut 
und vernünftig. Aber man sollte nachträglich eine Alternative 
installieren können.

Der Installer kennt ja z.Zt. keinen anderen Bootloader, aber es gibt 
offizielle Pakete als Alternative und der originale Debian-Kernel kommt 
mit dem EFI-Stub. Wer das nutzen möchte, braucht auch kein grub -- 
dachte ich bis eben. Aber die Anleitung¹ zum EFI-Stub im Debian-Wiki 
geht davon aus, dass man grub selbstverständlich behält; die 
funktioniert ohne grub garnicht. Faszinierend!

> Ich hab mal in der manpage nachgeschaut,
> mit der Option "--allow-remove-essential" kann man
> apt sagen, dass es das erlauben soll.

Danke, so extreme Optionen kenne ich natürlich nicht ;) Trotzdem, eine 
gewaltfreie Lösung wäre mir lieber. Wer weiß, vielleicht verlässt sich 
irgendein update-Script darauf, dass es grub gibt. Ich will nämlich grub 
deshalb loswerden, weil ich den ständigen automatischen Updates nicht 
traue.

[1] https://wiki.debian.org/EFIStub

von Bauform B. (bauformb)


Lesenswert?

Εrnst B. schrieb:
> Ein Vorteil von UEFI ist, dass du mehrere Bootloader parallel
> installieren kannst, und dann über das UEFI-Bootmenu auswählen kannst,
> welcher starten soll.
>
> Also: einfach sd-boot parallel installieren, ohne grub-Deinstallation.
>
> Ausprobieren. Wenn alles tut, im UEFI-Setup den default auf sd-boot
> ändern.

Bis hier ist alles trivial und funktioniert. Noch einfacher geht's mit 
efibootguard statt sd-boot (oder noch bunter mit refind).

> Dann (optional) grub deinstallieren.
Aber wie?

> EFI-Loader können sich auch ("Chainloading") gegenseitig starten,
> könntest also auch im Grub einen systemd-boot-Eintrag einbauen und
> umgekehrt.

Das konnte schon syslinux, es geht bestimmt noch komplizierter, gib 
dir ein bisschen Mühe ;)

von Daniel A. (daniel-a)


Lesenswert?

Bauform B. schrieb:
>> EFI-Loader können sich auch ("Chainloading") gegenseitig starten,
>> könntest also auch im Grub einen systemd-boot-Eintrag einbauen und
>> umgekehrt.
>
> Das konnte schon syslinux, es geht bestimmt noch komplizierter, gib
> dir ein bisschen Mühe ;)

Auf meinen Linux Phones und meinem Rock 5B habe ich U-Boot installiert, 
weil da keine Firmware drauf ist (sind alles ARM64 Geräte). Damit könnte 
ich direkt den Kernel laden, flash-kernel kann das alles übernehmen, 
aber stattdessen habe ich im selbst gebauten U-Boot EFI aktiviert, und 
starte mit U-Boot das normale Grub aus den Repos, womit ich wiederum den 
selbst kompilierten Kernel starte.

Die Idee war, dass das wie jede andere EFI Installation wäre, und ich 
irgend wann mal einfach den Installer statt selbst gebootstrapte Images 
nehmen kann. Aber es ist immer noch nicht ganz alles im Mainline Kernel 
(z.B. Display Zeugs), im Debian Kernel natürlich auch nicht, und im 
U-Boot sind die Display Panels auch nicht implementiert (und ich habe 
keinen EFI Framebuffer).
Beim Rock 5B mit EDK Firmware geht der Installer und EFI Framebuffer 
immerhin, wenn auch ein paar andere Sachen nicht.
Naja, irgendwann wird das schon noch kommen, der Tag, an dem man beim 
Smartphone einfach den Installer nehmen kann...

von Kilo S. (kilo_s)


Lesenswert?

Bauform B. schrieb:
> Ich will nämlich grub deshalb loswerden, weil ich den ständigen
> automatischen Updates nicht traue.

Und was genau hat der Bootloader damit zu tun? Glaubst du etwa das der 
dafür verantwortlich ist das du ein Update bekommst?

Schau mal unter /etc/apt/apt.conf.d/ ob da die Datei 10periodic liegt.

In der Zeile: APT::Periodic::Update-Package-Lists "1";

Einfach "0" anstelle 1 eintragen.

Damit prüft das System nicht mehr auf Updates und du hast deine Ruhe.

von Bauform B. (bauformb)


Lesenswert?

Kilo S. schrieb:
> Bauform B. schrieb:
>> Ich will nämlich grub deshalb loswerden, weil ich den ständigen
>> automatischen Updates nicht traue.
>
> Und was genau hat der Bootloader damit zu tun?

Ein tragisches Missverständnis :( Bei z.B. einem Kernel-Update wird 
automatisch update-grub gestartet. Das meinte ich mit automatisch.


Von wegen 'grub loswerden': anscheinend ist das wirklich nicht 
vorgesehen bzw. ungetestet: apt müsste mit Gewalt überredet werden, aber 
aptitude macht es einfach. Man darf dabei nur kein purge verlangen, dann 
gibt es eine fette Warnung und man müsste "Yes, I am aware this is a 
very bad idea" eintippen. Das aber auch nur bei einem der grub-Pakete, 
das meiste verschwindet ohne Warnung, man hat dann also ein halbes grub.

Mangels purge hätte ich erwartet, dass dpkg -l das Paket dann als rc 
listet (o.ä.), aber nein, es ist weg. Es bleiben allerdings ca. 10MB in 
über 300 Dateien unter /boot/grub/ übrig.

Der Installer bietet an, ganz ohne Bootloader zu installieren. Das sieht 
gut aus, grub wird nicht installiert und das System läuft. Allerdings 
war der systemd beim ersten Start total verwirrt und es gab nur noch die 
emergency console (heißt die so?).

Früher hatte ich mal grub auf der EFI-Partition manuell gelöscht. Der 
Rechner hätte also nicht mehr (mit grub) gebootet, aber update-grub hat 
das weder gemerkt noch repariert.

Ich glaube, man merkt, dass mir grub viel zu komplex ist.

von Kilo S. (kilo_s)


Lesenswert?

Bauform B. schrieb:
> Ein tragisches Missverständnis :( Bei z.B. einem Kernel-Update wird
> automatisch update-grub gestartet. Das meinte ich mit automatisch.

Das klingt gleich logischer.

von Andreas M. (amesser)


Lesenswert?

Bauform B. schrieb:
> Ein tragisches Missverständnis :( Bei z.B. einem Kernel-Update wird
> automatisch update-grub gestartet. Das meinte ich mit automatisch.

Ja natürlich, du willst den neuen Kernel ja auch booten. update-grub 
aktualisiert nicht grub, sondern dessen Konfigurationsdatei in /boot 
damit er  auch weis das da ein neuer Kernel liegt.

von Benny (cks389)


Lesenswert?

Debian-Bullseye-Nutzer hier! Ich habe kein grub installiert und kann 
mich auch nicht erinnern, dass ich Probleme hätte es nach der 
Systeminstallation zu entfernen ("apt list --installed 2>/dev/null | 
grep grub" ist tatsächlich leer).

Ich habe zu meiner Windows-Installation, die ich komplett unangetastet 
lassen wollte, da diese mithilfe des TPMs auch Bitlocker-verschlüsselt 
ist, im freien SSD-Speicher einfach eine weitere FAT- und Ext4-Partition 
erstellt. Über objcopy erstelle ich mir mit dem Efi-Stub, dem Kernel und 
dem Initramfs ein Unified Kernel Image.

Dieses Kernel-Image signiere ich dann noch mit selbst erstellten, 
Passwort-geschützen Keys und habe sie mit dem mokutil in die Efi 
Variablen geladen. Damit kann Shim dann das Kernel Image verifizieren. 
Wenn ich das System aktualisiere, führe ich diese Schritte dann immer 
manuell durch.

Das mit Shim war aber nicht so einfach. Es gibt an der Stelle ein 
gewisses Protokoll zwischen dem ursprünglichen Shim und Grub. Das hatte 
der EFI-Stub von sd-boot nicht implementiert. Hier weiß ich nicht, ob 
das mittlerweile funktioniert. Aus diesem Grund musste ich Shim 1.40.7 
von Ubuntu nutzen. Nicht schön, aber funktioniert.

Da ich Secure Boot erhalten wollte, wird Shim zuerst geladen. Shim wird 
im UEFI mit dem Tool efibootmgr registriert. Ich benutze hauptsächlich 
Linux. Das startet automatisch. Wenn ich Windows starten will, rufe ich 
beim Booten per F9 das Uefi-Bootmenü auf und wähle dort den 
Windows-Boot-Eintrag.

Da sind keine weiteren Bootloader notwendig. Shim lädt dann 
standardmäßig grubx64.efi im selben Verzeichnis. Also wird mein Kernel 
Image jetzt genau dorthin als grubx64.efi kopiert.

Das startet ohne Probleme und mit meinem TPM wird dann noch die 
Luks-verschlüsselte Partition, die zwei LVM Volumes (Root-Dateisystem 
und Swap) enthält, entschlüsselt.

: Bearbeitet durch User
von Bauform B. (bauformb)


Lesenswert?

Benny schrieb:
> Über objcopy erstelle ich mir mit dem Efi-Stub, dem Kernel und
> dem Initramfs ein Unified Kernel Image.
>
> Dieses Kernel-Image signiere ich dann noch mit selbst erstellten,
> Passwort-geschützen Keys und habe sie mit dem mokutil in die Efi
> Variablen geladen. Damit kann Shim dann das Kernel Image verifizieren.

Braucht man Shim dann überhaupt noch? Benutzt Shim wenigstens 
automatisch den machine owner key und ignoriert alle anderen? Ich 
dachte, die einzige Möglichkeit Secure Boot sinnvoll zu nutzen, wäre 
genau diese eine selbstsignierte Datei (inkl. initrd und allem) direkt 
per UEFI zu booten?

Ja, ich bin neugierig und eigentlich geht mich das garnichts an. Ich 
glaube, wenn der Angreifer seinen eigenen USB-Stick einstecken kann, 
nützt das alles nichts.

> Das mit Shim war aber nicht so einfach. Es gibt an der Stelle ein
> gewisses Protokoll zwischen dem ursprünglichen Shim und Grub.

Noch ein Grund, grub nicht zu mögen...

von Bauform B. (bauformb)


Lesenswert?

Bauform B. schrieb:
> Von wegen 'grub loswerden': anscheinend ist das wirklich
> nicht vorgesehen bzw. ungetestet

Also, grub bleibt drauf. Diese kleinen Ungereimtheiten sind mir doch 
noch suspekter als grub selbst.

> Der Installer bietet an, ganz ohne Bootloader zu installieren. Das sieht
> gut aus, grub wird nicht installiert und das System läuft. Allerdings
> war der systemd beim ersten Start total verwirrt

Das lag nicht an grub, das passiert auf dem Rechner auch mit einer ganz 
normalen Installation inkl. grub. Anscheinend kennt systemd den 
Partitions-Typ "Linux server data", kann aber damit nicht umgehen und 
deshalb(?) funktioniert system-timesyncd nicht. Warum muss der auch so 
neugierig sein, die Partition gehört nicht zu dem System, die geht ihn 
garnichts an.

von Benny (cks389)


Lesenswert?

Bauform B. schrieb:
> Benny schrieb:
>> Über objcopy erstelle ich mir mit dem Efi-Stub, dem Kernel und
>> dem Initramfs ein Unified Kernel Image.
>>
>> Dieses Kernel-Image signiere ich dann noch mit selbst erstellten,
>> Passwort-geschützen Keys und habe sie mit dem mokutil in die Efi
>> Variablen geladen. Damit kann Shim dann das Kernel Image verifizieren.
>
> Braucht man Shim dann überhaupt noch? Benutzt Shim wenigstens
> automatisch den machine owner key und ignoriert alle anderen? Ich
> dachte, die einzige Möglichkeit Secure Boot sinnvoll zu nutzen, wäre
> genau diese eine selbstsignierte Datei (inkl. initrd und allem) direkt
> per UEFI zu booten?

Shim brauche ich nur, da ich meine Keys nicht direkt im Uefi hinterlegt 
habe, sondern über den MOK verifiziere. Und soweit ich weiß prüft er nur 
gegen den MOK und direkt einkompilierte Keys. Aus diesem Grund ist es 
aus Sicherheitsgründen schwierig zu betrachten, dass ich so eine ältere 
Version von Shim einsetze.

Auf Server-Systemen (wo kein Windows drauf ist) habe ich das genau so 
umgesetzt, dass ich alle Keys im Uefi gelöscht, meine eigenen Keys 
installiert habe, und das Unified Kernel Image direkt vom Uefi geladen 
wird.

> Ja, ich bin neugierig und eigentlich geht mich das garnichts an. Ich
> glaube, wenn der Angreifer seinen eigenen USB-Stick einstecken kann,
> nützt das alles nichts.

Nunja, Secure Boot sollte meines Erachtens auch nie vor 
Evil-Maid-Angriffe schützen. Abhilfe wäre hier das Booten von USB im 
Bios zu deaktivieren und das Bios mit Passwort zu schützen. Das wäre die 
einfachste Maßnahme.

Noch ein Hinweis, falls du noch weiteres Interesse an dem Thema haben 
solltest: Wenn man das Root verschlüsselt und die Keys im TPM sichert, 
kann man konfigurieren, unter welchen Bedingungen das TPM die Keys 
freigibt. Das kann man so rigide einstellen, dass das TPM hier 
Modifikationen an der Firmware (dem Uefi), an den Einstellungen, an den 
Keys und an der Boot-Chain erkennt (siehe PCR-Register) und die Keys 
ggf. nicht freigibt. So ist es durchaus möglich, dass bei jeglicher 
Modifikation deine Daten nicht automatisch entschlüsselt werden. Wenn du 
beim Booten dann nach deinem Passwort zum Entschlüsseln gefragt wirst, 
wäre was faul. Das handhabt Windows genauso, es fragt dich nach deinem 
Bitlocker-Wiederherstellungsschlüssel, wenn man nach der Aktivierung von 
Bitlocker, Grub in die Boot-Chain einbaut.

Dann gibt es noch weitere Angriffsvektoren, aber das würde jetzt hier zu 
weit führen. Ein perfekt sicheres System gibt es nicht und bei den 
Sicherungsmaßnahmen sollte immer Aufwand mit Nutzen abgewogen werden.

von Bauform B. (bauformb)


Lesenswert?

Benny schrieb:
> Noch ein Hinweis, falls du noch weiteres Interesse an dem Thema haben
> solltest: Wenn man das Root verschlüsselt und die Keys im TPM sichert,

Das Thema ist sehr interessant, aber jetzt fange ich nicht auch noch 
damit an. Trotzdem vielen Dank für deine Beiträge.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.