For portability. All other Buildroot scripts (i.e. scripts that run on
host) already use the "/usr/bin/env bash" shebang.
This change is needed for NixOS, which lacks a global /bin/bash.
Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When the user specifies a number of blocks (and we do not auto-compute
them), the generated filesystem can be quite large with large zones with
only zeroes in them.
Thus, always create the filesystem as a sparse file.
Sparse files behave the same as normal files, except those long runs of
zeroes do not actually use space on the (host) filesystem. Also, this
should not break current behaviour, as neither cp nor dd nor cat preserve
sparseness by default. So users relying on the zeroed parts to actually
be written won;t see a change. Users that were expressly using cp or dd
to copy files to a sparse destination will however see a little bit of
improvements, as the zeroed out parts won't even be read from disk.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Tested-by: Karoly Kasza <kaszak@gmail.com>
Reviewed-by: Karoly Kasza <kaszak@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, we forcibly expand the generated filesystem by 1300 blocks
(i.e. a bit more than 1MiB) when we need to generate an ext3 or ext4
filesystem, even if the user already supplied us with the size it wants
the filesystem to be.
In that case, we overshoot what the user requested, which is bad because
the filesystem may no longer fit in the partition it is supposed to be
written into.
Only add extra blocks when we do compute the required size, not when the
user specifies the size.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, we are using a shell script called genext2fs, that
impersonates the real genext2fs. But that script does much more than
just call genextfs: it also calls tune2fs and e2fsck.
Because it impersonates genext2fs, we can not easily add new options,
and are constrained by the genext2fs options.
But it turns out that, of all the options supported by the real
genext2fs, we only really care for a subset, namely:
- number of blocks
- number of inodes
- percentage of blocks reeserved to root
- the root directory which to generate the image from
So, we introduce a new host package, mke2img, that is intended to
eventually replace genext2fs.sh.
This new script is highly modeled from the existing genext2fs.sh, but
was slightly refreshed, and a new, supposedly sane set of options has
been choosen for the features we need (see above), and some new options
were added, too, rather than relying on the arguments order or
environment variables:
-b <nb-blocks> number of blocks in the filesystem
-i <nb-inodes> number of inodes in the filesystem
-r <pc-reserved> percentage of reserved blocks
* -d <root-dir> directory containing the root of the filesystem
* -o <img-file> output image file
-G <ext-gen> extfs generation: 2, 3, or 4 (default: 2)
-R <ext-rev> ext2 revision: 0 or 1 (default 1)
-l <label> filesystem label
-u <uid> filesystem UUID; if not specified, a random one is used
* Mandatory options
Since the upstream e2fsprogs are expected to release a new mke2fs that
will be able to generate a filesystem image from a directory, we then
will be able to replace all the logic in mke2img, to use mke2fs instead
of the (relatively fragile) combination of the three tools we currently
use.
An entry is added for it in the "Host utilities" menu, so it can be
selected for use by post-{build,image} scripts. The ext2 filesystem
selection is changed to select that now.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Karoly Kasza <kaszak@gmail.com>
Reviewed-by: Karoly Kasza <kaszak@gmail.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
