LINUX: System lässt sich nicht mehr updaten...

[rabautz]

jupp hatte ich gerade auch gesehen und entsprechend ausgeführt.

Danke noch mal, das erspart mir bei dem Problem ne Menge Arbeit.

[Hollo]

Das mit den Abhängigkeiten ist ja eine sinnvolle Sache, aber wenn man sich plötzlich ma darin verfängt, kommt man schon leicht ins Schwitzen.
Hatte ich letztens auch mit einigen libs, wo dann eins vom anderen abhing, welches wieder, ihr wisst schon.

Hier war ja scheinbar eher der fehlende Plattenplatz das ursächliche Problem.
Es wird ja auch diverse gecached, was da im Laufe der Zeit so runtergeladen wurde.
Mit folgender Kombi kann man da "gucken & machen & wieder gucken", ohne dass man sich gleich mit den Abhängigkeiten rumschlägt.

Code Auswählen Erweitern


df -h
apt-get clean
df -h


[MarkusAutomaticus]

Hallo zusammen,

vielen Dank für die vielen Tipps und die rege Anteilnahme!

Der einzige Datenträger in meinem NUC ist eine SSD mit 128GB.
Das System wurde mit den Defaults von Ubuntu eingerichtet.

Das Ganze sieht aktuell so aus:

Code Auswählen Erweitern

-Mounted File Systems-
udev /dev 0,00 % (3,8 GiB of 3,8 GiB)
tmpfs /run 1,24 % (777,2 MiB of 786,9 MiB)
/dev/mapper/Jarvis3--vg-root / 17,68 % (89,3 GiB of 108,5 GiB)
tmpfs /dev/shm 0,01 % (3,8 GiB of 3,8 GiB)
tmpfs /run/lock 0,08 % (5,0 MiB of 5,0 MiB)
tmpfs /sys/fs/cgroup 0,00 % (3,8 GiB of 3,8 GiB)
/dev/sda2 /boot 100,00 % (0,0 B of 472,6 MiB)
/dev/sda1 /boot/efi 0,68 % (507,5 MiB of 511,0 MiB)
tmpfs /run/user/1000 0,00 % (786,9 MiB of 786,9 MiB)
tmpfs /run/user/111 0,00 % (786,9 MiB of 786,9 MiB)


Anscheind sehen die Defaults ein relativ kleines Boot-Verzeichnis vor, in dem sich dann so lange alte Kernel-Images ansammeln bis es zwangsläufig knallt:

/dev/sda2   /boot   100,00 % (0,0 B of 472,6 MiB)

Hier wäre ein Automatismus clever, der regelmäßig die ältesten Images löscht.
Wenn ich jetzt mit meinen bescheidenen Linux-Kentnissen im boot-Verzeichnis aufräume,
mache ich sicher etwas kaputt.

Kann man vielleicht /dev/sda2 vergrößern?

In Windows würde ich in die Datenträgerverwaltung und mit ein paar Mausclicks die betreffende Partition vergrößern.
Unter Linux habe ich schon mal gparted verwendet, das ist aber nicht drauf und beim Versuch es zu installieren, laufe ich wieder in die Abhängigkeitsfalle.

Gruß
Markus

[MarkusAutomaticus]

Nachtrag:

sudo dpkg --get-selections | grep deinstall ergibt folgendes:

Code Auswählen Erweitern

markus@Jarvis3:~$ sudo dpkg --get-selections | grep deinstall
linux-image-4.4.0-31-generic                    deinstall
linux-image-4.4.0-38-generic                    deinstall
linux-image-4.4.0-42-generic                    deinstall
linux-image-4.4.0-45-generic                    deinstall
linux-image-4.4.0-47-generic                    deinstall
linux-image-4.4.0-51-generic                    deinstall
linux-image-4.4.0-53-generic                    deinstall
linux-image-4.4.0-57-generic                    deinstall
linux-image-4.4.0-59-generic                    deinstall
linux-image-4.4.0-63-generic                    deinstall
linux-image-extra-4.4.0-31-generic              deinstall
linux-image-extra-4.4.0-38-generic              deinstall
linux-image-extra-4.4.0-42-generic              deinstall
linux-image-extra-4.4.0-45-generic              deinstall
linux-image-extra-4.4.0-47-generic              deinstall
linux-image-extra-4.4.0-51-generic              deinstall
linux-image-extra-4.4.0-53-generic              deinstall
linux-image-extra-4.4.0-57-generic              deinstall
linux-image-extra-4.4.0-59-generic              deinstall
linux-image-extra-4.4.0-63-generic              deinstall
linux-signed-image-4.4.0-31-generic             deinstall
linux-signed-image-4.4.0-38-generic             deinstall
linux-signed-image-4.4.0-42-generic             deinstall
linux-signed-image-4.4.0-45-generic             deinstall
linux-signed-image-4.4.0-47-generic             deinstall
linux-signed-image-4.4.0-51-generic             deinstall
linux-signed-image-4.4.0-53-generic             deinstall
linux-signed-image-4.4.0-57-generic             deinstall
linux-signed-image-4.4.0-59-generic             deinstall
linux-signed-image-4.4.0-63-generic             deinstall

