Fedora 20 Pós-atualização: / A partição de inicialização está quase cheia

0

Eu recentemente atualizei uma das minhas caixas do F18 para o F20, o que foi muito bom (usando fedup). No entanto, agora minha partição / boot está quase cheia:

/dev/sda2                477M  436M   12M  98% /boot

O conteúdo específico do FC18 pode ser visto abaixo:

[root@local-dev boot]# ls -hal | grep fc18
root root 129K Dec  2 14:35 config-3.11.10-100.fc18.x86_64
root root 129K Dec  2 14:23 config-3.11.10-100.fc18.x86_64.debug
root root 129K Nov  4 09:14 config-3.11.7-100.fc18.x86_64
root root 129K Nov  4 09:05 config-3.11.7-100.fc18.x86_64.debug
root root 129K Nov 20 15:29 config-3.11.9-100.fc18.x86_64
root root 129K Nov 20 15:17 config-3.11.9-100.fc18.x86_64.debug
root root  36M Dec 13 18:23 initramfs-3.11.10-100.fc18.x86_64.debug.img
root root  35M Dec 13 18:25 initramfs-3.11.10-100.fc18.x86_64.img
root root 7.7M Dec 13 18:28 initramfs-3.11.10-100.fc18.x86_64kdump.img
root root  36M Nov 13 15:24 initramfs-3.11.7-100.fc18.x86_64.debug.img
root root  35M Nov 13 15:23 initramfs-3.11.7-100.fc18.x86_64.img
root root 7.7M Nov 13 15:36 initramfs-3.11.7-100.fc18.x86_64kdump.img
root root  36M Dec  1 20:35 initramfs-3.11.9-100.fc18.x86_64.debug.img
root root  35M Dec  1 20:33 initramfs-3.11.9-100.fc18.x86_64.img
root root 7.7M Dec  1 20:55 initramfs-3.11.9-100.fc18.x86_64kdump.img
root root 2.6M Dec  2 14:35 System.map-3.11.10-100.fc18.x86_64
root root 2.8M Dec  2 14:23 System.map-3.11.10-100.fc18.x86_64.debug
root root 2.6M Nov  4 09:14 System.map-3.11.7-100.fc18.x86_64
root root 2.8M Nov  4 09:05 System.map-3.11.7-100.fc18.x86_64.debug
root root 2.6M Nov 20 15:29 System.map-3.11.9-100.fc18.x86_64
root root 2.8M Nov 20 15:17 System.map-3.11.9-100.fc18.x86_64.debug
root root 5.0M Dec  2 14:35 vmlinuz-3.11.10-100.fc18.x86_64
root root 5.5M Dec  2 14:23 vmlinuz-3.11.10-100.fc18.x86_64.debug
root root  174 Dec  2 14:23 .vmlinuz-3.11.10-100.fc18.x86_64.debug.hmac
root root  168 Dec  2 14:35 .vmlinuz-3.11.10-100.fc18.x86_64.hmac
root root 5.0M Nov  4 09:14 vmlinuz-3.11.7-100.fc18.x86_64
root root 5.5M Nov  4 09:05 vmlinuz-3.11.7-100.fc18.x86_64.debug
root root  173 Nov  4 09:05 .vmlinuz-3.11.7-100.fc18.x86_64.debug.hmac
root root  167 Nov  4 09:14 .vmlinuz-3.11.7-100.fc18.x86_64.hmac
root root 5.0M Nov 20 15:29 vmlinuz-3.11.9-100.fc18.x86_64
root root 5.5M Nov 20 15:17 vmlinuz-3.11.9-100.fc18.x86_64.debug
root root  173 Nov 20 15:17 .vmlinuz-3.11.9-100.fc18.x86_64.debug.hmac
root root  167 Nov 20 15:29 .vmlinuz-3.11.9-100.fc18.x86_64.hmac

Estou muito confiante, mas ainda não consegui encontrar uma resposta direta no Google, mas posso excluir esses arquivos com segurança agora, correto?

Obrigado pelo seu tempo e insight.

Atenciosamente,

    
por DroBuddy 06.05.2014 / 05:56

1 resposta

0

A solução simples (independente de distribuição Linux) é cd /boot && ls -hl . Leia a saída e remova todos os arquivos antigos do kernel. No meu caso, o kernel mais recente era o 3.14. , então eu sudo rm config-3.11* e removi os outros arquivos do kernel 3.11 . Isso liberou cerca de 280 MB da partição / boot.

Agora ela está trabalhando lindamente novamente.

Se você estiver rodando uma distribuição baseada na Debian, você precisará procurar os arquivos linux-image* em / boot, mas no CentOS / Fedora / RHEL os arquivos a serem removidos são os seguintes:

Nota: Use uname -a para descobrir sua versão atual do kerenl (por exemplo, saída: Linux local-dev 3.14.2-200.fc20.x86_64 #1 SMP Mon Apr 28 14:40:57 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux , então minha versão atual do kernel é 3.14.2).

sudo rm vmlinuz-3.{old kerenel version}*

sudo rm config-3.{old kernel version}*

sudo rm System.map-3{old kernel version}.*

E, quando você reiniciar, voila está pronto!

AVISO: Modificar a partição / boot pode facilmente abrir o seu sistema. Prossiga com cautela e use apenas os comandos acima se você souber o que eles fazem e o que você está fazendo quando os executa!

    
por 06.05.2014 / 18:48