Gelöst Ultramarine L. 37: Boot-Partition ist voll, was tun?

[Journey77]

ich nutze seit einiger Zeit Ultramarine Linux Version 37.

Bei Installation lies ich die installationsroutine die Platte selbst partitionieren, er nahm also die ganze Platte. Partitionsschema- und Belegung sieht folgendermaßen im Moment aus:

Partition    Name                Filesystem/Einhängepunkt    Grösse        benutzt        ungenutz    Markierungen
/dev/sda1    EFI System Partition     fat32/boot/efi         600.00 MiB    18.60 MiB      581.40 MiB  boot,esp
/dev/sda2                              ext4/boot               1.00 GiB   932.44 MiB       91.56 MiB
/dev/sda3                          lvm2 pv ul_localhost-live 230.01 GiB   230.01 GiB          0.00 B  lvm
unallocated                     unallocated                  6.88 GiB     ---

Wenn man sich nach dem Booten anmeldet, sagt das System, die Partition "boot" habe noch 25 MB.

Was passiert, wenn ich das einfach ignoriere, regelt das System dann selbst?

Ich nehme an, dass die Partition voll ist, weil so viele Kernel installiert sind? Momentan sind 5 Kernel installiert, 3 davon könnte man löschen. Ich trau mich da aber nicht ran, nicht dass ich etwas falsch mache... Sind die 5 Kernel hier das Problem, die die Partition voll werden lassen?

 

[Journey77]

Der neueste Kernel der heute installiert wurde, ist der 6.4.4-100
Ich würde aber gerne den 6.2.15-200 auch behalten, weil ich bei den neuesten Kerneln die letzten Zeit immer Probleme hatte und daher zu dem 6.2.15-200 zurück musste, damit das System problemlos läuft. Wie das System mit dem ganz neu installierten jetzt läuft, weiss ich noch garnicht.

 

[susejunky]

Hallo @Journey77 ,

Was passiert, wenn ich das einfach ignoriere, regelt das System dann selbst?

ich kenne Ultramarine Linux nicht, aber meine Vermutung ist, dass Du da schon selbst aktiv werden musst.

Sind die 5 Kernel hier das Problem, die die Partition voll werden lassen?

Davon ist auszugehen.

Momentan sind 5 Kernel installiert, 3 davon könnte man löschen.

Es ist sicherlich möglich, 3 der 5 Kernel zu löschen (und anschließend den Bootloader wieder entsprechend zu konfigurieren).

Wie Du dazu im Detail vorgehen musst, sollte Dir allerdings jemand erläutern, der Ultramarine Linux benutzt/sich damit auskennt.

Viele Grüße

susejunky

 

[Journey77]

Es ist sicherlich möglich, 3 der 5 Kernel zu löschen (und anschließend den Bootloader wieder entsprechend zu konfigurieren).

Wie Du dazu im Detail vorgehen musst, sollte Dir allerdings jemand erläutern, der Ultramarine Linux benutzt/sich damit auskennt.

Viele Grüße

susejunky

Hallo susejunky )

So speziell braucht es garnicht zu werden, Ultramarine Linux basiert auf Fedora, somit funktionieren sämtliche Befehle von Fedora auch auf diesem System.

Ich hab auch schon etwas recherchiert, aber ich habe eben die Befürchtung, dass ich da in etwas stochere, von was ich ohnehin nichts verstehe und am Ende viell. das ganze System verkorkse.

Bitte: Ich möchte niemandem Recherchearbeit machen, aber in einem solchen Forum sind doch bestimmt Kenner, die sich mit Fedora weitreichend genug auskennen, um das aus dem Stehgreif oder nahezu aus dem Stehgreif ins Forum schreiben können. Das hoffe ich zumindest, ansonsten muss ich halt doch dran gehen, auf die Gefahr hin, es zu verhunzen.

Wenn ihr Euch des Problems aber nicht annehmen wollt, ist das für mich ok.. ich kann damit leben ) man kann ja miteinander reden..

 

[marce]

dnf list kernel

... und dann die nicht gewünschten mit

dnf remove kernel-$version

löschen.

Ansonsten dann noch in der /etc/dnf/dnf.conf installonly_limit anpassen.

 

[susejunky]

Hallo @marce ,

... und dann die nicht gewünschten mit

dnf remove kernel-$version

löschen.

konfiguriert das auch den Bootloader entsprechend neu?

Viele Grüße

susejunky

 

[Journey77]

@marce
Das Entfernen mit Deinem Befehl hat geklappt... laut Teminal wurde der eine Kernel gelöscht.

@susejunky
ich hab dann versucht den Booloader anzupassen, aber weiss nicht, ob das die richtigen Befehle sind: ich fand zwei verschiedene im Netz, hab jeweils einen versucht und dann neu gestartet.. dann war aber immernoch nur 25 MB frei.. dann hab ich den zweiten Befehl probiert.. neu gestartet.. es ist aber immernoch nur 25 MB frei.

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

was mich auch irritiert ist, dass der Rechner beim Start im Menü mehr Kernel anzeigt, die gebootet werden können. (5)
In der Konsole mit dem Befehl "rpm -q kernel" werden aber nur 3 angezeigt.. somit konnte ich nur einen löschen, da ich ja zwei behalten möchte.

