Kernel-Update fehlgeschlagen

[Taucher (Gast)]

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

sudo purge-old-kernels
sudo update-grub
sudo update-grub2

ausgeführt, um wieder Platz zu bekommen. Hinterher waren in /boot 
folgende Kernels:

Found linux image: /boot/vmlinuz-5.4.0-60-generic
Found initrd image: /boot/initrd.img-5.4.0-60-generic
Found linux image: /boot/vmlinuz-5.4.0-59-generic
Found initrd image: /boot/initrd.img-5.4.0-59-generic
Found linux image: /boot/vmlinuz-5.3.0-62-generic
Found initrd image: /boot/initrd.img-5.3.0-62-generic
Found linux image: /boot/vmlinuz-5.0.0-32-generic
Found initrd image: /boot/initrd.img-5.0.0-32-generic
Found linux image: /boot/vmlinuz-4.15.0-130-generic
Found initrd image: /boot/initrd.img-4.15.0-130-generic
Found linux image: /boot/vmlinuz-4.15.0-54-generic
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?

[tux (Gast)]

Taucher schrieb:

> Oder kann man den Update irgendwie wiederholen?

update-initramfs?

[Daniel A. (daniel-a)]

Führe mal das aus:

dpkg-query -l 'linux-image-?.*'

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.

[Mike (Gast)]

Mach das besser über das GUI vom Update-Manger, darüber kannst Due 
Kernel selktereun, bzw all die überflüssigen sauber entfernen.

[Jim M. (turboj)]

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.

[Karl M. (Gast)]

Hallo TO,

bitte schaue mal nach, was in diesem Verzeichnis evtl. nicht gelöscht 
wurde.

$ ls -lA /lib/modules

Ich habe Systeme deren Libs nicht gelöscht wurden und dadurch "voll 
gelaufen" sind.

Bitte berichte.

[Taucher (Gast)]

$ ls -lA /lib/modules
drwxr-xr-x 2 root root 4096 Jan  8 12:56 4.15.0-128-generic
drwxr-xr-x 2 root root 4096 Jan  8 12:56 4.15.0-129-generic
drwxr-xr-x 5 root root 4096 Jan  8 12:56 4.15.0-130-generic
drwxr-xr-x 5 root root 4096 Jul 29  2019 4.15.0-54-generic
drwxr-xr-x 3 root root 4096 Sep 23  2019 4.15.0-60-generic
drwxr-xr-x 3 root root 4096 Okt  8  2019 4.15.0-62-generic
drwxr-xr-x 3 root root 4096 Okt 28  2019 4.15.0-64-generic
drwxr-xr-x 3 root root 4096 Nov 18  2019 4.15.0-65-generic
drwxr-xr-x 3 root root 4096 Dez  9  2019 4.15.0-66-generic
drwxr-xr-x 3 root root 4096 Jan 14  2020 4.15.0-72-generic
drwxr-xr-x 2 root root 4096 Mär  1  2020 4.15.0-76-generic
drwxr-xr-x 6 root root 4096 Dez 22  2019 5.0.0-32-generic
drwxr-xr-x 3 root root 4096 Feb  3  2020 5.0.0-37-generic
drwxr-xr-x 3 root root 4096 Mär  2  2020 5.3.0-26-generic
drwxr-xr-x 3 root root 4096 Mär 23  2020 5.3.0-28-generic
drwxr-xr-x 3 root root 4096 Apr  6  2020 5.3.0-40-generic
drwxr-xr-x 3 root root 4096 Apr  8  2020 5.3.0-42-generic
drwxr-xr-x 3 root root 4096 Mai  4  2020 5.3.0-45-generic
drwxr-xr-x 3 root root 4096 Mai 26  2020 5.3.0-46-generic
drwxr-xr-x 3 root root 4096 Jun 15  2020 5.3.0-51-generic
drwxr-xr-x 3 root root 4096 Jun 30  2020 5.3.0-53-generic
drwxr-xr-x 3 root root 4096 Jul  6  2020 5.3.0-59-generic
drwxr-xr-x 3 root root 4096 Jul 27 13:53 5.3.0-61-generic
drwxr-xr-x 6 root root 4096 Sep  7 00:23 5.3.0-62-generic
drwxr-xr-x 2 root root 4096 Jan  8 12:56 5.4.0-56-generic
drwxr-xr-x 2 root root 4096 Jan  8 12:56 5.4.0-58-generic
drwxr-xr-x 5 root root 4096 Jan  4 20:55 5.4.0-59-generic
drwxr-xr-x 5 root root 4096 Jan  8 12:56 5.4.0-60-generic

