Meldung "Auf dem Datenträger >>Boot<< ist nur noch...Speicherplatz verfügbar."

[gundheri]

Hallo zusammen,

auf einem unsrer Laptops erschien gestern zum zweiten Mal diese Meldung: https://framapic.org/TWdifSkeNJfH/UebXgfvF4cQl.png

Der Debianinstaller hat damals bei der Installation die Partitionen so angelegt: https://framapic.org/O3XFozVOPFjL/6vY3oQRAqMuA.png
Partition 2 wird hierbei in /boot eingehängt.

Ich bin mit der Meldung überfragt. Kann jemand von euch weiterhelfen?

Vielen Dank im Voraus!

[Lord_Carlos]

Vielleicht noch ein paar alte Kernel installiert die nicht mehr gebraucht werden.
Ich bin gerade nicht vor meinem Debian, aber vielleicht kann jemand den apt Befehl zeigen der alle installierte Kernel auflisted.

Was du mal machen kannst ist gucken was viel Platz auf /boot wegnimmt.
du -sch /boot/
Wenn es ein Ordner ist, mach das gleiche nochmal mit dem Ordner bist du die grossen Dateien findest.

[willy4711]

Erstmal sehen was da so alles versammelt ist.

Code: Alles auswählen

dpkg -l linux-image* |grep ii 

[whisper]

So zum Beispiel

Code: Alles auswählen

dpkg -l | grep linux-image

edith: Doppelpost geht beides

[gundheri]

Erstmal sehen was da so alles versammelt ist.

Code: Alles auswählen

dpkg -l linux-image* |grep ii 

ii linux-image-4.19.0-6-amd64 4.19.67-2+deb10u2 amd64 Linux 4.19 for 64-bit PCs (signed)
ii linux-image-4.19.0-8-amd64 4.19.98-1+deb10u1 amd64 Linux 4.19 for 64-bit PCs (signed)
ii linux-image-4.19.0-9-amd64 4.19.118-2+deb10u1 amd64 Linux 4.19 for 64-bit PCs (signed)
ii linux-image-amd64 4.19+105+deb10u4 amd64 Linux for 64-bit PCs (meta-package)

Tatsächlich kam die Meldung zum ersten Mal, als ich vor ein paar Tagen über Synaptic ein Update gemacht hatte.

[willy4711]

Unter der Voraussetzung, das Kernel 4.19.0-9-amd der aktive ist, könntest du
die beiden anderen löschen

Code: Alles auswählen

apt purge  linux-image-4.19.0-8-amd64 linux-image-4.19.0-6-amd64

Vielleicht mal, um die Belegung zu sehen (haben wir ja gerade geübt ):

Code: Alles auswählen

lsblk /dev/sda --output KNAME,FSTYPE,FSSIZE,FSAVAIL,LABEL,MOUNTPOINT

[gundheri]

Vielleicht mal, um die Belegung zu sehen (haben wir ja gerade geübt ):

KNAME FSTYPE FSSIZE FSAVAIL LABEL MOUNTPOINT
sda
sda1 vfat 511M 499,8M /boot/efi
sda2 ext2 236,3M 140,5M /boot
sda3 crypto_LUKS
dm-0 LVM2_member
dm-1 ext4 108,4G 88,7G /
dm-2 swap [SWAP]

Schon mal vielen Dank!!! Ich würde jetzt für mich dazulernen wollen, dass man nach einem Update auch mal nach den kernels schaut?! Wäre das so korrekt?

[willy4711]

Schon gelöscht ?
Was ist den da noch drin ?

Code: Alles auswählen

ls -alh /boot

Da sollte man in der Tat nachschauen. Selbst bei Stable sammelt sich da einiges an.

[gundheri]

Schon gelöscht ?
Was ist den da noch drin ?

Ja, schon gelöscht. Ich finde in Synaptic auch noch linux-headers der gelöschten kernels. Zusammen etwas über 100MB. Sollten die auch weg?