heißt das, dass ich alle obigen images löschen kann?

Leider ergibt
sudo apt-get purge $(dpkg --get-selections | grep deinstall | awk '{print $1}' | xargs)

folgendes:

Code Auswählen Erweitern

markus@Jarvis3:~$ sudo apt-get purge $(dpkg --get-selections | grep deinstall | awk '{print $1}' | xargs)
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Probieren Sie »apt-get -f install«, um dies zu korrigieren:
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
linux-image-extra-4.4.0-78-generic : Hängt ab von: linux-image-4.4.0-78-generic soll aber nicht installiert werden
linux-signed-image-4.4.0-78-generic : Hängt ab von: linux-image-4.4.0-78-generic (= 4.4.0-78.99) soll aber nicht installiert werden
E: Unerfüllte Abhängigkeiten. Versuchen Sie »apt-get -f install« ohne Angabe eines Pakets (oder geben Sie eine Lösung an).
markus@Jarvis3:~$


Aktueller Kernel ist:

Code Auswählen Erweitern

markus@Jarvis3:~$ uname -a
Linux Jarvis3 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux


Gruß
Markus

[Wernieman]

Kann Dir leider erst heute Abend helfen .... Da muss ich vorher etwas prüfen ....

[Manul]

Du könntest versuchen, die unerwünschten Kernel-Pakete mit 'dpkg --purge' zu löschen.

[betateilchen]

dann mach doch einfach mal, was Dein System Dir vorschlägt:

Code Auswählen Erweitern


Probieren Sie »apt-get -f install«, um dies zu korrigieren:


und danach das Löschen nochmal.

Wobei Du das Kernel-Image 4.4.0.75 nicht löschen solltest, solange das noch der aktuell laufende Kernel ist.

[Wernieman]

Siehe Anfang des Threads ... das hat er schon probierte
Edit:
Kannst Du uns bitte Mal geben:

Code Auswählen Erweitern

ls -lha /boot/

[kaputt]

Hier wäre ein Automatismus clever, der regelmäßig die ältesten Images löscht.

Den Automatismus gibt es, der heißt User bzw. System Adminidstration!

Kann man vielleicht /dev/sda2 vergrößern?

Kann man/frau rate dir aber davon ab.

In Windows würde ich in die Datenträgerverwaltung und mit ein paar Mausclicks die betreffende Partition vergrößern.

Ja is klar Windows kann alles besser.

Unter Linux habe ich schon mal gparted verwendet, das ist aber nicht drauf und beim Versuch es zu installieren, laufe ich wieder in die Abhängigkeitsfalle.

Gibt es auch als Live-CD/USB.
Warum die sda2 vergrößern? Mal davon ab das du LVM verwendest, wobei sich mir nicht erschließt warum, ist das eine Aktion die ich ohne entsprechende Kenntnisse nicht durchführen würde.

Gruß aus L.E.
Uwe

[MarkusAutomaticus]

Hallo zusammen,

es ist ein schönes Gefühl, dass wir hier alle so zusammenhalten und uns gegenseitig helfen.
Das wollte ich mal loswerden 

ls -lha /boot/ ergibt folgendes:

Code Auswählen Erweitern