EDITTEXT: Im Grunde würde es schon reichen wenn ihr schreibt.. ob ich das so lassen kann.. ob das System das selbst regelt und da schon dafür sorgt, dass alles weiter läuft.. es würde an sich ja nichts machen, wenn die Partition voll ist?! Oder crasht das System dann oder startet nicht mehr? Ich hab kein Problem damit, da erst mal nichts zu machen...

 

[josef-wien]

Schauen wir einmal, was da wirklich vorhanden ist:

ls -al /boot

ls -al /lib/modules

 

[Journey77]

kais on linux.fritz.box ~
❯ sudo su
[sudo] Passwort für kais:
[root@linux kais]# ls -al /boot
.rw-r--r--@  161 root 11 Mai 18:12 .vmlinuz-6.2.15-200.fc37.x86_64.hmac
.rw-r--r--@  161 root  5 Jul 22:25 .vmlinuz-6.3.12-100.fc37.x86_64.hmac
.rw-r--r--@  160 root 19 Jul 19:21 .vmlinuz-6.4.4-100.fc37.x86_64.hmac
.rw-r--r--@ 256k root 11 Mai 18:14 config-6.2.15-200.fc37.x86_64
.rw-r--r--@ 257k root  5 Jul 22:27 config-6.3.12-100.fc37.x86_64
.rw-r--r--@ 258k root 19 Jul 19:23 config-6.4.4-100.fc37.x86_64
drwx------@    - root  1 Jan  1970 efi
drwx------@    - root 25 Jul 17:51 grub2
.rw-------@ 117M root 19 Jul 17:08 initramfs-0-rescue-69c42698d9e54a0d989caba7529ce4ef.img
.rw-------@ 117M root 25 Jul 14:03 initramfs-0-rescue-465c377640544dca97ea71a1013ea577.img
.rw-------@ 108M root 15 Mai 12:43 initramfs-0-rescue-2476a2255e2e47e0a65765495ada41c1.img
.rw-------@ 114M root  5 Jun 20:43 initramfs-0-rescue-d9ca778f6ca940f78b109ca1931ffc5f.img
.rw-------@ 107M root  5 Jun 20:30 initramfs-6.2.15-200.fc37.x86_64.img
.rw-------@ 117M root 22 Jul 15:13 initramfs-6.3.12-100.fc37.x86_64.img
.rw-------@ 117M root 25 Jul 14:02 initramfs-6.4.4-100.fc37.x86_64.img
drwxr-xr-x@    - root 15 Mai 12:40 loader
drwx------@    - root 15 Mai 12:35 lost+found
lrwxrwxrwx@   46 root 15 Mai 13:04 symvers-6.2.15-200.fc37.x86_64.gz -> /lib/modules/6.2.15-200.fc37.x86_64/symvers.gz
lrwxrwxrwx@   46 root 19 Jul 17:06 symvers-6.3.12-100.fc37.x86_64.gz -> /lib/modules/6.3.12-100.fc37.x86_64/symvers.gz
lrwxrwxrwx@   45 root 25 Jul 14:03 symvers-6.4.4-100.fc37.x86_64.xz -> /lib/modules/6.4.4-100.fc37.x86_64/symvers.xz
.rw-------@ 8,4M root 11 Mai 18:14 System.map-6.2.15-200.fc37.x86_64
.rw-------@ 8,5M root  5 Jul 22:27 System.map-6.3.12-100.fc37.x86_64
.rw-------@ 8,6M root 19 Jul 19:23 System.map-6.4.4-100.fc37.x86_64
.rwxr-xr-x@  14M root 19 Jul 17:07 vmlinuz-0-rescue-69c42698d9e54a0d989caba7529ce4ef
.rwxr-xr-x@  14M root 25 Jul 14:02 vmlinuz-0-rescue-465c377640544dca97ea71a1013ea577
.rwxr-xr-x@  13M root 15 Mai 12:42 vmlinuz-0-rescue-2476a2255e2e47e0a65765495ada41c1
.rwxr-xr-x@  14M root  5 Jun 20:42 vmlinuz-0-rescue-d9ca778f6ca940f78b109ca1931ffc5f
.rwxr-xr-x@  14M root 11 Mai 18:14 vmlinuz-6.2.15-200.fc37.x86_64
.rwxr-xr-x@  14M root  5 Jul 22:27 vmlinuz-6.3.12-100.fc37.x86_64
.rwxr-xr-x@  14M root 19 Jul 19:23 vmlinuz-6.4.4-100.fc37.x86_64
[root@linux kais]# ls -al /lib/modules
drwxr-xr-x@ - root 15 Mai 13:04 6.2.15-200.fc37.x86_64
drwxr-xr-x@ - root 25 Jul 14:01 6.3.5-100.fc37.x86_64
drwxr-xr-x@ - root 19 Jul 17:06 6.3.12-100.fc37.x86_64
drwxr-xr-x@ - root 25 Jul 14:01 6.4.4-100.fc37.x86_64
[root@linux kais]#

 

[josef-wien]

