Image builder filesize "out of space"

For Developers
1

Hello! I am trying to experiment with the image builder, mainly to add all the packages that I need and their configuration files in advance. Problem is that I am getting an error out of space.

Summary 
Building images...
Parallel mksquashfs: Using 1 processor
Creating 4.0 filesystem on /home/trendy/OpenWrt/openwrt-imagebuilder-21.02.1-bcm27xx-bcm2711.Linux-x86_64/build_dir/target-aarch64_cortex-a72_musl/linux-bcm27xx_bcm2711/root.squashfs, block size 262144.
Pseudo file "/dev" exists in source filesystem "/home/trendy/OpenWrt/openwrt-imagebuilder-21.02.1-bcm27xx-bcm2711.Linux-x86_64/build_dir/target-aarch64_cortex-a72_musl/root-bcm27xx/dev".
Ignoring, exclude it (-e/-ef) to override.
[===========================================================================================================================================================================================================================-] 5021/5021 100%

Exportable Squashfs 4.0 filesystem, xz compressed, data block size 262144
	compressed data, compressed metadata, compressed fragments,
	compressed xattrs, compressed ids
	duplicates are removed
Filesystem size 26472.03 Kbytes (25.85 Mbytes)
	24.10% of uncompressed filesystem size (109847.41 Kbytes)
Inode table size 38440 bytes (37.54 Kbytes)
	20.20% of uncompressed inode table size (190323 bytes)
Directory table size 51392 bytes (50.19 Kbytes)
	41.22% of uncompressed directory table size (124665 bytes)
Number of duplicate files found 661
Number of inodes 5711
Number of files 4774
Number of fragments 146
Number of symbolic links  570
Number of device nodes 1
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 366
Number of ids (unique uids + gids) 1
Number of uids 1
	unknown (0)
Number of gids 1
	unknown (0)
Creating filesystem with parameters:
    Size: 109051904
    Block size: 4096
    Blocks per group: 32768
    Inodes per group: 6656
    Inode size: 256
    Journal blocks: 0
    Label: rootfs
    Blocks: 26624
    Block groups: 1
    Reserved blocks: 0
    Reserved block group size: 7
error: ext4_allocate_best_fit_partial: failed to allocate 700 blocks, out of space?
make[3]: *** [/home/trendy/OpenWrt/openwrt-imagebuilder-21.02.1-bcm27xx-bcm2711.Linux-x86_64/include/image.mk:334: /home/trendy/OpenWrt/openwrt-imagebuilder-21.02.1-bcm27xx-bcm2711.Linux-x86_64/build_dir/target-aarch64_cortex-a72_musl/linux-bcm27xx_bcm2711/root.ext4] Error 1
make[2]: *** [Makefile:186: build_image] Error 2
make[1]: *** [Makefile:124: _call_image] Error 2
make: *** [Makefile:240: image] Error 2

Since this image is going to be installed on a 32GB SD card for RPi-4b, is it possible to somehow override any size limitations that might be applied?

2

For strange reasons the default size for Rootfs image have been shrunk from 254 to 128MB to "save space" (images are gzipped anyway on official download server so I'm not following the logic)

and then down to 104 or something because that would allow the whole image (with kernel partition included) to fit on "the smallest possible CF card" at 128MB, again somewhat baffling

Your image is (from the console output) 109051904 bytes so 109MB or something, so it does not fit this arbitrary limit.

The workaround is to manually edit the .config file (it's hidden by default) in the folder wehre you extracted the imagebuilder and put your own numbers instead, whatever you want, in MB

CONFIG_TARGET_KERNEL_PARTSIZE=...
CONFIG_TARGET_ROOTFS_PARTSIZE=...

see the example below for a shell command you can add to a script that automates the build so it also edits the config 18MB of kernel/boot partition and 256MB of root partition.

sed -i 's/CONFIG_TARGET_KERNEL_PARTSIZE=.*/CONFIG_TARGET_KERNEL_PARTSIZE=18/' .config
sed -i 's/CONFIG_TARGET_ROOTFS_PARTSIZE=.*/CONFIG_TARGET_ROOTFS_PARTSIZE=256/' .config
6 Likes
3

Lovely! One more question, the kernel and rootfs partsize should match the partitions currently in SD card or they don't matter and will be adapted to the actual space during sysupgrade?
For example I have:

Filesystem           1M-blocks      Used Available Use% Mounted on
/dev/root                13808       159     13633   1% /
tmpfs                     1902        13      1889   1% /tmp
/dev/mmcblk0p1              64        16        48  25% /boot

so should I enter KERNEL partsize 64MB and ROOTFS 13808? Or can I use the 18/256 and it will adapt?

4

if there is a mismatch (parts 1 and 2) or -p is given... the image partitions will take over (full img is written)

during firstboot on squashfs it has been said that the overlay is adapted to the space on setup... but I can't confirm or deny this...

1 Like
5

Afaik with squashfs the overlay is created to take the free space of the rootfs partition, not the whole free space in the drive.

So back in the days of 256MB rootfs and with a relatively normal build you would have 230-ish free regardless of your drive size

3 Likes
6

this will dump a conversion to IB values;

. /lib/upgrade/common.sh
dd if=/dev/mmcblk0 of=/tmp/image.bs count=1 bs=512b 2>/dev/null
get_partitions /tmp/image.bs partsbaby
for tPART in $(cat /tmp/partmap.partsbaby | awk '{print $3}'); do
	echo "$(($tPART / 2 / 1024))"
done
1 Like
7

You can write whatever number you want there, the only limit is that the storage device must be equal or larger than that. The size isn't just padding, it's actual partition size.

So for example if you try to flash the image you made with KERNEL partsize 64MB and ROOTFS 13808 on a 4GB SD card, it will cause breakage as it expects to have around 13GB.

Afaik OpenWrt has no such system that enlarges partitions to use the whole drive in a dynamic way so all space you don't define in these variables won't be used. There is a PR on Github for the squashfs image I think, because even that is limited to the rootfs partition size as I mentioned in the post above (rootfs partition will contain squashfs and f2fs rw, the rw overlay will take over ONLY the free space left in the rootfs partition, it has no idea of the whole drive size)

1 Like
8

Thank you for your help, changing the partsizes did the trick! :slight_smile:
For the other part, I guess we're stuck with manual rootfs expansion for the time being.

9

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.