LTO breaks reproducible builds, and there is some question as to how
reliable LTO's code generator is --- there are some scary stories that
it doesn't work well, and the GCC maintainers aren't super-interested
in fixing the bugs:
debian: skip running "make check" if DEB_BUILD_OPTIONS contains nocheck
This was done automatically by debhelper, but it got dropped when
override_dh_auto_test was added by commit 7f4c3bb120 ("debian: run
"make check" with V=1 to keep blhc happy").
debian: add a hard dependency on logsave to e2fsprogs
The initramfs created by the initramfs-tools package needs logsave and
assumes it comes along with e2fsprogs. If it is not present, the
result systems which will fail to boot. Fix this by adding the
dependency.
In the future initramfs-tools will explicitly ask for logsave (tracked
in Debian Bug: #932854), but we'll need to keep this dependency until
the next stable release of Debian.
e2scrub_all_cron: check to make sure e2scrub_all exists
Since e2scrub_all.cron is marked as a config file, it can hang around
after the package is removed, in which case e2scrub_all might not be
present. So check to make sure e2scrub_all exists before trying to
execute it.
fuse2fs: stop using the nonempty option by default
The nonempty option isn't supported by fuse3, and so if fusermount is
from fuse3, having fuse2fs specify nonempty automatically will prevent
fuse2fs from working correctly.
The strings in e2fsck/problem.c use a special %-expansion scheme,
where %b gets expanded to a block number, %i gets expanded to an inode
number, etc., where these values are in a problem context data
structure. As such, there is no need to use a printf style positional
indicator (e.g., %2$s). Indeed, the use of things like %1$i or %2$b
will cause the %-expansion code to just print %1$i or %2$b, instead of
the inode or block number, respectively.
Addresses-Debian-Bug: #892173
Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: Philipp Thomas <pth@suse.de> Cc: Benno Schulenberg <vertaling@coevern.nl> Cc: Trần Ngọc Quân <vnwildman@gmail.com> Cc: Petr Pisar <petr.pisar@atlas.cz>
debian: drop special case CFLAGS for Alpha and PowerMac architectures
Defining HAVE_NETINET_IN_H for Alpha and __NO_STRING_INLINES for the
PowerMac QUICK bootloader date back to over two decades, to 1997 and
1998, respectively. These two architectures are no longer supported
by Debian, and it's not clear they are actually needed in 2019 even
for someone building for these architectures. So let's drop them and
see if anyone complains (or notices).
The e2scrub_all program was broken by commit c7d6525ecaab
("e2scrub_all: refactor device probe loop") so that it would use the
path of the snapshot volume instead of the base volume. This caused
"e2scrub_all -r" to pass the wrong pathname to e2scrub, with the
result that e2scrub would abort with an error instead of removing the
snapshot volume.
debian: drop support for not building the e2fsck-static and udebs packages
The ability to not build udebs packages and e2fsck-static made sense
when we were doing a separate e2fsprogs builds for those packages.
Since we're not doing that any more, we can simplify things by
dropping that flexibility.
debian: stop building a special version of e2fsprogs for e2fsprogs-udeb
Previously, we configured and built a separate version of e2fsprogs
for the e2fsprogs-udeb package. This was important back when we still
cared about build floppies, but going to extra lengths to save 145k of
disk space isn't worth it any more.
e2scrub_all: correctly handle the case where LUKS is stacked on an LV
We handle the case where an LVM's PV is stacked on top of a dm-crypt
device, but not the case where it's the other way around, where a LVM
LV contains a LUKS encrypted file system. Fix this oversight.
Addresses-Debian-Bug: #931387
Reported-by: Marc Haber <mh+debian-bugs@zugschlus.de> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
e2fsck: correctly handle inline directories when large_dir is enabled.
Historically, e2fsck has required that directories not contain holes.
(In fact, as of this writing, ext4 still requires this to be the
case.) Commit ae9efd05a98 ("e2fsck: 3 level hash tree directory
optimization") removed this requirement if the large_dir feature is
enabled; however, the way it was done caused it to incorrectly handle
inline directories.
To reproduce the problem fixed by this commit:
truncate -s 100000000 ext4.img
misc/mke2fs -t ext4 -I 512 -O 'inline_data,large_dir' ext4.img
mkdir m
sudo mount ext4.img m
mkdir m/aa
sudo umount m
e2fsck/e2fsck -f -n ext4.img
The last command gives this output:
[root@localhost e2fsprogs-kernel]# e2fsck/e2fsck -f -n ext4-2.img
e2fsck 1.45.2 (27-May-2019)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
'..' in /aa (12) is <The NULL inode> (0), should be / (2).
Fix? no
Pass 4: Checking reference counts
Inode 2 ref count is 4, should be 3. Fix? no
Inode 12 ref count is 2, should be 1. Fix? no
Pass 5: Checking group summary information
ext4-2.img: ********** WARNING: Filesystem still has errors **********
Theodore Ts'o [Fri, 7 Jun 2019 17:07:12 +0000 (13:07 -0400)]
Fix posix_memalign and posix_fadvise calls.
Almost all posix_ functions return a positive errno value (without
setting errno) rather than -1 and setting errno. Most calls in this
project were correct, but these two weren't.
Darrick J. Wong [Tue, 4 Jun 2019 04:27:12 +0000 (21:27 -0700)]
e2scrub: remove -C from e2scrub_all
We already have the "SERVICE_MODE=1" feature that signals to e2scrub
that we're running as a background daemon and therefore we should exit
quietly if conditions aren't right.
It's therefore unnecessary to have a separate -C flag to achieve the
same outcome for cron jobs. Merge the two together.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Eric Biggers [Tue, 28 May 2019 23:12:30 +0000 (16:12 -0700)]
tests: add test for e2fsck of verity file
Test that e2fsck doesn't report errors when an inode with the 'verity'
flag has blocks past i_size.
This is a regression test for commits 3baafde6a8ae ("e2fsck: allow
verity files to have initialized blocks past i_size") and 43466d039689
("e2fsck: handle verity files in scan_extent_node()").
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Theodore Ts'o [Mon, 27 May 2019 23:36:15 +0000 (19:36 -0400)]
mke2fs: accept the english yes character to the proceed question
In some cases if the translation file is missing some translations,
mke2fs can end up printing an English message, e.g.:
% LANG=it_IT.UTF-8 ./mke2fs /tmp/foo.img 8M
mke2fs 1.45.1 (12-May-2019)
/tmp/foo.img contiene un file system ext4
created on Mon May 27 19:35:48 2019
Proceed anyway? (y,N)
However, if there is a translation for string to match with "yY"
(e.g., to "sS" for Italian), then 'y' won't work. Fix this by falling
back to the english 'yY' characters.
Eric Biggers [Thu, 23 May 2019 15:30:33 +0000 (08:30 -0700)]
e2fsck: handle verity files in scan_extent_node()
Don't report PR_1_EXTENT_END_OUT_OF_BOUNDS on verity files during
scan_extent_node(), since they will have blocks stored past i_size.
This was missed during the earlier fix because this check only triggers
if the inode has enough extents to need at least one extent index node.
This bug is causing one of the fs-verity xfstests to fail with the
reworked fs-verity patchset.
Fixes: 3baafde6a8ae ("e2fsck: allow verity files to have initialized blocks past i_size") Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Theodore Ts'o [Sun, 19 May 2019 03:04:49 +0000 (23:04 -0400)]
e2scrub_all: avoid scrubbing all devices when there is nothing to scrub
Running lsblk when there are no valid block devicse results in
generating all block devices as the list of devices to scrub; this
results in a lot of e2scrub_all failures.
Andreas Dilger [Sun, 5 May 2019 22:33:46 +0000 (18:33 -0400)]
mke2fs: fix check for absurdly large devices
The check in mke2fs is intended to be for the number of blocks in the
filesystem exceeding the maximum number of addressable blocks in 2^32
bitmaps, which is (2^32 * 8 bits/byte * blocksize) = 2^47 blocks,
or 2^59 bytes = 512PiB for the common 4KiB blocksize.
However, s_log_blocksize holds log2(blocksize_in_kb), so the current
calculation is a factor of 2^10 too small. This caused mke2fs to fail
while trying to format a 900TB filesystem.
Fixes: 101ef2e93c25 ("mke2fs: Avoid crashes / infinite loops for absurdly large devices") Signed-off-by: Andreas Dilger <adilger@dilger.ca> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Theodore Ts'o [Sun, 5 May 2019 20:43:33 +0000 (16:43 -0400)]
e2fsck: check and fix tails of all bitmap blocks
Currently, e2fsck effectively checks only tail of the last inode and
block bitmap in the filesystem. Thus if some previous bitmap has unset
bits it goes unnoticed. Mostly these tail bits in the bitmap are
ignored; however, if blocks_per_group are smaller than 8*blocksize,
the multi-block allocator in the kernel can get confused when the tail
bits are unset and return bogus free extent.
Add support to libext2fs to check these bitmap tails when loading
bitmaps (as that's about the only place which has access to the bitmap
tail bits) and make e2fsck use this functionality to detect buggy bitmap
tails and fix them (by rewriting the bitmaps).
Reported-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Jan Kara <jack@suse.cz>
Theodore Ts'o [Fri, 3 May 2019 20:42:36 +0000 (16:42 -0400)]
libext2fs: move struct ext2fs_nls_table to the private ext2fsP.h header
Callers of libext2fs don't need to use this structure, and this gives
us the ability to change it later on without worrying about
changing public ABI's.
Theodore Ts'o [Fri, 3 May 2019 17:16:29 +0000 (13:16 -0400)]
Rename the feature "fname_encoding" to be "casefold".
Also change mke2fs so that the encoding and encoding flags are
specified in mke2fs.conf in the fs_types and defaults stanzas instead
of the options stanza.
Merge nls_utf8-norm.c and nls_utf8.c. This also allows us to comment
out functions which we don't actually need for e2fsprogs.
Also fix some gcc -Wall complaints, including one which would have
caused utf8_casefold() to misbehave (this was fixed in the kernel, but
not carried back to e2fsprogs).
Eric Biggers [Mon, 29 Apr 2019 00:35:21 +0000 (20:35 -0400)]
debugfs: fix encoding handling in dx_hash command
Fix the following bugs:
1. 'encoding' and 'hash_flags' are not initialized, causing a segfault.
2. 'hash_flags' incorrectly uses a __bitwise type.
3. The optstring doesn't contain "c" or "e", so the -c and -e options
aren't recognized.
4. The code that handles the -e option always returns.
Fixes: ef733f1a97ec ("debugfs: support encoding when printing the file hash") Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Eric Biggers [Sun, 28 Apr 2019 23:42:41 +0000 (19:42 -0400)]
debugfs: avoid ambiguity when printing filenames
The way debugfs escapes filenames is ambiguous because a sequence like
M-A can mean either the byte 'A' + 128 == 0xc1 or the three bytes
{'M', '-', 'A'}. Similarly, ^A can mean either the byte
'A' ^ 0x40 == 0x01 or the two bytes {'^', 'A'}.
Fix this and simplify the code by switching to a simpler strategy where
all bytes < 32, all bytes >= 127, and backslash are encoded with C-style
hex escape sequences. E.g., the byte 0xc1 will now be encoded as \xc1
rather than M-A as it was before, while a filename consisting of the
three bytes {'M', '-', 'A'} will continue to be shown as M-A.
I want to fix this mainly because I want to use debugfs to retrieve raw
encrypted filenames for ciphertext verification tests. But this doesn't
work if the returned filenames are ambiguous.
Fixes: 68a1de3df340 ("debugfs: pretty print encrypted filenames in the ls command") Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>