Du hast drei "normale" Kernel (samt initramfs, config und System.map) und vier Kernel mit dem Namensteil "rescue" (die Deine Distribution so intelligent benennt, daß man nicht erkennen kann, welche Version sie darstellen) installiert. Ich staune immer wieder, was manche Distributionen in die initrd/initramfs hineinstopfen (meine sind knapp 12 MB groß), aber bei diesen Größen ist es logisch, daß der Platz knapp wird.

Im Verzeichnis /lib/modules sind die Module von vier Kernel gespeichert.

Da ich Deine Distribution nicht kenne, müssen andere Helfer sagen, wie Du am besten Speicherplatz gewinnen kannst. Ein Problem hast Du erst dann, wenn Du mangels Speicherplatz keinen neuen Kernel installieren kannst.

 

[Journey77]

seit dem der neueste Kernel 6.4.4.100 heute Mittag bei einem systemweiten Update installiert wurde, traten die Probleme bisher nicht mehr auf, die mit den Kerneln davor auftraten.

Ich hab vor einigen Tagen die Version 38 von Ultramarine Linux installiert. Als aber dann darauf auch die Probleme mit dem da noch aktuellessten Kernel auftraten, bin ich zu meinem alten Festplattenabbild zurück, um den 6.2.15 nutzen zu können, mit dem ich dann keine Probleme mehr hatte.

ich lass das System jetzt mal noch laufen bis morgen. Wenn die Probleme dann mit dem 6.4.4.100. nicht mehr auftreten, schreib ich mein Abbild von Ultramarine 38 über die Platte, mache ein Systemweites Update und kann dann mit dem Kernel 6.4.4.100, den das System dann installieren sollte, auch mit Sicherheit fehlerfrei weiter arbeiten.

EDITTEXT: DANKE AN ALLE DIE GEPOSTET HABEN!

 

[Journey77]

Sorry Leute ich kann das Thema abhaken.

Mir hätte von Anfang an in den Sinn kommen müssen, dass es ja auch eine ganz andere Lösung gibt, die Ultramarine 37 weiter zu nutzen, anstatt der Version 38 wenn sich denn in den kommenden Stunden herausstellen sollte, dass der Kernel 6.4.4.100 doch auch Probleme macht und ich zu einem früheren zurück muss:

Mir kam gerade in den Sinn, dass ich neben dem aktuellen Festplattenabbild in dem so viele Kernel enthalten sind, ja noch zusätzlich das Ursprungsabbild habe von der Ultramarine Linux 37. DH das allerste Festplattenabbild als System V37 vor Monaten frisch installierte, und da sind mit Sicherheit nur maximal 2 Kernel installiert. Wenn ich das drüber schreibe über die Platte und das System aktualisiere, sollte er auch nur einen zusätzlichen Kernel hinzuinstallieren und dann sollte noch genug Platz auf der Partition sein.

 

[Journey77]

Nur zum Verständnis noch ein paar Fragen:

Ich hab mein ursprüngliches, erstes Festplattenabbild von Ultramarine 37 jetzt über die Platte geschrieben und ein Update durchgeführt. Jetzt sind 3 Kernel installiert und die Boot-Partition ist ca. zu 50% belegt.

Jetzt hab ich mir mal die Boot-Partition angesehen. Die Grossen Dateien sind die *.img-Dateien. Ich nehme an, dass das die Kernel sind?

Ich hab jeweils die rescue*.img Dateien mal weggelöscht und gleich wieder mehrere Hundert MB mehr auf der Boot-Partition, und das System bootet trotzdem ordnungsgemäss. Ich nehme an, so lange ich beim Booten die Menüpunkte rescue nicht anwähle, sollte es kein Problem geben ?

Gehe ich richtig davon aus, wenn ich denke, dass ich im Grunde auf der Boot-Partition alle *.img Dateien weglöschen kann, alle Kerneldateien, außer den, den ich beim Start des PCs im Bootmenü wähle?!

Wobei ich natürlich nicht weiss, was das System dann beim nächsten systemweiten Update machen wird...

 

[josef-wien]

Der Kernel heißt vmlinuz*, initramfs* ist bei Deiner Distribution die initial ram disk (enthält abgestimmt auf Deinen PC unter anderem alles, was für den Systemstart notwendig ist, vor allem das Programm zur Systeminitialisierung sowie jene Kernel-Module, die vor dem Zugriff auf die Systempartition benötigt werden). config* (enthält die Dokumentation der bei der Erstellung des Kernel verwendeten Konfiguration; für den laufenden Kernel ziehe ich das Ergebnis vonzcat /proc/config.gzvor) und System.map* (siehe FAQ/System.map - Linux Kernel Newbies) sind für den Systemstart nicht notwendig.

Manuelle Eingriffe bei der Boot-Partition können Probleme bei der Paketverwaltung bzw. der Bootloader-Einrichtung verursachen, aber dazu kann ich nichts beitragen. Falls in /lib/modules die Module zum zu startenden Kernel fehlen, hast Du ein Problem. Wenn es zu Modulen keinen Kernel in der Boot-Partition gibt, vergeudest Du Plattenplatz.