[Taucher (Gast)]

sudo dpkg --verify linux-image-5.4.0-60-generic bringt überhaupt keine 
Ausgabe und ist sehr schnell fertig – ist das normal?

[Jim M. (turboj)]

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.

[Karl M. (Gast)]

Taucher schrieb:
> $ ls -lA /lib/modules
> drwxr-xr-x 2 root root 4096 Jan  8 12:56 4.15.0-128-generic
> drwxr-xr-x 2 root root 4096 Jan  8 12:56 4.15.0-129-generic
> drwxr-xr-x 5 root root 4096 Jan  8 12:56 4.15.0-130-generic
> drwxr-xr-x 5 root root 4096 Jul 29  2019 4.15.0-54-generic
> drwxr-xr-x 3 root root 4096 Sep 23  2019 4.15.0-60-generic
> drwxr-xr-x 3 root root 4096 Okt  8  2019 4.15.0-62-generic
> drwxr-xr-x 3 root root 4096 Okt 28  2019 4.15.0-64-generic
> drwxr-xr-x 3 root root 4096 Nov 18  2019 4.15.0-65-generic
> drwxr-xr-x 3 root root 4096 Dez  9  2019 4.15.0-66-generic
> drwxr-xr-x 3 root root 4096 Jan 14  2020 4.15.0-72-generic
> drwxr-xr-x 2 root root 4096 Mär  1  2020 4.15.0-76-generic
> drwxr-xr-x 6 root root 4096 Dez 22  2019 5.0.0-32-generic
> drwxr-xr-x 3 root root 4096 Feb  3  2020 5.0.0-37-generic
> drwxr-xr-x 3 root root 4096 Mär  2  2020 5.3.0-26-generic
> drwxr-xr-x 3 root root 4096 Mär 23  2020 5.3.0-28-generic
> drwxr-xr-x 3 root root 4096 Apr  6  2020 5.3.0-40-generic
> drwxr-xr-x 3 root root 4096 Apr  8  2020 5.3.0-42-generic
> drwxr-xr-x 3 root root 4096 Mai  4  2020 5.3.0-45-generic
> drwxr-xr-x 3 root root 4096 Mai 26  2020 5.3.0-46-generic
> drwxr-xr-x 3 root root 4096 Jun 15  2020 5.3.0-51-generic
> drwxr-xr-x 3 root root 4096 Jun 30  2020 5.3.0-53-generic
> drwxr-xr-x 3 root root 4096 Jul  6  2020 5.3.0-59-generic
> drwxr-xr-x 3 root root 4096 Jul 27 13:53 5.3.0-61-generic
> drwxr-xr-x 6 root root 4096 Sep  7 00:23 5.3.0-62-generic
> drwxr-xr-x 2 root root 4096 Jan  8 12:56 5.4.0-56-generic
> drwxr-xr-x 2 root root 4096 Jan  8 12:56 5.4.0-58-generic
> drwxr-xr-x 5 root root 4096 Jan  4 20:55 5.4.0-59-generic
> drwxr-xr-x 5 root root 4096 Jan  8 12:56 5.4.0-60-generic

Na siehst'e, da hast Du die Lösung.

Einfach mit:

$ sudo rm -r /lib/modules/<kernel-version>*

die nicht mehr benötigten Libs entfernen!

$ sudo apt --purge remove *<kernel-version>*
macht dann den Rest!

[Karl M. (Gast)]

Hallo,

