Kernel Update schlägt fehl

Andy

Vergleichbar zum verlinkten Thread ist offenbar noch immer nicht behoben, dass sich Kernels nicht updaten lassen, solange nach einem Update mehr als 2 Kernels gespeichert wären. Kontrolle:

rpm -qa | grep -i 'kernel-default-5'

Sind vor einem Update 2 Kernels vorhanden muss daher manuell mit der ältere gelöscht werden, ansonsten bricht das Update komplett ab. Löschung:

zypper purge-kernels

WalterH

Andy Was sagt ein df -h | grep boot ? Wie viel ist auf /boot/ frei?

Andy

Wie folgt:

localhost:~ # df -h | grep boot
/dev/sda3                     295M  194M  101M  66% /boot
/dev/sda2                      20M  3,1M   17M  16% /boot/efi
localhost:~ #

Du meinst, nicht die Anzahl der Kernel ist ausschlaggebend, sondern der verfügbare Platz?

WalterH

Ein Kernel benötigt auf meinem System ca: 55MB, wenn nun 101 MB frei sind, gehen sich 2 zusätzlicher Kernel nicht mehr aus.

l /boot | grep 55.80
-rw-r--r-- 1 root root 5.0M Sep 18 17:27 System.map-5.14.21-150500.55.80-default
-rw-r--r-- 1 root root 249K Sep 18 17:12 config-5.14.21-150500.55.80-default
lrwxrwxrwx 1 root root   35 Sep 27 18:41 initrd -> initrd-5.14.21-150500.55.80-default
-rw------- 1 root root  24M Sep 27 18:42 initrd-5.14.21-150500.55.80-default
-rw-r--r-- 1 root root 461K Sep 18 17:31 symvers-5.14.21-150500.55.80-default.gz
-rw-r--r-- 1 root root  484 Sep 18 17:31 sysctl.conf-5.14.21-150500.55.80-default
-rw-r--r-- 1 root root  13M Sep 18 17:34 vmlinux-5.14.21-150500.55.80-default.gz
lrwxrwxrwx 1 root root   36 Sep 27 18:41 vmlinuz -> vmlinuz-5.14.21-150500.55.80-default
-rw-r--r-- 1 root root  12M Sep 18 18:07 vmlinuz-5.14.21-150500.55.80-default

Die Frage ist, wieso ist /boot ein eigenes Volume, bei meinem System ist /boot ein Teil von / und hat demnach genug Platz frei. Nur /boot/efi ist ein eigenes Volume.

jengelh

WalterH Ein Kernel benötigt auf meinem System ca: 55MB

Das ist auch der Wert, den ich in Virtualbox beobachte. Ein Bare-Metal-System kann aber andere Werte zu Tage bringen, je nachdem, welche Hardware verbaut ist. Mein Laptop gönnte sich ne 35 MB-initrd. Und bei der Erstinstallation wird die initrd nicht neu erzeugt, und es wird die 60 MB-"Monster"-initrd aus dem Installer übernommen.
Kurzum, in Virtualbox können es schon mal 3*55+(61-26)=200MB werden, mit BM etwa 218MB. Da müssten die 295M des Bootvolumes aber eigentlich noch reichen. Zumal die Festlegung nicht durch uns gemacht wird, sondern vom KIWI Image Builder. openSUSE-JeOS nutzt auch KIWI, und würde ja in das gleiche Problem rennen—kann aber sein, dass die /boot nicht getrennt anlegen. Wir probieren mal rum. bootpartition=no wäre wohl vermutlich am einfachsten.

Andy

Das kann ich nicht sagen. Da ich bei Erscheinen einer neuen Appliance jedesmal eine Neuinstallation anlege und die Daten übertrage, kann es ggf. daran liegen, wenn Du noch eine ältere Basisinstallation hast und dort war das noch anders gelöst. Allerdings scheint das auch bei anderen so wie bei mir zu sein, wie der verlinkte Thread zeigt.

WalterH

Meine neueste Appliance ist vom Feb. 2024, also nicht so alt, die eine ältere ist Nov. 2023. Beide haben /boot im /.

df -h | grep boot
/dev/vda3                             32G   15G   18G  46% /boot/grub2/i386-pc
/dev/vda3                             32G   15G   18G  46% /boot/grub2/x86_64-efi
/dev/vda2                             20M  6.3M   14M  32% /boot/efi

Andy

Ich habe die vom 15.4.2024. Es kann natürlich zudem sein, dass die Installationen abhängig vom Hypervisor sind. Ist es unabhängig davon aber nicht so, dass ältere Kernel generell eigentlich gelöscht werden vom System?

WalterH

jengelh Da müssten die 295M des Bootvolumes aber eigentlich noch reichen.

Gerade ein System upgedatet, 3 Kernels waren im /boot und das Update hat mit einem Fehler beim Kernel Update abgebrochen. Erst als ich den 3. Kernel mit zypper purge-kernels entfernt hatte, lief das Update durch.

WalterH

jengelh sondern vom KIWI Image Builder.

Die Kiwi Tools sind aber in jeder Appliance installiert, obwohl diese Tools zum Erstellen der Appliance verwendet werden, nicht zum Betrieb.

Die Kiwi Tools kann man entfernen:
rpm -qa | grep kiwi
und dann mit
zypper remove kiwi-tool ... ... ...
alle Pakete die kiwi im Nahmen haben entfernen, werden in der Appliance nicht benötigt.

jengelh

Bestehende Installationen werden mit einer Änderung der KIWI-Instructions unsererseits natürlich auch nicht erreicht, die Änderung wirkt nur für Neuinstallationen.

Bei bestehende Systemen kann man /boot einfach auflösen: /boot-Eintrag aus /etc/fstab entfernen, dann sowas wie mount --move /boot /mnt; mv /mnt/* /boot/; umount /mnt; update-bootloader; ist denkbar.

Die ISO wird einfach auf Platte kopiert, deswegen ist da KIWI noch im Zielsystem präsent auch wenn es nicht mehr gebraucht wird. Dafür dauert die Prozedur gegenüber z.B. der Installation per yast.