Perché la mia partizione di root viene visualizzata come piena in gparted?


1

Conosco un po 'di file system ma non molto. Ho solo un'idea generale di cosa sono le LVM, anche se apparentemente è quello che sto usando come partizione di root.

Ho un singolo disco rigido da 1TB nel mio computer. Corro Ubuntu 14.04.

Sono andato a installare alcuni aggiornamenti oggi e sono stato informato che non ho abbastanza spazio /boot partizione.

Sono andato a liberare un po 'di spazio con il gparted GUI da un CD live, ma ho notato che il mio file system di root è visualizzato come pieno:

enter image description here

Secondo df però:

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

Che cosa è successo con questo? Perché lo fa gparted pensi che la mia partizione sia piena?


Ho anche una domanda aggiuntiva. Qualcuno sa cosa è la differenza tra il /boot/efi e il /boot le partizioni sono e se ho bisogno di entrambi?


Se tutto ciò che stai cercando di fare è fare spazio /boot, dovresti fare una nuova domanda con l'output di ls -lR /boot.
Daniel B

Risposte:


2

Tra di loro, AFH e Romeo Ninov hanno fondamentalmente la risposta, ma devono essere raggruppati insieme.

Il tuo /boot la partizione è separata perché è essenzialmente necessaria per l'uso di LVM (che non è un filesystem, ma un contenitore per i volumi logici, che a loro volta contengono i filesystem). Una partizione LVM può essere ridimensionata; vedere Qui per una descrizione di ciò che è richiesto. Non sono sicuro che ci andrei, anche se ....

Segnala che il tuo processo di aggiornamento si sta lamentando dello spazio insufficiente nel tuo MiB 244 /boot partizione, ma quella partizione è attualmente utilizzata solo al 52%. Distribuzioni che di routine creano separatamente /boot le partizioni di solito le rendono grandi il doppio del tuo, ma è comunque strano che i tuoi aggiornamenti cerchino di raddoppiare quasi la quantità di spazio utilizzato lì. L'installazione di Ubuntu 14.04 su cui sto scrivendo usa solo 80 MiB /boot. Potresti quindi voler controllare cosa c'è. genere ls -lh /boot. Ecco cosa vedo sul mio sistema:

$ 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

