[Buildroot] [PATCH 1/1] package/mke2img: use mkfs to generate rootfs image

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

Hello,

On Thu, 2 Mar 2017 13:45:06 +0100, S?bastien Szymanski wrote:

> > Now that we use mkfs, is it possible to get rid of mke2img entirely?  
> 
> We still have to calculate the number of blocks needed. I guess we can
> do that in the .mk file, can't we?

Do we still need to do this calculation? Can't mkfs create an image of
an arbitrary size in MBs ?

Indeed, the current code that calculates the number of blocks needed is
completely bogus, and breaks as soon as the host filesystem is not
ext2/3/4. We have two bug reports that says it doesn't work, one one
ZFS, another on NTFS, and I remember it also broke on XFS.

See:

  https://bugs.busybox.net/show_bug.cgi?id=8831 (ZFS)
  https://bugs.busybox.net/show_bug.cgi?id=9496 (NTFS)
  https://github.com/buildroot/buildroot-defconfig-testing/blob/master/.travis.yml#L158 (XFS)

So the whole "let's calculate how many blocks are needed" logic we have
simply cannot work, because the number of blocks needed completely
depends on the internal architecture of the filesystem.

Therefore, I would suggest that we get rid of this, and instead add an
option "Filesystem size" in Config.in, default to some reasonable value
like 64M or 128M, and it would be up to the user to define it to a
value that is large enough to host the package selection he has done.

> >> +    # Disable some defaults features
> >> +    mkfs_O_opts+=",^ext_attr,^64bit,^flex_bg,^large_file,^huge_file,^dir_nlink,^extra_isize"  
> > 
> > Why would we disable these default features  
> 
> I disable these default features, to generate a rootfs as similar as
> possible the one generated by genext2fs.

OK.

> U-boot had some issues with rootfs with the 64bit flags, but this has
> been fixed
> 
> http://git.denx.de/?p=u-boot.git;a=commit;h=b4976b49a01ac68f7dbb33657a44dcffe584fa4a

Then, I think we want to disable it by default indeed, since we want to
remain compatible with old U-Boot versions that may not have this fix.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com