Created attachment 6411 [details] last output I tried building master at 4a6602f77cfe429d1dfc4f36964240b7d4410c54 today with only http://patchwork.ozlabs.org/patch/602668/ applied on top. The steps I did: `make distclean` `make raspberrypi2_defconfig` `make menuconfig` activate dropbear with default options `make` Build fails with genext2fs not being able to allocate a block. (See pasted output in attachement.) The host is a quite usual Debian stable (jessie) on amd64 but with ZFS by zfsonlinux as filesystem. The volume has no compression or dedup options set.
Maybe it's time we switch to use e2fsprogs from their 'next' branch, rather than our canned script? The upstream e2fsprogs now has the ability to fill-in the generated filesystem from the content of an existing directory (with the new -d option). FWIW, Debian is now using a snapshot of 2016-03-15 in Stretch (testing) and they have a single patch on top of that. I'd rather trust Debian. Regards, Yann E. MORIN.
FWIW, the current release of e2fsprogs we have in Buildroot can generate filesystem images: ./output/host/usr/sbin/mke2fs -d fs/ test.img 1024 However, it will *not* solve the problem: you still have to pass the size of the filesystem to be created, either in number of blocks or in KB/MB/GB. Therefore, we still have to estimate it (like we're doing today), and potentially get it wrong. Maybe it is simply impossible to automatically calculate the filesystem size, and we should stop supporting auto-calculation, and instead ask the user to fill in a size for the filesystem (either in blocks or KB/MB/GB). Thoughts?
We have dropped support for auto-calculating the size of the ext2 filesystem: the size *must* now be passed in a Buildroot option. See https://git.buildroot.org/buildroot/commit/?id=c6bca8cef0310bc649240b451989457ce94a8358. Therefore, the issue raised by this bug can no longer be encountered.