Questo è abbastanza tipico (anche se con un po 'più di quello che alcuni sistemi avrebbero). Se vedi più file di tipi diversi da quelli che ho mostrato qui, è possibile che qualcosa abbia aggiunto qualcosa di nuovo ed estraneo, e tali file potrebbero essere candidati alla rimozione - ma se non li capisci, chiedi consiglio prima cancellandoli.

Un'altra cosa da controllare sono i kernel esterni. Questi sono i file con i nomi che iniziano con vmlinuz. (Sono accoppiati con initrd.img file, per i quali AFH ha effettuato la ricerca.) Il mio esempio mostra quattro file del kernel, ma queste sono in realtà delle versioni firmate e non firmate di soli due kernel. Se vedi più di tre versioni del kernel (ognuna delle quali potrebbe essere disponibile in formato firmato e senza segno), prova il seguente comando:

sudo apt-get autoremove

Questo comando dovrebbe rimuovere tutti gli originali tranne due e il kernel più recente dal tuo sistema, che dovrebbe liberare spazio.

Se è necessario ridimensionare le partizioni, potrebbe essere più sicuro ridurre la partizione del sistema EFI (ESP; /dev/sda1 nel tuo caso) ed espandere /boot in quello spazio piuttosto che fare confusione con la configurazione LVM. Non consiglierei di ridimensionare di più di circa 200 MiB, e dovresti decisamente backup entrambe le partizioni su supporti rimovibili prima di procedere, perché entrambe le partizioni sono fondamentali per l'avvio, quindi se qualcosa va storto, sarai nei guai. Inoltre, tieni presente che alcuni EFI possono essere pignoli riguardo ai file system FAT sui loro ESP. Alcuni (per lo più vecchi EFI, da prima del 2012) reagiranno male a un ESP FAT32 che è inferiore a 512 MiB. Pertanto, se provi a ridimensionare in questo modo, inizia a ridurre l'ESP, quindi esegui un avvio di prova. Se è possibile avviare, espandere /boot nello spazio liberato e provare di nuovo l'avvio. In caso di problemi dopo il restringimento dell'ESP, utilizzare un sistema di emergenza per espanderlo nuovamente alla sua dimensione originale.


2

Trovo i risultati da gparted e df differiscono, ma non fino a questo punto: ho il sospetto gparted sta interpretando male il tuo lvm2 contenuto.

Il tuo problema è questo /boot è montato su un'unità separata da 0,25 GB, e questo è ciò che sta esaurendo lo spazio. Non sono sicuro di come sei entrato in questo stato, o come uscirne: forse grub non si avvia molto bene da lvm2 file-system.

La cosa più semplice da fare prima è rimuovere tutti i kernel tranne il corrente e il precedente (non avrai mai bisogno di più di un kernel di back-up). Genere:

ls -l /boot/initrd*
uname -a

Questo mostrerà tutte le versioni del kernel installate e il tuo kernel in esecuzione. Quindi è necessario rimuovere tutti tranne gli ultimi due. Preferisco usare synaptic per questo: selezionare Installed e nella casella di ricerca impostare a turno la parte numerica di ciascuna delle versioni che si desidera rimuovere, quindi digitare Ctrl-a per selezionare tutto e fare clic con il tasto destro e selezionare Mark for Complete Removal (assicurandoti assolutamente di non rimuovere la tua versione attuale!). Dopo aver esaminato tutti i kernel da rimuovere, fare clic su Apply.

Su Ubuntu 15.04 con due kernel installati, my /boot la directory ha poco più di 120 MB di spazio, quindi dovresti avere spazio per due rilasci mentre installi un terzo sul tuo /dev/sda2 (e ricorda di rimuovere la versione più vecchia ogni volta che lo fai).

Se questo non risolve il tuo problema, allora hai due opzioni: -

  1. Aumentare le dimensioni di /dev/sda2 spostando il confine tra questo e /dev/sda3.
  2. Cerca in internet per grub lvm2e segui il consiglio lì.

Per rispondere alla tua domanda ausiliaria, /boot è dove risiedono i file di avvio del kernel, e normalmente si trova nello stesso file system di /, ma grub ha bisogno di identificare dove risiedono i file di boot EFI, e questo viene fatto montando la partizione di boot EFI in /boot/efi. In altre parole, /boot/efi è il punto di montaggio per un file system separato, ma è inusuale per /boot stesso per essere un punto di mount. Sono necessari entrambi, a meno che non si stia effettuando l'avvio utilizzando un BIOS legacy.


1

Perché sullo schermo vedi PV (physical volume), non filesystem. E l'intero pv è assegnato a vg. Esecuzione

df

vedrai lo stato del filesystem


Ahhh, come posso cambiare questo in modo da poter ridimensionare la partizione?
Luke

Si dovrebbe usare qualche distribuzione live e senza montare questo lv si dovrebbe ridurre il filesystem, quindi ridimensionare il lv. E poi sarai in grado di creare nuovi volumi logici. Se si desidera ridimensionare sda1 ho paura che questo non è possibile (facile) :(
Romeo Ninov

Per chiarire: così posso ridimensionare l'LV su quel PV e fare un altro LV insieme se lo volessi, ma non posso ridimensionare il volume fisico stesso. Quindi non posso fare / boot più grande. È questo che stai dicendo? posso migrare / avviare quindi è esso stesso un LV all'interno di quel PV? o deve essere su una partizione completamente separata?
Luke

1
In effetti, puoi ridimensionare i PV, usando pvresize. Tuttavia, questo sposta solo la fine della partizione. Lo spazio libero risultante non può essere utilizzato per l'esistente /boot partizione.
Daniel B

1
Certo, potrebbe essere spostato, ma spostare le partizioni è pericoloso, perché implica lo spostamento di tutti i dati. Ci vuole anche molto tempo.
Daniel B
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.