it-swarm.com.de

Kann ich EFI-signierte Kernel sicher löschen? (Kann ich auch nicht signierte Kernel entfernen?)

Kann ich die linux-signed* -Pakete von meiner Ubuntu 16.10 (yakkety) -Installation sicher deinstallieren und löschen?

Der Grund, warum ich dies in Betracht ziehe, ist, dass mein UEFI-BIOS keinen sicheren Start verwendet und meine Startpartition nur 200 MiB (~ 210 MB) beträgt. Die restlichen Partitionen sind verschlüsselt, und ich möchte die Größe der Partitionen nicht ändern, um die Startpartition zu erweitern.

Leider sind 200 MiB kaum zu klein, um 3 Kernel aufzunehmen. Die aktuellen Kernel haben jeweils ca. 61 MiB (einschließlich der Kernel-Binärdateien abi, config, initrd, map sowie signierter und nicht signierter). Durch Hinzufügen von grub, memtest und der Partitionstabelle wird die Anzahl auf ca. 198 erhöht, was anscheinend nicht ausreicht, um den Kernel zu aktualisieren. Normalerweise behalte ich nur 2 Kernel (aktuell + zuletzt), aber während des Aktualisierungsprozesses benötige ich natürlich Platz für ein Drittel. Wenn ich die signierten Kernel nicht hätte (jeweils 7,2 MiB), wäre ich in Ordnung.

Ab heute habe ich die Build-Versionen 41, 45 und 46 von Kernel 4.8.0 installiert.

Brechen die folgenden mein System?

apt-get purge linux-signed*
grub-mkconfig -o /boot/grub/grub.cfg

(Zweite Zeile nach dem Kommentar von ubfan1, siehe unten)

Ich glaube, dass es die folgenden Kernelpakete entfernen und verhindern sollte, dass neu signierte Kernel installiert werden:

linux-signed-generic
linux-signed-image-4.8.0-41-generic
linux-signed-image-4.8.0-45-generic
linux-signed-image-4.8.0-46-generic
linux-signed-image-generic

Ich habe alle regulären (nicht signierten) Versionen dieser Pakete installiert.

Weiß jemand, warum die unicode.pf2 -Datei (2,3 MiB) sowohl in /boot/grub als auch in /boot/grub/fonts erscheint? Ich habe die Dateien unterschieden und sie sind genau gleich. Ich gehe davon aus, dass dies die im Grub-Menü verwendete Schriftart ist, aber warum wird sie auf derselben Partition zweimal angezeigt? Ich finde es albern, über 2,3 MiB zu streiten, aber das könnte in meinem speziellen Fall auch einen großen Unterschied machen.

Vielen Dank!

Die .efi.signed -Kerne erscheinen in jedem Menüeintrag in /boot/grub/grub.cfg. Ich weiß, dass meine UEFI-Firmware (ich denke, BIOS ist nicht mehr der richtige Begriff) keinen sicheren Start verwendet, aber die Grub-Konfigurationsdateien scheinen dies zu glauben. Offensichtlich bootet mein System die signierten Kernel einwandfrei, also kann ich vielleicht stattdessen die nsignierten Kernel löschen?

Ich habe in /etc/grub.d/10_linux nachgesehen, woher diese Zeilen stammen, und den folgenden Code gefunden:

if test -d /sys/firmware/efi && test -e "${linux}.efi.signed"; then
    sed "s/^/$submenu_indentation/" << EOF
    linux   ${rel_dirname}/${basename}.efi.signed
      root=${linux_root_device_thisversion} ro ${args}
EOF
  else
    sed "s/^/$submenu_indentation/" << EOF
    linux   ${rel_dirname}/${basename}
      root=${linux_root_device_thisversion} ro ${args}
EOF
  fi

Ich bin kein Bash-Experte, aber ich glaube, ich folge dem im Pseudocode

if /sys/firmware/efi AND /boot/vmlinuz-x.x.x-xx.efi.signed exist
  echo linux vmlinuz-x.x-xx-generic.efi.signed to /boot/grub/grub.cfg
else
  echo linux vmlinuz-x.x.x-xx-generic to /boot/grub/grub.cfg

wenn ich also die signierten Kernelpakete lösche und dann grub-mkconfig erneut ausführe, sollte es die regulären nicht signierten Kernel in grub.cfg setzen, richtig?

4
James Duvall

