• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[Gelöst] Volle Boot partition, Alte Kernel aus Live-System heraus löschen

F

Flash

Member
Hi,

Ich habe hier den Rechner meines Onkels vor der Nase der ein Boot-Problem hat. Das System meldet:
Code: 
kernel panic-not syncing: VFS: unable to mount root fs on unknown block(0,0)
Ich konnte nach einer gefühlten Ewigkeit das Problem zurück verfolgen auf eine volle Boot-Partition.

Im Ubuntu-Forum (wo Antworten leider nur einmal pro Woche kommen - an dem Mist sitze ich seit 3 Wochenenden) wurde ich auf das "Boot-Repair" Tool (live system) hingewiesen. Boot-Repair ist aktuell der einzige Zugang den ich zum defekten Rechner habe (ich hab zwar noch eine Fedora live DVD rumliegen, aber mit der hab ich auch 0 Erfahrung)

Man hat mich auf diesen ubuntu-help Artikel hingewiesen, wie ich alte Kernels entfernen kann. Leider funktioniert das so bei mir nicht, da ich im System nicht angemeldet bin und apt-get nicht zu verfügung steht. (Ich sitze ja außerhalb des Systems im Live-System.)

Aus dem boot-repair report kann ich erkennen, dass wohl noch Partitionen zu mounten sind etc. Nun stoße ich hier aber an meine Grenzen und bräuchte jemanden der mich aus dem Loch rausnavigiert.
 
J

josef-wien

Ultimate Guru
Flash schrieb:
kernel panic-not syncing: VFS: unable to mount root fs on unknown block(0,0)
Zum Vergrößern anklicken....
Mit einer vollen Boot-Partition hat dieses Problem bestenfalls indirekt zu tun. Der Boot-Manager liest von dort Kernel und initrd, der Kernel selbst greift dort gar nicht hin.

Eine volle Boot-Partition kann aber dazu führen, daß eine neue initrd nur unvollständig gespeichert wurde (wenn die jeweilige Routine zu dumm ist, das zu bemerken, oder der Benutzer, eine diesbezügliche Meldung zu ignorieren). Um die Boot-Partition zu säubern (damit irgendwelche Hilfsprogramme dann dort Platz für "Reparaturversuche" haben), brauchst Du nur die nicht benötigten Dateien vmlinuz* und initrd* zu löschen, eine Deinstallation von Kernel-Paketen ist da nicht notwendig (das kannst Du später im laufenden System nachholen).

Wenn aber die Boot-Partition voll ist, bedeutet das, daß jede Menge Kernel und initrd vorhanden sein müssen, was wiederum zur Frage führt, warum Du nicht einen davon im Boot-Menü auswählst und startest.

P. S. In Deinem "boot-repair report" (den ich mir nicht durchlesen werde) finde ich das Wichtigste nicht:
Code: 
ls -l /einhängepunkt/boot-partition
 
Gräfin Klara

Gräfin Klara

Hacker
>> kernel panic-not syncing: VFS: unable to mount root fs on unknown block(0,0)

Ist doch hier zu lesen.
Wenn die boot_partition voll ist aber komplett, dann spielt das keine Rolle. init() kann das rootfs nicht mounten. rootfs ist die partition, auf der das system (/etc, /sbin, usw.) liegt. Sollte die Anweisung block(0,0) richtig sein, (prüfe das) dann hilft nur ein Linux auf usb oder cd. Boote es und repariere das rootfs mit z.B. fsck. Aber, ist dein Onkel ein bedächtiger Mensch, der nicht im System herumstochert, testet und experimentiert, dann ist wohl die Platte kaputt.

Gräfin Klara
 
OP
F

Flash

Member
Danke Josef und Klara.

Die boot-Partition ist definitiv voll. Siehe boot-repair report:
Code: 
Filesystem                   Type       Size  Used Avail Use% Mounted on
/cow                         overlayfs  3.9G   16M  3.9G   1% /
udev                         devtmpfs   3.9G   12K  3.9G   1% /dev
tmpfs                        tmpfs      791M  1.2M  790M   1% /run
/dev/sdb1                    vfat       960M  619M  342M  65% /cdrom
/dev/loop0                   squashfs   549M  549M     0 100% /rofs
none                         tmpfs      4.0K     0  4.0K   0% /sys/fs/cgroup
tmpfs                        tmpfs      3.9G   24K  3.9G   1% /tmp
none                         tmpfs      5.0M     0  5.0M   0% /run/lock
none                         tmpfs      3.9G     0  3.9G   0% /run/shm
none                         tmpfs      100M   16K  100M   1% /run/user
/dev/sda1                    ext2       236M  225M     0 100% /mnt/boot-sav/sda1
/dev/mapper/kubuntu--vg-root ext4       212G   30G  172G  15% /mnt/boot-sav/mapper/kubuntu--vg-root

