Amplia uma imagem do sistema de arquivos

Question

Eu estava fazendo dpkg --configure -a no meu Debian wheezy. E recebi este erro:

dpkg --configure -a
dpkg: failed to write status record about 'libcairo2' to '/var/lib/dpkg/status': No space left on device

Eu sou chrooted em um arquivo .img . O que posso fazer?

    

Answer 1

Para fazer isso corretamente, você precisa:

1. Primeiro, expanda o arquivo .img .
2. Em seguida, expanda o sistema de arquivos dentro.

A melhor maneira de fazer a primeira coisa é com dd . Por alguma razão, algumas pessoas atribuem um tipo de mistério à maneira como o dd funciona, mas realmente não existe nenhum. Por exemplo, para acrescentar um buraco ao final do seu arquivo .img :

dd bs=1kx1k seek=100 of=.img </dev/null

Em qualquer sistema POSIX que irá truncar o arquivo para 100MiBs. Em um sistema GNU, o 1kx1k bit pode ser reduzido para apenas M . dd procura 100MiBs no arquivo, encontra EOF em sua primeira leitura e fecha o arquivo. É uma única ação, e não requer leituras (além da primeira vazia) ou escreve - é muito quase atômica.

Se o arquivo era de 50 MiBs antes, agora será alocado 50 MiBs mais. Se o arquivo foi 150MiBs antes, isso vai cortar os últimos 50 MiBs da cauda. Em um sistema de arquivos que entende arquivos esparsos , o arquivo anexado hole não usará espaço em disco, e usará apenas o que for necessário para preenchê-lo.

Outras maneiras de fazer o mesmo em alguns sistemas:

fallocate -l100M .img
truncate -s100M .img

... ambos os comandos farão a mesma coisa dd . Eu recomendo dd porque nenhuma dessas ferramentas é portável, onde o comportamento de dd é POSIX-spec ' d , e assim que você aprender a usar o disco-destruidor corretamente, nenhum disco nunca mais ousará para ficar no seu caminho.

Se você está apenas adicionando ao seu .img , você pode fazer a coisa acima, montada ou não (embora se você tirasse um pouco de %).img pode não funcionar como esperado) , mas você provavelmente precisará umount .img primeiro para redimensionar seu sistema de arquivos constituinte, e assim pode também. Você não precisa -d estroy the loop device, no entanto.

Como você lida com a segunda coisa depende se .img está particionado ou não. Se não for, como eu acho que é o caso baseado em seus comentários em outro lugar, então você só precisa abordar o fs por seu tipo. Para um arquivo ext[234] .img , você deve usar resize2fs e acabar com isso. Para outros, você desejará ver as ferramentas de espaço do usuário relevantes e suas man páginas.

Se .img for particionado, pode ser mais complicado. Em tais casos, o modo como você lida com a situação dependerá do tipo de tabela de partição usada (seja GPT vs MBR vs híbrido-MBR) , seja a última partição na tabela de partições do arquivo e muito mais. Hesito em arriscar quaisquer detalhes aqui sem mais informações: se você precisar de conselhos sobre como lidar com um .img particionado, por favor me avise com mais detalhes e eu ofereço o que puder.

    

Answer 2

Se o sistema de arquivos chroot estiver cheio, você poderá ampliar o arquivo de imagem.

Por exemplo usando dd conv=notrunc oflag=append bs=1M count=X of=file.img . Seja muito, muito cuidado :). Ou seja se você puder desmontar o chroot e fazer o backup do arquivo .img, porque isso seria altamente recomendado.

Em seguida, redimensione o sistema de arquivos, para que ele possa usar o espaço extra. Para um sistema de arquivos ext4, o comando seria resize2fs . A manpage sugere que você terá que executar o último comando em um dispositivo de loop, não no arquivo:

# losetup -f file.img
# losetup -l
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
/dev/loop0         0      0         0  0 /home/alan/file.img
# resize2fs /dev/loop0
...
# losetup -d /dev/loop0

O comando será diferente para sistemas de arquivos diferentes, por exemplo btrfs filesystem resize /dev/loop0 max ou xfs_growfs /test.img/is/mounted/here .