insgesamt 71M
drwxr-xr-x 5 root root 1,0K Jul 2 11:34 .
drwxr-xr-x 18 root root 4,0K Jul 2 11:33 ..
-rw-r--r-- 1 root root 202K Jun 7 17:42 config-4.19.0-9-amd64
drwx------ 3 root root 4,0K Jan 1 1970 efi
drwxr-xr-x 5 root root 1,0K Jul 2 11:34 grub
-rw-r--r-- 1 root root 62M Jul 2 11:34 initrd.img-4.19.0-9-amd64
drwx------ 2 root root 12K Feb 7 10:10 lost+found
-rw-r--r-- 1 root root 3,3M Jun 7 17:42 System.map-4.19.0-9-amd64
-rw-r--r-- 1 root root 5,1M Jun 7 17:42 vmlinuz-4.19.0-9-amd64

[willy4711]

Mach mal folgende Ausgabe:

Code: Alles auswählen

dpkg -l *linux* |grep ii

Können natürlich auch weg
Aber setze das doch bitte bitte in Code Tags. Oben der 5. Button von rechts </>

[MSfree]

Ich würde jetzt für mich dazulernen wollen, dass man nach einem Update auch mal nach den kernels schaut?

Ja, das ist zumindest keine schlechte Idee. Normalerweise braucht man nur einen Kernel, von der die Kiste booten soll. Bei einem Kernelupdate läßt der Installer aber den vorherigen Kernel stehen. Sollte es zu einem Bootproblem mit dem neuen Kernel kommen, hat man immer noch den vorherigen. Alle älteren Kernerl, also Vorvorgänger, Vorvorvorgänger etc. kann man einfach löschen.

Trotzdem noch ein Warnhinwes: es ist keine gute Idee, einen Kernel zu löschen, wenn es sich um den gerade laufenden Kernel handelt. Wer sein System nur alle paar Jahre mal bootet, der sammelt Kernel im /boot-Verzeichnis an. Auch hat man dann ggfls. einen uralten Kernel am Laufen, den man zu dem Zeitpunkt lieber nicht löschen sollte. Eigentlich sollte man es sich zur Gewohnheit machen, nach eine Kernelupdate zu booten, dann kann man hinterher auch alte Kernel ruhigen Gewissens löschen.

Ja, ich weiß, Reboot bei einem Server sollte man ein wenig im Voraus planen und ankündigen. Also nicht den Leuten den Server unter'm Hintern wegbooten.

[gundheri]

Code: Alles auswählen

ii  binutils-x86-64-linux-gnu           2.31.1-16          amd64        GNU binary utilities, for x86-64-linux-gnu target
ii  console-setup-linux                 1.193~deb10u1      all          Linux specific part of console-setup
ii  firmware-linux                      20190114-2         all          Binary firmware for various drivers in the Linux kernel (metapackage)
ii  firmware-linux-free                 3.4                all          Binary firmware for various drivers in the Linux kernel
ii  firmware-linux-nonfree              20190114-2         all          Binary firmware for various drivers in the Linux kernel (meta-package)
ii  libselinux1:amd64                   2.8-1+b1           amd64        SELinux runtime shared libraries
ii  linux-base                          4.6                all          Linux image base package
ii  linux-compiler-gcc-8-x86            4.19.118-2+deb10u1 amd64        Compiler for Linux on x86 (meta-package)
ii  linux-headers-4.19.0-6-amd64        4.19.67-2+deb10u2  amd64        Header files for Linux 4.19.0-6-amd64
ii  linux-headers-4.19.0-6-common       4.19.67-2+deb10u2  all          Common header files for Linux 4.19.0-6
ii  linux-headers-4.19.0-8-amd64        4.19.98-1+deb10u1  amd64        Header files for Linux 4.19.0-8-amd64
ii  linux-headers-4.19.0-8-common       4.19.98-1+deb10u1  all          Common header files for Linux 4.19.0-8
ii  linux-headers-4.19.0-9-amd64        4.19.118-2+deb10u1 amd64        Header files for Linux 4.19.0-9-amd64
ii  linux-headers-4.19.0-9-common       4.19.118-2+deb10u1 all          Common header files for Linux 4.19.0-9
ii  linux-headers-amd64                 4.19+105+deb10u4   amd64        Header files for Linux amd64 configuration (meta-package)
ii  linux-image-4.19.0-9-amd64          4.19.118-2+deb10u1 amd64        Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-amd64                   4.19+105+deb10u4   amd64        Linux for 64-bit PCs (meta-package)
ii  linux-kbuild-4.19                   4.19.118-2+deb10u1 amd64        Kbuild infrastructure for Linux 4.19
ii  linux-libc-dev:amd64                4.19.118-2+deb10u1 amd64        Linux support headers for userspace development
ii  util-linux                          2.33.1-0.1         amd64        miscellaneous system utilities
ii  util-linux-locales                  2.33.1-0.1         all          locales files for util-linux

