ubuntuusers.de

Boot-Partition zu klein, Kernel Installation mit Fehlermeldung

Status: Ungelöst | Ubuntu-Version: Ubuntu 17.10 (Artful Aardvark)
Antworten |

Fansurfer

Anmeldungsdatum:
13. Juni 2015

Beiträge: 56

Hallo,

bei mir wurden 4 Pakete nicht vollständig installiert bzw. entfernt wird mir gemeldet. Soweit ich das erkennen kann handelt es sich dabei um einen Kernel der nicht richtig installiert wurde.

1
linux-image-extra-4.13.0-17-generic (4.13.0-17.20) wird eingerichtet ...

Wenn ich das Upgrade anstoße kommen jedenfalls Fehlermeldungen die auf eine zu kleine Boot-Partition hin deuten.

Auf der Boot-Partition sind auch nur ca. 9 MB frei, was mich wundert. Die Boot-Partition ist ca 190 MB groß und das System ist ca. ein Monat drauf.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
sudo du -hs /boot/*
1,5M	/boot/abi-4.13.0-16-generic
1,5M	/boot/abi-4.13.0-17-generic
209K	/boot/config-4.13.0-16-generic
209K	/boot/config-4.13.0-17-generic
6,9M	/boot/grub
56M	/boot/initrd.img-4.13.0-16-generic
56M	/boot/initrd.img-4.13.0-17-generic
12K	/boot/lost+found
179K	/boot/memtest86+.bin
181K	/boot/memtest86+.elf
181K	/boot/memtest86+_multiboot.bin
3,7M	/boot/System.map-4.13.0-16-generic
3,8M	/boot/System.map-4.13.0-17-generic
7,5M	/boot/vmlinuz-4.13.0-16-generic
7,5M	/boot/vmlinuz-4.13.0-17-generic

Moderiert von ChickenLipsRfun2eat:

Dieses Thema ist verschoben worden. Bitte beachte die als wichtig markierten Themen („Welche Themen gehören hier her und welche nicht?“)!

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

Hallo!

Schau dir mal Skripte/Alte Kernel entfernen an.

Wieso ist denn deine Boot-Partition zu klein? Zeige bitte noch:

sudo parted --list
df -h;df -i

Fansurfer

(Themenstarter)

Anmeldungsdatum:
13. Juni 2015

Beiträge: 56

Hallo,

so wie es aussieht ist meine Bootpartition zu klein. Bei der Installation von einem Kernel gibt es Fehlermeldungen, die darauf hin deuten. Was mich nur wundert, das System ist erst gut einen Monat drauf auf der Platte. Die Bootpartition hat ca. 190MB und es sind ca. 9MB frei. Laut Synaptic sind 2 Kernel installiert, wobei für den zweiten auch die Fehlermeldungen kommen und dazu werden 4 Pakete nicht installiert.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
sudo apt-get dist-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
4 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] j
initramfs-tools (0.125ubuntu12) wird eingerichtet ...
update-initramfs: deferring update (trigger activated)
linux-image-extra-4.13.0-17-generic (4.13.0-17.20) wird eingerichtet ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.13.0-17-generic /boot/vmlinuz-4.13.0-17-generic
run-parts: executing /etc/kernel/postinst.d/dkms 4.13.0-17-generic /boot/vmlinuz-4.13.0-17-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.13.0-17-generic /boot/vmlinuz-4.13.0-17-generic
update-initramfs: Generating /boot/initrd.img-4.13.0-17-generic

gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-4.13.0-17-generic with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: Fehler beim Bearbeiten des Paketes linux-image-extra-4.13.0-17-generic (--configure):
 Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von linux-image-generic:
 linux-image-generic hängt ab von linux-image-extra-4.13.0-17-generic; aber:
  Paket linux-image-extra-4.13.0-17-generic ist noch nicht konfiguriert.

Wie kann ich des beheben?

Moderiert von ChickenLipsRfun2eat:

Ein Thema reicht.

DJKUhpisse Team-Icon

Supporter, Wikiteam
Avatar von DJKUhpisse

Anmeldungsdatum:
18. Oktober 2016

Beiträge: 18220

Wohnort: in deinem Browser, hier auf dem Bildschirm

dann muss die Partition ausgehängt werden und dann vergrößert werden. Ich glaube nicht, dass das im laufenden Betrieb von Ubuntu geht, wenn das Ubuntu diese Bootpartition nutzt. Nutze am besten ein Livesystem und dann halt gparted oder entsprechende Konsolenprogramme.

Tuemmler

Anmeldungsdatum:
26. März 2007

Beiträge: 8075

Wohnort: Süsel / Ostholstein

Moin Moin,

DJKUhpisse schrieb:

dann muss die Partition ausgehängt werden und dann vergrößert werden.

Tschuldigung, sollte man nicht erst prüfen warum die Bootpartition zu klein sein soll?

Also:Fansurfer

Dann zeige uns zunächst einmal die Terminalausgaben von

sudo lsblk -o NAME,FSTYPE,TYPE,SIZE,MOUNTPOINT,LABEL,UUID
df -h
df -i

ebenfalls im Codeblock

Gruß

Funde unter :

https://duckduckgo.com/?keyword=Boot+voll&q=site%3Aforum.ubuntuusers.de+Boot+voll&kam=osm&kj=D8A648&ky=f3eedd&k18=1&ka=Ubuntu&ia=web

Fansurfer

(Themenstarter)

Anmeldungsdatum:
13. Juni 2015

Beiträge: 56

So sieht lsblk aus:

NAME  FSTYPE TYPE   SIZE MOUNTPOINT LABEL   UUID
loop0 squash loop  76,4M /snap/keep         
loop1 squash loop  83,1M /snap/core         
loop2 squash loop  83,7M /snap/core         
sda          disk 232,9G                    
├─sda1
│     ext4   part   190M /boot              e01f2b80-385a-4a4f-b781-7413f516db59
├─sda2
│            part     1K                    
├─sda5
│     ext4   part    28G /                  f710bb04-d81f-4b5c-b25f-3f4a93da6a75
├─sda6
│     swap   part   3,7G [SWAP]             54970e81-2be1-4393-8e87-0ffacec3403a
└─sda7
      ext4   part   201G /home              89efdba1-b697-43e7-bf38-66a4a3d07024
sdb          disk 931,5G                    
├─sdb1
│     ext4   part   200G /cloud     d_cloud 68557f43-9dd0-4871-ad61-c6459be1dfd3
└─sdb2
      ext4   part 731,5G /datastore d_data  c6e2fe30-817c-4e9e-9c22-b30b120b24b5
df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev            3,9G       0  3,9G    0% /dev
tmpfs           795M     11M  785M    2% /run
/dev/sda5        28G    6,3G   20G   24% /
tmpfs           3,9G     21M  3,9G    1% /dev/shm
tmpfs           5,0M    4,0K  5,0M    1% /run/lock
tmpfs           3,9G       0  3,9G    0% /sys/fs/cgroup
/dev/loop0       77M     77M     0  100% /snap/keepassxc/26
/dev/loop1       84M     84M     0  100% /snap/core/3247
/dev/loop2       84M     84M     0  100% /snap/core/3440
/dev/sda1       180M    146M   22M   88% /boot
/dev/sda7       197G     24G  164G   13% /home
/dev/sdb2       720G    8,6G  674G    2% /datastore
/dev/sdb1       196G     61M  186G    1% /cloud
tmpfs           795M     16K  795M    1% /run/user/121
tmpfs           795M     32K  795M    1% /run/user/1000
df -i
Dateisystem      Inodes IBenutzt    IFrei IUse% Eingehängt auf
udev            1009571      545  1009026    1% /dev
tmpfs           1017088     1009  1016079    1% /run
/dev/sda5       1831424   200535  1630889   11% /
tmpfs           1017088       44  1017044    1% /dev/shm
tmpfs           1017088        5  1017083    1% /run/lock
tmpfs           1017088       18  1017070    1% /sys/fs/cgroup
/dev/loop0        22978    22978        0  100% /snap/keepassxc/26
/dev/loop1        13618    13618        0  100% /snap/core/3247
/dev/loop2        13624    13624        0  100% /snap/core/3440
/dev/sda1         48768      316    48452    1% /boot
/dev/sda7      13180928    31589 13149339    1% /home
/dev/sdb2      47947776     2168 47945608    1% /datastore
/dev/sdb1      13107200       11 13107189    1% /cloud
tmpfs           1017088       17  1017071    1% /run/user/121
tmpfs           1017088       27  1017061    1% /run/user/1000

axt

Anmeldungsdatum:
22. November 2006

Beiträge: 34254

Tuemmler schrieb:

sollte man nicht erst prüfen warum die Bootpartition zu klein sein soll?

Ganz einfach: Canonical hat es immer noch nicht geschafft, Ubuntu einen sinnvollen Partitionierungsautomatismus beizubringen. 180 MiB, sowas albernes.

Btw., ich habe diese Woche in der Fa. quasi das Pendant dazu unter Windows erlebt. Bei angestoßenem Build-Upgrade von 1703 auf 1709 (selbstverständlich offline, ich ziehe die 4.4 GiB doch nicht bei jedem Rechner neu) ist "Die für das System reservierte Partition konnte nicht aktualisiert werden." ausgegeben worden. Das passiert beispielsweise, wenn auf SSD geclonet wird (was man sowieso nicht macht) und eben jene Partition vom famosen Samsung-Cloning-Tool auch verkleinert wird. Bei dem 120er SSD sind aus dieser Bootpartition grandiose 43 MiB geworden.

Mit Lubuntu live und gparted habe ich von der zweiten Partition (c:) am Anfang etwas abgeschnitten (vorher Fastboot in Windows disabled) und den Free Space der Bootpartition zugeschlagen, freilich ohne sicher sein zu können, ob sich durch Änderung von UUIDs o.ä. das System noch booten läßt. Langer Rede kurzer Sinn, hat funktioniert und das Upgrade nach automatischem chkdsk dann auch.

Beim System des Threadstarters, also Linux, würde ich das auch machen. Man sollte jedoch von UUIDs, fstab und eventuellen Korrekturen daran schon mal etwas gehört haben. Wie sich das mit (seiner) Verschlüsselung verhält, kann ich allerdings nicht sagen, sprich ob man dann überhaupt noch 'rein kommt.

Fansurfer

(Themenstarter)

Anmeldungsdatum:
13. Juni 2015

Beiträge: 56

Bei der manuellen Partitionierung soll für Boot eine Partition von 100 - 200MB angelegt werden laut Wiki. Da sollten die 190MB erst einmal reichen und das System nicht gleich beim Installieren des 2. Kernel die Grenze überschritten werden. Bei Arch Linux war das ähnlich.

Da Frage ich mich schon was müllt die Bootpattition dicht? Denn wenn man die Bootpattition vergrößert, ist es doch nur eine Frage der Zeit wann wieder ein Kernel nicht korrekt installiert wird.

axt

Anmeldungsdatum:
22. November 2006

Beiträge: 34254

Fansurfer schrieb:

Da Frage ich mich schon was müllt die Bootpattition dicht?

Und welche Antwort gibt's? Frag das System:

1
ls -lahR /boot

Fansurfer

(Themenstarter)

Anmeldungsdatum:
13. Juni 2015

Beiträge: 56

Nach dem ich über Synaptic den Kernel 4.13.0-17 noch mal installiert habe, kam ich nicht mehr ins System. Nun habe ich den Kernel über Live-CD deinstalliert und ich hatte wieder zugriff auf mein System.

Nichts desto trotz möchte ich nun wissen warum meine Boot-Partition zu klein ist. axt schrieb:

Fansurfer schrieb:

Da Frage ich mich schon was müllt die Bootpattition dicht?

Und welche Antwort gibt's? Frag das System:

1
ls -lahR /boot

Die Antwort auf dem Befehl ergibt eine aktuelle Belegung von ca. 76MB. Das ist erst einmal für einen Kernel in Boot auch ok denke ich.

Fansurfer

(Themenstarter)

Anmeldungsdatum:
13. Juni 2015

Beiträge: 56

Sobald ich den Kernel 4.13.0-17 installiere, kann ich mich nicht mehr anmelden, weil die Tastatur dann nicht läuft. Ich habe den Kernel nach der Anleitung Alte Kernel entfernen: entfernt.

Aber der muss ja irgendwie ja da rein, denke ich mal. Wobei es den Anschein hat, dass die Pakete nicht in Ordnung sind. Positiv ist zu sehen das die Bootpartition jetzt nicht zu klein war.

Fansurfer

(Themenstarter)

Anmeldungsdatum:
13. Juni 2015

Beiträge: 56

Ich habe mehrfach versucht den Kernel 4.13.0-17 zu installieren. Es läuft immer darauf hinaus, das die Bootpartition mit zu kein ist. Die Bootpartition wurde automatisch beim Installieren angelegt, das man nicht mal einen zweiten Kernel dann installieren kann ist schon verwunderlich.

Wie groß sollte denn die Bootpartition sein, denn laut Wiki sollte sie reichen?

Kellerkind_2009

Avatar von Kellerkind_2009

Anmeldungsdatum:
26. November 2009

Beiträge: 19617

Wohnort: Schleswig-Holstein

Zeige mal

ls -a /boot/ -lahS

Fansurfer

(Themenstarter)

Anmeldungsdatum:
13. Juni 2015

Beiträge: 56

Jetzt habe ich die Bootpartition wohl verbastelt und mein PC startet nicht, weil er die Bootpartition nicht mehr findet. Ich habe mit gdisk Partitionsnamen vergeben und weil nichts ging diese auch wieder rueckgaengig gemacht. Wie bekomme ich das denn nun wieder hin?

Bert-

Avatar von Bert-

Anmeldungsdatum:
26. April 2009

Beiträge: 445

Wohnort: Niedersachsen

Fansurfer schrieb:

Wie bekomme ich das denn nun wieder hin?

Ein Boot-USB-Stick herstellen, darauf das Tool TestDisk (gibt es kostenlos im Internet) packen und den Rechner vom USB-Stick booten; mit diesem Tool habe ich schon viele Partitionen (von DOS bis WinXP) gerettet. Allerdings kenne ich mich mit den neuen Systemen nicht aus, aber das Tool kann auch mit Win10-Partitonen arbeiten.

Gruß, Bert

Antworten |