Wenn ich Josef richtig verstehe sollte ich prüfen, ob es mehrere vmlinuz* und initrd* auf der Platte gibt.

ich habe dazu folgendes zusammen gestümpert:
Code: 
lubuntu@lubuntu:/$ sudo mount -t ext2 /dev/sda1 /mnt/boot-sav/sda1
lubuntu@lubuntu:/$ cd /mnt/boot-sav/sda1/
lubuntu@lubuntu:/mnt/boot-sav/sda1$ ls -lp
total 220566
-rw-r--r-- 1 root root  1268815 Apr 17  2015 abi-3.19.0-15-generic
-rw-r--r-- 1 root root  1269284 Mai 19  2015 abi-3.19.0-18-generic
-rw-r--r-- 1 root root  1269462 Mai 29  2015 abi-3.19.0-20-generic
-rw-r--r-- 1 root root  1269462 Jun 14 19:44 abi-3.19.0-21-generic
-rw-r--r-- 1 root root  1270417 Jul 24 23:35 abi-3.19.0-25-generic
-rw-r--r-- 1 root root  1271689 Okt 21 11:54 abi-3.19.0-32-generic
-rw-r--r-- 1 root root   177656 Apr 17  2015 config-3.19.0-15-generic
-rw-r--r-- 1 root root   177700 Mai 19  2015 config-3.19.0-18-generic
-rw-r--r-- 1 root root   177700 Mai 29  2015 config-3.19.0-20-generic
-rw-r--r-- 1 root root   177700 Jun 14 19:44 config-3.19.0-21-generic
-rw-r--r-- 1 root root   177771 Jul 24 23:35 config-3.19.0-25-generic
-rw-r--r-- 1 root root   177782 Okt 21 11:54 config-3.19.0-32-generic
drwxr-xr-x 5 root root     1024 Nov 11 15:41 grub/
-rw-r--r-- 1 root root 30861158 Mai 25  2015 initrd.img-3.19.0-15-generic
-rw-r--r-- 1 root root 30864964 Jun 14 14:45 initrd.img-3.19.0-18-generic
-rw-r--r-- 1 root root 30865915 Jun 14 14:47 initrd.img-3.19.0-20-generic
-rw-r--r-- 1 root root 30865311 Jun 17 19:15 initrd.img-3.19.0-21-generic
-rw-r--r-- 1 root root 30872082 Jul 31 19:56 initrd.img-3.19.0-25-generic
drwx------ 2 root root    12288 Mai 23  2015 lost+found/
-rw-r--r-- 1 root root   164216 Mär  6  2015 memtest86+.bin
-rw-r--r-- 1 root root   165892 Mär  6  2015 memtest86+.elf
-rw-r--r-- 1 root root   166396 Mär  6  2015 memtest86+_multiboot.bin
-rw------- 1 root root  3615358 Apr 17  2015 System.map-3.19.0-15-generic
-rw------- 1 root root  3616263 Mai 19  2015 System.map-3.19.0-18-generic
-rw------- 1 root root  3617303 Mai 29  2015 System.map-3.19.0-20-generic
-rw------- 1 root root  3617303 Jun 14 19:44 System.map-3.19.0-21-generic
-rw------- 1 root root  3617653 Jul 24 23:35 System.map-3.19.0-25-generic
-rw------- 1 root root  3622220 Okt 21 11:54 System.map-3.19.0-32-generic
-rw-r--r-- 1 root root  6611584 Mai 23  2015 vmlinuz-3.19.0-15-generic
-rw------- 1 root root  6614144 Mai 19  2015 vmlinuz-3.19.0-18-generic
-rw------- 1 root root  6616960 Mai 29  2015 vmlinuz-3.19.0-20-generic
-rw------- 1 root root  6617408 Jun 14 19:44 vmlinuz-3.19.0-21-generic
-rw------- 1 root root  6616704 Jul 24 23:35 vmlinuz-3.19.0-25-generic
-rw------- 1 root root  6623936 Okt 21 11:54 vmlinuz-3.19.0-32-generic

Es gibt also mehrere initrd einträge und auch mehrere Kernels. Wie soll ich weiter vorgehen? (was kann ich löschen, und vor allem wie?)

