summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.46.1.bb
AgeCommit message (Collapse)Author
2021-08-25e2fsprogs: ensure small images have 256-byte inodesRoss Burton
e2fsprogs calls filesystems larger than 3MB but smaller than 512MB "small", which has some implications: - blocksize 1024 instead of 4096 - inode_ratio 4096 instead of 16384 - inode_size 128 instead of 256 The outcome of the inode size dropping to 128 bytes is that they cannot store 64-bit timestamps, so are not Y2038-safe. A previous attempt to solve this problem[1] changed some of the canned wic files to pass -T default to mkfs.ext4, but this only covered wic images and not traditional images. Also, actually small filesystems, for example a core-image-minimal, will happily be tens of megabytes and with the "default" options will result in an image which runs out of blocks before it runs out of space: mkfs.ext4: Could not allocate block in ext2 filesystem while populating file system Considering that many OpenEmbedded images are in fact "small", being 2038-safe is worth the marginal increase is disk usage. This patch alters the small configuration in native builds so that it also has 256-byte inodes. Target is unchanged so that standard behaviour is maintained outside of the build. This is actually the same underlying patch that Mathieu Dubois-Briand sent in April, but the wic change in [1] was accepted instead. I believe that is the wrong approach and this approach covers more cases. [ YOCTO #14478 ] [1] openembedded-core eecbe62 [2] https://lists.openembedded.org/g/openembedded-core/message/150298 Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 9ab0ae83a24ee99e69f8ac54256b253a122aef8a) Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
2021-03-02e2fsprogs: update 1.45.7 -> 1.46.1Alexander Kanavin
Drop gettext patches; upstream has fixed the issues. Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>