configure: support biarch builds with --multiarch=lib64

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
mke2fs: minor bugfixes for mk_hugefiles

Interpret "zero_hugefiles" relation in mke2fs.conf as a boolean value,
as documented in the man page.

If the hugefile is larger than 2GB, set the large_file file system
feature so e2fsck doesn't complain.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
debian: add make variable to prevent building udeb packages

Setting SKIP_UDEBS=yes in rules.custom will prevent the debian/rules
makefile from building the udeb files for the debian installer.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
debian: fix spelling typo in debian/control.in

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
e2fsprogs: Disallow tune2fs enabling sparse_super with ext4 meta_bg enabled

When meta_bg feature is enabled, group descriptor block is allocated
every 128 block group (or every 64 block group if 64bit feature is
enabled).

In such situation, files in block group more than #128 will be removed
if sparse_super feature is enabled with tune2fs and afterwards
necessary e2fsck running.

Because tune2fs does not reallocate group descriptor blocks but just
set sparse_super feature.  If ext4 has sparse_super,
ext2fs_descriptor_block_loc2() called by e2fsck thinks the block group
(e.g. #128) that it has group descriptor block at the head offset. But
that offset is used as backup super block before.  So e2fsck fixes
ext4 based on invalid group descriptor blocks and this cause data
lost.

The patch avoids this problem simply by disallow tune2fs enabling
sparse_super if meta_bg is enabled.

Steps to reproduce:

1. Create ext4 which has meta_bg, ^sparse_super and 129+ block groups.
	# mke2fs -t ext4 -O meta_bg,^resize_inode,^sparse_super DEV 17G
	# mount DEV /MP

2. Create direcotry and files which use block group #128's metadata.
	# echo $((8192*128+1)) > /sys/fs/ext4/DEV/inode_goal
	# mkdir /MP/DIR
	# for i in $(seq 1 100); do dd if=/dev/urandom of=/MP/DIR/file$i bs=1024 count=10; done

3. Enable sparse_super with tune2fs then execute e2fsck.
   Data in block group #128 will be lost!!
	# umount DEV
	# tune2fs -O sparse_super DEV
	# e2fsck/e2fsck -yf DEV

Signed-off-by: Akira Fujita <a-fujita@rs.jp.ne.cocm>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
mke2fs: clean up kernel version tests

Refactor the running kernel version checks to hide the details of
version code checking, etc.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
libext2fs: iterate past lower extents during punch

When we're iterating extents during a punch operation, the loop exits
if the punch region is entirely to the right of the extent we're
looking at.  This can happen if the punch region starts in the middle
of a hole and covers mapped extents.  When this happens, we want to
skip to the next extent, because it might be punchable.

Also, if we've totally passed the punch range, stop.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
libext2fs: during punch, fix parent extents after modifying extent

When modifying/removing an extent during punch, don't forget to update
the extent's parents.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
libext2fs: don't hang on to unmapped block if extent tree update fails

If we're doing a BMAP_ALLOC allocation and the extent tree update
fails, there's no point in hanging on to the newly allocated block.
So, free it to make fsck happy.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
libext2fs: try to roll back when splitting an extent fails

If a client asks us to remap a block in the middle of an extent, we
potentially have to allocate a fair number of blocks to handle extent
tree splits.  A failure in either of the ext2fs_extent_insert calls
leaves us with an extent tree that no longer maps the logical block in
question and everything that came after it!  Therefore, try to roll
back the extent tree changes before returning an error code.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>