• Bug
  • Kernel Update schlägt fehl

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

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

    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?

    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.

      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.

      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

      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 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.

        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.

        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.

        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.

        © 2020-2024 grommunio GmbH. All rights reserved. | https://grommunio.com | Data Protection | Legal notice