Add a dependency on subs to all-libs-recursive and all-progs-recursive
to dpkg-buildpackage -j2, since it builds make target 'libs'
explicitly, and we need to make sure the 'subs' target is run first.
Addresses-Debian-Bug: #563487
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
It's a bad idea to set the checksums if e2fsck is aborted by the user,
and it often causes an error message, "Inode bitmap not loaded while
setting block group checksum info".
Addresses-Launchpad-Bug: #582035
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Some devices, notably 4k sector drives, may have a 512 logical
sector size, mapped onto a 4k physical sector size.
When mke2fs is ratcheting down the blocksize for small filesystems,
or when a blocksize is specified on the commandline, we should not
willingly go below the physical sector size of the device.
When a blocksize is specified, we -must- not go below
the logical sector size of the device.
Add a new library function, ext2fs_get_device_phys_sectsize()
to get the physical sector size if possible, and adjust the
logic in mke2fs to enforce the above rules.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The top-level COPYING file states that the e2p and ext2fs libraries
are available under the LGPLv2. The files were incorrectly labelled.
Alex Thomas/Luster has been consulted wrt to the ext3_extents.h file;
the rest of the files were primarily authored by Theodore Ts'o.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
namei.o is also needed by e2initrd_helper.
Long term, if we care about reduced e2fsprogs builds, we need a more
general solution for deciding what .o files are needed for a
particular build. Given that install floppies are going (gone?) the
way the dodo bird, we probably don't care, though.
Addresses-Sourceforge-Bug: #2911433
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
These options allow e2fsprogs to be built using symlinks instead of
hard links, and to be installed using symlinks instead of hard links,
respectively.
Addresses-Sourceforge-Bug: #1436294
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This fixes a long-standing botch in the com_err library, and solves a
regression test problem for libss that gets tickled by source code
management systems (like Perforce) that don't preserve CRLF line
endings with fidelity.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Use a standard, fixed mke2fs.conf file so that if downstream
distributions want to change the mke2fs.conf which is distributed in
the RPM or dpkg file, it won't screw up the regression tests.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
In the case where s_first_data_block is 1, we need to explictly reject
an extent whose starting physical block is zero.
Thanks to Jiaying Zhang <jiayingz@google.com> for finding this bug.
Addresses-Google-Bug: #2573806
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If a corrupted file system causes us to want to delete an extent, and
that causes us to want to release a block in e2fsck pass #1, it would
be preferable if e2fsck didn't seg fault. This tends to get users
craky, as users are wont to do. :-)
Thanks to Dirk Reiners for reporting this bug:
e2fsck crashes fixing a corrupted 3.5 TB filesystem:
0x0000000000432002 in ext2fs_unmark_generic_bitmap (bitmap=0x0, bitno=623386749)
at gen_bitmap.c:183
183 if ((bitno < bitmap->start) || (bitno > bitmap->end)) {
(gdb) bt
bitno=623386749) at gen_bitmap.c:183
block=623386749) at ../../lib/ext2fs/bitops.h:319
inuse=-1) at alloc_stats.c:78
extent.c:1509
pb=0x7fffffffdfe0, start_block=0, ehandle=0x6dcf50) at pass1.c:1709
pb=0x7fffffffdfe0, start_block=0, ehandle=0x6dcf50) at pass1.c:1737
pctx=0x7fffffffe100, pb=0x7fffffffdfe0) at pass1.c:1842
block_buf=0x6c4330 "\373\212#") at pass1.c:1920
The source of the NULL bitmap is fs on stack frame 2:
(gdb) up 2
inuse=-1) at alloc_stats.c:78
78 ext2fs_unmark_block_bitmap(fs->block_map, blk);
Addresses-SourceForge-Bug: #2971800
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
There are broken embedded devices that have system clocks that always
reset to January 1, 1970 whenever they boot (even if no power is
lost). There are also systems that have super cheap clock crystals
that can be very inaccurate. So if the option broken_system_clock is
given, disable all time based checks. E2fsck will also try to detect
incorrect system clock times, and automatically mark the system clock
as insane.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Justin reported that creating a 4T file with posix_fallocate led
to fsck errors:
e2fsck 1.41.10 (10-Feb-2009)
Pass 1: Checking inodes, blocks, and sizes
Inode 12, i_blocks is 8589935432, should be 840. Fix? yes
This looks like a 32-bit overflow.
commmit 8a8f36540b added handling of
the high i_blocks number, but we accumulate blocks in the num_blocks
field, and that's still just 32 bits.
Note: we don't need to expand max_blocks for now, that's only used
in the non-extents case, and those files have smaller max sizes.
I haven't been able to replicate the problem, oddly, but Justin
reports that this patch fixed his situation.
Reported-by: Justin Maggard <jmaggard10@gmail.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
For a filesystem that fails with:
journal_bmap: journal block not found at offset 7334 on loop0
JBD: bad block at offset 7334
e2fsck won't actually fix this; it will mark the fs as clean,
so it will mount, but it does not fix that block, and when the
journal reaches this point again it will fail again.
The following simple change to process_journal_block() might be
a little drastic; it will clear & recreate the journal inode if
it's sparse - i.e. if it gets block 0.
I suppose we could be more complicated and try to replay the journal
up to the error, but I'm not sure it's worth it since we're fscking
it anyway.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
There were a number of problems that were prompting the user whether
or not to ABORT, but then would abort regardless of whether the user
answered yes or no. Change those to be PROMPT_NONE, PR_FATAL.
Also, fix PR_1_RESIZE_INODE_CREATE so that it recovers appropriately
after failing to create the resize inode. This problem now uses
PROMPT_CONTINUE instead of PROMPT_ABORT, and if the user says, "no",
the code will abort.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This for RH bug #572935 -
RFE: Misleading error message from mke2fs -J option
If the journal device UUID is typo'd or otherwise not found,
the error message looks like it's a usage() type of problem.
It'd be helpful to explicitly say that the device requested
could not be found.
Addresses-Red-Hat-Bug: #572935
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Right now, resize2fs -P on a dirty filesystem will give you a number;
however, it's probably wrong if the fs is not clean:
# resize2fs -P myimage.img
resize2fs 1.41.9 (22-Aug-2009)
Estimated minimum size of the filesystem: 75623
# e2fsck -fy myimage.img
e2fsck 1.41.9 (22-Aug-2009)
myimage.img: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
myimage.img: ***** FILE SYSTEM WAS MODIFIED *****
myimage.img: 9530/53760 files (0.1% non-contiguous), 24737/98304 blocks
# resize2fs -P myimage.img
resize2fs 1.41.9 (22-Aug-2009)
Estimated minimum size of the filesystem: 32165
We should issue the same "Please run e2fsck ..." message for
-P as we do for an actual resize request.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Add test to make sure e2fsck doesn't end up detaching and sending to
lost+found inodes which are in an bg_itable_unused_region (e.g. if
there was a power failure and bg_itable_unused wasn't updated because
journaling wasn't enabled).
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Commit 6267ee4 avoided repeating pass #1 over and over again if
multiple block groups are found with inodes in the bg_itable_unused
region during pass #2. This caused a regression because the problem
with not restarting pass #1 right away is that e2fsck will offer to
clear directory entries for inodes that are deleted, and e2fsck can't
easily distinguish between deleted inodes and inodes that were skipped
because of an incorrect bg_itable_unused value. So once an inode is
found in an unused region and we know that we're going to restart the
e2fsck pass, don't offer to clear any deleted inodes --- since those
will be caught in the second round.
Addresses-Google-Bug: #2642165
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Some kernels will crash if EOFBLOCKS_FL is set when it is it not
needed, and this if it is left set when it isn't needed, it is a sign
of a kernel bug.
Addresses-Google-Bug: #2604224
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This reverts commit 0ea910997b.
Since the Linux kernel now has support for the EXT4_EOFBLOCKS_FL flag
starting in 2.6.34, we don't need this workaround any more.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
From: Kees Cook <kees@debian.org>
I noticed that the debian/rules contains "-fno-stack-protector". While
this used to be needed a while back, this is no longer required, as the
stack protection code will be statically compiled into the static e2fsprogs
correctly now.
Addresses-Debian-Bug: #573923
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If the user grows a partition bigger than 2**32 blocks, e2fsprogs
1.41.x is not going to be able to support resizing the filesystem,
since it doesn't have > 2**32 block support. However, e2fsck should
still work, so the system administrator doesn't get stuck.
Addresses-Launchpad-Bug: #521648
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The offset in the bitmap was not getting correctly calculated when the
user specifics a block to track using "logdump -b <block-num>"
Addresses-Debian-Bug: #564084
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
I guess the message wasn't scary enough for users who are just smart
enough to really get themselves in deep doo-doo. Let's make it even
scarier.
Addresses-Launchpad-Bug: #537483
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
A user was surprised when -n -D caused the file system to be opened
read/write, and then outsmarted himself when e2fsck asked the question:
WARNING!!! Running e2fsck on a mounted filesystem may cause
SEVERE filesystem damage.
Do you really want to continue (y/n)?
This is partially our fault for not documenting the fact that -D
overrode opening the filesystem read-write. But the bottom line is it
much safer if -n *always* opens the file system read-only, so there
can be no confusion. This means that we have to disable certain
combination of options, such as "-n -c", "-n -l", and "-n -L", and
"-n -D", but the utility of these combinations is pretty low, and
is more than offset by making e2fsck idiot-proof.
Addresses-Launchpad-Bug: #537483
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Just print the warning message in this case.
Addresses-Red-Hat-Bug: #569021
Addresses-Launchpad-Bug: #530071
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When ext2fs_block_iterate2() is called on an extent-mapped file with a
depth > 1, it will erroneously calling the callback function starting
all over again with an offset of logical block 0. It shouldn't do
this, and it cases mke2fs to become very slow when creating files with
very large journals.
Fix this.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This is the userspace side of Jiaying's EOFBLOCKS patch. With
Aneesh's patches for .33, Jiaying's patch, and this one, xfstests
013/fsstress (even with direct IO enabled) has held up through many
runs.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
E2fsprogs 1.41.10 introduced a regression (in commit b71e018) where
e2fsck -fD can corrupt non-indexed directories when are exists one or
more file names which alphabetically sort before ".". This can happen
with ext2 filesystems or for small directories (take less than a
block) which contain filenames that begin with a space or some other
punctuation mark.
Fix this by making sure we never reorder the '.' or '..' entry in the
directory, since they must be first.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
mkfsing a plain file would lead to a warning about being unable
to determine geometry; we should just skip the topology-getting
if we see that we have a regular file.
This was breaking "make check" but I had missed it since I
inadvertently stopped running the checks during the Fedora
RPM build.
Also, add a newline to the warning.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Commit 74128f8 added tests for uninit groups, but it could access past
the end of the group_desc[] array after processing the last group:
==19668== Invalid read of size 2
==19668== at 0x40518C: resize_fs (resize2fs.c:1824)
==19668== by 0x405A46: main (main.c:451)
==19668== Address 0x5a0d002 is not stack'd, malloc'd or (recently) free'd
==19668==
==19668== Invalid read of size 2
==19668== at 0x405391: resize_fs (resize2fs.c:1864)
==19668== by 0x405A46: main (main.c:451)
==19668== Address 0x5a0d002 is not stack'd, malloc'd or (recently) free'd
==19668==
It was found by Eric Sandeen running the regression suite through
valgrind.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Rawhide now has libreadline.so.6 ... add it to the ever-expanding
list of libs to look for.
Unfortunately without commit 06ef971be5
this fails in a rather cryptic way.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Pass 1 has a test to see if a special file is really a directory.
Signed-off-by: Nick Dokos <nicholas.dokos@hp.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Theodore Ts'o