Enlarge a filesystem image

I was doing dpkg --configure -a in my Debian wheezy.
And got this error:

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

I am chrooted into a .img file. What can I do?

Asked By: JohnnyBoy

||

If the chroot filesystem is full, you can enlarge the image file.

E.g. using dd conv=notrunc oflag=append bs=1M count=X of=file.img. Be very, very careful :). It is strongly recommended to unmount the chroot and backup the .img file first, if you can.

Then resize the filesystem, so it can use the extra space. For an ext4 filesystem the command would be resize2fs. The manpage suggests you’ll have to run that last command on a loop device, not the file:

# 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

Command will be different for different filesystems, e.g. btrfs filesystem resize /dev/loop0 max, or xfs_growfs /test.img/is/mounted/here.

Answered By: sourcejedi

To do this correctly you need to:

  1. First expand the .img file.
  2. Next expand the filesystem within.

The best way to do the first thing is with dd. For whatever reason some people attribute a kind of mystery to the way dd works, but there really is none. For example, to append a hole to the end of your .img file:

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

On any POSIX system that will truncate the file to 100MiBs. On a GNU system the 1kx1k bit can be shortened to just M. dd seeks 100MiBs into the file, encounters EOF on its first read, and closes the file. It is a single action, and requires no reads (beyond the first empty one) or writes – it’s very nearly atomic.

If the file was 50MiBs before, it will now be allocated 50MiBs more. If the file was 150MiBs before, that will chop the last 50MiBs off the tail. On a filesystem which understands sparse files, the appended file hole will use no disk-space, really, and will only use what is necessary as you fill it.

Other ways to do the same on some systems:

fallocate -l100M .img
truncate -s100M .img

…both of those commands will do the exact same thing dd will. I recommend dd because neither of those tools is portable where dd‘s behavior is POSIX-spec’d, and once you learn how to use the disk-destroyer properly, no disk will ever again dare to stand in your way.

If you are merely adding to your .img you can do the above thing whether or not it is mounted (though if you were to take some of a mounted .img away it may not work as expected), but you will very likely need to umount.img first to resize its constituent filesystem anyway, and so might as well. You do not need to -destroy the loop device, though.

How you handle the second thing depends on whether .img is partitioned or not. If it is not, as I guess is the case based on your comments elsewhere, then you’ll only need to address the fs by its type. For an ext[234] .img file you should use resize2fs and be done with it. For others you’ll want to look at the relevant user-space tools and their man pages.

If .img is partitioned it can be more complicated. In such cases how you handle the situation will depend on what kind of partition table is used (such as GPT vs MBR vs hybrid-MBR), whether it is the last partition in the file’s partition table and much else. I hesitate to venture any specifics here without more information: if you require advice on how to handle a partitioned .img please let me know with some more details and I will offer what I can.

Answered By: mikeserv
Categories: Answers Tags:
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.