Ich weiß ein bisschen über Dateisysteme, aber nicht sehr viel. Ich habe nur eine allgemeine Vorstellung davon, was LVMs sind, obwohl ich anscheinend genau das als meine Root-Partition verwende.
Ich habe eine einzelne 1-TB-Festplatte in meinem Computer. Ich verwende Ubuntu 14.04.
/bootAls ich heute einige Updates installieren wollte, wurde mir mitgeteilt, dass in meiner Partition nicht genügend Speicherplatz vorhanden sei .
Ich habe versucht, mithilfe der GUI einer Live-CD etwas Speicherplatz freizugeben gparted, habe jedoch festgestellt, dass mein Root-Dateisystem als voll angezeigt wird:
Laut dfjedoch:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/ubuntu--vg-root 954367812 10720604 895145040 2% /
none 4 0 4 0% /sys/fs/cgroup
udev 2995912 12 2995900 1% /dev
tmpfs 608016 1312 606704 1% /run
none 5120 0 5120 0% /run/lock
none 3040072 17312 3022760 1% /run/shm
none 102400 52 102348 1% /run/user
/dev/sda2 241965 118221 111252 52% /boot
/dev/sda1 523248 3428 519820 1% /boot/efi
tmpfs 3040072 4 3040068 1% /var/lib/polkit-1/localauthority/90-mandatory.d
Was ist hier los? Warum gparteddenkt er, meine Partition sei voll?
Ich habe noch eine weitere Frage. Weiß jemand, was der Unterschied zwischen den /boot/efiund den /bootPartitionen ist und ob ich beide brauche?
Antwort1
AFH und Romeo Ninov haben im Grunde die Antwort, aber sie müssen gebündelt werden.
Ihre /bootPartition ist separat, da dies für die Verwendung von LVM (das kein Dateisystem ist, sondern ein Container für logische Datenträger, die selbst Dateisysteme enthalten) unbedingt erforderlich ist. Die Größe einer LVM-Partition kann geändert werden; sieheHierfür einen Überblick über die Anforderungen. Ich bin mir jedoch nicht sicher, ob ich dorthin gehen würde ...
Sie melden, dass Ihr Update-Prozess über unzureichenden Speicherplatz in Ihrer 244-MiB-Partition klagt /boot, diese Partition aber derzeit nur zu 52 % genutzt wird. Distributionen, die routinemäßig separate /bootPartitionen erstellen, machen diese normalerweise etwa doppelt so groß wie Ihre, aber es ist trotzdem seltsam, dass Ihre Updates versuchen, den dort genutzten Speicherplatz fast zu verdoppeln. Die Ubuntu 14.04-Installation, auf der ich dies schreibe, nutzt nur 80 MiB auf /boot. Sie sollten daher prüfen, was dort ist. Geben Sie ein ls -lh /boot. Folgendes sehe ich auf meinem System:
$ ls -lh /boot
total 70M
-rw-r--r-- 1 root root 1.2M Feb 14 17:06 abi-3.13.0-45-generic
-rw-r--r-- 1 root root 1.2M May 4 01:09 abi-3.13.0-52-generic
-rw-r--r-- 1 root root 162K Feb 14 17:06 config-3.13.0-45-generic
-rw-r--r-- 1 root root 162K May 4 01:09 config-3.13.0-52-generic
drwxr-xr-x 10 root root 4.0K Dec 31 1969 efi
drwxr-xr-x 3 root root 1.0K May 7 11:30 extlinux
drwxr-xr-x 5 root root 1.0K Mar 12 20:08 grub
drwxr-xr-x 2 root root 1.0K Feb 14 17:06 grub.bak
-rw-r--r-- 1 root root 20M Feb 26 18:39 initrd.img-3.13.0-45-generic
-rw-r--r-- 1 root root 20M May 7 11:28 initrd.img-3.13.0-52-generic
drwx------ 2 root root 12K Feb 14 17:05 lost+found
-rw-r--r-- 1 root root 173K Feb 14 17:06 memtest86+.bin
-rw-r--r-- 1 root root 174K Feb 14 17:06 memtest86+.elf
-rw-r--r-- 1 root root 175K Feb 14 17:06 memtest86+_multiboot.bin
-rw-r--r-- 1 root root 227 Feb 14 17:06 refind_linux.conf
-rw------- 1 root root 3.3M Feb 14 17:06 System.map-3.13.0-45-generic
-rw------- 1 root root 3.3M May 4 01:09 System.map-3.13.0-52-generic
-rw------- 1 root root 5.6M Feb 14 17:06 vmlinuz-3.13.0-45-generic
-rw-r--r-- 1 root root 5.6M Feb 19 21:38 vmlinuz-3.13.0-45-generic.efi.signed
-rw------- 1 root root 5.6M May 4 01:09 vmlinuz-3.13.0-52-generic
-rw-r--r-- 1 root root 5.6M May 10 21:36 vmlinuz-3.13.0-52-generic.efi.signed
Das ist ziemlich typisch (obwohl es etwas mehr sind, als manche Systeme haben). Wenn Sie mehr Dateien unterschiedlichen Typs sehen, als ich hier gezeigt habe, ist es möglich, dass etwas Neues und Fremdes hinzugefügt wurde, und solche Dateien könnten entfernt werden – aber wenn Sie sie nicht verstehen, fragen Sie vor dem Löschen um Rat.
Eine weitere Sache, nach der Sie suchen sollten, sind überflüssige Kernel. Dies sind die Dateien, deren Namen mit beginnen vmlinuz. (Sie sind mit initrd.imgDateien gepaart, nach denen AFH Sie suchen ließ.) Mein eigenes Beispiel zeigt vier Kerneldateien, aber dies sind tatsächlich signierte und unsignierte Versionen von nur zwei Kerneln. Wenn Sie mehr als drei Kernelversionen sehen (von denen jede in signierter und unsignierter Form verfügbar sein kann), versuchen Sie den folgenden Befehl:
sudo apt-get autoremove
Dieser Befehl sollte alle Kernel außer dem ursprünglichen und den beiden aktuellsten von Ihrem System entfernen, wodurch etwas Speicherplatz freigegeben werden sollte.
Wenn Sie die Größe von Partitionen ändern müssen, ist es möglicherweise sicherer, Ihre EFI-Systempartition (ESP; /dev/sda1in Ihrem Fall) zu verkleinern und /bootin diesen Bereich zu erweitern, als Ihr LVM-Setup zu verändern. Ich würde nicht empfehlen, die Größe um mehr als etwa 200 MiB zu ändern, und Sie solltendefinitivSichernbeide Partitionenauf Wechselmedien, bevor Sie fortfahren, da beide Partitionen für das Booten wichtig sind. Wenn also etwas schief geht, stecken Sie in großen Schwierigkeiten. Beachten Sie auch, dass einige EFIs empfindlich auf die FAT-Dateisysteme auf ihren ESPs reagieren können. Einige (meist ältere EFIs von vor 2012) reagieren schlecht auf ein FAT32 ESP, das kleiner als 512 MiB ist. Wenn Sie also versuchen, die Größe auf diese Weise zu ändern, verkleinern Sie zunächst das ESP und führen Sie dann einen Teststart durch. Wenn Sie booten können, erweitern Sie es /bootin den freigegebenen Speicherplatz und versuchen Sie den Bootvorgang erneut. Wenn Sie nach dem Verkleinern des ESP Probleme haben, verwenden Sie ein Notfallsystem, um es wieder auf seine ursprüngliche Größe zu erweitern.
Antwort2
Ich finde, dass die Ergebnisse unterschiedlich ausfallen gpartedund dfabweichen, aber nicht in diesem Ausmaß: Ich vermute, gparteddass Ihre lvm2Inhalte falsch interpretiert werden.
Ihr Problem ist, dass es /bootauf einem separaten Laufwerk mit 0,25 GB gemountet ist und dort der Speicherplatz knapp wird. Ich bin mir nicht sicher, wie Sie in diesen Zustand geraten sind oder wie Sie ihn wieder verlassen können: Vielleicht grubbootet es nicht sehr gut von lvm2Dateisystemen.
Am einfachsten ist es, zunächst alle Kernel außer dem aktuellen und dem vorherigen zu entfernen (Sie werden nie mehr als einen Backup-Kernel benötigen). Geben Sie Folgendes ein:
ls -l /boot/initrd*
uname -a
Dadurch werden alle installierten Kernel-Versionen und Ihr laufender Kernel angezeigt. Dann müssen Sie alle bis auf die letzten beiden entfernen. Ich verwende synaptichierfür am liebsten: Wählen Sie aus Installedund geben Sie im Suchfeld nacheinander den numerischen Teil jeder Version ein, die Sie entfernen möchten, geben Sie dann „ Ctrl-aAlle auswählen“ ein, klicken Sie mit der rechten Maustaste und wählen Sie aus Mark for Complete Removal(achten Sie dabei unbedingt darauf, dass Sie nicht Ihre aktuelle Version entfernen!). Nachdem Sie alle zu entfernenden Kernel durchgegangen sind, klicken Sie auf Apply.
Unter Ubuntu 15.04 mit zwei installierten Kerneln ist mein /bootVerzeichnis etwas über 120 MB groß, Sie sollten also Platz für zwei Versionen haben, während Sie eine dritte auf Ihrem Computer installieren /dev/sda2(und denken Sie daran, jedes Mal die älteste Version zu entfernen, wenn Sie dies tun).
Wenn das Ihr Problem nicht löst, haben Sie zwei Möglichkeiten: -
- Erhöhen Sie die Größe von ,
/dev/sda2indem Sie die Grenze zwischen ihm und verschieben/dev/sda3. - Suchen Sie im Internet nach
grub lvm2und befolgen Sie die dort gegebenen Ratschläge.
Um Ihre Zusatzfrage zu beantworten: /bootist der Ort, an dem die Kernel-Bootdateien liegen. Normalerweise ist dies dasselbe Dateisystem wie /, aber grubes muss ermittelt werden, wo die EFI-Bootdateien liegen. Dies geschieht durch das Mounten der EFI-Bootpartition in /boot/efi. Mit anderen Worten, /boot/efiist der Mount-Punkt für ein separates Dateisystem, aber es ist ungewöhnlich, dass /bootes selbst ein Mount-Punkt ist. Sie benötigen beides, es sei denn, Sie booten mit einem älteren BIOS.
Antwort3
Denn auf dem Bildschirm sehen Sie PV (physisches Volume), nicht Dateisystem. Und das gesamte PV ist vg zugewiesen. Ausführen
df
Sie sehen den Status des Dateisystems