Conheço um pouco sobre sistemas de arquivos, mas não muito. Eu só tenho uma idéia geral do que são LVMs, embora aparentemente seja isso que estou usando como minha partição raiz.
Eu tenho um único disco rígido de 1 TB no meu computador. Eu executo o Ubuntu 14.04.
Fui instalar algumas atualizações hoje e fui informado que não tenho espaço suficiente por /bootpartição.
Fui liberar espaço com a gpartedGUI de um live CD, mas percebi que meu sistema de arquivos raiz é exibido como cheio:
De acordo com dfno 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 gpartedacha que minha partição está cheia?
Eu também tenho uma pergunta adicional. Alguém sabe qual é a diferença entre /boot/efias /bootpartições e se eu preciso de ambas?
Responder1
Entre eles, AFH e Romeo Ninov basicamente têm a resposta, mas ela precisa ser agrupada.
Sua /bootpartição é separada porque é essencialmente necessária 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; veraquipara obter um esboço do que é necessário. Mas não tenho certeza se iria para lá....
Você relata que seu processo de atualização está reclamando de espaço insuficiente em sua /bootpartição de 244 MiB, mas atualmente essa partição é usada apenas 52%. Distribuições que rotineiramente criam /bootpartições separadas geralmente as tornam duas vezes maiores que as suas, mas ainda é estranho que suas atualizações tentem quase dobrar a quantidade de espaço usado ali. A instalação do Ubuntu 14.04 na qual estou digitando usa apenas 80 MiB no /boot. Portanto, você pode querer verificar o que está lá. Tipo ls -lh /boot. Aqui está o que 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 estranho, e esses arquivos podem ser candidatos à remoção - mas se você não os entender, peça conselhos antes deletando-os.
Outra coisa a verificar são os kernels estranhos. Estes são os arquivos com nomes que começam com vmlinuz. (Eles estão emparelhados com initrd.imgarquivos, pelos quais o AFH fez você pesquisar.) Meu próprio exemplo mostra quatro arquivos de kernel, mas na verdade são versões assinadas e não assinadas de apenas dois kernels. Se você vir mais de três versões do kernel (cada uma delas pode estar disponível no formato assinado e não assinado), tente o seguinte comando:
sudo apt-get autoremove
Este comando deve remover todos os kernels do seu sistema, exceto o original e os dois mais recentes, o que deve liberar algum espaço.
Se você precisar redimensionar partições, pode ser mais seguro reduzir a partição do sistema EFI (ESP; /dev/sda1no seu caso) e expandir /bootpara esse espaço do que mexer na configuração do LVM. Eu não recomendaria redimensionar mais de 200 MiB, e você deveriadefinitivamentecópia de segurançaambas as partiçõesem uma mídia removível antes de prosseguir, porque ambas as partições são essenciais para a inicialização, portanto, se algo der errado, você terá sérios problemas. Além disso, esteja ciente de que alguns EFIs podem ser meticulosos com os sistemas de arquivos FAT em seus ESPs. Alguns (principalmente EFIs mais antigos, anteriores a 2012) reagirão mal a um ESP FAT32 menor que 512 MiB. Assim, se você tentar redimensionar dessa forma, comece diminuindo o ESP e depois faça um teste de inicialização. Se você conseguir inicializar, expanda /bootpara o espaço liberado e tente inicializar novamente. Se você tiver problemas após reduzir o ESP, use um sistema de emergência para expandi-lo de volta ao tamanho original.
Responder2
Acho que os resultados gparteddiferem df, mas não neste ponto: suspeito gpartedque esteja interpretando mal o seu lvm2conteúdo.
Seu problema é que ele /bootestá montado em uma unidade separada de 0,25 GB e é isso que está ficando sem espaço. Não tenho certeza de como você chegou a esse estado ou como sair dele: talvez grubnão inicialize muito bem a partir de lvm2sistemas de arquivos.
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
Isso mostrará todas as versões do kernel instaladas e o kernel em execução. Então você precisa remover todos, exceto os dois últimos. Prefiro usar synapticpara isso: selecione Installede na caixa de pesquisa defina por sua vez a parte numérica de cada um dos lançamentos que deseja remover, digite Ctrl-apara selecionar todos, clique com o botão direito e selecione Mark for Complete Removal(tendo certeza absoluta 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 /bootdiretório tem pouco mais de 120 MB, então você deve ter espaço para duas versões enquanto instala uma terceira no seu /dev/sda2(e lembre-se de remover a versão mais antiga toda vez que fizer isso).
Se isso não resolver o seu problema, você tem duas opções: –
- Aumente o tamanho
/dev/sda2movendo o limite entre ele e/dev/sda3. - Pesquise na internet
grub lvm2e siga os conselhos lá.
Para responder à sua pergunta auxiliar, /booté onde residem os arquivos de inicialização do kernel, e isso normalmente está dentro do mesmo sistema de arquivos que /, mas grubprecisa identificar onde residem os arquivos de inicialização EFI, e isso é feito montando a partição de inicialização EFI em /boot/efi. Em outras palavras, /boot/efié o ponto de montagem para um sistema de arquivos separado, mas é incomum /bootser um ponto de montagem. Você precisa de ambos, a menos que esteja inicializando usando um BIOS legado.
Responder3
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