des weiteren sind die Aufrufe von
$ du -s /lib/modules/
und
$ du -s /lib/modules/*

sehr informativ!

[Taucher (Gast)]

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?

[Taucher (Gast)]

$ du -s /lib/modules/
1321768  /lib/modules/

$ du -s /lib/modules/*
1092  /lib/modules/4.15.0-128-generic
1092  /lib/modules/4.15.0-129-generic
239932  /lib/modules/4.15.0-130-generic
241144  /lib/modules/4.15.0-54-generic
32  /lib/modules/4.15.0-60-generic
32  /lib/modules/4.15.0-62-generic
32  /lib/modules/4.15.0-64-generic
32  /lib/modules/4.15.0-65-generic
32  /lib/modules/4.15.0-66-generic
32  /lib/modules/4.15.0-72-generic
1092  /lib/modules/4.15.0-76-generic
246164  /lib/modules/5.0.0-32-generic
32  /lib/modules/5.0.0-37-generic
32  /lib/modules/5.3.0-26-generic
32  /lib/modules/5.3.0-28-generic
32  /lib/modules/5.3.0-40-generic
32  /lib/modules/5.3.0-42-generic
32  /lib/modules/5.3.0-45-generic
32  /lib/modules/5.3.0-46-generic
32  /lib/modules/5.3.0-51-generic
32  /lib/modules/5.3.0-53-generic
32  /lib/modules/5.3.0-59-generic
620  /lib/modules/5.3.0-61-generic
67924  /lib/modules/5.3.0-62-generic
1136  /lib/modules/5.4.0-56-generic
1136  /lib/modules/5.4.0-58-generic
259960  /lib/modules/5.4.0-59-generic
259960  /lib/modules/5.4.0-60-generic

[Taucher (Gast)]

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 (Gast)]

Die Modules der 4.15.0-54 haben ein Complete Removal per synaptic 
unverändert überstanden – das scheint doch keine Rolle zu spielen.

[Taucher (Gast)]

Interessant: Beim Complete Removal per synaptic des 5.0.0-32 Kernels 
wurden die Module gelöscht und anschließend neu installiert:

linux-image-unsigned-5.0.0-32-generic (version 5.0.0-32.34~18.04.2) will be installed

[Taucher (Gast)]

So ganz sauber scheint es doch noch nicht zu sein:

$ update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.4.0-60-generic
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module r8169
W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_04.bin for module i915
W: Possible missing firmware /lib/firmware/i915/skl_guc_33.0.0.bin for module i915
W: Possible missing firmware /lib/firmware/i915/bxt_guc_33.0.0.bin for module i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_33.0.0.bin for module i915
W: Possible missing firmware /lib/firmware/i915/glk_guc_33.0.0.bin for module i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_33.0.0.bin for module i915
W: Possible missing firmware /lib/firmware/i915/icl_guc_33.0.0.bin for module i915
I: The initramfs will attempt to resume from /dev/dm-2
I: (/dev/mapper/mint--19.2--vg-swap_1)
I: Set the RESUME
variable to override this.

Was ist mit der RESUME Variablen gemeint?

[Taucher (Gast)]

Ein Reinstall des Kernels und der Module per synaptic hat an der Liste 
der Fehlermeldungen bei update-initramfs nichts geändert.

[Daniel A. (daniel-a)]

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:

$ file /boot/vmlinuz-4.19.0-10-amd64 
/boot/vmlinuz-4.19.0-10-amd64: Linux kernel x86 boot executable bzImage, version 4.19.0-10-amd64 ([e-mail]) #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:

$ file -k /boot/vmlinuz-4.19.0-10-amd64 
/boot/vmlinuz-4.19.0-10-amd64: Linux kernel x86 boot executable bzImage, version 4.19.0-10-amd64 ([e-mail]) #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:

$ file -k -i /boot/vmlinuz-4.19.0-10-amd64 
/boot/vmlinuz-4.19.0-10-amd64: application/x-dosexec\012- application/octet-stream; charset=binary

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.

[Daniel A. (daniel-a)]

$ apt-file search rtl8125a-3.fw
firmware-realtek: /lib/firmware/rtl_nic/rtl8125a-3.fw
$ apt-file search tgl_dmc_ver2_04.bin
firmware-misc-nonfree: /lib/firmware/i915/tgl_dmc_ver2_04.bin

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:

$ apt-file search rtl8125a-3.fw
firmware-realtek: /lib/firmware/rtl_nic/rtl8125a-3.fw
$ apt-file search tgl_dmc_ver2_04.bin
firmware-misc-nonfree: /lib/firmware/i915/tgl_dmc_ver2_04.bin

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.

[Taucher (Gast)]

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.

[Taucher (Gast)]

Ich hoffe, dass das Problem jetzt gelöst ist. Genaueres weiß ich nach 
dem nächsten Boot.

Vielen Dank an alle, die dazu beigetragen haben.