[Bug 1939409] Re: e2fsprogs 1.46.3-1 on architecture s390x fails in test f_baddotdir
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 very noticeable by many Ubuntu users, In fact, nearly all of the changes in 1.46.4 are bug fixes, designed so because engineers from a number of distributions attend the weekly ext4 development call, and 1.46.4 was designed to meet the needs of companies taking snapshots for enterprise distros (in the RHEL and SLE ecosystems) to be released in 2022 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1939409 Title: e2fsprogs 1.46.3-1 on architecture s390x fails in test f_baddotdir To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939409/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1939238] Re: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
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 changes they want to a package. (At which point they own any liability if the user is clueless enough that they need that amount of hand holding, but if that information is just enough to cause them to attempt to do a file system fixup, but they then lose files because they fumble the job, that's on Ubuntu, not on me.) Or perhaps Canonical could put a multiple page, or even a book-length tutorial in its initramfs scripts that tries to teach all eventualities of what a user might need to fix when they run e2fsck by hand, if fsck exits with an error code indicating that the file system needs to be fixed by hand. Again, feel free to convince canonical to do something like that if it's really needed by novice users. Personally, I think it's roughly equivalent to trying to teach medicine to a novice as opposed to telling them to see a doctor, but hey, Ubuntu can try to break ground by trying to lead users by the hand. I do predict that after you tell users to "hit fsck /dev/xx", what will happen next is users will go to forum.ubuntu-fr.org and ask, how do I answer this question? I'm so confused Where does this end? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1939238 Title: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939238/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1939409] Re: e2fsprogs 1.46.3-1 on architecture s390x fails in test f_baddotdir
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 systems for the GNU Hurd, which only supports 128 byte inodes). Creating non-Hurd file systems with 128 byte inodes will trigger a warning message to make sure users are aware of the potential problems of using small/legacy inode sizes. The bigalloc feature is now considered supported if the cluster size no more than 16 times the block size. So the mke2fs program has been changes to only warn if the cluster size is larger than that. Fixes - E2fsck now checks to make sure directory entries do not reference internal quota inodes. E2image now includes the quota inodes when creating file system image, since they are part of the file system metadata. E2fsck now properly accounts the quota usage of the project quota file. 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) Fix mke2fs to correctly create Posix ACL's on big-endian systems when copying files from a directory hierarchy. Updated and clarified the resize2fs man pages. (Addresses Debian Bug: #979411) Performance, Internal Implementation, Development Support etc. -- Improve various regression tests to be more portable and to reflect the new default inode size of 256 byte inodes, even for small file systems. Fixed a GNU Hurd portability problem which was causing tests to fail. Fixed a test failure in f_baddotdir on big-endian systems. This wasn't necessarily a bug per se in e2fsck, but rather e2fsck having different behaviour on big-endian systems. (Addresses Debian Bug: #991922) Use WantedBy=multi-user.target in e2scrub_reap.service. (Addresses Debian Bug: #991349) Synchronize e2fsck/recovery.c with the kernel's fs/jbd2/recovery.c Fix various Coverity and compiler warnings. Fix various error pathes to make sure we don't leak resources or potentially use or try to free uninitialized pointers. Added a setup-schroot command for use on Debian porter boxes. Updated config.guess and config.sub with newer versions from the FSF. Update Czech, Dutch, French, Polish, Portuguese, and Swedish translations. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1939409 Title: e2fsprogs 1.46.3-1 on architecture s390x fails in test f_baddotdir To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939409/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1939238] Re: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
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 -y. But there is the chance you may lose data that you might have been able to recover if you had more skills. Note that in the case that you referenced, the kernel had already detected some kind of file system inconsistency. That is the source of the "/dev/sda1 contains a file system with errors, checked force". This should not happen, unless there is some kind of hardware bug, or kernel bug which has led to the file system getting corrupted. This could be caused by flaky/low-quality/failing memory, or flaky/low- quality/failing HDD or SSD. An expert would have to look at the kernel logs for hints to see what might have gone wrong. If the user has regularly been doing backups, then sure, maybe you don't care they can just run "fsck -y".But I don't want to give that advice, only to hear that some graduate student had ten years worth of thesis research, and it wasn't backed up, and they were using the lowest possible cost HDD or SSD that was not reliably storing their data. Sometimes, the best thing to do for low-comptency users, is for them to ask for help, maybe at a local Linux User's Group, so that an expert can try help them out.There is no magic incantation, no kind of "Hocus Pocus" magic set of instructions that will always do the right thing. And to give "low competency users" instructions which might not be the best thing is ultimately, IMHO, going to doing them a grave disservice. P.S. One could argue that a graduate student who has ten years of research on cheap sh*t storage and who hasn't been doing their backups doesn't deserve to graduate with a Ph.D. But that's not a very charitable attitude -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1939238 Title: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939238/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1939409] Re: merge e2fsprogs 1.46.3-1 from Debian: s390x fails in test f_baddotdir
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 gracefully if possible")
changed the check_dot() function to try to avoid resetting the '..'
entry when the '.' entry is too large.. But if we do that, then on
big-endian systems, we need to try byte swapping the rest of the
directory entries, or else the f_baddotdir test will fail on
big-endian systems.
Also add a check to avoid UBSAN warning when there is not enough space
at the end of the directory block for a directory entry, and so we can
potentially overflow some pointer arithmetic when trying to byte swap
the remainder of the (negative) space in the directory block.
Fixes: 63f44aafb1f2 ("e2fsck: fix ".." more gracefully if possible")
Signed-off-by: Theodore Ts'o
commit 7a97083d4350b93f4055bdd8465667cecbb36438
Author: Theodore Ts'o
Date: Fri Jul 30 12:29:44 2021 -0400
libext2fs: fix translation of Posix ACL's on big-endian systems
The ACL returned by the kernel in lgetxattr(2) is returned in Little
Endian, even on Big Endian systems. Fix the functions
convert_posix_acl_to_disk_buffer() and convert_disk_buffer_to_posix_acl()
to work correctly on Big Endian systems. This fixes a failure of
the test m_rootdir_acl.
Signed-off-by: Theodore Ts'o
As I mentioned responding to another bug report, e2fsprogs's maint
branch is currently in a translation freeze pending an upcoming 1.46.4
release. PTAL and let me know if you see other issues. (You probably
don't care for Ubuntu but 1.46.4 should also fix some portability issues
for GNU Hurd.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1939409
Title:
merge e2fsprogs 1.46.3-1 from Debian: s390x fails in test f_baddotdir
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939409/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1939238] Re: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
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, not mine), yes this may be beyond their capabilities. But there is a reason why some jobs, like for example, fixing airplane engines, requires people who are "competent", and certified to be so.If you have a full set of backups, then sure, you could try using fsck -y, and if that leads to unacceptable data loss, it's possible that you could recover more data by selective use of answering some fsck questions, and using debugfs. The problem is that "users who are not competent" are also not likely to be doing regular backups of their data. :-( -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1939238 Title: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939238/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1935656] Re: e2fsprogs FTBFS when built with libfuse3-dev
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 e2fsprogs maintainer (me) also doesn't have much motivation to switch to Fuse3 either, as I have many other fires burning on my plate. Patches so e2fsprogs can auto-detect the presence of the fuse3 header files and libraries in the autoconf file, and then adding the appropriate #ifdef's so that fuse2fs can work with either Fuse2 or Fuse3 would be gratefully accepted. :-) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1935656 Title: e2fsprogs FTBFS when built with libfuse3-dev To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1935656/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1897741] Re: hang after using util badblocks
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 investigation; can it be reliably reproduced? What kernel version is it? What is the hardware --- especially what kind of storage device, and how is it connected to the computer?If you hook up a serial console, are there any interesting kernel messages, including potentially device driver messages indicating some kind of hardware issue (e.g., media errors, etc.) In any case, this needs to be redirected to the kernel, and if you have an LTS support contract, I'd suggest contacting Canonical's enterprise support to work the kernel issue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1897741 Title: hang after using util badblocks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1897741/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1881935] Re: Minimum inode size should be raised to 256 for forward compatibility (Y2038)
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 the GNU Hurd can support modern file systems with 256 byte inodes. Heck, the GNU Hurd implementation doesn't support journalling or extents last I checked.) This will double the overhead of ext4 file systems, especially on small file systems. This is why the default is set the way that it is. For really tiny thumb drives (especially the cheap ones found in the checkout aisle of the Micro Center), they are very likely to self- destruct within a few months, never mind 18 years. And users might get cranky if the amount of usable space is decreased. It may be that for the installer, it will want to hard code the use of a larger inode size, or specify a file system usage type hint via the -T option which could trigger a different default in mke2fs.conf.This is fundamentally a policy question, not a technical issue --- and different distributions may have different opinions about what the defaults should be; this is why we've made it easy to customize the defaults should be in misc/mke2fs.conf.in in the sources, as opposed to hard-coding it in the misc/mke2fs.c source file. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1881935 Title: Minimum inode size should be raised to 256 for forward compatibility (Y2038) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1881935/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1860917] Re: uas_eh_abort_handler uas-tag inflight OUT
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 problem. One thing I would suggest is running e2fsck -f after shrinking the file system using resize2fs. If there is any corruption that you can see when using resize2fs with shrinking, preferably with a fixed HDD or SSD which is known to be good (USB cable instability is a nightmare and I generally don't recommend people to use USB attached storage on laptops because laptops tend to move, and USB cables getting jostled is a really common problem). So from a problem isolation perspective, it's really helpful to try to isolate variables. So if you can try to isolate the problem using a image file stored on a fixed storage device, and then try shrinking the file system on the image, so we don't have to worry about gpart bugs, hardware bugs, etc., that is really helpful.And if you use e2fsck to make sure the file system is consistent, as opposed to waiting for the kernel to trip on the file corruption, that would be also very helpful. If you are paying $$$ to Canonical, then there will be much more likely to be Ubuntu support engineers will do this sort of fault determination procedure. As an upstream developer for e2fsprogs, however, I'm really not going to get involved until you can give me a reproducible test case that doesn't require your specific hardware --- hence the request to see if you can reproduce the problem using an image file without using hardware and partitions. If this is really dependent on which partition is involved, then this might be a gpart bug. And no one (and certainly Canonical!) is paying me to try to debug gpart. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1860917 Title: uas_eh_abort_handler uas-tag inflight OUT To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1860917/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1860676] Re: apt-get dist-upgrade -y hangs during e2fsprogs update
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, given that it is running as root.
{/home/tytso}
1046% sudo systemctl restart e2scrub_reap.service
[sudo] password for tytso:
{/home/tytso}
1047% sudo systemctl status e2scrub_reap.service
● e2scrub_reap.service - Remove Stale Online ext4 Metadata Check Snapshots
Loaded: loaded (/lib/systemd/system/e2scrub_reap.service; enabled; vendor
preset: enabled)
Active: inactive (dead) since Fri 2020-01-24 22:20:55 EST; 3s ago
Docs: man:e2scrub_all(8)
Process: 1106527 ExecStart=/sbin/e2scrub_all -A -r (code=exited,
status=0/SUCCESS)
Main PID: 1106527 (code=exited, status=0/SUCCESS)
Jan 24 22:20:55 lambda systemd[1]: Starting Remove Stale Online ext4 Metadata
Check Snapshots...
Jan 24 22:20:55 lambda systemd[1]: e2scrub_reap.service: Succeeded.
Jan 24 22:20:55 lambda systemd[1]: Started Remove Stale Online ext4 Metadata
Check Snapshots.
It is true that /sbin/e2scrub_all has changed significantly between
1.45.3 and 1.45.5; but it looked like you never got as far as actually
executing e2scrub_reap.service, and if it did, it shouldn't be calling
systemctl in reap mode.
Does "sudo /sbin/e2scrub_all -A -r" hang for you?
The only other thing which you might try i, commenting out this line
from /lib/systemd/system/e2scrpb_reap.service, and see if it fixes the
hang:
AmbientCapabilities=CAP_SYS_ADMIN CAP_SYS_RAWIO
If it does, I have no idea why it might be working for me using Debian
testing (which is using systemd 244-3) and why it ight be failing for
you with Ubuntu. Remember, systemd is your *friend*. It is the best
init replacement compared to all the others. All Hail Systemd! :-/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1860676
Title:
apt-get dist-upgrade -y hangs during e2fsprogs update
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1860676/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1857914] Re: resize2fs destroy the content of the partition
Can you provide an exact set of commands to create the file system, populate the file system, that *anyone* (but especially, the developers that you are asking to looking at the bug) to replicate this failure? In particular, how is the file system is created (the exact mke2fs command) and the set of files that were used to populate the file system. Is it sensitive to the set of files? Also, can you replicate it on some other storage device? If the exact sequence on a normal file doesn't reproduce, but it does on a hardware device, the first question that comes to mind is whether there is something wrong with the storage device --- since it really shouldn't make the difference whether you are using a file system image versus an external storage device. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1857914 Title: resize2fs destroy the content of the partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gpart/+bug/1857914/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1857914] Re: resize2fs destroy the content of the partition
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 this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1857914 Title: resize2fs destroy the content of the partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gpart/+bug/1857914/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1857914] Re: resize2fs destroy the content of the partition
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1857914 Title: resize2fs destroy the content of the partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1857914/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1857914] Re: resize2fs destroy the content of the partition
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 /path/to/fs.img 20G mount -o loop /path/to/fs.img /mnt umount /mnt e2fsck -fy /path/to/fs.img resize2fs /path/to/fs.img 30G If it does require gpart being in the mix, this could very much be a gpart bug, in which case I'll be happy to hand this off to the gpart maintainer. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1857914 Title: resize2fs destroy the content of the partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1857914/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1830500] Re: Issue with e2scrub@-.service and e2scrub@-boot.service which tries to scrub ext4 partitions (/boot and /)
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1830500 Title: Issue with e2scrub@-.service and e2scrub@-boot.service which tries to scrub ext4 partitions (/boot and /) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1830500/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1830500] Re: Issue with e2scrub@-.service and e2scrub@-boot.service which tries to scrub ext4 partitions (/boot and /)
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 * Avoid spurious e2scrub_all error messages spamming administrators from cron/systemd timer units when lvm2 is not installed and/or there are no lvm devices present in the system (Closes: #928977, #929186, #929254) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1830500 Title: Issue with e2scrub@-.service and e2scrub@-boot.service which tries to scrub ext4 partitions (/boot and /) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1830500/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1645232] Re: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL)
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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1645232 Title: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1645232/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1807288] Re: mkfs.ext4 -d $directory_with_acls leads to EINVAL
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"
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1807288/+attachment/5219885/+files/0001-libext2fs-fix-regression-so-we-are-correctly-transla.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1807288
Title:
mkfs.ext4 -d $directory_with_acls leads to EINVAL
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1807288/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1806272] Re: resize2fs results in ext4 filesystem with warning/errors
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 > yes and running the e2fsck once more the warning is still present.) Ah... that's interesting. So to be clear, if you run: e2fsck -fy /dev/skole-vg/root twice, the second time, you will still see: Inode 8 extent tree (at level 1) could be narrower. Fix? yes ... on the second run. Is that correct? Hmmm. can you send me the output of: debugfs -R "extents <8>" /dev/skole-vg/root Many thanks!! - Ted -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1806272 Title: resize2fs results in ext4 filesystem with warning/errors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1806272/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1806272] Re: resize2fs results in ext4 filesystem with warning/errors
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 When shrinking an file system, and we need to relocate an inode, the checksums in its extent tree must get updated to reflect its new inode number. When doing this, we need to do this *after* we update the extent tree to reflect any blocks which need to be relocated due to the file system shrink operation. Otherwise, in the case where only an interior node of the extent tree needs to get relocated, and none of the entries in that node need to be adjusted, the checksum for that interior node is updated in the old copy of that block, and then after the extent tree is updated to use the new copy of that interior node, the extent tree is left with an invalid checksum. This is a relatively rare case, since it requires the following conditions to be true: *) The metadata checksum feature must be enabled. *) An inode needs to be relocated. *) The inode needs to have an interior node. *) The block for that interior node needs to be relocated. *) None of blocks addressed by entries in that interior node needs to be relocated. When all of these conditions are true, though, the file system is left with corrupted with bad checksum for the extent tree block. Addresses-Launchpad-Bug: 1798562 Signed-off-by: Theodore Ts'o Reported-by: Jean-Baptiste Lallement If you're up for downloading the latest maint branch from e2fsprogs and give it a try to see if it fixes your issue, since you have a reliable repro, I would really appreciate it. Thanks!! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1806272 Title: resize2fs results in ext4 filesystem with warning/errors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1806272/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1778140] Re: resize2fs hoses a filesystem on lvm after resizing
*** 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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1778140 Title: resize2fs hoses a filesystem on lvm after resizing To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1778140/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1783757] Re: shrinking previous file systems makes them corrupted
*** 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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1783757 Title: shrinking previous file systems makes them corrupted To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1783757/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1798562] Re: After a side by side installation, resized filesystem is corrupted
Thanks for the very nice repro!I've created a fix which will be going into the maint branch of the e2fsprogs tree. The commit description: resize2fs: update checksums in the extent tree's relocated block When shrinking an file system, and we need to relocate an inode, the checksums in its extent tree must get updated to reflect its new inode number. When doing this, we need to do this *after* we update the extent tree to reflect any blocks which need to be relocated due to the file system shrink operation. Otherwise, in the case where only an interior node of the extent tree needs to get relocated, and none of the entries in that node need to be adjusted, the checksum for that interior node is updated in the old copy of that block, and then after the extent tree is updated to use the new copy of that interior node, the extent tree is left with an invalid checksum. This is a relatively rare case, since it requires the following conditions to be true: *) The metadata checksum feature must be enabled. *) An inode needs to be relocated. *) The inode needs to have an interior node. *) The block for that interior node needs to be relocated. *) None of blocks addressed by entries in that interior node needs to be relocated. When all of these conditions are true, though, the file system is left with corrupted with bad checksum for the extent tree block. 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 system. ** Patch added: "resize2fs: update checksums in the extent tree's relocated block" https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1798562/+attachment/5203340/+files/0001-resize2fs-update-checksums-in-the-extent-tree-s-relo.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1798562 Title: After a side by side installation, resized filesystem is corrupted To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1798562/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1797282] Re: fsck not running at all on reboot
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 e2fsprogs, that fsck runs *just* *fine* on Debian testing. With Debian, using systemd (which is the default), the systemd units which run fsck are generated by the systemd-fstab-generator program which is part of systemd. So the main issue is whether anyone on the Canonical/Ubuntu team is paying attention. I pay attention in case people report e2fsprogs bugs, but this is not an e2fsprogs issue. And I don't use Ubuntu so I can't really help. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1797282 Title: fsck not running at all on reboot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1797282/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1796788] Re: resize2fs: Illegal indirect block found while trying to resize
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 bandwidth so you want a highly compressed image? You might want to consider using a raw qemu image, e.g: e2image -Q /dev/sda1 /tmp/sda1.qcow bzip /tmp/sda1.qcow # optional which can then be unpacked via: bunzip /tmp/sda1.qcow.bz2 e2image -r /dev/sda1.qcow /dev/sda1 You can of course also use qemu-img from the qemu package. e2image -Q is a bit more efficient though since it will only include blocks which are in use in the file system, where as qemu-img is not aware of the underlying file system. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1796788 Title: resize2fs: Illegal indirect block found while trying to resize To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1796788/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1796788] Re: resize2fs: Illegal indirect block found while trying to resize
Yep, I can reproduce the problem. It bisected to: commit 538ef363261b4f851ca69f342336aa896e24eb27 (refs/bisect/bad) Author: Darrick J. Wong Date: Sun Dec 14 22:13:09 2014 -0500 resize2fs: don't play stupid games with the block count While it may be true that playing games with old_fs' block count during a grow operation shuts up a bunch of warnings, resize2fs doesn't actually expand the group descriptor array to match the size we're artificially stuffing into old_fs, which means that if we actually need to allocate a block out of the larger fs (i.e. we're in desperation mode), ext2fs_block_alloc_stats2() scribbles on the heap, leading to crashes if you're lucky and FS corruption if not. So, rip that piece out and turn off com_err warnings properly and add a test case to deal with growing a nearly full filesystem. Signed-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 in the bug. This is a very rare set of circumstances, which is why it hadn't been noticed for three years. I'm curious how the bug reporter came across it. Also note that it's strongly recommended that online resize be used whenever possible, as this actually tends to be the much more well- tested path. It's a real bug, but it's going to be lower priority to fix. ** Attachment added: "Bisection log" https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1796788/+attachment/5199134/+files/bisect.log ** Changed in: e2fsprogs (Ubuntu) Status: New => Confirmed ** Changed in: e2fsprogs (Ubuntu) Assignee: (unassigned) => Theodore Ts'o (tytso) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1796788 Title: resize2fs: Illegal indirect block found while trying to resize To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1796788/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1796379] Re: dumpe2fs crashed with SIGSEGV in e2p_is_null_uuid()
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1796379 Title: dumpe2fs crashed with SIGSEGV in e2p_is_null_uuid() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1796379/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 575542] Re: resize2fs does not respect flex_bg
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 e2fsprogs 1.44.x if you want to off-line resize file systems with flex_bg. And on-line resizing is actually going to be safer in general --- mainly because it's less capable --- the scary bits with off-line resizing are things that on-line resize can't do, like shrink the file system or move the inode table around to make room for more block group descriptors than were originally reserved at mkfs time. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/575542 Title: resize2fs does not respect flex_bg To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/575542/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1778140] Re: resize2fs hoses a filesystem on lvm after resizing
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 read the section "QCOW2 IMAGE FILES". I can use the metadata-only file system to reproduce the problem on my end, by running resize2fs on the raw metadat-only file system. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1778140 Title: resize2fs hoses a filesystem on lvm after resizing To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1778140/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1778140] Re: resize2fs hoses a filesystem on lvm after resizing
#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 file system pre-resize, since that means we can test potential fixes. If you can keep a snapshot of that exist file system image while I investigate this failure, it would be much appreciated. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1778140 Title: resize2fs hoses a filesystem on lvm after resizing To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1778140/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1743553] Re: [Typo] Missing word in Zesty Man Page for e4defrag
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1743553 Title: [Typo] Missing word in Zesty Man Page for e4defrag To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1743553/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1365874] Re: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming
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 journal commit block 3. cache flush This tends to make a lot of difference on HDD's from a performance perspective, because a cache flush commands are so expensive. On an SSD with a competently implemented flash translation layer (FTL), it shouldn't make much of a difference from a performance perspective, and it shouldn't hardly any difference from write endurance perspective. The way flash works is that flash chips are organized into erase blocks, which might be say, 64k. This is the minimal size must be erased as a unit. Once an erase block is cleared (which is the slow operation) it can be written a flash page (typically 4k in size) at a time. Once a flash page is written, it can't be erased except by erasing the entire erase block. If most of the erase blocks are filled, either with real data, or with garbage (former data contents which have been superceded), then it might be necessary to copy the still-used data contents to other erase blocks, so that an erase block can be emptied so it can be erased. If it is necessary to do those extra copies before the erase block can be rebase, this is cause of the "write amplifification" effect. However, doing an extra CACHE FLUSH operation (which is what journal_async_commit eliminates) should not make any difference on any competently implemented FTL on a normal SSD. The place where it make a difference is on what gets referred to as "cost optimized" flash in polite company, or "crap flash" by more honest engineers. You will most often find this in eMMC flash or SD cards found in the cash register aisle of Micro Center (assuming of course, that you actually get honestly labelled flash as opposed to a SD card claiming to have 1G of flash, but which is only backed by 16 MB of flash --- such that the 16MB + 4k write will end up overwriting previously written data).In these "cost optimized" flash, the FTL may end up mapping each 64k erase page to a 64k LBA address space. In that case, a 4k write followed by a cache flush will end up being the equivalent of a 64k flash erase/write. In the even more awful "crappy flash", each 64k erase block is direct mapped to a 64k LBA address space. In that case, if you are constantly overwriting any portion of the flash (either the FAT table for FAT file systems, or the journal in ext4), then those erase blocks will get worn out first --- and once they are worn out, the flash device becomes broken. But I emphasize that this is really only a problem for crap flash. For a normal SSD with a competent FTL, the use of journal_async_commit (or not using journal_async_commit) should not make any real difference to how long your flash device lasts. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1764180] Re: System slows down to almost freeze
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: http://blog.scoutapp.com/articles/2015/04/10/understanding-page-faults-and-memory-swap-in-outs-when-should-you-worry https://serverfault.com/questions/77461/how-do-i-measure-disk-thrashing-on-linux https://unix.stackexchange.com/questions/259223/memory-usage-inexorably-creeping-upward -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1764180 Title: System slows down to almost freeze To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1764180/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1365874] Re: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming
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 debian/control.in. (Usually I just check That may be what you are running into. Note that starting in 1.44.0, I've dropped all of the backwards compatibility stuff, on the theory that people who want to support ancient Linux distribution systems are paid the big bucks, and it wasn't worth my volunteer time to make it all work and do all of the testing on ancient systems. (And especially since most enterpise distro folks weren't taking the latest bug fixes anyway, and it's been over ten years since I've had to care about enterprise distro customers.) The short version is that the backwards compatibility stuff was all about making things like the debug packages work. It's all packaging gunk, and so as long as you crate packages that pass lintian checks, it's probably fine. As a reminder, the distro packaging of the latest version of e2fsprogs for old back-level enterpise distros may cause the distro release folks to want to constain the default ext4 file system features that are enabled, since the older versions of grub, the linux kernel, et. al, might not support metadata checksuming (for example). So I could easily see that Ubuntu might want to adjust misc/mke2fs.conf.in file to disable certain file system features from being enabled in freshly created file systems by default, for example. I also have a vague memory that Ubuntu had a slightly different convention for supporting debug symbol packages on older Ubuntu systems. If so, that may require more adjustments --- or maybe you'll just decide to disable the debug symbol packages and call it a day. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1365874] Re: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming
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 RO_COMPAT bitmask, it is safe to access the file system in read- only mode. Now, the 64-bit feature is an INCOMPAT feature. This means that if the kernel (or user-space program directly accessing the file sytem) doesn't understand a bit in the INCOMPAT feature set, it is *not* safe for it to try to understand the file system.This feature was only enabled in e2fsprogs 1.43.x if the file system was larger than 16TB. JHowever, by e2fsprogs 1.44.0, it is turned on by default even for file systems smaller than 16TB. That's because it was expected that by now, we had given grub2 and os-prober enough time to get with the program --- and if you create a file system without the 64-bit feature, it is not possible to online resize it beyond 16TB. So this is why we turn on the 64-bit feature out of the box with e2fsprogs 1.44.0 (there are failure modes with leaving it turned off for the sake of backwards compatibility with antique software versions).However, if a enterprise distribution decides that backwards compatibility is more important new features, it can ship e2fsprogs with an edited version of misc/mke2fs.conf.in. Feel free to turn off 64-bit if you think breaking the 15TB->16TB online resize is an acceptable consequence about the 16.04 vs 18.04 multi- booting issue. That's why the customers pay the enterprise distro providers the big bucks. :-) Or get really frustrated with the enterprise distro providers. Probably both. :-) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1601997] Re: Ubuntu 16.10+ installer uses ext4 feature 'metadata_csum' which is incompatible with older (LTS) e2fsprogs
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 some that could cause massive file system corruption and data loss (relative to e2fsprogs 1.42.x) in the right (wrong) circumstances. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1601997 Title: Ubuntu 16.10+ installer uses ext4 feature 'metadata_csum' which is incompatible with older (LTS) e2fsprogs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1601997/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1365874] Re: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming
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 turned on by default yet, but the second in particular is very useful for Samba servers since it was written specifically to efficiently support Windows ACL's and Security ID's better than any other file system by supporting xattr dedupe.) http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.44.0 In general e2fsprogs has a very conservative release process, and there have been a *large* number of bug fixes since e2fsprogs 1.42.13. (Including some that can cause horrible file system corruption and data loss if you do off-line resize2fs operations (resizing the file system while the file system is not mounted) under some circumstances. So if you are using distribution with that has e2fsprogs 1.42.13, on the misguided assumption that staying on an ancient version of e2fsprogs is "safer" --- that is simply not true. One caveat: in 1.44.0 I started relying on dpkg build profiles in debian/rules. This means e2fsprogs 1.44.0 no longer builds out of the box for Debian 7 (wheezy, aka Debian old-old-stable) and Ubuntu Trusty (14.04 LTS) and older releases. It should be possible to backport e2fsprogs 1.44.0 to 14.04 LTS, but at the very least 14.04 LTS should go to 1.43.9 to fix a huge number of bugs. But for 16.04, e2fsprogs 1.44.0 should just drop right in. And with 14.04 LTS and older, e2fsprogs 1.43.9 should Just Work. It wouldn't be that hard to make e2fsprogs 1.44.0 work on 14.04 LTS, but it won't be turn-key. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1601997] Re: Ubuntu 16.10 installer sets metadata_csum option on ext4 partition which is incompatible with other LTS Ubuntu versions
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 supports two new features, largedir and ea_inode, (neither turned on by default yet, but the second in particular is very useful for Samba servers since it was written specifically to efficiently support Windows ACL's and Security ID's better than any other file system by supporting xattr dedupe.) http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.44.0 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1601997 Title: Ubuntu 16.10 installer sets metadata_csum option on ext4 partition which is incompatible with other LTS Ubuntu versions To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1601997/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1749036] Re: package libcomerr2 1.43.8-2 failed to install/upgrade: libcomerr2:all 1.43.9-1 (Multi-Arch: no) is not co-installable with libcomerr2 which has multiple installed instances
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 "apt-get update --with-new-pkgs" it Just Works For Me. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1749036 Title: package libcomerr2 1.43.8-2 failed to install/upgrade: libcomerr2:all 1.43.9-1 (Multi-Arch: no) is not co-installable with libcomerr2 which has multiple installed instances To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1749036/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1713175] Re: Obsolete backup ext2/3/4 superblocks can confuse e2fsck on an encrypted LUKS partition
** 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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1713175 Title: Obsolete backup ext2/3/4 superblocks can confuse e2fsck on an encrypted LUKS partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1713175/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1713175] Re: fsck should check before running on an encrypted LUKS partition
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 to modify the file system. So it would have required multiple sysadmin errors in order get to this point. If you want a process which is fool-proof against sysadmin errors, you could run the following before you run cryptosetup: dd if=/dev/zero of=/dev/callcc/scratch seek=32766 count=10 bs=4k If you do this, then e2fsck won't find the backup superblock, and it will print: e2fsck 1.43.5 (04-Aug-2017) ext2fs_open2: Bad magic number in super-block e2fsck: Superblock invalid, trying backup blocks... e2fsck: Bad magic number in super-block while trying to open /dev/callcc/scratch The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 or e2fsck -b 32768 /dev/callcc/scratch contains a crypto_LUKS file system So we could try to do the "is there another file system or LUKS" check before falling back to the secondary superblock. I'd call this a feature request. It also should be the case that the wipefs program should have wiped enough to get rid of the backup superblock (it's considered best practice to run wipefs before running cryptsetup). Furthermore, crypsetup should have run wipefs, or done its own wiping. Mke2fs will wipe sectors at the beginning and the end of the superblock (otherwise it's possible for the device to get misidentified as part of a RAID array). Fundamentally, trying to use in-band signalling is fraught with peril. All tools need to do a better job of preventing this kind of mis- identification, especially at file system or LUKS creation/format time. ** Also affects: util-linux (Ubuntu) Importance: Undecided Status: New ** Also affects: cryptsetup (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1713175 Title: fsck should check before running on an encrypted LUKS partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1713175/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1713175] Re: fsck should check before running on an encrypted LUKS partition
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) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1713175 Title: fsck should check before running on an encrypted LUKS partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1713175/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1702240] Re: [Ubuntu 17.04] 'make test' failures seen when e2fsprogs instrumented with 'undefined behavior sanitizer'
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 Debian package upload, though. As a side note, I'll double check to see if Ubuntu has any distribution local patches, but if there's anything you want to make sure I look at for inclusion in 1.43.5, now would be a good time... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1702240 Title: [Ubuntu 17.04] 'make test' failures seen when e2fsprogs instrumented with 'undefined behavior sanitizer' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1702240/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1637779] Re: ext4 filesystem fails randomly with checksum error
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. The ext2fsd isn't aware of all of the latest new features in ext4, and worse, it didn't know to check the file system feature bitmaps, and if there is a feature set in the read-only incompat feature set or the incompat feature set which ext2fsd didn't understand, that it should keep its paws off the file system. This caused the checksum failures. In Gerard's case in #8 and #9, it's not clear what the cause might be. Ubuntu 14.04 doesn't ship with e2fsprogs 1.43. So you've updated to a newer version of e2fsprogs; one which is newer than what is supported with Ubuntu 14.04. It's possible that this was due to your using a much older kernel than one that was truly ready to support the metadata checksum feature; so if you are using the ancient Ubuntu 14.04 kernel, that might be the explanation. Or it could be that there is a true hardware problem that you are tripping up against. In any case, this isn't an e2fsprogs bug. It's possible it's a kernel bug, but neither Ubuntu nor the upstream kernel community is going to support the ext4 metadata checksum feature on an ancient Ubuntu 14.04 kernel. If you think your are technically saavy enough to run with an upstream kernel, you could update to a bleeding edge kernel, and then you can ask about ext4 problems on the linux-ext4 mailing list. If you don't think you're ready to go that extreme, it might be for the best if you were to just disable the metadata_csum feature, using "tune2fs -O ^metadata_csum /dev/sdb5" with the file system umounted. You can then disable mke2fs from enabling the metadata_csum feature in the future by editing /etc/mke2fs.conf, and removing metadata_csum from the features list. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1637779 Title: ext4 filesystem fails randomly with checksum error To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1637779/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1702240] Re: [Ubuntu 17.04] 'make test' failures seen when e2fsprogs instrumented with 'undefined behavior sanitizer'
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 no problems with e2fsprogs). [1] "Any sufficiently advanced compiler is indistinguishable from a malicious adversary." Still, it's better to fix these sorts of issues than not, so please see the attached patch. It will be included in the next release of e2fsprogs. ** Patch added: "0001-Fix-warnings-found-using-UBSAN.patch" https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1702240/+attachment/4909420/+files/0001-Fix-warnings-found-using-UBSAN.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1702240 Title: [Ubuntu 17.04] 'make test' failures seen when e2fsprogs instrumented with 'undefined behavior sanitizer' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1702240/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1682639] Re: resize2fs hang bug still lingering
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 notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1682639 Title: resize2fs hang bug still lingering To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1682639/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1186331] Re: [PATCH] e2fsck hangs up boot process because "Device or resource busy while checking ext3 journal for foobar"
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1186331 Title: [PATCH] e2fsck hangs up boot process because "Device or resource busy while checking ext3 journal for foobar" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1186331/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1645232] Re: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL)
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1645232 Title: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1645232/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1645232] Re: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL)
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 developers. Users of fuse2fs are more likely to be civilians. We've had this bug for a long time, and no one has complained. Taking some time to have a fix that doesn't corrupt file systems is far more important to me as the maintainer. For any distribution, but especially for Ubuntu, civilian users >>> embedded developers. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1645232 Title: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1645232/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1645232] Re: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL)
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 bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1645232 Title: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1645232/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1645232] Re: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL)
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 means if some
other program using this library function --- for example, fuse2fs,
reads in an existing xattr block with an ACL, it will read it the on-
disk format, _not_ translate it to a standard acl format, and then
write_xattrs_to_buffer() will take as input an acl encoded in the on-
disk format, and then try to convert it from lgetxattr format to on-disk
format again, and Much Hilarity will result.
I also wonder if write_xattrs_to_buffer() is the right place to make
this conversion, or rather ext2fs_{read,write}_ext_attr3(). Then what
is stored in the handle structure is the on-disk encoding, and we would
do the translation at the higher layer function rather than the low-
level read/write functions.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1645232
Title:
e2fsprogs - could not preserve ACL permissions : The getxattr()
returns with (EINVAL)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1645232/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1637779] Re: ext4 filesystem fails randomly with checksum error
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1637779 Title: ext4 filesystem fails randomly with checksum error To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1637779/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1601997] Re: Ubuntu 16.10 installer sets metadata_csum option on ext4 partition which is incompatible with other LTS Ubuntu versions
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 to enable it. So with the upstream e2fsprogs tarball, the user can still request metadata_csum by asking for it explicitly: mke2fs -t ext4 -O metadata_csum. With my *Debian* maintainer hat on (well, with some egging on with my upstream maintainer persona :-), I decided to enable metadata_csum by default so that in the testing and unstable branches, metadadata_csum checking would get some additional exposure, and hence testing. This gambit has worked. There have been a number of bug between 1.43 and 1.43.3 that were fixed because they were reported by Debian users. Whether I will continue leaving metadata_csum enabled right before Debian Stretch goes into final lockdown for the Debian Stable release is not something I have decided, but so far the bug report rate has been positive. Ubuntu has apparently adopted the Debian enablement of metadata_csum by default, because it's based on the Debian 1.43.3-1 package. However, there may be some differences between Ubuntu and Debian --- the average technical sophistication of a Debian vs. a Ubuntu user, compatibility constraints with Ubuntu LTS, etc. --- that may drive a different decision with respect to mke2fs's *defaults*. It would be good if a decision is made explicitly by Ubuntu / Canonical to decide what best makes since for Ubuntu. If you decide that Ubuntu 16.10 is a community distro, and you want to help me test metadata_csum, that's great.I have had some experiences with less-than-savvy Ubuntu users who really struggled with filing a useful bug report and participating in root causing a bug. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1601997 Title: Ubuntu 16.10 installer sets metadata_csum option on ext4 partition which is incompatible with other LTS Ubuntu versions To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1601997/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1627608] Re: resize2fs crashed with SIGSEGV in ext2fs_extent_translate()
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 a bug introduced in 1.43 by commit fb47b94fffc: "resize2fs:
rewrite extent/dir/ea block checksums when migrating". If there is an
extended attribute block and there are no blocks that need to migrate,
we will crash.
The bug was caused by a botched De Morgan's transformation.
Signed-off-by: Theodore Ts'o <ty...@mit.edu>
Note that e2fsprogs 1.43.3-1 is in Debian unstable, and the only reason why
it's blocked from entering testing for the last three weeks is because of the
glibc 2.24 transition.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1627608
Title:
resize2fs crashed with SIGSEGV in ext2fs_extent_translate()
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1627608/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1619918] Re: lsattr 32bit does not work on 64bit kernel (Inappropriate ioctl error)
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 notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1619918 Title: lsattr 32bit does not work on 64bit kernel (Inappropriate ioctl error) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1619918/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1619918] Re: lsattr 32bit does not work on 64bit kernel (Inappropriate ioctl error)
** 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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1619918 Title: lsattr 32bit does not work on 64bit kernel (Inappropriate ioctl error) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1619918/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1619918] Re: lsattr 32bit does not work on 64bit kernel (Inappropriate ioctl error)
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1619918 Title: lsattr 32bit does not work on 64bit kernel (Inappropriate ioctl error) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1619918/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1598136] Re: Fails to produce a loop-mountable FS on powerpc/armhf
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 note to stay far, far, far away. :-) We'd have to see the exact kernel version to be sure (and there should be some hints in the log messages), but at a guess, try building the file system with "mke2fs -O ^metadata_csum" and see if that fixes things for you. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1598136 Title: Fails to produce a loop-mountable FS on powerpc/armhf To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1598136/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1592862] Re: Merge e2fsprogs from Debian 1.43.1-1
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 the very least the changes to remove dietlibc are definitely no longer
needed for Ubuntu, and if Ubuntu now supports the Debian methods for generating
dbgsym and updating config.{guess,sub} files, it may be possible for Ubuntu
remove (a) and (c) as well.
BTW, note that if you run "make -f debian/rules mrproper ; make -f
debian/rules debian-files" the debian/rules file will automatically
reprobe the underlying build infrastructure and update various debian
files automatically to automate rebuilding e2fsprogs on legacy
distributions. For example, this should allow e2fsprogs to be rebuilt
on Debian Stable and (probably, although I haven't tested it) Ubuntu LTS
distributions.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1592862
Title:
Merge e2fsprogs from Debian 1.43.1-1
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1592862/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1090053] Re: e4defrag -c /mountpoint does not provide expected output
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 could argue is a bug, but if so, it's more of a design issue. (It's not like it's secret; and you get the same information using filefrag.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1090053 Title: e4defrag -c /mountpoint does not provide expected output To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1090053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1186331] Re: [PATCH] e2fsck hangs up boot process because "Device or resource busy while checking ext3 journal for foobar"
Fixed in 2013. ** Changed in: e2fsprogs (Ubuntu) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1186331 Title: [PATCH] e2fsck hangs up boot process because "Device or resource busy while checking ext3 journal for foobar" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1186331/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 463015] Re: Both fat and ext[234] boot sectors present at once cause confusion
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/463015 Title: Both fat and ext[234] boot sectors present at once cause confusion To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/463015/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1567567] Re: fsck taking way too long 20 hours & still going
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 you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1567567 Title: fsck taking way too long 20 hours & still going To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1567567/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1345682] Re: fsck on 24TB ext4 keeps crashing
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 build process to get me to a point of testing. I'm plan on doing a > little more testing before going into production based on the thought that > this problem was fixed, but initial testing shows I'm stilll having some > similar problems. I've built a 18TB file system raid5 ext4, and I was > crossing my fingers that it would be stable, but I'm seeing all kinds of > corruptions and doing fsck early I see that the file system doesn't stay > clean for long. I've built 3 systems so far. Two of them have gone into > production and I've limited my ext4 to 16TB. I built another system with > 18TB and I once I start copying large amounts of files onto the system, I > start seeing some warning messages indicating some forms of corruption, and > I stop the copy, run fsck, and I find I do not have a clean file system. > I'm running ubuntu 14.04.04 LTS on this test system. I've got another near > identical setup with ubuntu-14.04 and 16TB or less and works fine(this was > the original system that I saw my corruption. After downsizing, I'm good). > I've got another with 18TB, but split into a 16TB partition and 2TB > partition, on a ubuntu-15.04 system and that is working fine. I go back to > an hybrid system I built to do this test. It is running ubuntu14.04.04 and > built this one with 18TB. This was an older file server that did not have > problems that I decomissioned recently so I could do this testing. I > started my burn in tests and started seeing corruption of the file system. > As expected the only thing I can determine is that it doesn't seem to like > >16TB. Please let me know how I can help get this debugged. So the original problem was about fsck crashing with a seg fault. That's different from it finding corruptions. So the first question is what exactly are you seeing? Corruptions? Fsck crashing? Both? The next question is are you using resize2fs or not? There are known problems with using resize2fs with large partitions, especially if you aren't using the very latest version of e2fsprogs. In general on-line resizing is going to be much safer than off-line resizing (the bugs were in resize2fs's off-line resizing code). If you are seeing it crash, the best thing to do is to get the very latest version of e2fsprogs, and build it, and then run it from there, so we can get a stack trace with line numbers. Since I'm about to release 1.43, ideally you would do this with both 1.42.13 as well as the tip of the e2fsprogs git's "master" branch. (Sorry, I don't provide support for distro versions of the kernel and e2fsprogs. If you want that, you need to pay $$$ to Canonical and get their enterprise support product offerring.) - Ted P.S. Also, to be clear, you are are using software raid? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1345682 Title: fsck on 24TB ext4 keeps crashing To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1345682/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1345682] Re: fsck on 24TB ext4 keeps crashing
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 man page. Failing that, there probably isn't much we can do, short of having you get a newer version of e2fsprogs, build it with debugging information enabled, and then run it under a debugger so we can get an accurate stack trace. I will note that the stack trace printed by e2fsck doesn't look completely sane, since ext2fs_rb_next() doesn't actually call any C library functions, and far too many of the stack frames don't have symbol names to annotate the addresses. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1345682 Title: fsck on 24TB ext4 keeps crashing To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1345682/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1345682] Re: fsck on 24TB ext4 keeps crashing
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. There is a known issue where if you are using a huge number of hard links (if you are using a backup solution which uses hard links and a huge number of parallel directory hierarchies) e2fsck uses a large amount of memory. I don't know if that's what you are doing, but if that's what you are doing, it wouldn't surprise me if you are running out of memory. You should have gotten an explicit "you ran out of memory" error instead of a seg fault, though. There is a way you can use scratch files for some of the data structures that e2fsck needs to track all of the hard links; see the "The [scratch_files] Stanza" section in the e2fsck.conf. However, this is going to be *SLOW*.The primary use of this was for people who were using 32-bit systems and who didn't have the address space for the memory requirements for large file systems with a large number of hard links. You may be better off just trying to configure our swap space. (All of this is assuming the problem is that the file system has a very large number of hard link farms. Have you confirmed that when you configured 25GB of swap, that the system actually used that amount of swap)? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1345682 Title: fsck on 24TB ext4 keeps crashing To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1345682/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1497032] Re: dumpe2fs crashed with SIGSEGV in strlen()
*** 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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1497032 Title: dumpe2fs crashed with SIGSEGV in strlen() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1497032/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 796717] Re: e2fsck not fixing some fs errors
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 anyway. It made sense back in the days of IDE disks, or its predecessors, which didn't do the bad block remapping in the drive firmware. These days, it just causes confusion and data loss by users who think it's a good idea. I'm of half a mind of deprecating and disabling badblocks and e2fsck -cc in the next major release of e2fsprogs, since more and more users are using it to their detriment, and while I can't legislate away stupid user tricks, I can remove tools that invite stupid user tricks -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/796717 Title: e2fsck not fixing some fs errors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/796717/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1229618] Re: Saucy: /forcefsck not being removed after execution / completion of boot system check
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1229618 Title: Saucy: /forcefsck not being removed after execution / completion of boot system check To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1229618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1415077] Re: resize2fs -P minimum size differs greatly between v1.42.10 and v1.42.9
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1415077 Title: resize2fs -P minimum size differs greatly between v1.42.10 and v1.42.9 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1415077/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1415077] Re: resize2fs -P minimum size differs greatly between v1.42.10 and v1.42.9
The change was deliberate, because under some extreme circumstances you could end up corrupting the file system image when resize2fs aborted in the middle of a shrink operation. This tends to make some users cranky when they lose their data. If you had bothered to read the entire git commit description, you would have gotten a lot more context: resize2fs: refine minimum required blocks for flex_bg file systems The previous commit exposed bugs in the calculation for flex_bg file systems. The problem is that since (by default) we keep the metadata blocks for the flex_bg in the first block group of the flex_bg, and because we don't want to overwrite metadata blocks used by the original file system with data blocks make life easier in case the resize is aborted for some reason, we need to treat all of the metadata blocks in the existing flex_bg has in use for the purposes of calculate_minimum_resize_size(). Even though this means we need to reserve more data blocks to avoid running out of space, the net result of these two commits is a net savings in how much we can shrink a file system. Using the following test sequence: mke2fs -F -t ext4 /tmp/foo.img 2T resize2fs -M /tmp/foo.img resize2fs -M /tmp/foo.img resize2fs -M /tmp/foo.img Here is the comparison in the resulting file systems between the old and new resize2fs (units are in 4k blocks): 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 for speed. In fact, it can be really bad for slow devices, such as CD-ROM's and Amazon Elastic Block devices, since files and directories will end up getting fragmented and where the data blocks can end up getting placed farther than optimal from the inode table locations. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1415077 Title: resize2fs -P minimum size differs greatly between v1.42.10 and v1.42.9 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1415077/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1321418] Re: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk
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 received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1321418 Title: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1321418/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1348431] Re: -O inline_data not supported by Ubuntu e2fsprogs
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 data and metadata csum feature support) * next == unstable (and every few days to 1-2 weeks master will get moved up to the current unstable before I add new commits) * pu == experimental (not currently active) After 1.43 gets released, master will track 1.43 development for a while, and then maint will get renamed oldmaint, maint will get reset to master, and master and next will start tracking new development for the eventual 1.44 release. We have not decided yet whether mke2fs will create file systems with metadata_csum and inline data by default in the 1.43 release series, although the answer is probably not, at least not at first. Individual sysadmins can edit /etc/mke2fs.conf to change the defaults. (File system developers tend to be *very* conservative, because while users will tolerate kernel crashes, bugs that lead to data loss tend to make end users very cranky indeed, and we try rather hard as a point of pride not to avoid such eventualities.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1348431 Title: -O inline_data not supported by Ubuntu e2fsprogs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1348431/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1348431] Re: -O inline_data not supported by Ubuntu e2fsprogs
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 this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1348431 Title: -O inline_data not supported by Ubuntu e2fsprogs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1348431/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1348431] Re: -O inline_data not supported by Ubuntu e2fsprogs
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1348431 Title: -O inline_data not supported by Ubuntu e2fsprogs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1348431/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1365874] Re: Ubuntu 14.04 does not support ext4 metadata checksumming
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 checksums are welcome, but it should be people who are willing to use bleeding edge kernels and it's not **that** hard to build e2fsprogs from the git tree. Cheat sheet: git clone git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git cd e2fsprogs ./debian/rules dpkg-buildpackage -b -uc -rfakeroot Someone who doesn't feel themselves comfortable typing the above commands, and subcribing to the linux-ext4 list, and be prepared to potentially lose data and send bug reports to linux-ext4, probably shouldn't be experimenting with metadata_csum just yet. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 14.04 does not support ext4 metadata checksumming To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1398434] Re: e4defrag has fatal CPU performance bottleneck
Please strace the e4defrag process to see if it is spinning in userspace or in the kernel.If it is spinning in the kernel, then it's a kernel bug, not an e2fsrpogs problem. And since you're using a non-Ubuntu kernel, you'll need to take this to the upstream linux-ext4 mailing list. If it turns out to be a case of spinning in the kernel, what we'll want to know is whether you can easily reproduce the problem, and if so, whether you can give us a kernel stack trace by using magic-sysrq-l and magic-sysrq-t. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1398434 Title: e4defrag has fatal CPU performance bottleneck To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1398434/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1393151] Re: Writing to ext4 LVM FS causes GPF in mpage_process_page_bufs
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 user space should be able to trigger this kind of failure --- nor have we seen anyone report anything even vaguely like this on upstream kernels. So it's likely that this is either triggered by some hardware bug, a device-driver specific bug if you are using something esoteric, or a some other miscellaneous bug introduced in the Ubuntu kernel. It's likely that the bug is corrupting the data structures which track the page cache buffers, judging from the stack trace and the fact that the process which died was something entirely unrelated to the the mkfs.ext3: - Nov 16 09:26:03 nas kernel: [ 230.610810] CPU: 1 PID: 1927 Comm: vsftpd Tainted: G D 3.13.0-39-generic #66-Ubuntu It might be useful to try running mkfs.ext3 to a USB-attached storage device, and see if that triggers the problem. If doesn't and you can safely write to the USB drive, then the figure of suspicion would pretty squarely fall on the hardware device or its device driver (or the Ubuntu kernel, of course). It might also be useful to try this on another server altogether, or to try swapping out to another kernel (say, an upstream kernel). Cheers, - Ted -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1393151 Title: mkfs.ext3 causes kernel panic on new WD 6 TB drive To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1393151/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1393151] Re: mkfs.ext3 causes kernel panic on new WD 6 TB drive
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 subtle flaw (either in the design, or your specific mainboard --- i.e., maybe a slightly cracked trace in the PCB) that is affecting DMA transfers from the HDD, but not from the USB stick. If you can borrow a 2TB USB-attached HDD, and try that, and that works, but a 2TB drive attached via SATA fails, then I would be deeply suspicious of your mainboard. Did this ever work before? What changed recently? Did you upgrade to a newer version of the distro, kernel, etc.? Has the system been recently moved (dropped, etc.)? Or is this a completely new installation? Sorry for asking such basic questions, but this really doesn't smell like a software bug at this point. - Ted -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1393151 Title: mkfs.ext3 causes kernel panic on new WD 6 TB drive To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1393151/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1375640] Re: fsck should do some sanity checks to avoid damaging an ext3/ext4 file system
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 reason why upstream kerenl developers will generally refuse to debug a kernel crash where the kernel is tainted by using a proprietary closed source kernel module. The kernel oops has a taint flag specifically because buggy video drivers in particular have historically been responsible for a huge number of failures that were at first not obviously related to the video driver, and upstream kernel developers wasted a lot of time before concluding: try again without any closed source modules loaded; we refuse to debug a tainted kernel. And before you ask why not put the Nvidia driver in a separate address space --- Microsoft tried this a long time ago with the version of Windows NT --- and the resulting video performance was so awful that the first version of Windows NT was a complete failure, and they had to reverse course and allow video drivers to run in the same address space. Linux cares about performance as well, and besides, we have zero interest in enabling crappy closed-source drivers, especially those from video card companies. Personally, I use laptops with Intel video chips, since that allows me to use 100% open source kernel. 3) It may be possible to recover the data by using e2fsck and debugfs, if you can find someone with ext4 skills who is willing to give you some free consulting time.Alternatively, you can try using photorec, which is one of the better tools for scanning the raw partition and finding and recongizing various data formats. It was originally designed to find image files (hence photorec), but it has since been extended to support a huge number of document types, including Libreoffice, Microsoft Office, etc., etc. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1375640 Title: fsck should do some sanity checks to avoid damaging an ext3/ext4 file system To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1375640/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1375640] Re: fsck should do some sanity checks to avoid damaging an ext3/ext4 file system
You're jumping to conclusions here that the damage was caused by the lack of -t ext4 to fsck. #1, the fsck program will determine the file system type based on the file system type found in /etc/fstab. So if the /etc/fstab file indicates that you were using ext4, then it wlil do the equivalent of running fsck -t ext4.#2, even if that was wrong, all that would have happened was the wrong fsck program would have been called. If it was really a btrfs or xfs file system, it would have run fsck.btrfs or fsck.xfs, and they would have rejected the file system as not a btrfs or xfs.If the /etc/fstab wrongly thought it was a ext2 or ext3, then fsck would have run /sbin/fsck.ext2 or /sbin/fsck.ext3 --- but /sbin/fsck.ext* are all symlinks to the same program, /sbin/e2fsck. So it wouldn't have made a difference. So the severe file system damage had nothing to do with the use or lack thereof of -t ext4, but rather because the file system was badly damaged by the Nvidia-induced crash. If the closed source kernel module managed to scribble on kernel memory, it could have caused metadata blocks to be written to the wrong place on disk, or corrupting critical metadata blocks. Or if you had to hard power cycle the system, and you were using a SSD that doesn't have power fail protection (most consumer grade SSD's don't), then that might also explain the severe file system corruption. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1375640 Title: fsck should do some sanity checks to avoid damaging an ext3/ext4 file system To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1375640/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1365864] Re: fsck.ext4 broken on FS created with bigalloc
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 doing; there are real tradeoffs involved with its use, so it's a bit of an advanced feature). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1365864 Title: fsck.ext4 broken on FS created with bigalloc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365864/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1365874] Re: Ubuntu 14.04 does not support ext4 metadata checksumming
Canonical doesn't employ any ext4 engineers, and as far as I know, no Ubuntu developers contribute to ext4 development. So the fact the release notes might get a few things wrong shouldn't be surprising. Canonical simply doesn't have any file system developers on staff, as far as I know. If you are willing to try out Metadata checksumming, testers who report bugs are always appreciated. The way to get a feature out sooner is to get more people to contribute to those features.If you are ranting about the lack of a feature, I wonder how much more you would rant if the feature was released before it was ready and your data got damanged or lost? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 14.04 does not support ext4 metadata checksumming To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1356496] Re: filefrag shows wrong number of extents
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 notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1356496 Title: filefrag shows wrong number of extents To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1356496/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1356496] [PATCH] filefrag: fix extent count calculation when using FIBMAP
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 ty...@mit.edu
---
misc/filefrag.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/misc/filefrag.c b/misc/filefrag.c
index d71bf43..c1a8684 100644
--- a/misc/filefrag.c
+++ b/misc/filefrag.c
@@ -329,16 +329,17 @@ static int filefrag_fibmap(int fd, int blk_shift, int
*num_extents,
print_extent_info(fm_ext, *num_extents - 1,
(last_block + 1) * st-st_blksize,
blk_shift, st);
- fm_ext.fe_logical = logical;
- fm_ext.fe_physical = block * st-st_blksize;
fm_ext.fe_length = 0;
(*num_extents)++;
} else if (last_block (block != last_block + 1)) {
if (verbose)
printf(Discontinuity: Block %ld is at %lu (was
%lu)\n, i, block, last_block + 1);
+ fm_ext.fe_length = 0;
(*num_extents)++;
}
+ fm_ext.fe_logical = logical;
+ fm_ext.fe_physical = block * st-st_blksize;
fm_ext.fe_length += st-st_blksize;
last_block = block;
}
--
2.0.0
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1356496
Title:
filefrag shows wrong number of extents
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1356496/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1321958] Re: resize2fs does not start to actually grow an ext4
Someone has reported what appears to be the same problem on the linux- ext4 list, and between correlations of the observations from Dennis (Thermaltaker) and on the linux-ext4 list, I believe we have a fix that should address this problem: http://thread.gmane.org/gmane.comp.file-systems.ext4/44870 If someone wants to try the patch proposed by Azat applied to 1.42.11, that would be much appreciated. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1321958 Title: resize2fs does not start to actually grow an ext4 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1321958/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1348775] Re: Supporting -D from e2fsck in e4defrag
Unfortunately, what you are requesting isn't possible. E4defrag works in an online mode -- that it is, it works while the file system is mounted. E2fsck -D works off-line; the file system must be unmounted to optimize the directory. So it simply wouldn't be possible to move the functionality from e2fsck to e4defrag without adding a huge amount of kernel support. And in practice, honestly, it's rarely needed. If you know no one is using a dirctory, you can mostly get the behaviour you want by doing this: mkdir foo.new ; mv foo.new/* foo ; rmdir foo ; mv foo.new foo Of course, if something is trying to access the directory foo while you are doing this, it will fail, which is why this isn't something that I would put into e4defrag. Also, it's pretty simple for anyone to do from the command line. ** Changed in: e2fsprogs (Ubuntu) Status: New = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1348775 Title: Supporting -D from e2fsck in e4defrag To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1348775/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1340448] Re: 5% reservation for root is inappropriate for large disks/arrays
I just don't think an adaptive algorithm is going to be worth the complexity. It will invariably get it wrong for some work load or another. At which point more people will start kvetching and opening bug reports. For one thing, it matters a lot what the average size is of the files being stored on a file system. For example, if the average file size is 4k, then you can fill it to 100% without suffering any performance degradation.It will also depend on the distibution of the files and whether you just write once and be done, or whether files are constantly being deleted and inserted, potentially with different sizes. It also matters whether the user cares about performance or capacity. Disks have essentially not changed the average seek time, while doubling in capacity every 18 months or so (with this trend only only slowing down in the past year or two). So if you consider the average seek per GB of capacity, it's been dropping with every single disk generation. As a result, there are probably many applications which are now no longer constrained by disk capacity, but by seek capacity (i.e., by the number of spindles). I've even seen examples of shops that have deliberately not gotten the latest 6TB or 8TB disks, because they are spindle constrained, and so they are better off buying 2T or 4T disks. This last is why I really don't think it's worth while to worry about that last 51GB if you have a 1T disk.Adding complexity to the calculation just makes it harder for system administrators to understand what is going on, and with the seeks per GB dropping like a stone over the past few decades, for many shops performance is far more important than the value of that 51GB (which in dollar values, given today's costs in disk, is approximately $2.50 USD. In terms of minutes of a system administrators time, or a software engineers time, you've no doubt wasted far more than that in discussing it. :-) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1340448 Title: 5% reservation for root is inappropriate for large disks/arrays To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1340448/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1340448] Re: 5% reservation for root is inappropriate for large disks/arrays
If you try to use more than 95% of the storage, performance will generally suffer -- badly. Now, you may not care for certain use cases; if you are doing backups, you might not worry about that much about performance, and you might care a lot more about using the last few bytes of the disk. But changing this default is not something I plan to do upstream. In addition for the root file system, you really do want to leave the default at 5% so that root can write to critical file systems. And since the vast majority of Ubuntu users are using a single root file system, that implies that the for the vast majority of file systems created by Ubuntu, the default is in fact appropriate. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1340448 Title: 5% reservation for root is inappropriate for large disks/arrays To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1340448/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1340448] Re: 5% reservation for root is inappropriate for large disks/arrays
As the file system gets more and more full, the free space gets more and more fragmented. This results in disastrous performance hits for files that are written when the file system gets full, and then when you later try to read them, you will suffer similar disastrous performance hits. This is of course much more notable on HDD, but even on SSD's, a random write workload is always going to result in greater flash wear and lower performance than a sequential write workload --- particularly on the cheaper flash that you would expect to see in tablets and phones (i.e., eMMC flash) --- and even some of the crappier desktop SSD's. Now, if you have an Intel or Samsung SSD, this might not matter as much (although you will still see a performance hit) --- but having mke2fs figure out whether you have a competently implemented flash translation layer, or a spectacularly crappy one (since on phones they calculate the BOM cost down to the hundredth or thousandth of a cent, and that extra 25 cents worth of better FTL license fees and controller memory is Just Too Damn High :-), is just too much complexity to put into mke2fs's program logic.It's better to have a simple, well defined default, and then if you know for sure that you have a system where you don't mind highly fragmented files, to adjust the root reserve. As far as the server and the cloud, for the cloud, it won't really matter since guest OS's generally have relatively small amounts of space. And Ubuntu has stopped caring about the enterprise server market a long time ago. As far as the cloud host OS, there's a heck of a lot more tuning you need to do if you what a high-performing, price/performance competitive offering, such that adjusting the root reserve is the very least of your problems In any case, this is not something I intend to change for upstream, either in e2fsprogs or the Debian package. If the Ubuntu release engineers want to make a change, they are of course free to do so. But I wouldn't recomend it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1340448 Title: 5% reservation for root is inappropriate for large disks/arrays To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1340448/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1329288] Re: fsck SEGV
Can you get me the fsck transcript for this run in question? It might be in /var/log/fsck Failing that, can you tell me what file system it was checking? Can you run e2fsck by hand, and try to reproduce the failure, and grab the e2fsck output when you do re-run it? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1329288 Title: fsck SEGV To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1329288/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1321958] Re: resize2fs does not start to actually grow an ext4
If someone could try running the following tests, it would be very useful. 1) strace -o /tmp/resize.strace resize2fs /dev/XXX 2) resize2fs -d 31 /dev/XXX | tee /tmp/resize.debug And then upload the files of the hanging resize2fs. It's not something I've been able to reproduce when doing a quick test. Thanks!! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1321958 Title: resize2fs does not start to actually grow an ext4 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1321958/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1321418] Re: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk
Can you send me the output of the following: debugfs /dev/md/1 debugfs: stat 27528105 debugfs: stat 27528089 debugfs: quit Thanks!! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1321418 Title: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1321418/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1321418] Re: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk
Right, I didn't notice the first time I read the bug report you had already deleted the inode to fix the problem. It would have been nice to have gotten a look at the inode in question so I could really see what was going on. The internal error: can't find dup_blk error is one of those this should never happen situations, so it would be good to understand how and why it happened, and hopefully figure out how to reproduce it. Can you send me the output of dumpe2fs -h /dev/md/1, just for the record? Thanks!! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1321418 Title: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1321418/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1321418] Re: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk
Thanks, I was able to reproduce the problem using a test file system. The problem appears to have been caused by an extent-mapped inode getting written (or copied) to a different/wrong place in the inode table. I should be able to get this fixed now that I have a simple repro. ** Changed in: e2fsprogs (Ubuntu) Status: New = Confirmed ** Changed in: e2fsprogs (Ubuntu) Assignee: (unassigned) = Theodore Ts'o (tytso) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1321418 Title: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1321418/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1321418] Re: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk
** Attachment added: File system image with repro. https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1321418/+attachment/4116503/+files/f_dup5.img.gz -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1321418 Title: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1321418/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1319667] Re: root file system 100% full, goes 52% after reboot
If you have processes keeping a file open, the space doesn't get reclaimed until the file is closed or the process is killed. Obviously, the latter tends to happen when you reboot a system. This is standard practice going back to 1970's and Unix; in fact, it is required by the POSIX standard. Why df is hanging is a separate issue.Creating a separate bug against the kernel and including the output of strace df -h might be helpful. ** Changed in: e2fsprogs (Ubuntu) Status: New = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1319667 Title: root file system 100% full, goes 52% after reboot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1319667/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1275794]
I tried applying the two patches which you posted on intel-gfx[1], ported to 3.13. [1] http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/33737 Using a T540p and an Ultradock, connected to a Dell U2410 via a DisplayPort cable --- and it worked! Not only were there no hangs, but in fact I could enable and disable the external display. The too many retries did indeed trigger: [4.152360] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 ... [4.245174] fbcon: inteldrmfb (fb0) is primary device ... [5.952436] [drm:intel_dp_aux_native_write] *ERROR* too many retries, giving up [6.004766] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [6.129836] Console: switching to colour frame buffer device 240x75 [6.134854] i915 :00:02.0: fb0: inteldrmfb frame buffer [6.134856] i915 :00:02.0: registered panic notifier [6.275753] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [6.276089] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input11 [6.276620] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [6.277149] snd_hda_intel :00:03.0: irq 46 for MSI/MSI-Xdevice When I tried disabling the external monitor, undocking, and redocking, and then tried enabled the external monitor again, the too many retries did trigger again: [ 1066.879571] drm: not enough stolen space for compressed buffer (need 33554432 more bytes), disabling. Hint: you may be able to increase stolen memory size in the BIOS to avoid this. [ 1070.884851] [drm:intel_dp_aux_native_write] *ERROR* too many retries, giving up -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1275794 Title: Lenovo T440s freezes when connected to docking station To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1275794/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1275794]
I tried applying the patch ([PATCH]HDMI connection via dock works with some (random) delay: https://bugs.freedesktop.org/attachment.cgi?id=93653) against a 3.13 kernel, and it makes things **worse** on my T540p. With the 3.13 kernel w/o the patch, I can boot and start up the X server w/o problems, as long as it is not docked. With this patch, the system locks up very early in the boot process, as soon as the console switches from the compat VGA mode into the higher resolution console mode). Also, when comparing an unpatched 3.12 kernel with an unpatched 3.13 kernel, 3.13 is also worse with the T540p. With the unpatched 3.12 kernel, I can have the laptop in the dock, and so long as there are no external monditors hooked up via the dock video connectors, it worked fine. With the unpatched 3.13 kernel, it's fine outside of the dock, but if it is in the dock, even if the dock does not have any external video monitors hooked up, any time there is any change to the video setup (i.e., X server starts up, DPMS puts the monitor to sleep, etc.) the system will lock up. It will recover after I eject the laptop from the dock, and after that point I can redock it, but while the system is locked up, the laptop heats up and the fan starts up --- which I suspect means that we are indeed hanging in some spinlock. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1275794 Title: Lenovo T440s freezes when connected to docking station To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1275794/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
