thor: Theodore Ts'o
Date: Thu, 15 Jun 2023 00:17:01 -0400
Subject: resize2fs: use Direct I/O when reading the superblock for
online resizes
Link:
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84
The commit has not been tagged to any rel
Today, we don't create the sparse file "with the required size" when it
is first opened. We could try seeking to maximum size of the device
and writing a single byte, and seeing whether or not that fails, and if
it fails, *assume* that this was caused by the target file system not
supporting
If the file system has a limit on the size of the file (for example,
ext4 has a maximum file size of 16TB), then when you do a relative seek
via llseek(fd, offset, SEEK_CURR), the system call will return EINVAL.
This is what is causing the error.
If you want to create a raw image of a very large
Your original bug request said: "e2label lets you use any character,
including / or * or $ ( and probably others, like accented letters é è à
). it should not be possible to use those in label names." You've
now backpedaled and said, "I never said that! Only "risky" characters!"
"Risky" as
Right, but exactly the same argument can be made about disallowing
anything other than plain ASCII characters in file names. It may be
that in some graphical interfaces, spaces and accented characters and
special characters like "$" don't require any escaping whatsoever. In
other command-line
Flawed by what definition? Editors allow people to create files with
spaces, or with dollar signs, or with accepted characters. Some of these
characters may require quoting if you use spaces or doll=lars. Not
allowing accented characters will cause speakers of various European
languages to
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/2027979
Title:
won't warn neither prevent usage of « risky » characters in labels
Status in e2fsprogs package in Ubuntu:
In order for e2label to modify the file system label, you need to have
write access to the block device. That means that a malicious user can
always directly modify the blockdevice (or just use a version of e2label
that doesn't have the proposed check).Hence, this feature request
should not
For Debian the metadata_csum_seed and orphan_file features were disabled
by default by changing the /etc/mke2fs.conf file.
e2fsprogs (1.47.0-2) unstable; urgency=medium
* Don't enable metadata_csum_seed and orhpan_file by default (Closes:
#1031622, #1030939)
-- Theodore Y. Ts'o Sat, 04
Invalid, user filed a new bug (also in the wrong component, but I'll let
the evince maintainer deal with that), so it's also a duplicate at this
point.
** Changed in: e2fsprogs (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch
If you don't take 1.46.4 for 22.04, you might want to consider at the
very least backporting the fix for:
Fix a regression introduced in 1.64.3 where attempting to create a file
system image using mke2fs into a non-existent file would fail.
(Addresses Debian Bug: #992094)
As this will likely be
Your suggested message presupposes that busybox is used on a particular
distribution. That's not necessarily the case. Remember, e2fsprogs
is designed for all distributions, not just for Ubuntu. If Canonical
wants to make a change like that to e2fsprogs, all distributions are
free to make any
Note that I've just released e2fsprogs 1.46.4-1 for Debian:
E2fsprogs 1.46.4 (August 18, 2021)
==
Updates/Fixes since v1.46.3:
UI and Features
---
The defaults for mke2fs now call for 256 byte inodes for all file
systems (with the exception of file
It doesn't matter whether you store your personal data on the partition
where the OS is located, or elsewhere. Either way, you may need to
know how to run e2fsck on the file system if you want to try to
maximally recover data. If you don't know what you are doing, sure, go
ahead and run fsck
These problems are fixed upstream. See:
commit 225e5d093b519f9dbe9fcaacd995426f0e5194f6
Author: Theodore Ts'o
Date: Wed Jul 28 13:51:13 2021 -0400
e2fsck: fix f_baddotdir failure on big-endian systems
Commit 63f44aafb1f2 ("e2fsck: fix ".." more gracefu
fsck -y isn't *always* the right answer. The reason why the boot
scripts don't just run fsck -y automatically is that sometimes a human
with judgement can do better by manually running fsck instead of just
blindly answering yes to all questions.For "users who are not
competent" (your words,
E2fsprogs has its build dependency set to libfuse-dev for a reason.
The Fuse upstream has minimal instructions on how to do the fuse->fuse3
conversion, and the e2fsprogs upstream (me) doesn't have the time
currently to try to figure it out, and Debian is supplying both fuse and
fuse3 so the debian
If the computer is hanging as you describe, this is a kernel bug,
possibly exacerbated by a hardware bug. It isn't a userspace bug;
e2fsprogs is just reading from the block device. If that is causing the
computer hang, it's by definition not a userspace bug.
So this needs to be a kernel
This relatively simple to change the default inode size in all cases.
Look at /etc/mke2fs.conf, which is in the sources as
misc/mke2fs.conf.in. Find the lines where the inode_size is set to
128, and change it to be 256. (This might or might cause problems on
Hurd; since I'm not sure whether
janv. 26 13:30:12 a kernel: sd 6:0:0:0: [sdb] tag#16
uas_eh_abort_handler 0 uas-tag 17 inflight: OUT
UAS is "USB Attached SCSI", and this error indicates some kind of
hardware issue (maybe a loose cable connector?).
If you can't replicate the failure, it might be because it's a one-off
hardware
Hmm... I can't duplicate this on Debian testing, which is using a newer
version of e2fsprogs (1.45.5-2). The e2scrub_reap.service file is
identical with Ubuntu's 1.45.3-4ubuntu2.1, though. And looking at the
service file, I have no idea why systemctl would be trying to paskk for
a password,
So if the same procedure (with exactly the same files) reproduces
reliably when using a partition and gpart --- and it does not reproduce
at all, even with multiple attmepts, without gpart, then it is clearly a
gpart bug.
** Package changed: e2fsprogs (Ubuntu) => gpart (Ubuntu)
--
You received
Oh, also please send me the dumpe2fs -h of the partition before you try
to resize it, and please send the output of your reproduction with the
locale set to POSIX, so I can read the output of e2fsprogs in English,
please?
--
You received this bug notification because you are a member of Ubuntu
Can you provide a detailed reproduction instructions --- preferably one
that I can run myself, so I can see exactly is going on?
One thing that would be helpful is whether this can me reproduced
without gpart being part of the mix. That is, can you do something like
this:
mke2fs -t ext4
This is a known bug fixed in Debian and upstream git.
** Changed in: e2fsprogs (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
This is fixed by e2fsprogs 1.45.1-3 in Debian, or in the soon to be
released e2fsprogs 1.45.2.
e2fsprogs (1.45.1-3) unstable; urgency=medium
* Fix e2scrub_all cron failures (Closes: #9292870)
-- Theodore Y. Ts'o Mon, 20 May 2019 21:48:40 -0400
e2fsprogs (1.45.1-2) unstable; urgency=medium
This was a regression that was reported at:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1807288
... a fix has been applied uptream and the fix has been cherry picked
for Ubuntu. See the above bug for details.
--
You received this bug notification because you are a member of
Yep, it looks like it was a regression that was introduced by commit
50d0998cfee ("libext2fs: add ea_inode support to set xattr"). The
following patch should fix things.
** Patch added:
"0001-libext2fs-fix-regression-so-we-are-correctly-transla.patch"
On Mon, Dec 03, 2018 at 08:24:07AM -, Tor Stenvaag wrote:
> The maint branch indeed fixed the problem. Output attached. Thanks for
> your effort.
>
> (There is still a "warning" about "extent tree (at level 1) could be
> narrower. Fix? yes" when running e2fsck after resize. When selecting
>
This looks like a dup of
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1798562
and is fixed by:
commit 4b3038134baf81c6f9bd36dbbf565ea66e46331f
Author: Theodore Ts'o
Date: Sat Oct 20 09:14:48 2018 -0400
resize2fs: update checksums in the extent tree's relocated block
*** This bug is a duplicate of bug 1798562 ***
https://bugs.launchpad.net/bugs/1798562
** This bug has been marked a duplicate of bug 1798562
After a side by side installation, resized filesystem is corrupted
--
You received this bug notification because you are a member of Ubuntu
Touch
*** This bug is a duplicate of bug 1798562 ***
https://bugs.launchpad.net/bugs/1798562
** This bug has been marked a duplicate of bug 1798562
After a side by side installation, resized filesystem is corrupted
--
You received this bug notification because you are a member of Ubuntu
Touch
.
Addresses-Launchpad-Bug: 1798562
Signed-off-by: Theodore Ts'o
Reported-by: Jean-Baptiste Lallement
I've tested e2fsprogs with this change and it fixes your repro. I also
have a regression test in the subsequent commit which reproduces the
problem with a smaller test file
This is probably not assigned to the right package. It's not an issue
with e2fsprogs, but whatever component is running fsck. This might be
systemd, or upstart, or whatever the heck Ubuntu is using these days.
I lost track a while ago. :-)
I can tell, you as the Debian maintainer of
Note a file system which is significantly shrunk --- which tends to be
the case with resize2fs -M --- is going to have files fragmented which
will have performance implications. It's not clear to me what you are
trying to optimize for --- I assume you're just wanting to save on
download
-off-by: Darrick J. Wong
Signed-off-by: Theodore Ts'o
In the course of fixing the above bug, it means that if there was a need
to grow file system which is nearly full, and the resize is being done
off-line, and there is a need to grow the file system, we will end up
failing as described
This is almost certainly fixed via this patch:
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?h=maint=b0ec76d623f737a32abc5ab8bb7198bf1d9939a4
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in
Yes, this has been fixed quite a while ago. :-)
Online resize with flex_bg was fixed in 2012 --- call with the v3.10
kernel or so.
Offline resize was fixed around that time (e2fsprogs 1.43), but there
have been some bugs with flex_bg and off-line resizing, so I'd recommend
using at least
OK so it looks like you were trying to shrink a file system from 59G to
30G (using an off-line resize, since on-line resizing only supports
growing a file system).
Hmm are you willing to send me (probably off-line) a metadata-only
dump of the "before" file system? See the e2image page, and
#1 Was this an on-line or off-line resize? That is, was the file
system mounted at the time when you ran resize2fs?
#2 Can you post a copy of dumpe2fs before you started to resize?
#3 How big were you trying to resize the file system to become?
It's great that you have a snapshot of the
Thanks, fixed in upstream e2fsprogs-maint. Will be in next 1.44.x
release of e2fsprogs.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1743553
Title:
[Typo] Missing
The blog post here:
https://raid6.com.au/posts/fs_ext4_external_journal_caveats/
is not generally true. What journal_async_commit does is convert the
sequence:
1. write journal blocks
2. cache flush
3. write journal commit block
4. cache flush
... to:
1. write journal blocks
2. write
Your system sounds like its thrashing due your processes wanting to you
more memory than is available in your system. (BTW, this has nothing to
do with e2fsprogs).
Some links to pages that might be helpful:
If you are trying to build from the unpacked debian sources for 1.43.x,
you'll need to run the commands:
./debian/rules mrproper
./debian/rules
... to have the build system figure out which antique version of Debian
build infrastructure you are using, and regenerate debian/control from
The Metadata_csum feature is a RO_COMPAT feature. Hence, grub2 and os-
prober shouldn't care about this feature (if properly implemented).
This is because the guarntee is that even if the kernel (or userspace
application directly accessing the file system) doesn't know about a bit
in the
E2fsprogs 1.44.0 now depends on dpkg build-profiles, which means that
getting it backported to 14.04 LTS would require adjusting
debian/control and debian/rules a bit. For 14.04 LTS, I'd urge
consideration of going to e2fsprogs 1.43.9. This will get you most of
the latest bug fixes, including
I recently released e2fsprogs 1.44.0 (currently in Debian Unstable,
should hopefully hit Debian Testing in three more days) which turns on
Metadata Checksums for everyone.
https://packages.debian.org/sid/e2fsprogs
Pulling in 1.44.0 supports two new features, largedir and ea_inode,
(neither
It should be noted that I recently released e2fsprogs 1.44.0 (currently
in Debian Unstable, should hopefully hit Debian Testing in three more
days) which turns on Metadata Checksums for everyone.
https://packages.debian.org/sid/e2fsprogs
Pulling in 1.44.0 into 18.04 LTS would be nice since it
Note that libcomerr2 has been renamed to libcom-err2 to conform with
Debian's packaging naming guidelines. So libcomerr2 is now a
transitional package (arch=all) where previously it was a binary
package.
Why this is failing on Ubuntu is a complete mystery to me. On Debian
Unstable, using
** Summary changed:
- fsck should check before running on an encrypted LUKS partition
+ Obsolete backup ext2/3/4 superblocks can confuse e2fsck on an encrypted LUKS
partition
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to
Note: I think this should be a low-priority/wishlist/feature request.
But I can't edit the importance.It is a valid feature request
though, so I plan to treat it at that priority.
If someone else thinks it's higher priority, patches are welcome. :-)
** Changed in: cryptsetup (Ubuntu)
So what happened is the following. There was a previous ext4 file
system on the disk. You ran "cryptsetup luksFormat /dev/sda1" which
wiped out the primary superblock.
You then manually ran fsck.ext4 on the device. It noticed the primary
superblock was non-existent, and then asked permission
The commit is upstream in git now:
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?h=maint=c8ca23979fa75df15208922422e81c83cf112320
I will be releasing e2fsprogs 1.43.5 soonish and I plan to do a release
to Debian Unstable/Testing at the same time. So you might just want to
wait for
The errors simply mean that ext4 has detected that its metadata has
gotten corrupted. How and why it happened is going to vary from
situation to situation.
For example, in the case of the original reporter, it was due to him
installing ext2fsd, and trying to access the file system from windows.
You don't need to check with upstream e2fsprogs; I do keep an eye on
Launchpad bugs.
None of UBSAN warnings are actually dangerous assuming sane[1] compilers
and reasonable architecture. (e.g., a compiler that can correctly
compile the Linux kernel and an architecture that run Linux should have
I would recommend doing an on-line resize. That code path should work
for you.
As far as why the off-line resize is hanging, you would need to run it
with debugging symbols under gdb and then stop it and submit a stack
trace so we can see where it is hanging.
--
You received this bug
Was released a ***long*** time ago. Guess Canonical doesn't do this
automatically.
** Changed in: e2fsprogs (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in
Fix is in e2fsprogs 1.43.4
** Changed in: e2fsprogs (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1645232
Title:
I've committed a complete fix to the master branch of the e2fsprogs git
tree.
One of the reasons why I don't want to commit a partial fix is because
the potential for corruption of production file systems by programs such
as fuse2fs was extremely high. Users of mke2fs -d are generally
embedded
I was hoping you would be interested in further refining the patch which
you put forward. But if you don't have the time or interest, that's
fine, I'll put it on my queue of things on my todo list. (Or maybe
someone from Canonical will be interested in picking this up.)
--
You received this
Thanks for the patch; it definitely helps identify the problem. I don't
think it is a completely correct change, however.
The problem is that it's doing the translation in
write_xattrs_to_buffer(), but it is not making the translation in the
opposite direction in read_xattrs_to_buffer(). This
Is it always the same inode number which is reported as having an
invalid checksum?
Can you attach the output of dumpe2fs -h /dev/hdXX (where hdXX should be
replaced with the block device name of your file system)?
--
You received this bug notification because you are a member of Ubuntu
Touch
One bit of context --- metadata_csum is not enabled by default in the
official upstream e2fsprogs.tar.gz file. So with my upstream maintainer
hat, I deliberately decided not to enable it by default, and mentioned
in the release notes that individual distributions should decide whether
they wanted
Known problem, fixed in e2fsprogs 1.42.2 or 1.42.3 in commit:
commit 3d6fc974831a360aee460e54c442538445f3017c
Author: Theodore Ts'o <ty...@mit.edu>
Date: Wed Aug 10 15:49:35 2016 -0400
resize2fs: fix crash when there is an ea block and no blocks to migrate
This fixes
Rolf, can you collect the requested logs? I think this is pointless
since it's pretty clear that there's a commit that just needs to be
backported, but that's between use and the Ubuntu Kernel team to figure
out. Or you can just use the upstream 4.7 kernel. :-)
--
You received this bug
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Changed in: e2fsprogs (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
This is not an e2fsprogs bug, but a bug in the kernel. The fix is in
mainline as of v4.7, commit id: 4c63c2454eff996. It needs to be ported
to the Ubuntu Trusted (and other Ubuntu LTS) kernels.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
Looks like you are using a pre-3.18 kernel with e2fsprogs 1.43.1. I'm
guessing this is because whatever cloud service you are using is using a
very old kernel? (In contrast, Yakkety Yak is using a 4.x kernel.)
What kernel version is this cloud service using, anyway? I want to
make a mental
You may want to recheck the merge, or at least the remaining changes,
since Debian e2fsprogs 1.43.1 now:
a) Uses dh_update_autotools_config to update config.guess / config.guess
b) No longer uses dietlibc
c) Generates dbgsym packages if the underlying package infrastructure supports
them
At
There wasn't actually an *error*. E4defrag doesn't need root prives to
find and print statistics. It doesn't deliberately because the people
who wrote the program decided this was the right thing to do. So it's
not actually hiding the error, it's just doing something weird/stupid.
Which you
this bug was not reproducible in 2011 and could not be reproduced as far
back as Lucid. Might as well close this since there has been no
activity since then.
** Changed in: e2fsprogs (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Fixed in 2013.
** Changed in: e2fsprogs (Ubuntu)
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1186331
Title:
[PATCH] e2fsck
Has fsck run spit out any errors or output?If you have a completion
output, has it given an percentage output, or some other way of
determining how far along fsck is going?
When e2image wouldn't create an image file, did it report any errors?
--
You received this bug notification because
On Sun, Mar 27, 2016 at 03:25:40AM -, DD Park wrote:
> Hello, I need your help. This bug seemed to have been placed offline due to
> inactivity. It is still a problem as been working on moving things around
> to get a testing platform. I've been getting new hardware, and started
> another
You do realize that e2image doesn't contain any data blocks --- just
file system metadata blocks, right? And if you are concerned about the
directory names being too revealing, e2image has a -s option which will
scramble the directory file names. See the section "RAW IMAGE FILES" in
the e2image
There are plenty of people who *are* able to check file systems larger than
16TB. So talking about it in terms "that problem" doesn't make much sense.
*** This bug is a duplicate of bug 1438405 ***
https://bugs.launchpad.net/bugs/1438405
Can someone make the private bug public, if there is no private
information in that bug report?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
The badblocks program really isn't designed to catch maliciously
designed fake flash FTL's. The bit dropping pages aren't
necessarily constant, which means there might not be a set of block
numbers that you can _put_ in the bad block inode. The bad block inode
is a bad idea in these modern days
It's not e2fsprogs' responsibility to remove the /forcefsck file. It is
the job of initscripts.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1229618
Title:
Saucy:
Changing to invalid, will not fix upsteam.
** Changed in: e2fsprogs (Ubuntu)
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1415077
):
resize #1 resize #2 resize #3
old resize2fs1117186 45679 43536
new resize2fs 48784 37413 37392
Signed-off-by: Theodore Ts'o ty...@mit.edu
Note that using resize2fs -M multiple times will result in a file system
which is *not* optimized
The file system which I posted in #6 no longer triggers a bug in
1.42.12. It looks like it was fixed as a side effect of commit
9a1d614df217. @bigeel, what version of e2fsck were you using?
Could you try using e2fsprogs 1.42.12 and see if that fixes the problem
for you?
Thanks!!
--
You
To explain the e2fsprogs git branch naming scheme in terms of Debian
releases:
* maint == stable (and currently has a few bug fixes beyond what is in
1.42.12, although it's unlikely we will have a 1.42.13 release unless something
really serious comes up)
* master == testing (and has the inline
Just use the master branch of e2fsprogs; the pu branch is currently not
actually active, and when it is, it has experiments in it that might not
necessarily be ready for primetime.
The master branch should be good enough for both the inline data and
metadata checksum features.
--
You received
Note: if you want to use inline data, please strongly consider using the
upstream kernel; there are a lot of bugs that we're only now shaking
out.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
Note that there were bugs found that necessitated format changes for
metadata checksums in 3.18 --- which was released earlier this week.
E2fsprogs 1.43 hasn't been released yet, and e2fsprogs 1.42 has
***no support for metadata checksums.
People who are interested in testing metadata
If you can see the GPF happen when mkfs.ext3 is writing to a bare
block device (/dev/sdc1 or /dev/sdd1), then it's not involving the
file system code at all, but just the block device or device driver
code. It's clearly not a file system bug at all, nor is it a
e2fsprogs bug, because nothing from
Can you try running memtest86+ for 12-24 hours, and see if that turns
up anything? Sometimes flaky memory can result in very confusing
problems / symptoms --- espeially when it almost but not always works
correctly.
The other thing which I might be suspicious about is if there might be
some
1) e2fsck (which is what fsck.ext[234] is hard linked to) is designed
to be safe when getting interrupted by ^C
2) The all kernel code uses the same address space. So if there is a
wild pointer in the Nvidia driver scribbles on random kernel memory,
literally anything can happen. There is a
It depends on the version of e2fsprogs in Ubuntu (which is't specified
in this bug report).
The bug appeared in 1.42.9-3, and was fixed in 1.42.11-1. The bigalloc
file system is also notone which is used by default by most users. (and
probably shouldn't be unless you really know what you are
Confirmed on an NTFS file system. It applies for those file systems
that do not support the FIEMAP ioctl, and so filefrag has to fall back
to the legacy (and far more inefficient) FIBMAP ioctl.
** Changed in: e2fsprogs (Ubuntu)
Status: New = Confirmed
--
You received this bug
The extent count calculation works correctly with the FIBMAP ioctl in
verbose (-v) mode, but without the verbose option, the calculation was
broken because we weren't properly updating the fm_ext data structures
in non-verbose mode.
Addresses-Launchpad-Bug: #1356496
Signed-off-by: Theodore Ts'o
92 matches
Mail list logo