Sobald die partition wieder genug platz hat, kann ich wohl Boot-Repair nutzen um das System wieder zu reparieren. Boot-Repair würde folgendes tun wollen:
Code: 
sudo chroot "/mnt/boot-sav/mapper/kubuntu--vg-root" dpkg --configure -a
sudo chroot "/mnt/boot-sav/mapper/kubuntu--vg-root" apt-get install -fy
sudo chroot "/mnt/boot-sav/mapper/kubuntu--vg-root" apt-get install -y --force-yes dmraid
sudo chroot "/mnt/boot-sav/mapper/kubuntu--vg-root" dmraid -ay
sudo chroot "/mnt/boot-sav/mapper/kubuntu--vg-root" apt-get install -y --force-yes lvm2
sudo chroot "/mnt/boot-sav/mapper/kubuntu--vg-root" apt-get purge -y --force-yes grub*-common shim-signed linux-signed*
 
S

spoensche

Moderator
Teammitglied
Flash schrieb:
Code: 
kernel panic-not syncing: VFS: unable to mount root fs on unknown block(0,0)
Diese Meldung sagt, dass der Kernel sein RootFS nicht mounten kann, weil er das Blockdevice block(0,0) nicht findet bzw. nicht kennt. Es hat also nichts mit der vollen /boot Partition zu tun. Die Kernel kannst du später mit dem Paketmanager löschen.

Wenn du mit einem Live-System bootest und die /boot Partition gemountet hast, dann poste mal bitte den Inhalt der grub.cfg.
Zum Vergrößern anklicken....
Zum Vergrößern anklicken....
 
J

josef-wien

Ultimate Guru
Die initrd zum Kernel 3.19.0-32 ist nicht fehlerhaft, sie ist überhaupt nicht vorhanden, und ohne passende initrd kann der Kernel die Systempartition nicht finden. (Herzlichen Glückwunsch an die *buntu-Entwickler, die es nicht stört, wenn keine initrd erzeugt werden konnte, und sogar Menü-Einträge ohne initrd zusammenbasteln.)

Flash schrieb:
Boot-Repair würde folgendes tun wollen:
Zum Vergrößern anklicken....
Und wo wird da eine initrd erzeugt?

josef-wien schrieb:
was wiederum zur Frage führt, warum Du nicht einen davon im Boot-Menü auswählst und startest.
Zum Vergrößern anklicken....
 
OP
F

Flash

Member
oh mann..... josef hat natürlich recht.
Ich hab die anderen Kernels die sich hinter "Ubuntu with Advanced Options" verbergen, gar nicht wahrgenommen....

Ich kann also den nächst älteren Kernel laden.

Ich habe nun mit
Code: 
sudo apt-get purge linux-image-3.19.0-15-generic
versucht einen Kernel, zu löschen. Ich habe das auch mit linux-image-extra und linux-image jeweils mit der Versionsnummer -3.19.0-15-generic gemacht.

ich habe am Ende im lpkg gecheckt und alle hatten das Flag rC.

Interessanterweise hat apt-get versucht nach jedem Purge den letzten (gescheiterten) Kernelinstallationsversucht fortzusatzen (3.19.0-32), scheiterte jedoch wie bisher an "no space left on device". Also ging ich davon aus, dass ein Neustart mich vorwärts bringt und den Speicherplatz final freigibt.

Das scheint auch funktioniert zu haben. Denn ich kam wieder ins System. Via uname -r konnte ich zeigen, dass 3.19.0-32 gestartet ist.

Was allerdings seltsam ist, ist der bootvorgang selbst. Es wird kein Grub angezeigt sondern Kubuntu bootet direkt.
Zwischenzeitlich flackern Konsolenausgaben mit seltsamer Bildschirmauflösung auf. Was muss ich machen, dass Grub wieder auftaucht und mir wie vorher alle Bootoptionen anzeigt?
 
OP
F

Flash

Member
Gehe ich recht in der Annahme, dass
Code: 
sudo grub-install /dev/sda
Grub repariert und wieder herstellt?
Ich frage weil ich nicht versehentlich den nächsten Schaden anrichten will.

/dev/sda habe ich abgeleitet aus
1. der Partitionsliste die ich oben gepostet hatte und wo sda1 die boot partition sein soll (die überfüllt war)
2. diesem Artikel der darauf hinweist keine Partitionsnummer zu verwenden.
 
OP
F

Flash

Member
Ok. Ich hab Boot-Repair benutzt. Das System ist ja dazu da den Bootloader zu reparieren. Der Wizard hat mich durch die Neuinstallation geführt und jetzt läuft alles wieder wie es soll.

Thread kann geschlossen werden.

Danke nochmal an die Helfer.Im ubuntuforum hätte ich noch 3 Wochen warten können.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben