Por que minha partição raiz está sendo exibida como cheia no gparted?

Question

Eu sei um pouco sobre sistemas de arquivos, mas não muito. Eu só tenho uma idéia geral do que LVMs são, embora aparentemente é o que eu estou usando como minha partição raiz.

Eu tenho um único disco rígido de 1 TB no meu computador. Eu corro o Ubuntu 14.04.

Eu fui instalar algumas atualizações hoje e fui informado de que não tenho espaço suficiente na partição /boot .

Eu fui liberar algum espaço com a gparted GUI de um live CD, mas notei que meu sistema de arquivos raiz é exibido como cheio:

De acordo com df , no entanto:

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

O que há com isso? Por que gparted acha que minha partição está cheia?

Eu também tenho uma pergunta adicional. Alguém sabe saber qual é a diferença entre as partições /boot/efi e /boot e se eu precisar de ambas?

    

Answer 1

Entre eles, AFH e Romeo Ninov basicamente têm a resposta, mas precisam ser agrupados juntos.

Sua partição /boot é separada porque isso é essencialmente necessário para o uso do LVM (que não é um sistema de arquivos, mas um contêiner para volumes lógicos, que contêm sistemas de arquivos). Uma partição LVM pode ser redimensionada; veja aqui para um resumo do que é necessário. Eu não tenho certeza se eu iria lá, embora ....

Você relata que o processo de atualização está reclamando de espaço insuficiente na sua partição 244 MiB /boot , mas essa partição está atualmente apenas 52% usada. Distribuições que rotineiramente criam partições /boot separadas geralmente as tornam duas vezes mais grandes que as suas, mas ainda assim é estranho que suas atualizações tentem quase dobrar a quantidade de espaço usada lá. A instalação do Ubuntu 14.04 na qual estou digitando usa apenas 80 MiB em /boot . Você pode, portanto, querer verificar o que está lá. Digite ls -lh /boot . Aqui está o que eu vejo no meu 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

Isso é bastante típico (embora com um pouco mais do que alguns sistemas teriam). Se você vir mais arquivos de tipos diferentes dos que mostrei aqui, é possível que algo tenha adicionado algo novo e irrelevante, e esses arquivos podem ser candidatos à remoção - mas se você não os entender, peça conselhos antes excluindo-os.

Outra coisa para verificar é kernels estranhos. Estes são os arquivos com nomes que começam com vmlinuz . (Eles estão emparelhados com initrd.img files, para os quais AFH teve sua pesquisa.) Meu próprio exemplo mostra quatro arquivos de kernel, mas estes são realmente assinados e versões não assinadas de apenas dois kernels. Se você ver mais de três versões do kernel (cada uma das quais pode estar disponível no formulário assinado e não assinado), tente o seguinte comando:

sudo apt-get autoremove

Este comando deve remover todos os kernels originais, exceto os dois mais recentes, do seu sistema, o que deve liberar algum espaço.

Se você tiver que redimensionar partições, pode ser mais seguro reduzir a partição do sistema EFI (ESP; /dev/sda1 no seu caso) e expandir /boot nesse espaço do que mexer com a configuração do LVM. Eu não recomendaria redimensionar em mais de 200 MiB, e você deve definitivamente fazer backup ambas as partições em mídia removível antes de prosseguir, porque ambas as partições são críticas para a inicialização, Então, se algo der errado, você estará em apuros. Além disso, esteja ciente de que algumas EFIs podem ser complicadas sobre os sistemas de arquivos FAT em seus ESPs. Alguns (EFIs mais antigos, antes de 2012) reagirão mal a um FAT32 ESP menor que 512 MiB. Assim, se você tentar redimensionar dessa maneira, comece diminuindo o ESP e faça uma inicialização de teste. Se você puder inicializar, expanda /boot no espaço liberado e tente inicializar novamente. Se você tiver problemas após encolher o ESP, use um sistema de emergência para expandi-lo de volta ao tamanho original.

    

Answer 2

Acho que os resultados de gparted e df diferem, mas não a esse ponto: suspeito que gparted esteja interpretando mal seu conteúdo lvm2 .

Seu problema é que /boot é montado em uma unidade separada de 0,25 GB e isso é o que está ficando sem espaço. Não tenho certeza de como você chegou a esse estado, ou como sair dele: talvez grub não inicialize muito bem de lvm2 file-systems.

A coisa mais simples a fazer primeiro é remover todos os kernels, exceto o atual e o anterior (você nunca precisará de mais de um kernel de backup). Tipo:

ls -l /boot/initrd*
uname -a

Isto mostrará todas as versões do kernel instaladas e seu kernel em execução. Então você precisa remover todos, mas os dois últimos. Prefiro usar synaptic para isso: selecione Installed e na caixa de pesquisa, por sua vez, a parte numérica de cada um dos lançamentos que você deseja remover, digite Ctrl-a para selecionar todos e clique com o botão direito e selecione Mark for Complete Removal (certificando-se de não remover sua versão atual!). Depois de passar por cada um dos kernels a serem removidos, clique em Apply .

No Ubuntu 15.04 com dois kernels instalados, meu diretório /boot tem pouco mais de 120 MB, então você deve ter espaço para dois lançamentos enquanto você instala um terceiro no seu /dev/sda2 (e lembre-se de remover o lançamento mais antigo a cada vez que você faz isso).

Se isso não resolver o seu problema, você tem duas opções: -

1. Aumente o tamanho de /dev/sda2 movendo o limite entre ele e /dev/sda3 .
2. Pesquise na internet por grub lvm2 e siga os conselhos.

Para responder à sua pergunta complementar, /boot é onde residem os arquivos de inicialização do kernel, e isso normalmente está no mesmo sistema de arquivos que / , mas grub precisa identificar onde os arquivos de inicialização EFI residem e isso é feito montando a partição de inicialização EFI em /boot/efi . Em outras palavras, /boot/efi é o ponto de montagem de um sistema de arquivos separado, mas é incomum que o próprio /boot seja um ponto de montagem. Você precisa de ambos, a menos que esteja inicializando usando um BIOS legado.

    

Answer 3

Porque na tela você vê PV (volume físico), não sistema de arquivos. E todo o pv é atribuído a vg. Executando

df

você verá o status do sistema de arquivos