Vielen Dank für all die Hilfe und Links. Ich habe dieses Wochenende ein paar Stunden verbracht und Folgendes überprüft

Kurze Antworten

  1. Ja, Sie können alle linux-signed* -Pakete löschen, aber Sie müssen linux-generic installieren, wenn die automatischen Kernel-Updates weiterhin ordnungsgemäß funktionieren sollen. Die gesamte Neukonfiguration von grub, kernel und initramfs wird automatisch durchgeführt. Die Kernel-Installationsskripte erledigen wirklich alles ohne Probleme.
    apt-get purge linux-signed* linux-generic+
  2. Ja, Sie können die nicht signierten Kernel ohne negative Auswirkungen entfernen, aber sie werden nach Kernel-Updates immer wieder zurückkehren. Dies kann nicht durch das Verwalten von Paketen gelöst werden, es ist jedoch einfach mit einem kurzen Skript zu beheben.

    #!/bin/sh
    #
    # user script: 
    /etc/kernel/postinst.d/zzz-remove-unsigned-kernel
    #
    # after a new signed kernel image is installed, this script removes
    # the unsigned image
    #
    if [ -e "$2.efi.signed" ]; then
        echo "/etc/kernel/postinst.d/zzz-remove-unsigned-kernel: removing $2"
        rm "$2";
    fi
    

Längere Antworten

Im ersten Fall ist die Lösung wirklich einfach. Es funktioniert so ziemlich so, wie Sie es auf den ersten Blick annehmen würden. Trotzdem habe ich einige hilfreiche Dinge über die Ubuntu-Paketstruktur für Kernel gelernt. Ich wollte sichergehen, dass ich die Nebenwirkungen oder Konsequenzen verstehe, aber ich möchte auch nur sehen, wie Dinge aufgebaut sind. Nur als Randnotiz verwende ich den generischen Kernel, aber tausche einfach generic gegen lowlatency oder virtual, wenn das dein Ding ist. Auch hier basiert alles auf 16.10 (yakkety). Hier ist die Kernel-Pakethierarchie: kernel package hierarchy

  • linux-signed-generic ist ein Metapaket , dh es enthält keinen Code. Es gibt nur eine Liste von Abhängigkeiten, die immer die vollständige Installation des neuesten Kernel-Updates enthält. "Vollständig" bezeichnet alle Kernel-Header, das Kernel-Image, die (getrennte) Image-Signatur und zusätzliche Kernel-Module für nahezu jedes Gerät, das Ubuntu unterstützen kann.

  • linux-generic ist ein weiteres Metapaket, das mit Ausnahme der Bildsignatur alle gleichen realen Pakete enthält. Das eigentliche Kernel-Image ist nur im Paket linux-image-x.x.x-yy enthalten. Das Paket linux-signed-image-x.x.x-yy enthält nur eine getrennte Signatur, und das Erstellungsskript hängt diese Signatur an /boot/vmlinuz-x.x.x.yy-generic an und erstellt /boot/vmlinuz-x.x.x.yy-generic.efi.signed. Das Skript bereinigt das nicht signierte Bild nicht.

  • Kernel-Pakete haben spezielle Skripte in /etc/kernel, die das Standardverhalten für das automatische Entfernen von Apt ändern. Normalerweise würde das Entfernen von linux-signed-generic alle Downstream-Pakete für die automatische Entfernung markieren. Dies geschieht jedoch nicht für Kernel-Pakete, bis es zwei neuere Builds derselben Version gibt.

Im zweiten Fall (der Versuch, nur das signierte Kernel-Image beizubehalten) scheint das Löschen von /boot/vmlinuz-x.x.x.yy-generic nach Abschluss der Installation keine Konsequenzen zu haben. Die beiden Kernel-Images sind bis auf die Signatur identisch und verwenden dieselben Module und Konfigurationsdateien. Sobald jedoch ein aktualisierter Kernel installiert ist, hinterlässt er das nicht signierte Image. Glücklicherweise gab es bei jeder Installation eines neuen Kernels einfache Hooks zum Ausführen eines Skripts. Alle Skripte in /etc/kernel/postinst.d werden von run-parts mit zwei Argumenten ausgeführt. $1 ist die Kernelversion und $2 ist der vollständige Pfad des Images (d. H. /boot/vmlinuz-x.x.x-yy-generic).