markus@Jarvis3:~$ ls -lha /boot/
insgesamt 442M
drwxr-xr-x  5 root root 5,0K Jun 17 11:11 .
drwxr-xr-x 23 root root 4,0K Jun 17 00:23 ..
-rw-r--r--  1 root root 1,2M Jan 18 16:59 abi-4.4.0-62-generic
-rw-r--r--  1 root root 1,2M Feb 20 14:40 abi-4.4.0-64-generic
-rw-r--r--  1 root root 1,2M Feb 23 21:00 abi-4.4.0-65-generic
-rw-r--r--  1 root root 1,2M Mär  3 19:25 abi-4.4.0-66-generic
-rw-r--r--  1 root root 1,2M Mär 22 17:11 abi-4.4.0-70-generic
-rw-r--r--  1 root root 1,2M Mär 24 16:20 abi-4.4.0-71-generic
-rw-r--r--  1 root root 1,2M Apr 20 14:02 abi-4.4.0-75-generic
-rw-r--r--  1 root root 1,2M Apr 27 20:24 abi-4.4.0-78-generic
-rw-r--r--  1 root root 186K Apr 20 14:02 config-4.4.0-75-generic
-rw-r--r--  1 root root 186K Apr 27 20:24 config-4.4.0-78-generic
drwx------  3 root root 4,0K Jan  1  1970 efi
drwxr-xr-x  5 root root 1,0K Jun 17 00:36 grub
-rw-r--r--  1 root root  40M Jun 17 00:36 initrd.img-4.4.0-62-generic
-rw-r--r--  1 root root  40M Jun 17 00:36 initrd.img-4.4.0-64-generic
-rw-r--r--  1 root root  40M Jun 17 00:36 initrd.img-4.4.0-65-generic
-rw-r--r--  1 root root  40M Jun 17 00:35 initrd.img-4.4.0-66-generic
-rw-r--r--  1 root root  40M Jun 17 00:35 initrd.img-4.4.0-70-generic
-rw-r--r--  1 root root  40M Jun 17 00:35 initrd.img-4.4.0-71-generic
-rw-r--r--  1 root root  40M Jun 17 00:35 initrd.img-4.4.0-75-generic
-rw-r--r--  1 root root  40M Jun 17 00:34 initrd.img-4.4.0-78-generic
drwx------  2 root root  12K Okt  6  2016 lost+found
-rw-r--r--  1 root root 179K Jan 28  2016 memtest86+.bin
-rw-r--r--  1 root root 181K Jan 28  2016 memtest86+.elf
-rw-r--r--  1 root root 181K Jan 28  2016 memtest86+_multiboot.bin
-rw-------  1 root root 3,7M Jan 18 16:59 System.map-4.4.0-62-generic
-rw-------  1 root root 3,8M Feb 20 14:40 System.map-4.4.0-64-generic
-rw-------  1 root root 3,8M Feb 23 21:00 System.map-4.4.0-65-generic
-rw-------  1 root root 3,8M Mär  3 19:25 System.map-4.4.0-66-generic
-rw-------  1 root root 3,8M Mär 22 17:11 System.map-4.4.0-70-generic
-rw-------  1 root root 3,8M Mär 24 16:20 System.map-4.4.0-71-generic
-rw-------  1 root root 3,8M Apr 20 14:02 System.map-4.4.0-75-generic
-rw-------  1 root root 3,8M Apr 27 20:24 System.map-4.4.0-78-generic
-rw-------  1 root root 6,8M Feb  3 14:44 vmlinuz-4.4.0-62-generic.efi.signed
-rw-------  1 root root 6,8M Feb 22 11:26 vmlinuz-4.4.0-64-generic.efi.signed
-rw-------  1 root root 6,8M Mär  2 16:21 vmlinuz-4.4.0-65-generic.efi.signed
-rw-------  1 root root 6,8M Mär  8 03:30 vmlinuz-4.4.0-66-generic.efi.signed
-rw-------  1 root root 6,8M Mär 22 17:11 vmlinuz-4.4.0-70-generic
-rw-------  1 root root 6,8M Mär 28 04:22 vmlinuz-4.4.0-70-generic.efi.signed
-rw-------  1 root root 6,8M Mär 24 16:20 vmlinuz-4.4.0-71-generic
-rw-------  1 root root 6,8M Mär 30 16:36 vmlinuz-4.4.0-71-generic.efi.signed
-rw-------  1 root root 6,8M Apr 20 14:02 vmlinuz-4.4.0-75-generic
-rw-------  1 root root 6,8M Jun 17 00:19 vmlinuz-4.4.0-75-generic.efi.signed
-rw-------  1 root root 6,8M Apr 27 20:24 vmlinuz-4.4.0-78-generic
-rw-------  1 root root 6,8M Jun 17 00:23 vmlinuz-4.4.0-78-generic.efi.signed
markus@Jarvis3:~$



Gestern habe ich in meiner Verzweiflung mit sudo rm auf Dateisystemebene die zu den alten Kerneln gehörenden Dateien gelöscht.
Darauf waren diese auch kurzzeitig weg.

Wunderbarerweise waren sie nach einem erneuten apt-get update/upgrade aber alle wieder da und /boot bei 100%

Wtf?

Der Server lebt und will mich ärgern.

apt-get -f install

Wirft folgendes:

Code Auswählen Erweitern

markus@Jarvis3:~$ sudo apt-get -f install
[sudo] Passwort für markus:
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 4 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
initramfs-tools (0.122ubuntu8.8) wird eingerichtet ...
update-initramfs: deferring update (trigger activated)
Trigger für initramfs-tools (0.122ubuntu8.8) werden verarbeitet ...
update-initramfs: Generating /boot/initrd.img-4.4.0-78-generic
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.

gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-4.4.0-78-generic with 1.
dpkg: Fehler beim Bearbeiten des Paketes initramfs-tools (--configure):
Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)
markus@Jarvis3:~$


