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. | 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
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?
|
|
DJKUhpisse
Supporter, Wikiteam
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:
|
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:
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
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-
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
|