Die einzige kleine Einschränkung ist, dass das nicht signierte Bild entfernt werden muss , nachdem grub die Aktualisierung von grub.cfg abgeschlossen hat. Wenn /boot/vmlinuz-x.x.x-yy-generic.efi.signed vorhanden ist, fügt grub dieses Bild zu grub.cfg hinzu und ignoriert das nicht signierte Bild. Es muss jedoch eine Stelle im Prozess geben, die das nicht signierte Image noch erwartet, da grub ohne dieses Image nicht ordnungsgemäß konfiguriert werden kann. Das Skript, das die Grub-Konfiguration initiiert, ist /etc/kernel/postinst.d/zz-update-grub. Ich habe mein Skript zzz-remove-unsigned-kernel so benannt, dass run-parts es ausführt, nachdem alles andere beendet ist.

EDIT: Ich habe dieses Skript jetzt mit ein paar Kernel-Build-Updates verwendet und alles scheint gut zu funktionieren. Ich verwende Option 2 oben (Löschen von nicht signierten Kerneln). Ich werde dies als die richtige Antwort markieren.

4
James Duvall

AFAIK, der .efi.signed -Kernel ist derselbe wie der reguläre Kernel, nur dass er mit dem EFI Secure Boot-Schlüssel von Canonical signiert ist. Wenn Sie also nicht mit aktivem Secure Boot booten, können Sie die .efi.signed -Kerne sicher löschen. Wenn ich die Paketinformationen korrekt analysiere, sollten Sie in der Lage sein, die Pakete linux-signed-image-generic und linux-signed-generic zu löschen, um zu verhindern, dass zukünftige Aktualisierungen der signierten Kernel ebenfalls installiert werden.

Eine langfristig bessere Lösung ist es jedoch, die Größe Ihrer /boot -Partition zu erhöhen. Dies kann schmerzhaft und sogar gefährlich für Ihre Daten sein, insbesondere wenn Sie LVM oder Software-RAID verwenden. Die Details hängen jedoch stark von Ihrem aktuellen Festplattenlayout ab und planen, dieses Layout aus anderen Gründen zu ändern. Beachten Sie, dass es abhängig von Ihrem Layout möglicherweise vorzuziehen ist, eine Datenpartition am Ende zu verkleinern und nach dieser jetzt verkleinerten Datenpartition eine größere /boot -Partition zu erstellen, als zu versuchen, eine Datenpartition von Anfang an zu verkleinern um Platz für die /boot -Partition zu schaffen, in die sie hineinwachsen kann.

Wenn Sie verzweifelt genug sind, um ein paar Megabyte freizugeben, um doppelte Dateien in der /boot/grub -Verzeichnisstruktur anzuzeigen, sollten Sie sich möglicherweise von GRUB entfernen. Die meisten anderen Bootloader erfordern nicht so viele Dateien in /boot wie GRUB. Wenn Sie im EFI-Modus booten, ist mein eigener RefInd-Boot-Manager wahrscheinlich am einfachsten zu installieren. Sie können ihn auf einem USB-Laufwerk oder einer CD-R testen, um zu sehen, wie er sich vor dem Mucking verhält mit Ihrer Festplatte. Wenn Sie im BIOS-Modus booten, stehen LILO, SYSLINUX und sogar GRUB Legacy zur Verfügung, aber ich habe keine Hinweise darauf, wie Sie eine dieser Optionen direkt installieren können.

2
Rod Smith

Die ..signed-Kernel sind etwas größer. Wenn Sie also nicht mit aktiviertem sicherem Start ausgeführt werden und versuchen, Speicherplatz zu sparen, verwenden Sie den nicht signierten Kernel und löschen Sie den signierten Kernel. Ich denke auch, dass Ihr Ansatz beim Wiederaufbau von Grub funktionieren wird. Wenn Sie vor der Wiederherstellung der Datei grub.cfg die Stromversorgung verlieren, können Sie das alte Menü grub jederzeit bearbeiten und das signierte Teil löschen. Natürlich können Sie eine signierte Version (die neueste) lassen und die anderen loswerden, um zu sehen, ob die Dinge wie erwartet funktionieren, und dann die letzte erneut ausführen, ohne dass Sie ein bekanntes bootfähiges Setup haben. Was die unicode.pf2-Dateien betrifft, so existieren sie auch auf meinem System. Sie können versuchen, einen durch einen Link zum anderen zu ersetzen (mit einem praktischen Boot-Medium, falls Sie die Datei dort ablegen müssen, wo sich der Link befindet).

0
ubfan1