Was ich nicht verstehe, ist folgendes:

W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.

Was will mir mein bockiges System damit sagen?

Ich finde, ein Betriebssystem sollte einfach nur laufen, sich automatisch aktuell halten und nicht den Anwender von den Anwendungen abhalten.

Ich habe den Ubuntu-Server komplett mit den Standard-Setting eingerichtet, da sollte man nicht in solche Zeitbomben reinlaufen, wenn man einfach nur regelmäßig
apt-get update und apt-get upgrade aufruft

Gruß
Markus

[Manul]

Ich habe keine Lust, hier auf eine Linux vs. Windows-Diskussion einzusteigen. Hast Du das "dpkg --purge" denn mal probiert?

Quelle: https://askubuntu.com/questions/171209/my-boot-partition-hit-100-and-now-i-cant-upgrade-cant-remove-old-kernels-to

[Hollo]

So, hab meinen Beitrag mal fix wieder gelöscht und ersetze das einfach durch einen Link:

https://www.thomas-krenn.com/de/wiki/Alte_Kernel_in_Ubuntu_entfernen

So wie es aussieht ist das kein Linux-, sondern ein reines (altes) Ubuntu-Problem.
Kenne ich von Debian auch absolut nicht, und da läuft der Server schon zig Jahre.

[Wernieman]

Jep ... irgendwie kriegen die das nicht hin (

Wobei ein purgen aller gelöschten sachen ist trotzdem mal eine gute Idee ...

[Jorge3711]

Das "Problem" kennt RedHat/CentOS auch, hat das aber IMHO einfacher gelöst IMHO:

Code Auswählen Erweitern


[root@honstname boot]# ll *-3.10*
-rw-r--r-- 1 root root   137701 Mar  3 01:15 config-3.10.0-514.10.2.el7.x86_64
-rw-r--r-- 1 root root   137701 Apr 12 17:15 config-3.10.0-514.16.1.el7.x86_64
-rw-r--r-- 1 root root   137701 May 25 19:16 config-3.10.0-514.21.1.el7.x86_64
-rw------- 1 root root 45789948 Mar  9 19:52 initramfs-3.10.0-514.10.2.el7.x86_64.img
-rw------- 1 root root 18406265 Apr  5 18:14 initramfs-3.10.0-514.10.2.el7.x86_64kdump.img
-rw------- 1 root root 45792366 Apr 14 11:21 initramfs-3.10.0-514.16.1.el7.x86_64.img
-rw------- 1 root root 45792178 Jun  7 15:28 initramfs-3.10.0-514.21.1.el7.x86_64.img
-rw-r--r-- 1 root root   277969 Mar  3 01:17 symvers-3.10.0-514.10.2.el7.x86_64.gz
-rw-r--r-- 1 root root   277943 Apr 12 17:18 symvers-3.10.0-514.16.1.el7.x86_64.gz
-rw-r--r-- 1 root root   277955 May 25 19:18 symvers-3.10.0-514.21.1.el7.x86_64.gz
-rw------- 1 root root  3112473 Mar  3 01:15 System.map-3.10.0-514.10.2.el7.x86_64
-rw------- 1 root root  3113648 Apr 12 17:15 System.map-3.10.0-514.16.1.el7.x86_64
-rw------- 1 root root  3114102 May 25 19:16 System.map-3.10.0-514.21.1.el7.x86_64
-rwxr-xr-x 1 root root  5393008 Mar  3 01:15 vmlinuz-3.10.0-514.10.2.el7.x86_64*
-rwxr-xr-x 1 root root  5396240 Apr 12 17:15 vmlinuz-3.10.0-514.16.1.el7.x86_64*
-rwxr-xr-x 1 root root  5397552 May 25 19:16 vmlinuz-3.10.0-514.21.1.el7.x86_64*
[root@hostname boot]# package-cleanup --oldkernels --count=1
Loaded plugins: fastestmirror
Not removing kernel 3.10.0-514.10.2.el7 because it is the running kernel
--> Running transaction check
---> Package kernel.x86_64 0:3.10.0-514.16.1.el7 will be erased
---> Package kernel-devel.x86_64 0:3.10.0-514.16.1.el7 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================================================================
Package                          Arch                       Version                                  Repository                    Size
=========================================================================================================================================
Removing:
kernel                           x86_64                     3.10.0-514.16.1.el7                      @updates                     148 M
kernel-devel                     x86_64                     3.10.0-514.16.1.el7                      @updates                      34 M

Transaction Summary
=========================================================================================================================================
Remove  2 Packages

Installed size: 182 M
Is this ok [y/N]:


[Wernieman]

@MarkusAutomaticus

hast Du die dpkg --purge sache jetzt mal gemacht oder nicht?