Eben kam ein Kernel-Update für Linux Mint 19. Ich habs angeworfen ohne
vorher nachzusehen, ob in /boot noch genug Platz ist, worauf der Update
mit Fehlermeldung abstieg.
Ich habe dann die Kommandos
1
sudo purge-old-kernels
2
sudo update-grub
3
sudo update-grub2
ausgeführt, um wieder Platz zu bekommen. Hinterher waren in /boot
folgende Kernels:
1
Found linux image: /boot/vmlinuz-5.4.0-60-generic
2
Found initrd image: /boot/initrd.img-5.4.0-60-generic
3
Found linux image: /boot/vmlinuz-5.4.0-59-generic
4
Found initrd image: /boot/initrd.img-5.4.0-59-generic
5
Found linux image: /boot/vmlinuz-5.3.0-62-generic
6
Found initrd image: /boot/initrd.img-5.3.0-62-generic
7
Found linux image: /boot/vmlinuz-5.0.0-32-generic
8
Found initrd image: /boot/initrd.img-5.0.0-32-generic
9
Found linux image: /boot/vmlinuz-4.15.0-130-generic
10
Found initrd image: /boot/initrd.img-4.15.0-130-generic
11
Found linux image: /boot/vmlinuz-4.15.0-54-generic
12
Found initrd image: /boot/initrd.img-4.15.0-54-generic
Im Moment läuft die Kiste mit 5.4.0-59-generic, der 5.2.0.60er ist der
neue. Auf /boot sind jetzt immer noch 72% belegt, mir scheint, dass
purge-old-kernels wenig gebracht hat.
Ich bin mit Mint 17 in der Situation schon mal bös auf die Nase
gefallen: das Image ließ sich hinterher nur noch mit einem alten Kernel
per Bootmenü booten, weil man bei dem verunglückten Kernel kein LUKS-PW
mehr eingeben konnte – das will ich auf jeden Fall vermeiden. (Das
17er-Image als virtuelle Maschine funktioniert interessanter Weise.)
Wie kann man prüfen, ob der neue Kernel in Ordnung ist, ohne ihn zu
booten?
Oder kann man den Update irgendwie wiederholen?
ii ist installiert, rc ist deinstalliert, aber nicht gepurged (config
files noch da), un ist ganz deinstalliert. Ich weiss gerade nicht
auswendig, was die halb installierten Zustände sind. Die die du
nichtmehr brauchst kannst du ja dann manuell entfernen. Lasse den
5.4.0-59-generic noch drauf, "apt-get purge" den 5.2.0.60, und dann
nochmal "apt-get install" für den 5.2.0.60.
Das Deinstallieren eines Kernels sollte diesen eigentlich auch aus
boot entfernen. Tut es das nicht, kann man das ja immer noch manuell
machen.
Schau Dir einfach die Dateigrößen mal an.
Die Initrd kann man mittels "sudo update-initramfs -u" neu generieren.
Den Kernel könnte man mittels "dpkg --verify kernel_paket_name"
verifizieren - ich weiss allerdings den Paketnamen nicht bei Mint.
Taucher schrieb:> sudo dpkg --verify linux-image-5.4.0-60-generic bringt überhaupt keine> Ausgabe und ist sehr schnell fertig – ist das normal?
Ja - dann ist alles in Ordnung.
Heute kam ein 5er- und ein 4er-Kernel und damit folgende libs:
5.4.0-60-generic
5.4.0-58-generic
5.4.0-56-generic
4.15.0-128-generic
4.15.0-129-generic
4.15.0-130-generic
Welchen Sinn hat es, dass für ältere Versionen nocmal libs nachgeschoben
wurden?
Das ist ja merkwürdig: der Kernel vmlinuz-4.15.0-54-generic soll ein
DOS/Windows Image sein?
Seltsamerweise scheint die Existenz der alten Module frühere Läufe von
purge-old-kernels nicht gejuckt zu haben. In /boot vorhanden sind
jedenfalls nur noch diese:
4.15.0-54
4.15.0-130
5.0.0-32
5.3.0-62
5.4.0-59
5.4.0-60
Taucher schrieb:> Das ist ja merkwürdig: der Kernel vmlinuz-4.15.0-54-generic soll ein> DOS/Windows Image sein?
Bei x86/64 Systemen unterstützt der Kernel meistens den direkten EFI
boot. EFI Dateien verwenden das PE Format, genau wie Ausführbare Windows
Dateien auch. Der Kernel ist dann also im grunde ein Polyglot aus PE/EFI
Anwendung und legacy second stage x86/64 code. Alte Bios bootloader
nutzen letzteres beim chainloading, neuere nutzen das EFI zeug, plus EFI
PCs könnten die EFI Kernels auch direkt ohne Bootloader laden.
Die mime Datenbank kann normalerweise den Linux Kernel erkennen:
1
$ file /boot/vmlinuz-4.19.0-10-amd64
2
/boot/vmlinuz-4.19.0-10-amd64: Linux kernel x86 boot executable bzImage, version 4.19.0-10-amd64 (debian-kernel@lists.debian.org) #1 SMP Debian 4.19.132-1 (2020-07-24), RO-rootFS, swap_dev 0x5, Normal VGA
Aber es erkennt auch den PE Header der EFI Datei. Sieht man, wenn man es
anweist, alle Treffer anzuzeigen:
1
$ file -k /boot/vmlinuz-4.19.0-10-amd64
2
/boot/vmlinuz-4.19.0-10-amd64: Linux kernel x86 boot executable bzImage, version 4.19.0-10-amd64 (debian-kernel@lists.debian.org) #1 SMP Debian 4.19.132-1 (2020-07-24), RO-rootFS, swap_dev 0x5, Normal VGA\012- DOS/MBR boot sector DOS/MBR boot sector PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows\012- data
"Linux kernel x86 boot executable" ist aber kein mime format. Sucht man
nach einem mime typ wird also der für PE Anwendungen gefunden
(application/x-dosexec), die historisch für DOS & Windows Anwendungen
verwendet wurden:
Der Dateibrowser wird also den mime typ nachgesehen haben, dank dem MZ
am Dateianfang wurde application/x-dosexec gefunden, und die
Beschreibung davon war dann "DOS/Windows executable".
Bleibt noch die Frage, warum das bei den anderen nicht der fall war.
Vermutlich hatte der Dateibrowser einfach keine Leserechte, konnte also
den Inhalt nicht gegen die mime Datenbank checken, und damit den mime
typ nicht ermitteln.
Taucher schrieb:> Ein Reinstall des Kernels und der Module per synaptic hat an der Liste> der Fehlermeldungen bei update-initramfs nichts geändert.
Die "W:" dinger sind nur Warnungen, keine Fehler. Debian packt Firmware
in separate Packete. Du kannst mit apt-file danach suchen:
Die firmware ist nur nötig, falls man ein Gerät hat, dass diese braucht,
und das Gerät nicht selbst noch eine Version der Firmware hat. Wie alles
non-free, gibt es non-free Firmware nur in den non-free repos. Falls man
die will, muss man das non-free in /etc/apt/sources.list hinzufügen.
Das RESUME könnte man in /etc/initramfs-tools/conf.d/resume ändern,
vermutlich ist es aber schon richtig so wie es ist.
Das "I:" steht für Info.
Daniel A. schrieb:> Vermutlich hatte der Dateibrowser einfach keine Leserechte, konnte also> den Inhalt nicht gegen die mime Datenbank checken, und damit den mime> typ nicht ermitteln.
Die Caja-Instanz, die ich dafür verwendet hatte, lief unter
root-Rechten.