[willy4711]

Schöön
Bei den Headers braucht man nur die "commons" löschen, der Rets geht dann automatisch (Abhängigkeiten)
ALSO

Code: Alles auswählen

apt purge linux-headers-4.19.0-6-common linux-headers-4.19.0-8-common

[gundheri]

Schöön
Bei den Headers braucht man nur die "commons" löschen, der Rets geht dann automatisch (Abhängigkeiten)

Trotzdem noch ein Warnhinwes:

Vielen Dank, ist notiert! Einen Neustart habe ich noch nicht gemacht. Den hole ich nun noch nach. Ist das Laptop meiner Frau. Wird spaßig, wenn was nicht mehr funktioniert.

Daten sind gesichert! 3,2,1....bis gleich!

[willy4711]

Trotzdem noch ein Warnhinwes: es ist keine gute Idee, einen Kernel zu löschen, wenn es sich um den gerade laufenden Kernel handelt.

Hatte mich mal vertippt, und wollte das machen. Aber so einfach geht es dann auch wieder nicht.

Kam ne dicke Warnung von apt, die mich dann von meinem Vorhaben doch lieber Abstand nehmen ließ.

[gundheri]

Bin wieder hier - läuft! Herzlichen Dank!

[wanne]

Warum wird das eigentlich nicht von apt autoremove erledigt?

[gundheri]

Wird's evtl, ich hab's allerdings aus Unwissenheit nie gemacht, da ich apt autoremove erst bei MX-Linux kennengelernt habe. Ich mach's künftig auch bei Debian, dann mal schauen.

[Radfahrer]

Warum wird das eigentlich nicht von apt autoremove erledigt?

Das wird es. Wenn man es denn benutzt. Ich halte da nicht so viel von. Damit kann man sich schnell mal das System zerlegen.

[Lord_Carlos]

Warum wird das eigentlich nicht von apt autoremove erledigt?

Das wird es. Wenn man es denn benutzt. Ich halte da nicht so viel von. Damit kann man sich schnell mal das System zerlegen.

Wie koennte das passieren?

[Radfahrer]

Wenn man z.B. ein Metapaket (z.B. eine Desktopumgebung) installiert und dann ein einzelnes Paket daraus wieder deinstalliert.
Dann schmeißt autoremove gerne mal den kompletten Desktop weg wenn man nicht aufpasst. Ist aber ein schon seit langem bekanntes Problem. Suche einfach mal nach autoremove. Dann wirst du auf Threads wie "Autoremove will das halbe System deinstallieren", u.a. stoßen.

[willy4711]

Ich habe immer das Tool von Siduction für diese Zwecke toll gefunden. Leider gibt es den Kernel-Remover bei Debian nicht.
Also war immer Handarbeit angesagt.
Hab mal bemüht und dies gefunden:
https://axebase.net/blog/2015/07/26/ker ... in-ubuntu/
Werde ich mal in einer VM Testen (brauch aber erstmal ein Paar Kernel).
Mal sehen. ob das am Wochenende klappt.

Na in einer VM hab ich auch dieses Sudo.
Sollte das funktionieren, werde ich mir wohl mangels Sudo eine Policy basteln müssen

Edit:
die beiden Dateien kann aus dem Link oben kann man sich auch hier ziehen:
http://ftp.uni-stuttgart.de/siduction/e ... l-remover/
http://ftp.uni-stuttgart.de/siduction/e ... ecommons3/

[willy4711]

Cool
Nach Test in einer VM Ist es sogleich in mein Produktiv System (Testing) aufgenommen worden.
Hat gleich erfolgreich gearbeitet:


Dank an Siduction

EDIT:

Noch was Interessantes:
Der Starter hört auf den Befehl:

Code: Alles auswählen

su-to-root -X -c /usr/sbin/kernel-remover

su-to-root kommt aus dem Paket menu

Kein sudo, keine extra Policy, trotzdem funktioniert das.

Wieder was gelernt