I'm using debootstrap to create a rootfs for a device that I want to then write to an image file. To calculate the size needed from my rootfs, I do the following:

local SIZE_NEEDED=$(du -sb $CHROOT_DIR|awk '{print $1}')
SIZE_NEEDED=$(($SIZE_NEEDED / 1048576 + 50)) # in MB + 50 MB space
dd if=/dev/zero of=$ROOTFS_IMAGE bs=1M count=$SIZE_NEEDED

As you can see I'm leaving 50MB of padding beyond what dd calculates I need.

I then create the loopback device, create a partition table and filesystem:

LO_DEVICE=$(losetup --show -f $ROOTFS_IMAGE)
parted $LO_DEVICE mktable msdos mkpart primary ext4 0% 100%
partprobe $LO_DEVICE
mkfs.ext4 -O ^64bit $LO_ROOTFS_PARTITION

It seems parted attempts to do some sector alignment (?) as the partition doesn't quite take up the whole virtual disk, but close enough.

I then mount the new partition and start writing files. But then I run out of disk space right near the end!


cp: cannot create directory '/root/buildimage/rootfs_mount/var': No space left on device

I suspect this is some block size conversion issue or maybe difference between MiB and MB? Because up to a certain image size, it seems that I have enough headroom with the 50MB of padding. (I want some free space in the image by default, but not a lot.) The image size isn't off by a factor-of-two so there's some creep or overhead that gets magnified as the image size gets larger and I'm not sure where it's coming from.

For context, here's the last one I did that doesn't fit:

# du -sb build/rootfs
489889774   build/rootfs

Ok, 489MB/1024**2 + 50MB = 517MB image size. So dd looked like:

# dd if=/dev/zero of=build/rootfs.img size=1M count=517
517+0 records in
517+0 records out
542113792 bytes (542 MB, 517 MiB) copied, 2.02757 s, 267 MB/s

Confirmed on disk it looks slightly larger:

# du -sb build/rootfs.img
542113792   build/rootfs.img

The partition looks like:

# parted /dev/loop0 print
Model: Loopback device (loopback)
Disk /dev/loop0: 542MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  542MB  541MB  primary  ext4

and mounted filesystem:

# df -h /dev/loop0p1
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0p1    492M  482M     0 100% /root/buildimage/build/rootfs_mount

So maybe there is overhead in the ext4 filesystem, possibly for superblocks/ journal/ etc? How can I account for that in my size calculation?


Looking into ext4 overhead such as this ServerFault question.

Also looking into mkfs.ext4 options such as -m (reserved) and various journaling and inode options. In general if I know there's a 5% overhead coming from the filesystem, I can factor that in easily enough.

EDIT #2:

Thinking that du might be under-reporting actual on-disk size requirements (e.g. a 10-byte file still takes up a 4k block, right?) I tried a few other options:

# du -sb build/rootfs        # This is what I was using
489889774   build/rootfs

# du -sm build/rootfs        # bigger
527 build/rootfs

# du -sk build/rootfs        # bigger-est
539088  build/rootfs

Furthermore, the manpage for -b notes that it's an alias for --apparent-size which can be smaller than "actual disk usage." So that may be (most) of where my math was wrong.


2 Answers 2


Possibly the simplest solution is to heavily overprovision the space initially, copy all the files, then use resize2fs -M to reduce the size to the minimum this utility can manage. Here's an example:

rm -f /tmp/image
size=$(du -sb $dir/ | awk '{print $1*2}')
truncate -s $size /tmp/image
mkfs.ext4 -m 0 -O ^64bit /tmp/image
sudo mount /tmp/image /mnt/loop
sudo chown $USER /mnt/loop
rsync -a $dir/ /mnt/loop
df /mnt/loop
sudo umount /mnt/loop
e2fsck -f /tmp/image 
resize2fs -M /tmp/image 
newsize=$(e2fsck -n /tmp/image | awk -F/ '/blocks$/{print $NF*1024}')
truncate -s $newsize /tmp/image
sudo mount /tmp/image /mnt/loop
df /mnt/loop
diff -r $dir/ /mnt/loop
sudo umount /mnt/loop

Some excerpts from the output for an example directory:

+ size=13354874
Creating filesystem with 13040 1k blocks and 3264 inodes
+ df /mnt/loop
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/loop1         11599  7124      4215  63% /mnt/loop
+ resize2fs -M /tmp/image
Resizing the filesystem on /tmp/image to 8832 (1k) blocks.
+ newsize=9043968
+ truncate -s 9043968 /tmp/image
+ df /mnt/loop
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/loop1          7391  7124        91  99% /mnt/loop
  • Thanks! I had considered that but wasn't sure how to shrink it down afterwards. What about a whole-disk image that include a partition table? You can resize the filesystem but then I guess you would need to use parted to resize the partition too before truncating.
    – thom_nic
    Mar 23, 2017 at 1:51
  • Yes, but of course you could just stop at the resize result, throw everything away, and start again with your original code and this new target size.
    – meuh
    Mar 23, 2017 at 6:18

For the record, I've changed my original code to use du -sm which seems to have resolved my issue. I think the crux of the problem was the fact that -sb is an alias for --apparent-size.

Furthermore, knowing that ext4 requires, say 5% overhead makes it easy enough to factor into the calculation but I don't think that was the actual issue at hand since it was failing while writing as superuser.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .