[Touch-packages] [Bug 2036467] Re: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
n.b. If Ubuntu hasn't taken the 32-bit time_t change (which is in Debian unstable) I have a commit which backs out this change for building e2fsprogs on older systems, e.g., for backports. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/2036467 Title: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs Status in cloud-images: New Status in e2fsprogs package in Ubuntu: In Progress Status in e2fsprogs source package in Trusty: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix Status in e2fsprogs source package in Focal: In Progress Status in e2fsprogs source package in Jammy: In Progress Status in e2fsprogs source package in Lunar: Won't Fix Status in e2fsprogs source package in Mantic: In Progress Status in e2fsprogs source package in Noble: In Progress Bug description: [Impact] This is a long running bug plaguing cloud-images, where on a rare occasion resize2fs would fail and the image would not resize to fit the entire disk. Online resizes would fail due to a superblock checksum mismatch, where the superblock in memory differs from what is currently on disk due to changes made to the image. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. Changing the read of the superblock to Direct I/O solves the issue. [Testcase] Start an c5.large instance on AWS, and attach a 60gb gp3 volume for use as a scratch disk. Run the following script, courtesy of Krister Johansen and his team: #!/usr/bin/bash set -euxo pipefail while true do parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s sleep .5 mkfs.ext4 /dev/nvme1n1p1 mount -t ext4 /dev/nvme1n1p1 /mnt stress-ng --temp-path /mnt -D 4 & STRESS_PID=$! sleep 1 growpart /dev/nvme1n1 1 resize2fs /dev/nvme1n1p1 kill $STRESS_PID wait $STRESS_PID umount /mnt wipefs -a /dev/nvme1n1p1 wipefs -a /dev/nvme1n1 done Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] We are changing how resize2fs reads the superblock from underlying disks. If a regression were to occur, resize2fs could fail to resize offline or online volumes. As all cloud-images are online resized during their initial boot, this could have a large impact to public and private clouds should a regression occur. [Other info] Upstream mailing list discussion: https://lore.kernel.org/linux-ext4/20230605225221.ga5...@templeofstupid.com/ https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/ This was fixed in the below commit upstream: commit 43a498e938887956f393b5e45ea6ac79cc5f4b84 Author: Theodore Ts'o Date: Thu, 15 Jun 2023 00:17:01 -0400 Subject: resize2fs: use Direct I/O when reading the superblock for online resizes Link: https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84 The commit has not been tagged to any release. All supported Ubuntu releases require this fix, and need to be published in standard non- ESM archives to be picked up in cloud images. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2063369] Re: e2image reports invalid argument when used with big partitions
Today, we don't create the sparse file "with the required size" when it is first opened. We could try seeking to maximum size of the device and writing a single byte, and seeing whether or not that fails, and if it fails, *assume* that this was caused by the target file system not supporting such a large file. There are other reasons why the write might fail (for example, the system administrator or some supervisor program might have set a file size limit via the setrlimit(3) systme call or the /etc/security/limits.h file. Also note not there is no supported way for a userspace program to query the kernel to find the maximum file size supported by a particular file system. It will depend on the file system type, the file system block size, and potentially, file system features that might be enabled on a particular file system. I agree that it would be nice to print a more user-friendly error message, and right away, as opposed after writing up to 16TB of image file. We just want to make sure if the system administrator has set a maximum file size of say, 2 GiB, and we print a message that it's a file system limitation, that will be confusing and will result in my getting angry bug reports. :-) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/2063369 Title: e2image reports invalid argument when used with big partitions Status in e2fsprogs package in Ubuntu: New Bug description: It seems e2image is unable to work correctly with large filesystems. I get the following error with etx4 on top of 48TB RAID5 array. # e2image -pr /dev/md3 md3.e2i e2image 1.46.5 (30-Dec-2021) Scanning inodes... Copying 802818 / 1547571 blocks (52%) 00:02:21 remaining at 20.50 MB/sseek_relative: Invalid argument To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2063369/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2063369] Re: e2image reports invalid argument when used with big partitions
If the file system has a limit on the size of the file (for example, ext4 has a maximum file size of 16TB), then when you do a relative seek via llseek(fd, offset, SEEK_CURR), the system call will return EINVAL. This is what is causing the error. If you want to create a raw image of a very large file system, you'll either to write it to a block device which is sufficiently large, or you'll have to make sure the destination file system can support a file size of that particular length. (And, of course, has sufficient free space to hold the raw image in the first place.) Another workaround is to compress the file, e.g., "e2image -pr /dev/md3 - | gzip > md3.e2i.gz" -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/2063369 Title: e2image reports invalid argument when used with big partitions Status in e2fsprogs package in Ubuntu: New Bug description: It seems e2image is unable to work correctly with large filesystems. I get the following error with etx4 on top of 48TB RAID5 array. # e2image -pr /dev/md3 md3.e2i e2image 1.46.5 (30-Dec-2021) Scanning inodes... Copying 802818 / 1547571 blocks (52%) 00:02:21 remaining at 20.50 MB/sseek_relative: Invalid argument To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2063369/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2027979] Re: won't warn neither prevent usage of « risky » characters in labels
Your original bug request said: "e2label lets you use any character, including / or * or $ ( and probably others, like accented letters é è à ). it should not be possible to use those in label names." You've now backpedaled and said, "I never said that! Only "risky" characters!" "Risky" as defined by whom?In your example, lsblk and e2label displayed the label without a problem. Who cares if you needed to use a backslash to protect the "$" or "*" or " " characters? They look just fine. And if the argument is that space character is well managed by auto-completion in most CLI "mostly", I'll note that so is the "*" character. For example: % touch qfoo\*bar % ls qf ... and bash will expand that to "qfoo\*bar" so it works just **fine** with bash. I've just checked and the completion function used in ksh, tcsh, and emacs (which does not require any quoting so that's a gimme) means that it works just fine. So any argument that you use for outlawing * in labels would apply to spaces, too and if for labels, why not filenames? Shouldn't filenames be "robust" and "foolproof"? By some unknown definition of "fool"? Going back to labels for the most part, labels are mostly used for display purposes, so if someone happens to create a label with a ' ', '*', or '$' character, it's not a big deal; lsblk, blkid, etc. will display them just fine. And no escaping is necessary if you put a special character in /etc/fstab. For example, the following works in /etc/fstab: LABEL=foo$bar /mnt ext4 defaults 0 0 Sure, some care might be needed to *set* the label to "foo$bar" --- you might need to type "e2label /dev/loop0 'foo$bar'" --- but the quoting rules are enforced by the shell. It might be some other shell might not use "$" for variables --- or there might be a disk management GUI which doesn't use quoting, just as emacs and Libreoffice doesn't require quoting for file names with spaces in it. So setting some arbitrary rule because of the interface that the user might be using doesn't make any sense. If the user is smart enough to figure out how to pass 'foo$bar' to e2label, we should let them use it. Why should we print some kind of nanny-state, "naughty, naughty! you did something that might confuse a less clueful user!!" warning. Again, the standard that said we should do that for labels would also apply to characters, and then I will have *other* launchpad users complaining to me about why did I set some kind of arbitrary restriction, and that they had a perfectly good reason for wanting to use these characters in their label or their filenames. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/2027979 Title: won't warn neither prevent usage of « risky » characters in labels Status in e2fsprogs package in Ubuntu: Confirmed Bug description: Hi, if naming or renaming an EXT volume, e2label lets you use any character, including / or * or $ ( and probably others, like accented letters é è à ) I'd expect at least a warning if such are to be found in a label name. Or better, it should not be possible to use those in label names. Example : a@p:~$ sudo e2label /dev/sdb12 /Ti\$* a@p:~$ a@p:~$ sudo e2label /dev/sdb12 /Ti$* a@p:~$ a@p:~$ lsblk -fe7 | grep sdb12 └─sdb12 ext4 1.0 /Ti$* f583e9b0-f1de-438f-8da8-c1e070407628 a@p:~$ coming from https://forum.ubuntu- fr.org/viewtopic.php?pid=22692892#p22692892 ( french ) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2027979/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2027979] Re: won't warn neither prevent usage of « risky » characters in labels
Right, but exactly the same argument can be made about disallowing anything other than plain ASCII characters in file names. It may be that in some graphical interfaces, spaces and accented characters and special characters like "$" don't require any escaping whatsoever. In other command-line interfaces, they require escaping. Shall we not allow spaces when saving OpenOffice filenames because when you look at the using the command line interface, you need to type something like: /media/arena/Music/Coig/Carols/01\ Carol\ of\ the\ Celts.mp3 Sure, this might be "confusing to the uneducated user", but just go ahead and file a bug against RipperX claiming that all such filenames should prohibited. I'll wait, and see what you get back from the author If we are going to restrict labels and filenames to least common denominators, then we can't allow any special characters, because the "uneducated user" might not know how to type "è" on a US keyboard. Where do we draw the line in terms of enforcing policy to protect the "uneducated user" from themselves? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/2027979 Title: won't warn neither prevent usage of « risky » characters in labels Status in e2fsprogs package in Ubuntu: Confirmed Bug description: Hi, if naming or renaming an EXT volume, e2label lets you use any character, including / or * or $ ( and probably others, like accented letters é è à ) I'd expect at least a warning if such are to be found in a label name. Or better, it should not be possible to use those in label names. Example : a@p:~$ sudo e2label /dev/sdb12 /Ti\$* a@p:~$ a@p:~$ sudo e2label /dev/sdb12 /Ti$* a@p:~$ a@p:~$ lsblk -fe7 | grep sdb12 └─sdb12 ext4 1.0 /Ti$* f583e9b0-f1de-438f-8da8-c1e070407628 a@p:~$ coming from https://forum.ubuntu- fr.org/viewtopic.php?pid=22692892#p22692892 ( french ) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2027979/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2027979] Re: won't warn neither prevent usage of « risky » characters in labels
Flawed by what definition? Editors allow people to create files with spaces, or with dollar signs, or with accepted characters. Some of these characters may require quoting if you use spaces or doll=lars. Not allowing accented characters will cause speakers of various European languages to complain that you're not letting them use french words in file names (or file system labels), and this is an unacceptable English language hegemony over the great languange which is French. :-) In fact, there's nothing wrong with using any of these characters in file system labels. For example, look at /dev/disk/by-label for a filesystem set with "e2label /tmp/foo.img foo\$bar": # ls /dev/disk/by-label/ total 0 ext-disk 'foo\x24bar' lambda-backup old-files@ And with the filename label set via "e2label /tmp/foo.img Misère" # /bin/ls /dev/disk/by-label ext-disk lambda-backup Misère old-files ^^^ So how are these characters flawed? what makes them be forced to wear a large scarlet letter "A" over their clothing? Why shouldn't the french be allowed to use accepted characters in file names or in file system labels? Inquiring minds want to know but as the upstream maintainer of e2fsprogs, I absolutely reject this as a bug. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/2027979 Title: won't warn neither prevent usage of « risky » characters in labels Status in e2fsprogs package in Ubuntu: Confirmed Bug description: Hi, if naming or renaming an EXT volume, e2label lets you use any character, including / or * or $ ( and probably others, like accented letters é è à ) I'd expect at least a warning if such are to be found in a label name. Or better, it should not be possible to use those in label names. Example : a@p:~$ sudo e2label /dev/sdb12 /Ti\$* a@p:~$ a@p:~$ sudo e2label /dev/sdb12 /Ti$* a@p:~$ a@p:~$ lsblk -fe7 | grep sdb12 └─sdb12 ext4 1.0 /Ti$* f583e9b0-f1de-438f-8da8-c1e070407628 a@p:~$ coming from https://forum.ubuntu- fr.org/viewtopic.php?pid=22692892#p22692892 ( french ) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2027979/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2027979] Re: won't warn neither prevent usage of « risky » characters in labels
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/2027979 Title: won't warn neither prevent usage of « risky » characters in labels Status in e2fsprogs package in Ubuntu: Confirmed Bug description: Hi, if naming or renaming an EXT volume, e2label lets you use any character, including / or * or $ ( and probably others, like accented letters é è à ) I'd expect at least a warning if such are to be found in a label name. Or better, it should not be possible to use those in label names. Example : a@p:~$ sudo e2label /dev/sdb12 /Ti\$* a@p:~$ a@p:~$ sudo e2label /dev/sdb12 /Ti$* a@p:~$ a@p:~$ lsblk -fe7 | grep sdb12 └─sdb12 ext4 1.0 /Ti$* f583e9b0-f1de-438f-8da8-c1e070407628 a@p:~$ coming from https://forum.ubuntu- fr.org/viewtopic.php?pid=22692892#p22692892 ( french ) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2027979/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2027979] Re: won't warn neither prevent usage of « risky » characters in labels
In order for e2label to modify the file system label, you need to have write access to the block device. That means that a malicious user can always directly modify the blockdevice (or just use a version of e2label that doesn't have the proposed check).Hence, this feature request should not be considered a security feature. This seems to be more of a "protect a naive / clueless user who tries to set a file system label: 'Make money fa$t". -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/2027979 Title: won't warn neither prevent usage of « risky » characters in labels Status in e2fsprogs package in Ubuntu: Confirmed Bug description: Hi, if naming or renaming an EXT volume, e2label lets you use any character, including / or * or $ ( and probably others, like accented letters é è à ) I'd expect at least a warning if such are to be found in a label name. Or better, it should not be possible to use those in label names. Example : a@p:~$ sudo e2label /dev/sdb12 /Ti\$* a@p:~$ a@p:~$ sudo e2label /dev/sdb12 /Ti$* a@p:~$ a@p:~$ lsblk -fe7 | grep sdb12 └─sdb12 ext4 1.0 /Ti$* f583e9b0-f1de-438f-8da8-c1e070407628 a@p:~$ coming from https://forum.ubuntu- fr.org/viewtopic.php?pid=22692892#p22692892 ( french ) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2027979/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2025339] Re: FDE image fails to run e2fsck
For Debian the metadata_csum_seed and orphan_file features were disabled by default by changing the /etc/mke2fs.conf file. e2fsprogs (1.47.0-2) unstable; urgency=medium * Don't enable metadata_csum_seed and orhpan_file by default (Closes: #1031622, #1030939) -- Theodore Y. Ts'o Sat, 04 Mar 2023 22:16:08 -0500 Ubuntu Lunar and Mantic chose to only disable metadata_csum_seed: e2fsprogs (1.47.0-1ubuntu1) lunar; urgency=low * Merge from Debian unstable. Remaining changes: - Use 4k blocksize in all ext4 mke2fs.conf stanzas, so lvm migration between non-4k PVs and 4k PVs works regardless of the volume size. * Disable the metadata_csum_seed feature again, as grub does not yet support it (Closes: #866603) -- Julian Andres Klode Fri, 17 Feb 2023 11:58:55 +0100 It should be noted that users are always free to change /etc/mke2fs.conf, since that's a configuration file, and the whole point of that file is to make it easy for distributions and users to customize how they mke2fs should behave. So if you think that Ubuntu Mantic should be able create file systems that can be handled by Jammy, it's just a matter of adjusting the mke2fs.conf file in Mantic. As far as grub support is concerned, the metadata_csum_seed feature flag is supposed by grub2 (2.06-8) or newer. And grub doesn't care about orphan_file, since it's a COMPAT flag. That is an issue for e2fsck, but not for grub. The question was always whether a distribution supports creating a file system that can be (a) mounted and/or (b) fsck'ed by an older distribution, and if so, for how many versions back. That's not something for which people of good will can disagree, which is why it can be made configurable. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/2025339 Title: FDE image fails to run e2fsck Status in e2fsprogs package in Ubuntu: Confirmed Status in e2fsprogs source package in Jammy: Confirmed Bug description: After installation of the FDE image, the system fails to boot due to e2fsck failing with: Jun 21 12:48:19 ubuntu systemd-fsck[268]: /dev/vda2 has unsupported feature(s): FEATURE_C12 this means that Jammy fsck fails against mantic created ext4 which is not great Seems this is orphan_file feature / orphan_present Also need to check if grub2 supports this as it is RO_INCOMPAT feature. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2025339/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2000625] Re: cp command loop when using ntfs3 package
Invalid, user filed a new bug (also in the wrong component, but I'll let the evince maintainer deal with that), so it's also a duplicate at this point. ** Changed in: e2fsprogs (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/2000625 Title: cp command loop when using ntfs3 package Status in e2fsprogs package in Ubuntu: Invalid Bug description: Hello. I'm on ubuntu 22.04, I saw that ntfs3 is supposed to correctly write to an NTFS partition. I inform you that this is not the case. Here is my quick test First try on EFI computer: I remove the NTFS-3G package to be sure not to use it. When I detect that the cp command is no longer responding, I kill the process. Nothing is happening. I shut down the computer. During the shutdown phase, I am informed twice that the cp command is running. On reboot, I cannot access the partition. But I succeed in read-only mode. I run another normal ubuntu which tells me that I have to use windows to do an chkdsk But windows refuse to start, I duplicate by the dd command the NTFS partition in a larger NTFS partition stored in an external disk. Then I delete the NTFS partition from the internal disk. Then I repare windows. After restarting windows, I find that its disk space manager cannot access to the duplicate partition on external disk. There's no answer. So no letter to do the CHKDSK command. I decide to be more methodical in order to open a discussion and make a script to see a little what is happening. See the rest. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2000625/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1939409 Title: e2fsprogs 1.46.3-1 on architecture s390x fails in test f_baddotdir Status in e2fsprogs package in Ubuntu: In Progress Status in e2fsprogs source package in Impish: In Progress Bug description: e2fsprogs 1.46.3-1ubuntu1 is in proposed. Architecture s390x fail in test f_baddotdir. The test image was changed with the new release. Next step should be analyzing the error on a s390x virtual machine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939409/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1939238 Title: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Status in e2fsprogs package in Ubuntu: New Bug description: Hello This problem did not occur on my computer. https://nsa40.casimages.com/img/2021/08/07/210807015400327092.png It occurs in users who are not competent. This week, the French forum collapsed over this incident. I think changing the advice phrase might improve understanding of the action to be taken. Can these lines " ( i.e.. without -a or -p options) fsck existed with status code 4 The root file system on /dev/ requires a manual fsck" become "execute this command 'fsck -y /dev/xx' to do a manual fsck on the root file system." ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: gnome-terminal 3.38.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22 Uname: Linux 5.11.0-25-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Sun Aug 8 15:16:28 2021 ExecutablePath: /usr/libexec/gnome-terminal-server InstallationDate: Installed on 2020-08-02 (370 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) ProcEnviron: LANG=fr_FR.UTF-8 PATH=(custom, user) SHELL=/bin/bash XDG_RUNTIME_DIR= SourcePackage: gnome-terminal UpgradeStatus: Upgraded to hirsute on 2021-07-11 (27 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939238/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1939409 Title: e2fsprogs 1.46.3-1 on architecture s390x fails in test f_baddotdir Status in e2fsprogs package in Ubuntu: In Progress Bug description: e2fsprogs 1.46.3-1ubuntu1 is in proposed. Architecture s390x fail in test f_baddotdir. The test image was changed with the new release. Next step should be analyzing the error on a s390x virtual machine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939409/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1939238 Title: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Status in e2fsprogs package in Ubuntu: New Bug description: Hello This problem did not occur on my computer. https://nsa40.casimages.com/img/2021/08/07/210807015400327092.png It occurs in users who are not competent. This week, the French forum collapsed over this incident. I think changing the advice phrase might improve understanding of the action to be taken. Can these lines " ( i.e.. without -a or -p options) fsck existed with status code 4 The root file system on /dev/ requires a manual fsck" become "execute this command 'fsck -y /dev/xx' to do a manual fsck on the root file system." ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: gnome-terminal 3.38.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22 Uname: Linux 5.11.0-25-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Sun Aug 8 15:16:28 2021 ExecutablePath: /usr/libexec/gnome-terminal-server InstallationDate: Installed on 2020-08-02 (370 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) ProcEnviron: LANG=fr_FR.UTF-8 PATH=(custom, user) SHELL=/bin/bash XDG_RUNTIME_DIR= SourcePackage: gnome-terminal UpgradeStatus: Upgraded to hirsute on 2021-07-11 (27 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939238/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1939409
Title:
merge e2fsprogs 1.46.3-1 from Debian: s390x fails in test f_baddotdir
Status in e2fsprogs package in Ubuntu:
New
Bug description:
e2fsprogs 1.46.3-1ubuntu1 is in proposed.
Architecture s390x fail in test f_baddotdir. The test image was
changed with the new release.
Next step should be analyzing the error on a s390x virtual machine.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939409/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1939238 Title: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Status in e2fsprogs package in Ubuntu: New Bug description: Hello This problem did not occur on my computer. https://nsa40.casimages.com/img/2021/08/07/210807015400327092.png It occurs in users who are not competent. This week, the French forum collapsed over this incident. I think changing the advice phrase might improve understanding of the action to be taken. Can these lines " ( i.e.. without -a or -p options) fsck existed with status code 4 The root file system on /dev/ requires a manual fsck" become "execute this command 'fsck -y /dev/xx' to do a manual fsck on the root file system." ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: gnome-terminal 3.38.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22 Uname: Linux 5.11.0-25-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Sun Aug 8 15:16:28 2021 ExecutablePath: /usr/libexec/gnome-terminal-server InstallationDate: Installed on 2020-08-02 (370 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) ProcEnviron: LANG=fr_FR.UTF-8 PATH=(custom, user) SHELL=/bin/bash XDG_RUNTIME_DIR= SourcePackage: gnome-terminal UpgradeStatus: Upgraded to hirsute on 2021-07-11 (27 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939238/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1935656 Title: e2fsprogs FTBFS when built with libfuse3-dev Status in e2fsprogs package in Ubuntu: Invalid Bug description: Fuse3 is a requirement for qemu 6 (LP: #1934510). Since we don't want to support two versions of fuse in main, we'd like reverse- dependencies of fuse to switch to fuse3. e2fsprogs FTBFS in a test rebuild changing the build-dependency on libfuse-dev to libfuse3-dev. Excerpt from the build log: checking for fuse.h... no To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1935656/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1897741 Title: hang after using util badblocks Status in e2fsprogs package in Ubuntu: New Bug description: sudo badblocks -v /dev/sdb2 > badsectors.txt after this command my computer hang, keyboard/mouse not working, no reaction, no ping in local network only hardreset can help sudo fdisk -l | grep /dev/sdb2 /dev/sdb2 206848 1422700543 1422493696 678,3G 7 HPFS/NTFS/exFAT ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: e2fsprogs 1.44.1-1ubuntu1.3 ProcVersionSignature: Ubuntu 5.4.0-48.52~18.04.1-generic 5.4.60 Uname: Linux 5.4.0-48-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.17 Architecture: amd64 CurrentDesktop: XFCE Date: Tue Sep 29 16:00:24 2020 InstallationDate: Installed on 2020-03-09 (204 days ago) InstallationMedia: Xubuntu 18.04.4 LTS "Bionic Beaver" - Release amd64 (20200203.1) SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1897741/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1881935
Title:
Minimum inode size should be raised to 256 for forward compatibility
(Y2038)
Status in e2fsprogs package in Ubuntu:
New
Bug description:
mke2fs in all supported Ubuntu releases to date creates 'small' ext4
file systems with an inode size of 128. This is said to be
insufficient to store time stamps referring to year 2038 and later
(when the Unix epoch exceeds a signed 32-bit integer -
https://en.wikipedia.org/wiki/Year_2038_problem). When such file
systems are mounted by the kernel, such as a /boot file system created
by the Ubuntu 20.04.0 Desktop installer (ubiquity 20.04.15), the
kernel will warn about this fact:
kernel: ext4 filesystem being mounted at /boot supports timestamps
until 2038 (0x7fff)
Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953494
Admittedly, that's another 18 years, by when most systems installed
now will be no longer in use, or will have been reinstalled.
Also, on a /boot file system the 5.4.0-33-generic #37 Ubuntu (20.04) kernel
warned about this, I was able to
$ touch -t 203812312359 /tmp/test
and got
$ ls -l /tmp/test
-rw-r--r-- 1 root root 0 Dez 31 2038 /tmp/test
so this warning may not always apply, or patches may have been applied to
handle this situation more gracefully already.
Ubuntu 20.04 comes with e2fsprogs 1.45.5-2ubuntu1. Theodore Y. Ts'o
has submitted patches for Debian's 1.45.6-1 - but (strictly speaking
based on the changelog) these seem to be limited to documentation
changes.
Still, creating such file systems may seem undesirable in terms of
forward compatibility. I therefore suggest to change the minimum inode
size for mke2fs, as defined in /etc/mke2fs.conf, to 256 for all file
systems which do not already use this value (maybe with the exception
of floppies). That is, I suggest the following change to Ubuntu
20.04's /etc/mke2fs.conf:
Before change:
small = {
inode_size = 128
inode_ratio = 4096
}
After change:
small = {
inode_ratio = 4096
}
This assumes that the default inode size is already set to 256 further
above.
As a WORKAROUND, after backing up the file system (this command is not well
tested, according to the lead ext4 file system developer), users can unmount
the affected file system and run
tune2fs -I 256 /path/to/block_device
where /path/to/block_device should be replaced by the path to the block
device which contains the file system the kernel reports the warning for. For
example, for the file system mounted at /boot, the
findmnt /boot
command would return the block device path in the SOURCE column.
Please note I prefer not to use apport for this bug report, I believe it is
already sufficiently complete.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1881935/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1860917 Title: uas_eh_abort_handler uas-tag inflight OUT Status in e2fsprogs package in Ubuntu: New Bug description: 591/5000 Hello To try to understand this incident ( https://bugs.launchpad.net/ubuntu/+source/gpart/+bug/1857914 ) which systematically occurs in version 19.10 and which I cannot (yet?) reproduce in version 18.04.03, I made a test game. Using this test game consisting only of cp and diff commands, I caused a similar problem. The first visible consequence which seems serious to me: The copied file is not identical to the sending file. It seems that the blocks are shifted. It would be desirable for the user to be warned that the written files have become incorrect. Thank you for your advice. Journalctl says only janv. 26 13:29:35 a kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) 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 janv. 26 13:30:12 a kernel: sd 6:0:0:0: [sdb] tag#16 CDB: Write(10) 2a 00 00 0f ec 00 00 04 00 00 janv. 26 14:22:48 a kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) a@a:~$ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1860917/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1860676
Title:
apt-get dist-upgrade -y hangs during e2fsprogs update
Status in e2fsprogs package in Ubuntu:
New
Bug description:
My recent apt-get dist-upgrade -y hung here:
...
update-initramfs: deferring update (trigger activated)
e2scrub_all.service is a disabled or a static unit not running, not starting
it.
I did a pstree on the apt-get process and saw this:
apt-get(31290)───dpkg(562)───e2fsprogs.posti(587)───systemctl(722
)───systemd-tty-ask(863)
Relevant processes:
root 863 0.0 0.0 15976 5996 pts/12 S+ 09:13 0:00
/bin/systemd-tty-ask-password-agent --watch
root 722 0.0 0.0 19668 3672 pts/12 S+ 09:13 0:00
/bin/systemctl restart e2scrub_all.timer e2scrub_reap.service
I killed the systemd-tty-ask-password-agent process, and it became
defunct but didn't die. So I killed the systemctl restart process, and
the upgrade continued, apparently without noticing that the systemctl
restart failed, which is a separate issue.
When I ran "sudo systemctl restart e2scrub_all.timer
e2scrub_reap.service" from the command line after the upgrade, it also
hung with systemd-tty-ask-password-agent apparently waiting for
something, so this problem isn't unique to upgrades.
ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: e2fsprogs 1.45.3-4ubuntu2.1
ProcVersionSignature: Ubuntu 5.3.0-26.28-generic 5.3.13
Uname: Linux 5.3.0-26-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu8.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Jan 23 09:37:04 2020
InstallationDate: Installed on 2019-09-12 (132 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
SourcePackage: e2fsprogs
UpgradeStatus: Upgraded to eoan on 2019-09-20 (125 days ago)
modified.conffile..etc.apport.crashdb.conf: [modified]
mtime.conffile..etc.apport.crashdb.conf: 2019-10-23T16:51:18.143596
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1860676/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1857914 Title: resize2fs destroy the content of the partition Status in gpart package in Ubuntu: New Bug description: Hello The used version of ubuntu is 19.10 So the used version of ubuntu is GParted 0.32.0 and the used of resize2fs is 1.45.3 (14-Jul-2019) I wanted to shrink by 20 GB the size of an old partition created with ubuntu 18.04 and stored on an external hard drive connected by USB3. The process says it works perfectly well see attachment file But the partition can no longer be mounted. The message is: mount: /mnt/sdb2 : wrong fs type, bad option, bad superblock on /dev/sdb2, missing codepage or helper program, or other error. if I do the stupidity to launch the fsk command to repair, I find all the files and directory in the special directory called Lost + found Being able to remake the original content, I have seen four times that it gives this unpleasant result. It also allows me to change the scenario. - If I use an internal disk partition instead of the external disk, you're fine. - If I use version 18.04, everything is fine even if I use the external disk - If I make a new partition on the external disk in version 19.10, I can shrink also without any problem. So I think there is a software regression for a very specific context. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gpart/+bug/1857914/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1857914 Title: resize2fs destroy the content of the partition Status in e2fsprogs package in Ubuntu: New Bug description: Hello The used version of ubuntu is 19.10 So the used version of ubuntu is GParted 0.32.0 and the used of resize2fs is 1.45.3 (14-Jul-2019) I wanted to shrink by 20 GB the size of an old partition created with ubuntu 18.04 and stored on an external hard drive connected by USB3. The process says it works perfectly well see attachment file But the partition can no longer be mounted. The message is: mount: /mnt/sdb2 : wrong fs type, bad option, bad superblock on /dev/sdb2, missing codepage or helper program, or other error. if I do the stupidity to launch the fsk command to repair, I find all the files and directory in the special directory called Lost + found Being able to remake the original content, I have seen four times that it gives this unpleasant result. It also allows me to change the scenario. - If I use an internal disk partition instead of the external disk, you're fine. - If I use version 18.04, everything is fine even if I use the external disk - If I make a new partition on the external disk in version 19.10, I can shrink also without any problem. So I think there is a software regression for a very specific context. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1857914/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1857914 Title: resize2fs destroy the content of the partition Status in e2fsprogs package in Ubuntu: New Bug description: Hello The used version of ubuntu is 19.10 So the used version of ubuntu is GParted 0.32.0 and the used of resize2fs is 1.45.3 (14-Jul-2019) I wanted to shrink by 20 GB the size of an old partition created with ubuntu 18.04 and stored on an external hard drive connected by USB3. The process says it works perfectly well see attachment file But the partition can no longer be mounted. The message is: mount: /mnt/sdb2 : wrong fs type, bad option, bad superblock on /dev/sdb2, missing codepage or helper program, or other error. if I do the stupidity to launch the fsk command to repair, I find all the files and directory in the special directory called Lost + found Being able to remake the original content, I have seen four times that it gives this unpleasant result. It also allows me to change the scenario. - If I use an internal disk partition instead of the external disk, you're fine. - If I use version 18.04, everything is fine even if I use the external disk - If I make a new partition on the external disk in version 19.10, I can shrink also without any problem. So I think there is a software regression for a very specific context. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1857914/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1830500 Title: Issue with e2scrub@-.service and e2scrub@-boot.service which tries to scrub ext4 partitions (/boot and /) Status in e2fsprogs package in Ubuntu: Confirmed Bug description: This is a fresh install of 19.04 upgraded to 19.10. I'm receiving these emails which seems to be related to a cronjob. I also tried to run /usr/sbin/e2scrub_all manually and I'm receiving the 2 same emails after I ran it. The emails in question: So sorry, the automatic e2scrub of /boot on cryptosid.local.lan failed. A log of what happened follows: ● e2scrub@-boot.service - Online ext4 Metadata Check for /boot Loaded: loaded (/lib/systemd/system/e2scrub@.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2019-05-24 08:26:37 EDT; 73ms ago Docs: man:e2scrub(8) Process: 28530 ExecStart=/sbin/e2scrub -t /boot (code=exited, status=1/FAILURE) Main PID: 28530 (code=exited, status=1/FAILURE) May 24 08:26:35 CryptoSiD systemd[1]: Starting Online ext4 Metadata Check for /boot... May 24 08:26:35 CryptoSiD e2scrub@-boot[28530]: /boot: Not connnected to a LVM logical volume. May 24 08:26:35 CryptoSiD e2scrub@-boot[28530]: Usage: /sbin/e2scrub [OPTIONS] mountpoint | device May 24 08:26:35 CryptoSiD e2scrub@-boot[28530]: mountpoint must be on a LVM-managed block device May 24 08:26:35 CryptoSiD e2scrub@-boot[28530]: -n: Show what commands e2scrub would execute. May 24 08:26:35 CryptoSiD e2scrub@-boot[28530]: -r: Remove e2scrub snapshot and exit, do not check anything. May 24 08:26:35 CryptoSiD e2scrub@-boot[28530]: -t: Run fstrim if successful. May 24 08:26:35 CryptoSiD e2scrub@-boot[28530]: -V: Print version information and exit. May 24 08:26:37 CryptoSiD systemd[1]: e2scrub@-boot.service: Main process exited, code=exited, status=1/FAILURE May 24 08:26:37 CryptoSiD systemd[1]: e2scrub@-boot.service: Failed with result 'exit-code'. May 24 08:26:37 CryptoSiD systemd[1]: Failed to start Online ext4 Metadata Check for /boot. May 24 08:26:37 CryptoSiD systemd[1]: e2scrub@-boot.service: Triggering OnFailure= dependencies. So sorry, the automatic e2scrub of /boot on cryptosid.local.lan failed. A log of what happened follows: ● e2scrub@-boot.service - Online ext4 Metadata Check for /boot Loaded: loaded (/lib/systemd/system/e2scrub@.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2019-05-23 23:09:29 EDT; 163ms ago Docs: man:e2scrub(8) Process: 31843 ExecStart=/sbin/e2scrub -t /boot (code=exited, status=1/FAILURE) Main PID: 31843 (code=exited, status=1/FAILURE) May 23 23:09:27 CryptoSiD systemd[1]: Starting Online ext4 Metadata Check for /boot... May 23 23:09:27 CryptoSiD e2scrub@-boot[31843]: /boot: Not connnected to a LVM logical volume. May 23 23:09:27 CryptoSiD e2scrub@-boot[31843]: Usage: /sbin/e2scrub [OPTIONS] mountpoint | device May 23 23:09:27 CryptoSiD e2scrub@-boot[31843]: mountpoint must be on a LVM-managed block device May 23 23:09:27 CryptoSiD e2scrub@-boot[31843]: -n: Show what commands e2scrub would execute. May 23 23:09:27 CryptoSiD e2scrub@-boot[31843]: -r: Remove e2scrub snapshot and exit, do not check anything. May 23 23:09:27 CryptoSiD e2scrub@-boot[31843]: -t: Run fstrim if successful. May 23 23:09:27 CryptoSiD e2scrub@-boot[31843]: -V: Print version information and exit. May 23 23:09:29 CryptoSiD systemd[1]: e2scrub@-boot.service: Main process exited, code=exited, status=1/FAILURE May 23 23:09:29 CryptoSiD systemd[1]: e2scrub@-boot.service: Failed with result 'exit-code'. May 23 23:09:29 CryptoSiD systemd[1]: Failed to start Online ext4 Metadata Check for /boot. May 23 23:09:29 CryptoSiD systemd[1]: e2scrub@-boot.service: Triggering OnFailure= dependencies. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: e2fsprogs 1.45.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6 Uname: Linux 5.0.0-15-generic x86_64 ApportVersion: 2.20.11-0ubuntu2 Architecture: amd64 Date: Sat May 25 17:43:20 2019 ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1830500/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1830500 Title: Issue with e2scrub@-.service and e2scrub@-boot.service which tries to scrub ext4 partitions (/boot and /) Status in e2fsprogs package in Ubuntu: Confirmed Bug description: This is a fresh install of 19.04 upgraded to 19.10. I'm receiving these emails which seems to be related to a cronjob. I also tried to run /usr/sbin/e2scrub_all manually and I'm receiving the 2 same emails after I ran it. The emails in question: So sorry, the automatic e2scrub of /boot on cryptosid.local.lan failed. A log of what happened follows: ● e2scrub@-boot.service - Online ext4 Metadata Check for /boot Loaded: loaded (/lib/systemd/system/e2scrub@.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2019-05-24 08:26:37 EDT; 73ms ago Docs: man:e2scrub(8) Process: 28530 ExecStart=/sbin/e2scrub -t /boot (code=exited, status=1/FAILURE) Main PID: 28530 (code=exited, status=1/FAILURE) May 24 08:26:35 CryptoSiD systemd[1]: Starting Online ext4 Metadata Check for /boot... May 24 08:26:35 CryptoSiD e2scrub@-boot[28530]: /boot: Not connnected to a LVM logical volume. May 24 08:26:35 CryptoSiD e2scrub@-boot[28530]: Usage: /sbin/e2scrub [OPTIONS] mountpoint | device May 24 08:26:35 CryptoSiD e2scrub@-boot[28530]: mountpoint must be on a LVM-managed block device May 24 08:26:35 CryptoSiD e2scrub@-boot[28530]: -n: Show what commands e2scrub would execute. May 24 08:26:35 CryptoSiD e2scrub@-boot[28530]: -r: Remove e2scrub snapshot and exit, do not check anything. May 24 08:26:35 CryptoSiD e2scrub@-boot[28530]: -t: Run fstrim if successful. May 24 08:26:35 CryptoSiD e2scrub@-boot[28530]: -V: Print version information and exit. May 24 08:26:37 CryptoSiD systemd[1]: e2scrub@-boot.service: Main process exited, code=exited, status=1/FAILURE May 24 08:26:37 CryptoSiD systemd[1]: e2scrub@-boot.service: Failed with result 'exit-code'. May 24 08:26:37 CryptoSiD systemd[1]: Failed to start Online ext4 Metadata Check for /boot. May 24 08:26:37 CryptoSiD systemd[1]: e2scrub@-boot.service: Triggering OnFailure= dependencies. So sorry, the automatic e2scrub of /boot on cryptosid.local.lan failed. A log of what happened follows: ● e2scrub@-boot.service - Online ext4 Metadata Check for /boot Loaded: loaded (/lib/systemd/system/e2scrub@.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2019-05-23 23:09:29 EDT; 163ms ago Docs: man:e2scrub(8) Process: 31843 ExecStart=/sbin/e2scrub -t /boot (code=exited, status=1/FAILURE) Main PID: 31843 (code=exited, status=1/FAILURE) May 23 23:09:27 CryptoSiD systemd[1]: Starting Online ext4 Metadata Check for /boot... May 23 23:09:27 CryptoSiD e2scrub@-boot[31843]: /boot: Not connnected to a LVM logical volume. May 23 23:09:27 CryptoSiD e2scrub@-boot[31843]: Usage: /sbin/e2scrub [OPTIONS] mountpoint | device May 23 23:09:27 CryptoSiD e2scrub@-boot[31843]: mountpoint must be on a LVM-managed block device May 23 23:09:27 CryptoSiD e2scrub@-boot[31843]: -n: Show what commands e2scrub would execute. May 23 23:09:27 CryptoSiD e2scrub@-boot[31843]: -r: Remove e2scrub snapshot and exit, do not check anything. May 23 23:09:27 CryptoSiD e2scrub@-boot[31843]: -t: Run fstrim if successful. May 23 23:09:27 CryptoSiD e2scrub@-boot[31843]: -V: Print version information and exit. May 23 23:09:29 CryptoSiD systemd[1]: e2scrub@-boot.service: Main process exited, code=exited, status=1/FAILURE May 23 23:09:29 CryptoSiD systemd[1]: e2scrub@-boot.service: Failed with result 'exit-code'. May 23 23:09:29 CryptoSiD systemd[1]: Failed to start Online ext4 Metadata Check for /boot. May 23 23:09:29 CryptoSiD systemd[1]: e2scrub@-boot.service: Triggering OnFailure= dependencies. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: e2fsprogs 1.45.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6 Uname: Linux 5.0.0-15-generic x86_64 ApportVersion: 2.20.11-0ubuntu2 Architecture: amd64 Date: Sat May 25 17:43:20 2019 ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: e2fsprogs UpgradeStatus: No upgrade log p
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1645232 Title: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL) Status in e2fsprogs package in Ubuntu: Fix Released Bug description: The original installed e2fsprogs did not support mke2fs -d /directory " option . So , git cloned from e2fsprogs packages from repository and installed it and followed below steps to reproduce this : 1. set the ACL rules as below to one of the binary : $ setfacl -m u:vipatil:r-- rootfs/usr/bin/helloworld $ getfacl rootfs/usr/bin/helloworld # file: rootfs/usr/bin/helloworld # owner: shkumar # group: hardev user::rwx user:vipatil:r-- group::--- mask::r-- other::--- 2. $ dd if=/dev/zero of=test.ext4 bs=1M count=60 3. $ mke2fs -t ext4 test.ext4 -d rootfs/ mke2fs 1.43.3 (04-Sep-2016) Discarding device blocks: done Creating filesystem with 61440 1k blocks and 15360 inodes Filesystem UUID: 495713b3-5f1f-427a-8359-a736dfb2ece9 Superblock backups stored on blocks: 8193, 24577, 40961, 57345 Allocating group tables: done Writing inode tables: done Creating journal (4096 blocks): done Copying files into the device: done Writing superblocks and filesystem accounting information: done 4. sudo mount -o loop,acl,user_xattr,rw,sync test.ext4 mountpoint 5.@/mountpoint$ getfacl usr/bin/helloworld getfacl: usr/bin/helloworld: Invalid argument To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1645232/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1807288
Title:
mkfs.ext4 -d $directory_with_acls leads to EINVAL
Status in e2fsprogs package in Ubuntu:
New
Bug description:
This looks an awful lot like bug 1645232 but that is claimed to be
fixed:
mwhudson@ringil:~/tmp$ mkfs.ext4 -V
mke2fs 1.44.1 (24-Mar-2018)
Using EXT2FS Library version 1.44.1
mwhudson@ringil:~/tmp$ dd if=/dev/zero count=0 bs=1M seek=100 of=./fake.img
0+0 records in
0+0 records out
0 bytes copied, 0.0015871 s, 0.0 kB/s
mwhudson@ringil:~/tmp$ mkdir -p stuff/journal
mwhudson@ringil:~/tmp$ setfacl -m g:adm:rwx stuff/journal
mwhudson@ringil:~/tmp$ mkfs.ext4 -L lala -O -metadata_csum -T default -O
uninit_bg fake.img -d ./stuff/
mke2fs 1.44.1 (24-Mar-2018)
Discarding device blocks: done
Creating filesystem with 25600 4k blocks and 6400 inodes
Allocating group tables: done
Writing inode tables: done
Creating journal (1024 blocks): done
Copying files into the device: done
Writing superblocks and filesystem accounting information: done
mwhudson@ringil:~/tmp$ sudo mount ./fake.img /mnt
mwhudson@ringil:~/tmp$ getfacl /mnt/journal/
getfacl: /mnt/journal/: Invalid argument
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1807288/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1806272 Title: resize2fs results in ext4 filesystem with warning/errors Status in e2fsprogs package in Ubuntu: New Bug description: Resized (downsized) an offline ext4 filesystem on LVM. Before resizing, I confirmed filesystem was clean with e2fsck. After resizing, several warnings/errors were found. Tried first with version 1.44.1 from Ubuntu 18.04.1 LTS. Then I compiled the 1.44.4 source, but the error was still present. Using ESXi 6.7 and starts with a fresh copy of the filesystem before each run. root@vedlikehold:~# e2fsck -f /dev/skole-vg/root e2fsck 1.44.4 (18-Aug-2018) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/skole-vg/root: 139206/8331264 files (0.2% non-contiguous), 3274416/33294336 blocks root@vedlikehold:~# resize2fs -P /dev/skole-vg/root resize2fs 1.44.4 (18-Aug-2018) Estimated minimum size of the filesystem: 3337578 root@vedlikehold:~# lvresize --resizefs -l 11776 /dev/skole-vg/root fsck from util-linux 2.31.1 /dev/mapper/skole--vg-root: clean, 139206/8331264 files, 3274416/33294336 blocks resize2fs 1.44.4 (18-Aug-2018) Resizing the filesystem on /dev/mapper/skole--vg-root to 12058624 (4k) blocks. The filesystem on /dev/mapper/skole--vg-root is now 12058624 (4k) blocks long. Size of logical volume skole-vg/root changed from <127.01 GiB (32514 extents) to 46.00 GiB (11776 extents). Logical volume skole-vg/root successfully resized. root@vedlikehold:~# e2fsck -f /dev/skole-vg/root e2fsck 1.44.4 (18-Aug-2018) Pass 1: Checking inodes, blocks, and sizes Inode 8 extent tree (at level 1) could be narrower. Fix? yes Inode 44075 extent block passes checks, but checksum does not match extent (logical block 10240, physical block 421888, len 8691) Fix? yes Inode 44083 extent block passes checks, but checksum does not match extent (logical block 51200, physical block 3414016, len 10293) Fix? yes Inode 44087 extent block passes checks, but checksum does not match extent (logical block 34816, physical block 3444736, len 574) Fix? yes Inode 44091 extent block passes checks, but checksum does not match extent (logical block 28672, physical block 4087808, len 7804) Fix? yes Inode 44093 extent block passes checks, but checksum does not match extent (logical block 26624, physical block 4030464, len 351) Fix? yes Inode 44106 extent block passes checks, but checksum does not match extent (logical block 49152, physical block 1308672, len 8370) Fix? yes Inode 44112 extent block passes checks, but checksum does not match extent (logical block 69632, physical block 1607680, len 16969) Fix? yes Inode 44116 extent block passes checks, but checksum does not match extent (logical block 2848, physical block 7861156, len 178) Fix? yes Inode 44117 extent block passes checks, but checksum does not match extent (logical block 1592, physical block 7862368, len 98) Fix? yes Inode 44119 extent block passes checks, but checksum does not match extent (logical block 2150, physical block 15663, len 134) Fix? yes Inode 44120 extent block passes checks, but checksum does not match extent (logical block 24934, physical block 5329460, len 1014) Fix? yes Inode 44122 extent block passes checks, but checksum does not match extent (logical block 734, physical block 3257320, len 44) Fix? yes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/skole-vg/root: 139206/3014656 files (0.2% non-contiguous), 2938632/12058624 blocks root@vedlikehold:~# To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1806272/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post t
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1806272 Title: resize2fs results in ext4 filesystem with warning/errors Status in e2fsprogs package in Ubuntu: New Bug description: Resized (downsized) an offline ext4 filesystem on LVM. Before resizing, I confirmed filesystem was clean with e2fsck. After resizing, several warnings/errors were found. Tried first with version 1.44.1 from Ubuntu 18.04.1 LTS. Then I compiled the 1.44.4 source, but the error was still present. Using ESXi 6.7 and starts with a fresh copy of the filesystem before each run. root@vedlikehold:~# e2fsck -f /dev/skole-vg/root e2fsck 1.44.4 (18-Aug-2018) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/skole-vg/root: 139206/8331264 files (0.2% non-contiguous), 3274416/33294336 blocks root@vedlikehold:~# resize2fs -P /dev/skole-vg/root resize2fs 1.44.4 (18-Aug-2018) Estimated minimum size of the filesystem: 3337578 root@vedlikehold:~# lvresize --resizefs -l 11776 /dev/skole-vg/root fsck from util-linux 2.31.1 /dev/mapper/skole--vg-root: clean, 139206/8331264 files, 3274416/33294336 blocks resize2fs 1.44.4 (18-Aug-2018) Resizing the filesystem on /dev/mapper/skole--vg-root to 12058624 (4k) blocks. The filesystem on /dev/mapper/skole--vg-root is now 12058624 (4k) blocks long. Size of logical volume skole-vg/root changed from <127.01 GiB (32514 extents) to 46.00 GiB (11776 extents). Logical volume skole-vg/root successfully resized. root@vedlikehold:~# e2fsck -f /dev/skole-vg/root e2fsck 1.44.4 (18-Aug-2018) Pass 1: Checking inodes, blocks, and sizes Inode 8 extent tree (at level 1) could be narrower. Fix? yes Inode 44075 extent block passes checks, but checksum does not match extent (logical block 10240, physical block 421888, len 8691) Fix? yes Inode 44083 extent block passes checks, but checksum does not match extent (logical block 51200, physical block 3414016, len 10293) Fix? yes Inode 44087 extent block passes checks, but checksum does not match extent (logical block 34816, physical block 3444736, len 574) Fix? yes Inode 44091 extent block passes checks, but checksum does not match extent (logical block 28672, physical block 4087808, len 7804) Fix? yes Inode 44093 extent block passes checks, but checksum does not match extent (logical block 26624, physical block 4030464, len 351) Fix? yes Inode 44106 extent block passes checks, but checksum does not match extent (logical block 49152, physical block 1308672, len 8370) Fix? yes Inode 44112 extent block passes checks, but checksum does not match extent (logical block 69632, physical block 1607680, len 16969) Fix? yes Inode 44116 extent block passes checks, but checksu
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1783757 Title: shrinking previous file systems makes them corrupted Status in e2fsprogs package in Ubuntu: New Bug description: Booted in UEFI mode, running test example 'Install (auto-resize) in Kubuntu Desktop amd64 in Bionic Daily' the previous file system was shrunk in order to create space for the current one. But it was corrupted and must be fixed. Workaround: sudo e2fsck -f /dev/sda2 The same thing happened when booted in UEFI mode, running test example 'Install (manual partitioning) in Kubuntu Desktop amd64 in Bionic Daily' Workaround: sudo e2fsck -f /dev/sda3 (This current operating system's file system was fixed and made bootable again.) --- tester@tester-SATELLITE-PRO-C850-19W:~$ sudo parted -ls [sudo] password for tester: Model: ATA KINGSTON SUV400S (scsi) Disk /dev/sda: 120GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End SizeFile system Name Flags 1 2098kB 317MB 315MB fat32 boot, esp 2 317MB 20,3GB 20,0GB ext4 3 20,3GB 45,9GB 25,6GB ext4 4 45,9GB 107GB 61,4GB ext4 tester@tester-SATELLITE-PRO-C850-19W:~$ sudo lsblk -fm NAME FSTYPE LABEL UUID MOUNTPOINT SIZE OWNER GROUP MODE sda 111,8G root disk brw-rw ├─sda1 vfat 6106-B035/boot/efi300M root disk brw-rw ├─sda2 ext4 d6df56de-4490-4508-beb4-8259dda193c4 18,6G root disk brw-rw ├─sda3 ext4 e375e0d6-e162-4136-af21-377a635761a8 / 23,9G root disk brw-rw └─sda4 ext4 646734a2-45bf-4000-815e-31bbafcdfd29 57,2G root disk brw-rw sr0 1024M root cdrom brw-rw tester@tester-SATELLITE-PRO-C850-19W:~$ ubuntu-bug ubiquity --- ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: ubiquity (not installed) ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18 Uname: Linux 4.15.0-29-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: KDE Date: Thu Jul 26 14:01:38 2018 InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/kubuntu.seed boot=casper maybe-ubiquity quiet splash --- InstallationDate: Installed on 2018-07-26 (0 days ago) InstallationMedia: Kubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) SourcePackage: ubiquity UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1783757/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1778140 Title: resize2fs hoses a filesystem on lvm after resizing Status in e2fsprogs package in Ubuntu: Confirmed Bug description: Resized an ext4 filesystem on LVM. Before resizing, I confirmed filesystem was clean with e2fsck. After resizing, three errors were found. root@ubuntu:~# e2fsck -f /dev/ubuntu-vg/root e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking inodes, blocks, and sizes Inode 21110 extent block passes checks, but checksum does not match extent (logical block 18432, physical block 503808, len 3813) Fix? no Inode 26807 extent block passes checks, but checksum does not match extent (logical block 34816, physical block 768000, len 896) Fix? no Inode 28306 extent block passes checks, but checksum does not match extent (logical block 30720, physical block 430080, len 5130) Fix? no Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information This setup is currently in a virtual machine with a snapshot, so I can revert back and retest. The resize2fs is coming from the 18.04 Ubuntu CD. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: e2fsprogs 1.44.1-1 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 CasperVersion: 1.394 CurrentDesktop: ubuntu:GNOME Date: Thu Jun 21 21:03:56 2018 LiveMediaBuild: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1778140/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1798562 Title: After a side by side installation, resized filesystem is corrupted Status in e2fsprogs package in Ubuntu: Confirmed Bug description: Test Case 1: With e2fsprogs 1.44.4-2: Download this file system image: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1798562/+attachment/5203159/+files/vda1b.qcow2.bz Run the following commands: bunzip2 vda1b.qcow2.bz qemu-img convert vda1b.qcow2 vda1b.raw e2fsck -f vda1b.raw resize2fs vda1b.raw 6200M e2fsck -f vda1b.raw e2fsck 1.44.4 (18-Aug-2018) Pass 1: Checking inodes, blocks, and sizes Inode 45746 extent block passes checks, but checksum does not match extent (logical block 1272, physical block 466167, len 776) Fix? Test Case 2 (Use case of the installer): 1. Perform a first installation of Ubuntu 2. Reboot into the freshly installed system and verify everything works as expected 3. Do a second installation and select "Install alonogside". Keep the size proposed by the installer and proceed to the end of installation 4. Reboot 5. On boot, in the list of installed systems, select the first system installed on the machine 6. Verify that it boots, you can login and it works as expected Actual Result The FS is corrupted and depending on the corruption it goes to initramfs, boots but cannot login, ... Attached is the journal of the system installed on the corrupted partition. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: ubiquity (not installed) ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 Uname: Linux 4.18.0-10-generic x86_64 ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Oct 18 10:53:57 2018 InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper only-ubiquity quiet splash --- InstallationDate: Installed on 2018-10-18 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) SourcePackage: ubiquity UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1798562/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1797282 Title: fsck not running at all on reboot Status in e2fsprogs package in Ubuntu: Confirmed Bug description: After upgrading some servers from 16.04 to 18.04 I'm met with a MOTD that says: *** /dev/xvda1 should be checked for errors *** I added "fsck.mode=force" to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub before running 'sudo update-grub'. I also verified that fsck was present in /boot/grub/grub.cfg afterwards, before rebooting the server. Surprisingly I was met with the same error message in MOTD when logging in. I then ran tune2fs to see when the last check was performed and this is the output: $ sudo tune2fs -l /dev/xvda1 | grep checked Last checked: Wed Sep 12 16:17:00 2018 I then tried to change mount count to 1 with tune2fs -c 1 /dev/xvda1, but after another reboot I was still met with the same error message and the timestamp for last checked was unchanged. I have the same problem on all the servers that was upgraded from 16.04 to 18.04, but also on a new server installed directly with 18.04. In should be mentioned that the servers are AWS EC2 instances, so I have no way of trying to run fsck from a liveusb. Another user has reported the same issue here: https://ubuntuforums.org/showthread.php?t=2403368 I'm not quite sure what information is needed, but attached are some basic information about the system. Please let me know if you need any any other outputs or logs. Edit1: I tested fsck.mode=force on my laptop running Ubuntu 18.04.1 LTS (Xubuntu) and it works fine. Seems to be related to the server edition. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1797282/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1796788 Title: resize2fs: Illegal indirect block found while trying to resize Status in e2fsprogs package in Ubuntu: Confirmed Bug description: The new resize2fs(1.43+) failed to resize attached image file, and e2fsck didn't report any error before the resizing. Test steps: 1/ e2fsck -fy userdata.img 2/ resize2fs userdata.img 220M Result: When using resize2fs from e2fsprogs 1.43+(tested 1.43.4/1.43.5/1.44.4), it would abort with: Resizing the filesystem on userdata.img to 225280 (1k) blocks. resize2fs: Illegal indirect block found while trying to resize userdata.img Please run 'e2fsck -fy userdata.img' to fix the filesystem after the aborted resize operation. More information: 1/ The image is generated on xenial with genext2fs 2/ It works well on xenial with e2fsprogs 1.42.13-1ubuntu1 3/ It works well when resizing with a size less than 220M, for example "resize2fs userdata.img 219M" 4/ online resize works To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1796788/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1796788 Title: resize2fs: Illegal indirect block found while trying to resize Status in e2fsprogs package in Ubuntu: Confirmed Bug description: The new resize2fs(1.43+) failed to resize attached image file, and e2fsck didn't report any error before the resizing. Test steps: 1/ e2fsck -fy userdata.img 2/ resize2fs userdata.img 220M Result: When using resize2fs from e2fsprogs 1.43+(tested 1.43.4/1.43.5/1.44.4), it would abort with: Resizing the filesystem on userdata.img to 225280 (1k) blocks. resize2fs: Illegal indirect block found while trying to resize userdata.img Please run 'e2fsck -fy userdata.img' to fix the filesystem after the aborted resize operation. More information: 1/ The image is generated on xenial with genext2fs 2/ It works well on xenial with e2fsprogs 1.42.13-1ubuntu1 3/ It works well when resizing with a size less than 220M, for example "resize2fs userdata.img 219M" 4/ online resize works To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1796788/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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&id=b0ec76d623f737a32abc5ab8bb7198bf1d9939a4 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1796379 Title: dumpe2fs crashed with SIGSEGV in e2p_is_null_uuid() Status in e2fsprogs package in Ubuntu: New Bug description: when using gnome control center (no idea, if related) ProblemType: Crash DistroRelease: Ubuntu 18.10 Package: e2fsprogs 1.44.4-2 ProcVersionSignature: Ubuntu 4.18.0-8.9-generic 4.18.7 Uname: Linux 4.18.0-8-generic x86_64 ApportVersion: 2.20.10-0ubuntu11 Architecture: amd64 Date: Fri Oct 5 19:27:27 2018 ExecutablePath: /sbin/dumpe2fs InstallationDate: Installed on 2018-10-05 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Beta amd64 (20181004) ProcCmdline: dumpe2fs -h /dev/sdc1 SegvAnalysis: Segfault happened at: 0x7fa1b9836ffc : cmpb $0x0,-0x1(%rdi) PC (0x7fa1b9836ffc) ok source "$0x0" ok destination "-0x1(%rdi)" (0x7ffcdb8f3000) not located in a known VMA region (needed writable region)! SegvReason: writing unknown VMA Signal: 11 SourcePackage: e2fsprogs StacktraceTop: e2p_is_null_uuid () from /lib/x86_64-linux-gnu/libe2p.so.2 e2p_uuid2str () from /lib/x86_64-linux-gnu/libe2p.so.2 e2p_list_journal_super () from /lib/x86_64-linux-gnu/libe2p.so.2 ?? () ?? () Title: dumpe2fs crashed with SIGSEGV in e2p_is_null_uuid() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1796379/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/575542 Title: resize2fs does not respect flex_bg Status in e2fsprogs package in Ubuntu: Triaged Status in linux package in Ubuntu: Triaged Bug description: Binary package hint: e2fsprogs When running resize2fs to perform an online extend of an ext4 filesystem, it does not respect the flex_bg feature. Instead, it lays out the added block groups with their normal non flex_bg positions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/575542/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1778140 Title: resize2fs hoses a filesystem on lvm after resizing Status in e2fsprogs package in Ubuntu: New Bug description: Resized an ext4 filesystem on LVM. Before resizing, I confirmed filesystem was clean with e2fsck. After resizing, three errors were found. root@ubuntu:~# e2fsck -f /dev/ubuntu-vg/root e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking inodes, blocks, and sizes Inode 21110 extent block passes checks, but checksum does not match extent (logical block 18432, physical block 503808, len 3813) Fix? no Inode 26807 extent block passes checks, but checksum does not match extent (logical block 34816, physical block 768000, len 896) Fix? no Inode 28306 extent block passes checks, but checksum does not match extent (logical block 30720, physical block 430080, len 5130) Fix? no Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information This setup is currently in a virtual machine with a snapshot, so I can revert back and retest. The resize2fs is coming from the 18.04 Ubuntu CD. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: e2fsprogs 1.44.1-1 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 CasperVersion: 1.394 CurrentDesktop: ubuntu:GNOME Date: Thu Jun 21 21:03:56 2018 LiveMediaBuild: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1778140/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1778140 Title: resize2fs hoses a filesystem on lvm after resizing Status in e2fsprogs package in Ubuntu: New Bug description: Resized an ext4 filesystem on LVM. Before resizing, I confirmed filesystem was clean with e2fsck. After resizing, three errors were found. root@ubuntu:~# e2fsck -f /dev/ubuntu-vg/root e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking inodes, blocks, and sizes Inode 21110 extent block passes checks, but checksum does not match extent (logical block 18432, physical block 503808, len 3813) Fix? no Inode 26807 extent block passes checks, but checksum does not match extent (logical block 34816, physical block 768000, len 896) Fix? no Inode 28306 extent block passes checks, but checksum does not match extent (logical block 30720, physical block 430080, len 5130) Fix? no Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information This setup is currently in a virtual machine with a snapshot, so I can revert back and retest. The resize2fs is coming from the 18.04 Ubuntu CD. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: e2fsprogs 1.44.1-1 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 CasperVersion: 1.394 CurrentDesktop: ubuntu:GNOME Date: Thu Jun 21 21:03:56 2018 LiveMediaBuild: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1778140/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1743553 Title: [Typo] Missing word in Zesty Man Page for e4defrag Status in e2fsprogs package in Ubuntu: New Bug description: Location: First sentence, second paragraph, Notes section. http://manpages.ubuntu.com/manpages/zesty/man8/e4defrag.8.html Original: "It safe to run e4defrag on a file while it is actively in use by another application." Text should state "It is safe to run..." To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1743553/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming Status in e2fsprogs package in Ubuntu: Triaged Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1764180 Title: System slows down to almost freeze Status in e2fsprogs package in Ubuntu: New Bug description: For quite a while sometimes my system slows down to almost freeze where it becomes unusable. The problem seems to be related to heavy disk i/o, but I have not been able to pinpoint the cause. The problem seems to occur when I both use the bitcoin core application for Bitcoin Gold and VirtualBox. I normally use VirtualBox to run two Windows 2008 servers. It seems in the end the system sorts itself out and starts running normal again, but it often causes to destroy the status of the Virtual Machines, sometimes resulting in a Virtual Machine going into 'guru- meditation' mode. Normally my system is fast enough to run everything. I have 8 Gb memory, 5 hard disks and an Intel I5. I tried to spread the load over the hard disks, but that doesn't seem to have any effect on the slowing down of the system. My feeling is that the problem is somehow related to some disk i/o system independent of the individual disks. Mostly the problem is solved by stopping the Bitcoin Core Gold program, but that is very hard to do, as even a terminal window takes minutes or up to an hour or so to respond. That also makes it very hard to identify the problem. I have several monitoring programs installed, but can't use them when the system is in this 'almost frozen' mode. I am using Ubuntu 16.04.4. The problem is not to x.x.4 version of Ubuntu 16.04. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: e2fslibs 1.42.13-1ubuntu1 ProcVersionSignature: Ubuntu 4.13.0-38.43~16.04.1-generic 4.13.16 Uname: Linux 4.13.0-38-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.15 Architecture: amd64 CurrentDesktop: LXDE Date: Mon Apr 16 04:45:11 2018 Dependencies: gcc-7-base 7.1.0-10ubuntu1~16.04.york0 [origin: LP-PPA-jonathonf-gcc-7.1] libc6 2.23-0ubuntu10 libgcc1 1:7.1.0-10ubuntu1~16.04.york0 [origin: LP-PPA-jonathonf-gcc-7.1] InstallationDate: Installed on 2017-01-21 (449 days ago) InstallationMedia: Lubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021) SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1764180/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming Status in e2fsprogs package in Ubuntu: Triaged Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming Status in e2fsprogs package in Ubuntu: Triaged Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1601997 Title: Ubuntu 16.10+ installer uses ext4 feature 'metadata_csum' which is incompatible with older (LTS) e2fsprogs Status in e2fsprogs package in Ubuntu: Triaged Bug description: Ubuntu 16.10 installer sets metadata_csum option on ext4 partition which is incompatible with other LTS Ubuntu versions (12.04 LTS, 14.04 LTS, 16.04 LTS). Steps to reproduce: 1. Download Ubuntu 16.10 installation media. 2. Install Ubuntu. 3. Try to do fsck -fy /dev/sdX1 from other supported Ubuntu distro. Expected results: User can check and fix errors on ext4 filesystem, created on Ubuntu 16.10. Actual results: User can not check and fix errors on ext4 filesystem because of lack of 'metadata_csum' option in previous LTS Ubuntu versions. The only one working solution was to scan from 16.10 live install media. Note: it is known, that Dan Watkins disabled metadata_csum when creating ext4 filesystems ( see http://bazaar.launchpad.net/~daniel-thewatkins/maas-images/fix-yakkety-builds/revision/305 ). It is good solution. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: e2fsprogs 1.43.1-1 ProcVersionSignature: Ubuntu 4.4.0-30.49-generic 4.4.13 Uname: Linux 4.4.0-30-generic i686 ApportVersion: 2.20.2-0ubuntu1 Architecture: i386 CurrentDesktop: Unity Date: Mon Jul 11 23:42:49 2016 SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1601997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming Status in e2fsprogs package in Ubuntu: Triaged Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in 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 Status in e2fsprogs package in Ubuntu: Triaged Bug description: Ubuntu 16.10 installer sets metadata_csum option on ext4 partition which is incompatible with other LTS Ubuntu versions (12.04 LTS, 14.04 LTS, 16.04 LTS). Steps to reproduce: 1. Download Ubuntu 16.10 installation media. 2. Install Ubuntu. 3. Try to do fsck -fy /dev/sdX1 from other supported Ubuntu distro. Expected results: User can check and fix errors on ext4 filesystem, created on Ubuntu 16.10. Actual results: User can not check and fix errors on ext4 filesystem because of lack of 'metadata_csum' option in previous LTS Ubuntu versions. The only one working solution was to scan from 16.10 live install media. Note: it is known, that Dan Watkins disabled metadata_csum when creating ext4 filesystems ( see http://bazaar.launchpad.net/~daniel-thewatkins/maas-images/fix-yakkety-builds/revision/305 ). It is good solution. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: e2fsprogs 1.43.1-1 ProcVersionSignature: Ubuntu 4.4.0-30.49-generic 4.4.13 Uname: Linux 4.4.0-30-generic i686 ApportVersion: 2.20.2-0ubuntu1 Architecture: i386 CurrentDesktop: Unity Date: Mon Jul 11 23:42:49 2016 SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1601997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 in
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 Touch seeded packages, which is subscribed to e2fsprogs in 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 Status in e2fsprogs package in Ubuntu: New Bug description: This happened during a partial upgrade of Bionic. ProblemType: Package DistroRelease: Ubuntu 18.04 Package: libcomerr2 1.43.8-2 ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13 Uname: Linux 4.13.0-32-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.8-0ubuntu8 Architecture: amd64 Date: Mon Feb 12 15:51:57 2018 Dependencies: gcc-7-base 7.2.0-18ubuntu2 libc6 2.26-0ubuntu2 libgcc1 1:7.2.0-18ubuntu2 DpkgTerminalLog: Preparing to unpack .../comerr-dev_2.1-1.43.9-1_amd64.deb ... Unpacking comerr-dev:amd64 (2.1-1.43.9-1) over (2.1-1.43.8-2) ... dpkg: error processing archive /var/cache/apt/archives/libcomerr2_1.43.9-1_all.deb (--unpack): libcomerr2:all 1.43.9-1 (Multi-Arch: no) is not co-installable with libcomerr2 which has multiple installed instances DuplicateSignature: package:libcomerr2:1.43.8-2 Unpacking comerr-dev:amd64 (2.1-1.43.9-1) over (2.1-1.43.8-2) ... dpkg: error processing archive /var/cache/apt/archives/libcomerr2_1.43.9-1_all.deb (--unpack): libcomerr2:all 1.43.9-1 (Multi-Arch: no) is not co-installable with libcomerr2 which has multiple installed instances ErrorMessage: libcomerr2:all 1.43.9-1 (Multi-Arch: no) is not co-installable with libcomerr2 which has multiple installed instances InstallationDate: Installed on 2013-01-16 (1853 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130116) Python3Details: /usr/bin/python3.6, Python 3.6.4, python3-minimal, 3.6.4-1 PythonDetails: /usr/bin/python2.7, Python 2.7.14+, python-minimal, 2.7.14-4 RelatedPackageVersions: dpkg 1.19.0.5ubuntu1 apt 1.6~alpha7ubuntu1 SourcePackage: e2fsprogs 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 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1749036/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1733517] [NEW] ip link set dev eth0 vf 0 trust on
Public bug reported: Looks like I can't execute the following command...this is for an Intel X710 adapter...when I execute the following for my adapter: ip link set dev enp131s0f0 vf 0 trust on I get the following output from iproute2: Command line is not complete. Try option "help" I see a similar redhat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1444210 Has this feature been deprecated ? ** Affects: iproute2 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1733517 Title: ip link set dev eth0 vf 0 trust on Status in iproute2 package in Ubuntu: New Bug description: Looks like I can't execute the following command...this is for an Intel X710 adapter...when I execute the following for my adapter: ip link set dev enp131s0f0 vf 0 trust on I get the following output from iproute2: Command line is not complete. Try option "help" I see a similar redhat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1444210 Has this feature been deprecated ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1733517/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1713175 Title: Obsolete backup ext2/3/4 superblocks can confuse e2fsck on an encrypted LUKS partition Status in cryptsetup package in Ubuntu: Confirmed Status in e2fsprogs package in Ubuntu: New Status in util-linux package in Ubuntu: New Bug description: fsck.ext4 runs on a LUKS partition and starts to correct inode entries, rendering the partition corrupted and useless. It seems like it should defensively check where it is an isLuks partition using "cryptsetup isLuks /dev/sda1" before continuing to modify it. I hope such a defensive check can be added. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1713175/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1713175 Title: fsck should check before running on an encrypted LUKS partition Status in cryptsetup package in Ubuntu: Confirmed Status in e2fsprogs package in Ubuntu: New Status in util-linux package in Ubuntu: New Bug description: fsck.ext4 runs on a LUKS partition and starts to correct inode entries, rendering the partition corrupted and useless. It seems like it should defensively check where it is an isLuks partition using "cryptsetup isLuks /dev/sda1" before continuing to modify it. I hope such a defensive check can be added. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1713175/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1713175 Title: fsck should check before running on an encrypted LUKS partition Status in cryptsetup package in Ubuntu: Confirmed Status in e2fsprogs package in Ubuntu: New Status in util-linux package in Ubuntu: New Bug description: fsck.ext4 runs on a LUKS partition and starts to correct inode entries, rendering the partition corrupted and useless. It seems like it should defensively check where it is an isLuks partition using "cryptsetup isLuks /dev/sda1" before continuing to modify it. I hope such a defensive check can be added. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1713175/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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&id=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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1702240 Title: [Ubuntu 17.04] 'make test' failures seen when e2fsprogs instrumented with 'undefined behavior sanitizer' Status in The Ubuntu-power-systems project: New Status in e2fsprogs package in Ubuntu: New Bug description: ---Problem Description--- 'make test' shows '262 tests failed' when e2fsprogs instrumented with 'Undefined Behavior Sanitizer' Contact Information = nasas...@in.ibm.com ---uname output--- Linux powerkvm1-lp1 4.10.0-9-generic #11-Ubuntu SMP Mon Feb 20 13:45:11 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux Machine Type = 8284-22A ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1. Prepare the build environment and download e2fsprogs apt-get build-dep -y e2fsprogs mkdir pkg cd pkg apt-get source e2fsprogs cd e2fsprogs-1.43.4/ 2. Now instrument with 'undefined behavior sanitizer' and run 'make test' dh_testdir dh_auto_configure -- CFLAGS="-fsanitize=undefined -fsanitize=address" LDFLAGS="-fsanitize=undefined -fsanitize=address" CXXFLAGS="-fsanitize=undefined -fsanitize=address" dh_auto_build dh_auto_test ... 65 tests succeeded262 tests failed Tests failed: d_dumpe2fs_group_only d_fallocate_bigalloc d_fallocate_blkmap d_fallocate d_loaddump d_punch_bigalloc d_punch d_special_files d_xattr_edits d_xattr_sorting f_16384_block f_8192_block f_bad_bbitmap f_badbblocks f_bad_bmap_csum f_badcluster f_baddir2 f_baddir f_bad_disconnected_inode f_baddotdir f_bad_gdt_csum f_bad_ibitmap f_bad_inode_csum f_badinode f_badjourblks f_badjour_indblks f_bad_local_jnl f_badorphan f_badprimary f_badroot f_badsymlinks f_badtable f_bbfile f_bb_in_bb f_bbinode f_big_sparse f_bitmaps f_boundscheck f_clear_xattr f_cloneblock_alloc_error f_collapse_extent_tree f_compress_extent_tree_level f_convert_bmap_and_extent f_convert_bmap f_corrupt_dirent_tail f_create_symlinks f_deleted_inode_bad_csum f_desc_size_128 f_desc_size_bad f_dir_bad_csum f_dir_bad_mode f_dirlink f_dup2 f_dup3 f_dup4 f_dup_ba f_dup_de2 f_dup_de f_dupdot f_dup f_dupfsblks f_dup_resize f_dupsuper f_ea_bad_csum f_ea_checks f_ea_value_crash f_emptydir f_encrypted_lpf f_end-bitmap f_e ofblocks f_expand f_expandroot_create_lnf f_extent_bad_node f_extent_htree f_extent_int_bad_csum f_extent_int_bad_extent f_extent_int_bad_magic f_extent_interior_start_lblk f_extent_leaf_bad_csum f_extent_leaf_bad_extent f_extent_leaf_bad_magic f_extent_oobounds f_extents2 f_extents f_extent_too_deep f_ext_journal f_extra_journal f_ext_zero_len f_fast_symlink_extents f_file_acl_high f_filetype f_first_meta_bg_too_big f_full_bg f_h_badnode f_h_badroot f_h_normal f_holedir2 f_holedir3 f_holedir4 f_holedir f_h_reindex f_htree_bad_csum f_htree_leaf_csum f_hugedir_blocks f_h_unsigned f_hurd f_idata_and_extents f_illbbitmap f_illibitmap f_illitable f_illitable_flexbg f_imagic f_imagic_fs f_ind_inode_collision f_inlinedata_dirblocks f_inlinedata_repair f_inlinedir_detector f_inode_ea_collision f_invalid_bad_inode f_invalid_extent_symlink f_itable_collision f_jnl_32bit f_jnl_64bit f_jnl_errno f_jnl_etb_alloc_fail f_journal f_lotsbad f_lpf2 f_lpf f_lpffile f_messy_inode f_miss_blk_bmap f_mis s_journal f_misstable f_mke2fs2b f_mmp_garbage f_no_cache_corrupt_inode f_no f_noroot f_nospc_create_lnf f_okgroup f_opt_extent_ext3 f_opt_extent f_orphan_dotdot_ft f_orphan_extents_inode f_orphan f_orphan_indirect_inode f_overfsblks f_preen f_quota f_readonly_fsck f_rebuild_csum_rootdir f_recnect_bad f_reconnect f_rehash_dir f_resize_inode f_salvage_dir f_sb_extra_isize f_selinux f_short_encrypted_dirent f_special_ea f_summary_counts f_super_bad_csum f_toobig_extent_dir f_trunc_dirent_header f_uninit_cat f_uninit_dir f_uninit_ext_past_eof2 f_uninit_ext_past_eof f_uninit_last_uninit f_unsorted_EAs f_unused_itable f_valid_ea_in_inode f_write_ea_no_extra_isize f_write_ea_toobig_extra_isize f_write_ea_toosmall_extra_isize f_yesall f_yes f_yesthenall f_yesthenno f_zeroed_ext_header f_zero_group f_zero_inode_size f_zero_super f_zero_xattr i_bad_csum j_corrupt_commit_csum j_corrupt_commit_tid j_corrupt_descr_csum j_corrupt_descr_tid j_corrupt_ext_jnl_sb_csum j_corrupt_journal_block j_corr upt_revoke_block j_corrupt_revoke_csum j_corrupt_revoke_rcount j_co
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1637779 Title: ext4 filesystem fails randomly with checksum error Status in e2fsprogs package in Ubuntu: Confirmed Bug description: Description: Ubuntu 16.10 Release: 16.10 package version: linux-image-4.8.0-26-generic: Installed: 4.8.0-26.28 Candidate: 4.8.0-26.28 Version table: *** 4.8.0-26.28 500 500 http://sk.archive.ubuntu.com/ubuntu yakkety-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu yakkety-security/main amd64 Packages 100 /var/lib/dpkg/status fresh installation of Ubunut 16.10, all updates included While I am working with system after few minutes root filesystem /dev/sdb5 switches into readonly mode in dmesg is this: [ 304.921552] EXT4-fs error (device sdb5): ext4_iget:4476: inode #24577: comm updatedb.mlocat: checksum invalid [ 304.925565] Aborting journal on device sdb5-8. [ 304.926507] EXT4-fs (sdb5): Remounting filesystem read-only [ 304.927416] EXT4-fs error (device sdb5): ext4_journal_check_start:56: Detected aborted journal [ 304.943408] EXT4-fs error (device sda1): ext4_iget:4476: inode #12: comm updatedb.mlocat: checksum invalid when it happens I must do fsck f /dev/sdb1 once, second time it says everything is fine. after reboot when I start dto do something it soon happens again To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1637779/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1702240 Title: [Ubuntu 17.04] 'make test' failures seen when e2fsprogs instrumented with 'undefined behavior sanitizer' Status in The Ubuntu-power-systems project: New Status in e2fsprogs package in Ubuntu: New Bug description: ---Problem Description--- 'make test' shows '262 tests failed' when e2fsprogs instrumented with 'Undefined Behavior Sanitizer' Contact Information = nasas...@in.ibm.com ---uname output--- Linux powerkvm1-lp1 4.10.0-9-generic #11-Ubuntu SMP Mon Feb 20 13:45:11 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux Machine Type = 8284-22A ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1. Prepare the build environment and download e2fsprogs apt-get build-dep -y e2fsprogs mkdir pkg cd pkg apt-get source e2fsprogs cd e2fsprogs-1.43.4/ 2. Now instrument with 'undefined behavior sanitizer' and run 'make test' dh_testdir dh_auto_configure -- CFLAGS="-fsanitize=undefined -fsanitize=address" LDFLAGS="-fsanitize=undefined -fsanitize=address" CXXFLAGS="-fsanitize=undefined -fsanitize=address" dh_auto_build dh_auto_test ... 65 tests succeeded262 tests failed Tests failed: d_dumpe2fs_group_only d_fallocate_bigalloc d_fallocate_blkmap d_fallocate d_loaddump d_punch_bigalloc d_punch d_special_files d_xattr_edits d_xattr_sorting f_16384_block f_8192_block f_bad_bbitmap f_badbblocks f_bad_bmap_csum f_badcluster f_baddir2 f_baddir f_bad_disconnected_inode f_baddotdir f_bad_gdt_csum f_bad_ibitmap f_bad_inode_csum f_badinode f_badjourblks f_badjour_indblks f_bad_local_jnl f_badorphan f_badprimary f_badroot f_badsymlinks f_badtable f_bbfile f_bb_in_bb f_bbinode f_big_sparse f_bitmaps f_boundscheck f_clear_xattr f_cloneblock_alloc_error f_collapse_extent_tree f_compress_extent_tree_level f_convert_bmap_and_extent f_convert_bmap f_corrupt_dirent_tail f_create_symlinks f_deleted_inode_bad_csum f_desc_size_128 f_desc_size_bad f_dir_bad_csum f_dir_bad_mode f_dirlink f_dup2 f_dup3 f_dup4 f_dup_ba f_dup_de2 f_dup_de f_dupdot f_dup f_dupfsblks f_dup_resize f_dupsuper f_ea_bad_csum f_ea_checks f_ea_value_crash f_emptydir f_encrypted_lpf f_end-bitmap f_e ofblocks f_expand f_expandroot_create_lnf f_extent_bad_node f_extent_htree f_extent_int_bad_csum f_extent_int_bad_extent f_extent_int_bad_magic f_extent_interior_start_lblk f_extent_leaf_bad_csum f_extent_leaf_bad_extent f_extent_leaf_bad_magic f_extent_oobounds f_extents2 f_extents f_extent_too_deep f_ext_journal f_extra_journal f_ext_zero_len f_fast_symlink_extents f_file_acl_high f_filetype f_first_meta_bg_too_big f_full_bg f_h_badnode f_h_badroot f_h_normal f_holedir2 f_holedir3 f_holedir4 f_holedir f_h_reindex f_htree_bad_csum f_htree_leaf_csum f_hugedir_blocks f_h_unsigned f_hurd f_idata_and_extents f_illbbitmap f_illibitmap f_illitable f_illitable_flexbg f_imagic f_imagic_fs f_ind_inode_collision f_inlinedata_dirblocks f_inlinedata_repair f_inlinedir_detector f_inode_ea_collision f_invalid_bad_inode f_invalid_extent_symlink f_itable_collision f_jnl_32bit f_jnl_64bit f_jnl_errno f_jnl_etb_alloc_fail f_journal f_lotsbad f_lpf2 f_lpf f_lpffile f_messy_inode f_miss_blk_bmap f_mis s_journal f_misstable f_mke2fs2b f_mmp_garbage f_no_cache_corrupt_inode f_no f_noroot f_nospc_create_lnf f_okgroup f_opt_extent_ext3 f_opt_extent f_orphan_dotdot_ft f_orphan_extents_inode f_orphan f_orphan_indirect_inode f_overfsblks f_preen f_quota f_readonly_fsck f_rebuild_csum_rootdir f_recnect_bad f_reconnect f_rehash_dir f_resize_inode f_salvage_dir f_sb_extra_isize f_selinux f_short_encrypted_dirent f_special_ea f_summary_counts f_super_bad_csum f_toobig_extent_dir f_trunc_dirent_header f_uninit_cat f_uninit_dir f_uninit_ext_past_eof2 f_uninit_ext_past_eof f_uninit_last_uninit f_unsorted_EAs f_unused_itable f_valid_ea_in_inode f_write_ea_no_extra_isize f_write_ea_toobig_extra_isize f_write_ea_toosmall_extra_isize f_yesall f_yes f_yesthenall f_yesthenno f_zeroed_ext_header f_zero_group f_zero_inode_size f_zero_super f_zer
[Touch-packages] [Bug 1694063] [NEW] package gconf2-common 3.2.6-3ubuntu7 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128
Public bug reported: i think this bug came up when i restarted my laptop after i tried to install chrome from the official site and it got stuck saying installing and it never installed ProblemType: Package DistroRelease: Ubuntu 17.04 Package: gconf2-common 3.2.6-3ubuntu7 ProcVersionSignature: Ubuntu 4.10.0-21.23-generic 4.10.11 Uname: Linux 4.10.0-21-generic x86_64 ApportVersion: 2.20.4-0ubuntu4.1 Architecture: amd64 Date: Sat May 27 21:56:41 2017 ErrorMessage: subprocess installed post-installation script returned error exit status 128 InstallationDate: Installed on 2017-05-27 (0 days ago) InstallationMedia: Lubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) PackageArchitecture: all RelatedPackageVersions: dpkg 1.18.10ubuntu2 apt 1.4 SourcePackage: gconf Title: package gconf2-common 3.2.6-3ubuntu7 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gconf (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package need-duplicate-check zesty -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gconf in Ubuntu. https://bugs.launchpad.net/bugs/1694063 Title: package gconf2-common 3.2.6-3ubuntu7 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128 Status in gconf package in Ubuntu: New Bug description: i think this bug came up when i restarted my laptop after i tried to install chrome from the official site and it got stuck saying installing and it never installed ProblemType: Package DistroRelease: Ubuntu 17.04 Package: gconf2-common 3.2.6-3ubuntu7 ProcVersionSignature: Ubuntu 4.10.0-21.23-generic 4.10.11 Uname: Linux 4.10.0-21-generic x86_64 ApportVersion: 2.20.4-0ubuntu4.1 Architecture: amd64 Date: Sat May 27 21:56:41 2017 ErrorMessage: subprocess installed post-installation script returned error exit status 128 InstallationDate: Installed on 2017-05-27 (0 days ago) InstallationMedia: Lubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) PackageArchitecture: all RelatedPackageVersions: dpkg 1.18.10ubuntu2 apt 1.4 SourcePackage: gconf Title: package gconf2-common 3.2.6-3ubuntu7 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gconf/+bug/1694063/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1682639 Title: resize2fs hang bug still lingering Status in e2fsprogs package in Ubuntu: New Bug description: This bug is flagged numerous times in 1321958 and repeatedly marked cleared. It's still there though. root@uneca-fs:~# cat /etc/issue | grep -i ubuntu && uname -a && aptitude show e2fsprogs | grep -i version Ubuntu 14.04.5 LTS \n \l Linux uneca-fs 3.19.0-65-generic #73~14.04.1-Ubuntu SMP Wed Jun 29 21:05:22 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Version: 1.42.9-3ubuntu1.3 root@uneca-fs:~# lvdisplay /dev/vg_data/lv_wodroot | grep "LV Size" && df -h /exports/wodroot LV Size50.82 TiB Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_data-lv_wodroot 45T 42T 605G 99% /exports/wodroot running "resize2fs -p /dev/mapper/gv_data-lv_wodroot" will cause it to hang in ~100% cpu. An strace shows that it opens up the device, sets the flags and then hangs on a read. Unfortunately I can't find older e2fsprogs packages to install :/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1682639/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in 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" Status in e2fsprogs package in Ubuntu: Fix Released Bug description: I installed Kubuntu 13.04 x64 on a new SSD, but pointed its ext4 journal to another partition on a spinning disk (same block size, of course). At every boot, e2fsck prompts me to check / for errors but it dies because: fsck.ext4: Device or resource busy while checking ext3 journal for foobar foobar: ** WARNING: Filesystem still has errors ** [Please, also note: If I press I to ignore and continue the boot process, it complains about /tmp not being ready yet (I used bind in fstab because it's on another partition). So I press S to skip the mount and access lightdm which can't login yet because /tmp is unmounted (it would just restart itself). Accessing the tty with CTRL+ALT+F1 works and I can "sudo mountall" to correctly mount /tmp, then login and use the system as usual.] Using a LiveCD to fsck the / partition shows that the filesystem is clean. I built e2fsck from source and applied this patch http://www.spinics.net/lists/linux-ext4/msg38096.html before compiling and it solved the problem. Now the boot-up process is smooth and it also carried away the /tmp not ready issue. Please, apply this patch to e2fsprogs. If you need more info, please just tell me. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1186331/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1645232 Title: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL) Status in e2fsprogs package in Ubuntu: Fix Released Bug description: The original installed e2fsprogs did not support mke2fs -d /directory " option . So , git cloned from e2fsprogs packages from repository and installed it and followed below steps to reproduce this : 1. set the ACL rules as below to one of the binary : $ setfacl -m u:vipatil:r-- rootfs/usr/bin/helloworld $ getfacl rootfs/usr/bin/helloworld # file: rootfs/usr/bin/helloworld # owner: shkumar # group: hardev user::rwx user:vipatil:r-- group::--- mask::r-- other::--- 2. $ dd if=/dev/zero of=test.ext4 bs=1M count=60 3. $ mke2fs -t ext4 test.ext4 -d rootfs/ mke2fs 1.43.3 (04-Sep-2016) Discarding device blocks: done Creating filesystem with 61440 1k blocks and 15360 inodes Filesystem UUID: 495713b3-5f1f-427a-8359-a736dfb2ece9 Superblock backups stored on blocks: 8193, 24577, 40961, 57345 Allocating group tables: done Writing inode tables: done Creating journal (4096 blocks): done Copying files into the device: done Writing superblocks and filesystem accounting information: done 4. sudo mount -o loop,acl,user_xattr,rw,sync test.ext4 mountpoint 5.@/mountpoint$ getfacl usr/bin/helloworld getfacl: usr/bin/helloworld: Invalid argument To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1645232/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1645232 Title: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL) Status in e2fsprogs package in Ubuntu: Confirmed Bug description: The original installed e2fsprogs did not support mke2fs -d /directory " option . So , git cloned from e2fsprogs packages from repository and installed it and followed below steps to reproduce this : 1. set the ACL rules as below to one of the binary : $ setfacl -m u:vipatil:r-- rootfs/usr/bin/helloworld $ getfacl rootfs/usr/bin/helloworld # file: rootfs/usr/bin/helloworld # owner: shkumar # group: hardev user::rwx user:vipatil:r-- group::--- mask::r-- other::--- 2. $ dd if=/dev/zero of=test.ext4 bs=1M count=60 3. $ mke2fs -t ext4 test.ext4 -d rootfs/ mke2fs 1.43.3 (04-Sep-2016) Discarding device blocks: done Creating filesystem with 61440 1k blocks and 15360 inodes Filesystem UUID: 495713b3-5f1f-427a-8359-a736dfb2ece9 Superblock backups stored on blocks: 8193, 24577, 40961, 57345 Allocating group tables: done Writing inode tables: done Creating journal (4096 blocks): done Copying files into the device: done Writing superblocks and filesystem accounting information: done 4. sudo mount -o loop,acl,user_xattr,rw,sync test.ext4 mountpoint 5.@/mountpoint$ getfacl usr/bin/helloworld getfacl: usr/bin/helloworld: Invalid argument To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1645232/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1645232 Title: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL) Status in e2fsprogs package in Ubuntu: Confirmed Bug description: The original installed e2fsprogs did not support mke2fs -d /directory " option . So , git cloned from e2fsprogs packages from repository and installed it and followed below steps to reproduce this : 1. set the ACL rules as below to one of the binary : $ setfacl -m u:vipatil:r-- rootfs/usr/bin/helloworld $ getfacl rootfs/usr/bin/helloworld # file: rootfs/usr/bin/helloworld # owner: shkumar # group: hardev user::rwx user:vipatil:r-- group::--- mask::r-- other::--- 2. $ dd if=/dev/zero of=test.ext4 bs=1M count=60 3. $ mke2fs -t ext4 test.ext4 -d rootfs/ mke2fs 1.43.3 (04-Sep-2016) Discarding device blocks: done Creating filesystem with 61440 1k blocks and 15360 inodes Filesystem UUID: 495713b3-5f1f-427a-8359-a736dfb2ece9 Superblock backups stored on blocks: 8193, 24577, 40961, 57345 Allocating group tables: done Writing inode tables: done Creating journal (4096 blocks): done Copying files into the device: done Writing superblocks and filesystem accounting information: done 4. sudo mount -o loop,acl,user_xattr,rw,sync test.ext4 mountpoint 5.@/mountpoint$ getfacl usr/bin/helloworld getfacl: usr/bin/helloworld: Invalid argument To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1645232/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1645232
Title:
e2fsprogs - could not preserve ACL permissions : The getxattr()
returns with (EINVAL)
Status in e2fsprogs package in Ubuntu:
Confirmed
Bug description:
The original installed e2fsprogs did not support mke2fs -d /directory
" option . So , git cloned from e2fsprogs packages from repository
and installed it and followed below steps to reproduce this :
1. set the ACL rules as below to one of the binary :
$ setfacl -m u:vipatil:r-- rootfs/usr/bin/helloworld
$ getfacl rootfs/usr/bin/helloworld
# file: rootfs/usr/bin/helloworld
# owner: shkumar
# group: hardev
user::rwx
user:vipatil:r--
group::---
mask::r--
other::---
2. $ dd if=/dev/zero of=test.ext4 bs=1M count=60
3. $ mke2fs -t ext4 test.ext4 -d rootfs/
mke2fs 1.43.3 (04-Sep-2016)
Discarding device blocks: done
Creating filesystem with 61440 1k blocks and 15360 inodes
Filesystem UUID: 495713b3-5f1f-427a-8359-a736dfb2ece9
Superblock backups stored on blocks:
8193, 24577, 40961, 57345
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Copying files into the device: done
Writing superblocks and filesystem accounting information: done
4. sudo mount -o loop,acl,user_xattr,rw,sync test.ext4 mountpoint
5.@/mountpoint$ getfacl usr/bin/helloworld
getfacl: usr/bin/helloworld: Invalid argument
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1645232/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1637779 Title: ext4 filesystem fails randomly with checksum error Status in e2fsprogs package in Ubuntu: New Bug description: Description: Ubuntu 16.10 Release: 16.10 package version: linux-image-4.8.0-26-generic: Installed: 4.8.0-26.28 Candidate: 4.8.0-26.28 Version table: *** 4.8.0-26.28 500 500 http://sk.archive.ubuntu.com/ubuntu yakkety-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu yakkety-security/main amd64 Packages 100 /var/lib/dpkg/status fresh installation of Ubunut 16.10, all updates included While I am working with system after few minutes root filesystem /dev/sdb5 switches into readonly mode in dmesg is this: [ 304.921552] EXT4-fs error (device sdb5): ext4_iget:4476: inode #24577: comm updatedb.mlocat: checksum invalid [ 304.925565] Aborting journal on device sdb5-8. [ 304.926507] EXT4-fs (sdb5): Remounting filesystem read-only [ 304.927416] EXT4-fs error (device sdb5): ext4_journal_check_start:56: Detected aborted journal [ 304.943408] EXT4-fs error (device sda1): ext4_iget:4476: inode #12: comm updatedb.mlocat: checksum invalid when it happens I must do fsck f /dev/sdb1 once, second time it says everything is fine. after reboot when I start dto do something it soon happens again To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1637779/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in 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 Status in e2fsprogs package in Ubuntu: Invalid Bug description: Ubuntu 16.10 installer sets metadata_csum option on ext4 partition which is incompatible with other LTS Ubuntu versions (12.04 LTS, 14.04 LTS, 16.04 LTS). Steps to reproduce: 1. Download Ubuntu 16.10 installation media. 2. Install Ubuntu. 3. Try to do fsck -fy /dev/sdX1 from other supported Ubuntu distro. Expected results: User can check and fix errors on ext4 filesystem, created on Ubuntu 16.10. Actual results: User can not check and fix errors on ext4 filesystem because of lack of 'metadata_csum' option in previous LTS Ubuntu versions. The only one working solution was to scan from 16.10 live install media. Note: it is known, that Dan Watkins disabled metadata_csum when creating ext4 filesystems ( see http://bazaar.launchpad.net/~daniel-thewatkins/maas-images/fix-yakkety-builds/revision/305 ). It is good solution. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: e2fsprogs 1.43.1-1 ProcVersionSignature: Ubuntu 4.4.0-30.49-generic 4.4.13 Uname: Linux 4.4.0-30-generic i686 ApportVersion: 2.20.2-0ubuntu1 Architecture: i386 CurrentDesktop: Unity Date: Mon Jul 11 23:42:49 2016 SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1601997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 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 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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1627608 Title: resize2fs crashed with SIGSEGV in ext2fs_extent_translate() Status in e2fsprogs package in Ubuntu: New Bug description: I was trying to install yakkety from a bootable USB with latest the image, but when trying to resize partition an error window appeared. All the information about it is here> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1627603 ProblemType: Crash DistroRelease: Ubuntu 16.10 Package: e2fsprogs 1.43.1-1 ProcVersionSignature: Ubuntu 4.8.0-14.15-generic 4.8.0-rc7 Uname: Linux 4.8.0-14-generic x86_64 ApportVersion: 2.20.3-0ubuntu7 Architecture: amd64 CasperVersion: 1.378 Date: Mon Sep 26 06:41:43 2016 ExecutablePath: /sbin/resize2fs LiveMediaBuild: Ubuntu 16.10 "Yakkety Yak" - Alpha amd64 (20160922) ProcCmdline: resize2fs /dev/sda5 139789789K SegvAnalysis: Segfault happened at: 0x5635641f751c:cmpq $0x0,0x20(%rdi) PC (0x5635641f751c) ok source "$0x0" ok destination "0x20(%rdi)" (0x0020) not located in a known VMA region (needed writable region)! SegvReason: writing NULL VMA Signal: 11 SourcePackage: e2fsprogs StacktraceTop: ?? () ?? () ?? () __libc_start_main (main=0x5635641f6080, argc=3, argv=0x7ffef0c06668, init=, fini=, rtld_fini=, stack_end=0x7ffef0c06658) at ../csu/libc-start.c:291 ?? () Title: resize2fs crashed with SIGSEGV in __libc_start_main() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1627608/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1619918 Title: lsattr 32bit does not work on 64bit kernel (Inappropriate ioctl error) Status in e2fsprogs package in Ubuntu: Invalid Status in linux package in Ubuntu: Incomplete Bug description: I run an amd64 kernel on trusty. The e2fsprogs package was still the 32 bit i386 variety. This lead to the following situation (for essentially all files on a btrfs partition). $ lsattr /lib/modules/3.13.0-95-generic/kernel/drivers/staging/lustre/lustre/ptlrpc/ptlrpc.ko lsattr: Inappropriate ioctl for device While reading flags on /lib/modules/3.13.0-95-generic/kernel/drivers/staging/lustre/lustre/ptlrpc/ptlrpc.ko The problem was resolved by installing e2fsprogs:amd64. https://patchwork.kernel.org/patch/7517361/ might be related. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1619918/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1619918 Title: lsattr 32bit does not work on 64bit kernel (Inappropriate ioctl error) Status in e2fsprogs package in Ubuntu: Invalid Status in linux package in Ubuntu: Incomplete Bug description: I run an amd64 kernel on trusty. The e2fsprogs package was still the 32 bit i386 variety. This lead to the following situation (for essentially all files on a btrfs partition). $ lsattr /lib/modules/3.13.0-95-generic/kernel/drivers/staging/lustre/lustre/ptlrpc/ptlrpc.ko lsattr: Inappropriate ioctl for device While reading flags on /lib/modules/3.13.0-95-generic/kernel/drivers/staging/lustre/lustre/ptlrpc/ptlrpc.ko The problem was resolved by installing e2fsprogs:amd64. https://patchwork.kernel.org/patch/7517361/ might be related. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1619918/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1619918 Title: lsattr 32bit does not work on 64bit kernel (Inappropriate ioctl error) Status in e2fsprogs package in Ubuntu: Invalid Status in linux package in Ubuntu: New Bug description: I run an amd64 kernel on trusty. The e2fsprogs package was still the 32 bit i386 variety. This lead to the following situation (for essentially all files on a btrfs partition). $ lsattr /lib/modules/3.13.0-95-generic/kernel/drivers/staging/lustre/lustre/ptlrpc/ptlrpc.ko lsattr: Inappropriate ioctl for device While reading flags on /lib/modules/3.13.0-95-generic/kernel/drivers/staging/lustre/lustre/ptlrpc/ptlrpc.ko The problem was resolved by installing e2fsprogs:amd64. https://patchwork.kernel.org/patch/7517361/ might be related. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1619918/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1598136
Title:
Fails to produce a loop-mountable FS on powerpc/armhf
Status in cloud-images:
New
Status in e2fsprogs package in Ubuntu:
New
Bug description:
In yakkety cloud image builds for each of powerpc and armhf (but not
amd64, i386, ppc64el, arm64 or s390x) we see the following failure:
[2016-07-01 09:51:08] lb_binary_chroot
P: Begin copying chroot...
[2016-07-01 09:51:08] lb_binary_rootfs
P: Begin building root filesystem image...
0+0 records in
0+0 records out
0 bytes copied, 3.7116e-05 s, 0.0 kB/s
mke2fs 1.43.1 (08-Jun-2016)
ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing
mtab file while determining whether binary/boot/filesystem.ext4 is mounted.
Suggestion: Use Linux kernel >= 3.18 for improved stability of the metadata
and journal checksum features.
Discarding device blocks: 4096/343040
done
Creating filesystem with 343040 4k blocks and 171600 inodes
Filesystem UUID: 43ff7fc9-12bb-4151-8549-77c8e1e35e2c
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: 0/11 done
Writing inode tables: 0/11 done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: 0/11
done
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
This is caused by this code in live-build's lb_binary_rootfs script:
dd if=/dev/zero of=binary/${INITFS}/filesystem.${LB_CHROOT_FILESYSTEM}
bs=1024k count=0 seek=${REAL_DIM}
mkfs.${LB_CHROOT_FILESYSTEM} -F -b ${LB_EXT_BLOCKSIZE:-1024} -i 8192 -m 0 -L
${LB_HDD_LABEL} ${LB_EXT_RESIZEBLOCKS:+-E resize=${LB_EXT_RESIZEBLOCKS}}
binary/${INITFS}/filesystem.${LB_CHROOT_FILESYSTEM}
mkdir -p filesystem.tmp
${LB_ROOT_COMMAND} mount -o loop
binary/${INITFS}/filesystem.${LB_CHROOT_FILESYSTEM} filesystem.tmp
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1598136/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1592862
Title:
Merge e2fsprogs from Debian 1.43.1-1
Status in e2fsprogs package in Ubuntu:
New
Bug description:
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1090053 Title: e4defrag -c /mountpoint does not provide expected output Status in e2fsprogs package in Ubuntu: Invalid Bug description: According to the man page this is the expected output below. OPTIONS -c Get a current fragmentation count and an ideal fragmentation count, and calculate fragmentation score based on them. By see‐ ing this score, we can determine whether we should execute e4defrag to target. When used with -v option, the current frag‐ mentation count and the ideal fragmentation count are printed for each file. Also this option outputs the average data size in one extent. If you see it, you'll find the file has ideal extents or not. Note that the maximum extent size is 131072KB in ext4 filesystem (if block size is 4KB). If this option is specified, target is never defragmented. I am attaching a screenshot of my output which is not what I expected. This may not be a bug but it is not very informational. ProblemType: Bug DistroRelease: Ubuntu 12.10 Package: e2fsprogs 1.42.5-1ubuntu2 ProcVersionSignature: Ubuntu 3.5.0-19.30-generic 3.5.7 Uname: Linux 3.5.0-19-generic i686 ApportVersion: 2.6.1-0ubuntu6 Architecture: i386 Date: Thu Dec 13 12:09:04 2012 InstallationDate: Installed on 2012-12-12 (1 days ago) InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release i386 (20121017.2) MarkForUpload: True ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1090053/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/463015 Title: Both fat and ext[234] boot sectors present at once cause confusion Status in e2fsprogs package in Ubuntu: Invalid Status in grub2 package in Ubuntu: New Bug description: Binary package hint: grub2 grub-probe incorrectly identifies my ext3 partition as containing a fat file system. This means it can't boot without manual tweaking. I suspect the problem is that my partition contains stale fat signatures... this is probably a common problem, as mke2fs often doesn't wipe old signatures. I attached first 8k of my file system for testing purposes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/463015/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in 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" Status in e2fsprogs package in Ubuntu: Fix Committed Bug description: I installed Kubuntu 13.04 x64 on a new SSD, but pointed its ext4 journal to another partition on a spinning disk (same block size, of course). At every boot, e2fsck prompts me to check / for errors but it dies because: fsck.ext4: Device or resource busy while checking ext3 journal for foobar foobar: ** WARNING: Filesystem still has errors ** [Please, also note: If I press I to ignore and continue the boot process, it complains about /tmp not being ready yet (I used bind in fstab because it's on another partition). So I press S to skip the mount and access lightdm which can't login yet because /tmp is unmounted (it would just restart itself). Accessing the tty with CTRL+ALT+F1 works and I can "sudo mountall" to correctly mount /tmp, then login and use the system as usual.] Using a LiveCD to fsck the / partition shows that the filesystem is clean. I built e2fsck from source and applied this patch http://www.spinics.net/lists/linux-ext4/msg38096.html before compiling and it solved the problem. Now the boot-up process is smooth and it also carried away the /tmp not ready issue. Please, apply this patch to e2fsprogs. If you need more info, please just tell me. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1186331/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1567567 Title: fsck taking way too long 20 hours & still going Status in e2fsprogs package in Ubuntu: New Bug description: Hi, I have a 24T file system ext4, ran fsck. It is running fsck for 20 hours so far and looks like it will keep on going. The system is not a slow machine at all, relatively new server. I checked top and saw that CPU usage was not high. I seen similar problem like this before but CPU usage was high in the past. I'm using ubuntu-14.04.4 lts. and running this on the 2nd extra copy of the superblock. I didn't want to do it with the main copy. I ran e2image -r -s on the main superblock but it wouldn't create an image file. I doubt that anything useful is happening and I don't know how to debug this further so please advise if I should keep it going else I'm likely to shut it down soon To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1567567/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1345682 Title: fsck on 24TB ext4 keeps crashing Status in e2fsprogs package in Ubuntu: Expired Bug description: date; fsck -vy /dev/mapper/raid61p1 ;date Thu Jul 17 11:54:21 PDT 2014 fsck from util-linux 2.20.1 I can't get my ext4 24TB to fsck clean. there came a whole bunch of file stat problems after a clean reboot. I tried 3 times so far, and each does something like segfault. I looked twice, and the errors were different, but was able to capture one output. The system has 6GB ram, and it used up all the memory. ended up adding 25GB of swap as fsck seems to use up a huge amount of memory. After a long while, usually after mem use is >90%, I come back to see the fsck has crashed and file system is still not clean. The reboot was clean and should not have caused any corruption. the system is using ubuntu-14.04 # uname -a Linux gigabyte133 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux root@gigabyte133:~# I had to use the 64 bit version since the 32 bit version I couldn't get more than 15TB file system built and read that there were compatibility problems between 32bit version with the -O 64bit and the 64 bit version so just built the whole thing in 64 bit ubuntu.. e2fsck 1.42.9 (4-Feb-2014) /dev/mapper/raid61p1 contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Inode 203167820 has compression flag set on filesystem without compression support. Clear? yes Signal (11) SIGSEGV si_code=SI_KERNEL fault addr=(nil) fsck.ext4[0x4266f1] /lib/x86_64-linux-gnu/libc.so.6(+0x36ff0)[0x7fd38d087ff0] /lib/x86_64-linux-gnu/libext2fs.so.2(ext2fs_rb_n
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1345682 Title: fsck on 24TB ext4 keeps crashing Status in e2fsprogs package in Ubuntu: Incomplete Bug description: date; fsck -vy /dev/mapper/raid61p1 ;date Thu Jul 17 11:54:21 PDT 2014 fsck from util-linux 2.20.1 I can't get my ext4 24TB to fsck clean. there came a whole bunch of file stat problems after a clean reboot. I tried 3 times so far, and each does something like segfault. I looked twice, and the errors were different, but was able to capture one output. The system has 6GB ram, and it used up all the memory. ended up adding 25GB of swap as fsck seems to use up a huge amount of memory. After a long while, usually after mem use is >90%, I come back to see the fsck has crashed and file system is still not clean. The reboot was clean and should not have caused any corruption. the system is using ubuntu-14.04 # uname -a Linux gigabyte133 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux root@gigabyte133:~# I had to use the 64 bit version since the 32 bit version I couldn't get more than 15TB file system built and read that there were compatibility problems between 32bit version with the -O 64bit and the 64 bit version so just built the whole thing in 64 bit ubuntu.. e2fsck 1.42.9 (4-Feb-2014) /dev/mapper/raid61p1 contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Inode 203167820 has compression flag set on filesystem without compression support. Clear? yes Signal (11) SIGSEGV si_code=SI_KERNEL fault addr=(nil) fsck.ext4[0x4266f1] /lib/x86_64-linux-gnu/libc.so.6(+0x36ff0)[0x7fd38d087ff0] /lib/x86_64-linux-gnu/libext2fs.so.2(ext2fs_rb_next+0x23)[0x7fd38dc7bc43] /lib/x86_64-linux-gnu/libext2fs.so.2(+0x10670)[0x7fd38dc5e670] fsck.ext4[0x4100f6]# lsb_release -va No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 14.04 LTS Release:14.04 Codename: trusty /lib/x86_64-linux-gnu/libext2fs.so.2(+0x11c3d)[0x7fd38dc5fc3d] /lib/x86_64-linux-gnu/libext2fs.so.2(+0x11f78)[0x7fd38dc5ff78] /lib/x86_64-linux-gnu/libext2fs.so.2(ext2fs_block_iterate3+0xa13)[0x7fd38dc60b13] fsck.ext4[0x4115c4] fsck.ext4[0x412699] fsck.ext4[0x412761] /lib/x86_64-linux-gnu/libext2fs.so.2(ext2fs_get_next_inode_full+0x59)[0x7fd38dc6c9a9] fsck.ext4(e2fsck_pass1+0x8d8)[0x4130c8] fsck.ext4(e2fsck_run+0x52)[0x40deb2] fsck.ext4(main+0xd27)[0x40a0e7] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fd38d072ec5] fsck.ext4[0x40bde6] Thu Jul 17 15:55:01 PDT 2014 # lsb_release -va No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 14.04 LTS Release:14.04 Codename: trusty ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: util-linux 2.20.1-5.1ubuntu20.1 ProcVersionSignature: Ubuntu 3.13.0-32.57-generic 3.13.11.4 Uname: Linux 3.13.0-32-generic x86_64 NonfreeKernelModules: zfs zunicode zavl zcommon znvpair ApportVersion: 2.14.1-0ubuntu
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1345682 Title: fsck on 24TB ext4 keeps crashing Status in e2fsprogs package in Ubuntu: Incomplete Bug description: date; fsck -vy /dev/mapper/raid61p1 ;date Thu Jul 17 11:54:21 PDT 2014 fsck from util-linux 2.20.1 I can't get my ext4 24TB to fsck clean. there came a whole bunch of file stat problems after a clean reboot. I tried 3 times so far, and each does something like segfault. I looked twice, and the errors were different, but was able to capture one output. The system has 6GB ram, and it used up all the memory. ended up adding 25GB of swap as fsck seems to use up a huge amount of memory. After a long while, usually after mem use is >90%, I come back to see the fsck has crashed and file system is still not clean. The reboot was clean and should not have caused any corruption. the system is using ubuntu-14.04 # uname -a Linux gigabyte133 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux root@gigabyte133:~# I had to use the 64 bit version since the 32 bit version I couldn't get more than 15TB file system built and read that there were compatibility problems between 32bit version with the -O 64bit and the 64 bit version so just built the whole thing in 64 bit ubuntu.. e2fsck 1.42.9 (4-Feb-2014) /dev/mapper/raid61p1 contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Inode 203167820 has compression flag set on filesystem without compression support. Clear? yes Signal (11) SIGSEGV si_code=SI_KERNEL fault addr=(nil) fsck.ext4[0x4266f1] /lib/x86_64-linux-gnu/libc.so.6(+0x36ff0)[0x7fd38d087ff0] /lib/x86_64-linux-gnu/libext2fs.so.2(ext2fs_rb_next+0x23)[0x7fd38dc7bc43] /lib/x86_64-linux-gnu/libext2fs.so.2(+0x10670)[0x7fd38dc5e670] fsck.ext4[0x4100f6]# lsb_release -va No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 14.04 LTS Release:14.04 Codename: trusty /lib/x86_64-linux-gnu/libext2fs.so.2(+0x11c3d)[0x7fd38dc5fc3d] /lib/x86_64-linux-gnu/libext2fs.so.2(+0x11f78)[0x7fd38dc5ff78] /lib/x86_64-linux-gnu/libext2fs.so.2(ext2fs_block_iterate3+0xa13)[0x7fd38dc60b13] fsck.ext4[0x4115c4] fsck.ext4[0x412699] fsck.ext4[0x412761] /lib/x86_64-linux-gnu/libext2fs.so.2(ext2fs_get_next_inode_full+0x59)[0x7fd38dc6c9a9] fsck.ext4(e2fsck_pass1+0x8d8)[0x4130c8] fsck.ext4(e2fsck_run+0x52)[0x40deb2] fsck.ext4(main+0xd27)[0x40a0e7] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fd38d072ec5] fsck.ext4[0x40bde6] Thu Jul 17 15:55:01 PDT 2014 # lsb_release -va No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 14.04 LTS Release:14.04 Codename: trusty ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: util-linux 2.20.1-5.1ubuntu20.1 ProcVersionSignature: Ubuntu 3.13.0-32.57-generic 3.13.11.4 Uname: Linux 3.13.0-32-generic x86_64 NonfreeKernelModules: zfs zunicode zavl zcommon znvpair ApportVersion: 2.14.1-0ubuntu3.2 Architecture: amd64 Date: Sat Jul 19 18:49:32 2014 InstallationDate: Installed on 2014-07-11 (8 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: util-linux UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1345682/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1497032 Title: dumpe2fs crashed with SIGSEGV in strlen() Status in e2fsprogs package in Ubuntu: New Bug description: atualização Kubuntu 15.10 beta 1 ProblemType: Crash DistroRelease: Ubuntu 15.10 Package: e2fsprogs 1.42.12-1ubuntu2 Uname: Linux 4.2.0-040200-generic x86_64 ApportVersion: 2.18.1-0ubuntu1 Architecture: amd64 Date: Thu Sep 17 01:24:22 2015 ExecutablePath: /sbin/dumpe2fs InstallationDate: Installed on 2015-09-01 (16 days ago) InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1) ProcCmdline: dumpe2fs SegvAnalysis: Segfault happened at: 0x3ac028b6fa : movdqu (%rax),%xmm12 PC (0x3ac028b6fa) ok source "(%rax)" (0x) not located in a known VMA region (needed readable region)! destination "%xmm12" ok SegvReason: reading NULL VMA Signal: 11 SourcePackage: e2fsprogs StacktraceTop: strlen () at ../sysdeps/x86_64/strlen.S:106 ext2fs_open2 () from /lib/x86_64-linux-gnu/libext2fs.so.2 ext2fs_open () from /lib/x86_64-linux-gnu/libext2fs.so.2 ?? () __libc_start_main (main=0x401a60, argc=1, argv=0x7ffd74296758, init=, fini=, rtld_fini=, stack_end=0x7ffd74296748) at libc-start.c:289 Title: dumpe2fs crashed with SIGSEGV in strlen() UpgradeStatus: Upgraded to wily on 2015-09-12 (5 days ago) UserGroups: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1497032/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/796717 Title: e2fsck not fixing some fs errors Status in e2fsprogs package in Ubuntu: Invalid Bug description: Binary package hint: e2fsprogs I've got a software RAID10 in Ubuntu 10.04 that started giving me fs errors Saturday evening. After running e2fsck multiple times and fixing many errors, it seems there are three left that it is not fixing even after multiple runs. Description:Ubuntu 10.04.2 LTS Release:10.04 e2fsprogs: Installed: 1.41.11-1ubuntu2.1 Candidate: 1.41.11-1ubuntu2.1 Version table: *** 1.41.11-1ubuntu2.1 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages 100 /var/lib/dpkg/status 1.41.11-1ubuntu2 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid/main Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/796717/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1444442] Re: External screen turns grey or green after some random time.
Turns out it was a faulty screen, closing this. ** Changed in: xorg (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/142 Title: External screen turns grey or green after some random time. Status in xorg package in Ubuntu: Invalid Bug description: As in the title the external screen attached to my laptop through Displayport suddenly turns grey and I have to unplug/replug it in order to get the environment to appear again. This bug started appearing after installing the latest updates (2015-04-14) that included linux-headers-3.13.0-49-generic:amd64. I have in the past installed the Intel Linux Graphics drivers which apparently are now causing some problems with 14.04 so the problem could also be caused by that. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: xorg 1:7.7+1ubuntu8.1 ProcVersionSignature: Ubuntu 3.13.0-49.83-generic 3.13.11-ckt17 Uname: Linux 3.13.0-49-generic x86_64 .tmp.unity.support.test.0: ApportVersion: 2.14.1-0ubuntu3.8 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true CurrentDesktop: Unity Date: Wed Apr 15 14:17:51 2015 DistUpgraded: Fresh install DistroCodename: trusty DistroVariant: ubuntu EcryptfsInUse: Yes ExtraDebuggingInterest: Yes GpuHangFrequency: Several times a day GpuHangReproducibility: Seems to happen randomly GpuHangStarted: Today GraphicsCard: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:2214] InstallationDate: Installed on 2014-08-19 (238 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) MachineType: LENOVO 20AL00BYMS ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-49-generic root=UUID=58f7be01-3efd-41f5-adbb-d0a430268da1 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/09/2015 dmi.bios.vendor: LENOVO dmi.bios.version: GIET79WW (2.29 ) dmi.board.asset.tag: Not Available dmi.board.name: 20AL00BYMS dmi.board.vendor: LENOVO dmi.board.version: SDK0E50510 PRO dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvrGIET79WW(2.29):bd01/09/2015:svnLENOVO:pn20AL00BYMS:pvrThinkPadX240:rvnLENOVO:rn20AL00BYMS:rvrSDK0E50510PRO:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 20AL00BYMS dmi.product.version: ThinkPad X240 dmi.sys.vendor: LENOVO version.compiz: compiz 1:0.9.11.3+14.04.20150122-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.56-1 version.libgl1-mesa-dri: libgl1-mesa-dri 10.3.0-0ubuntu2intel1 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 10.3.0-0ubuntu2intel1 version.xserver-xorg-core: xserver-xorg-core 2:1.15.1-0ubuntu2.7 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.8.2-1ubuntu2 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.3.0-1ubuntu3.1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.911-0intel1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.10-1ubuntu2 xserver.bootTime: Wed Apr 15 10:59:44 2015 xserver.configfile: default xserver.errors: xserver.logfile: /var/log/Xorg.0.log xserver.outputs: product id 41106 vendor DEL xserver.version: 2:1.15.1-0ubuntu2.7 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/142/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1444442] Re: External screen turns grey or green after some random time.
Here's something that popped up in my system log, don't know if it's related: Apr 15 16:02:45 hidden-username kernel: [18175.627427] [ cut here ] Apr 15 16:02:45 hidden-username kernel: [18175.627468] WARNING: CPU: 3 PID: 76 at /var/lib/dkms/i915-3.16-3.13/1/build/drivers/gpu/drm/i915/intel_dp.c:3124 intel_dp_link_down+0x1a3/0x210 [i915]() Apr 15 16:02:45 hidden-username kernel: [18175.627470] Modules linked in: xt_addrtype xt_conntrack ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables x_tables bridge stp llc aufs ctr ccm dm_crypt hid_generic arc4 rfcomm bnep intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel dm_multipath scsi_dh kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel uvcvideo videobuf2_vmalloc videobuf2_memops aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd cdc_mbim cdc_wdm videobuf2_core binfmt_misc videodev usbhid iwlmvm cdc_acm cdc_ncm usbnet mac80211 mii hid snd_seq_midi joydev btusb snd_seq_midi_event thinkpad_acpi serio_raw nvram snd_rawmidi rtsx_pci_ms snd_hda_codec_realtek bluetooth snd_hda_codec_hdmi memstick iwlwifi cfg80211 lpc_ich snd_hda_intel snd_hda_codec shpchp mei_me snd_hwdep mei snd_pcm snd_seq snd_seq_device snd_page_alloc snd_timer snd soundcore parport_pc intel_smartconnect mac_hi d ppdev lp parport rtsx_pci_sdmmc e1000e psmouse ptp rtsx_pci ahci i915(OX) i2c_algo_bit pps_core libahci drm_kms_helper(OX) drm(OX) wmi video(OX) Apr 15 16:02:45 hidden-username kernel: [18175.627530] CPU: 3 PID: 76 Comm: kworker/3:1 Tainted: GW OX 3.13.0-49-generic #83-Ubuntu Apr 15 16:02:45 hidden-username kernel: [18175.627532] Hardware name: LENOVO 20AL00BYMS/20AL00BYMS, BIOS GIET79WW (2.29 ) 01/09/2015 Apr 15 16:02:45 hidden-username kernel: [18175.627547] Workqueue: events i915_hotplug_work_func [i915] Apr 15 16:02:45 hidden-username kernel: [18175.627549] 0009 88020df77c98 81721b36 Apr 15 16:02:45 hidden-username kernel: [18175.627553] 88020df77cd0 810677dd 88020d43 88020d403800 Apr 15 16:02:45 hidden-username kernel: [18175.627556] 8106 0001 880212fd60d8 88020df77ce0 Apr 15 16:02:45 hidden-username kernel: [18175.627559] Call Trace: Apr 15 16:02:45 hidden-username kernel: [18175.627565] [] dump_stack+0x45/0x56 Apr 15 16:02:45 hidden-username kernel: [18175.627569] [] warn_slowpath_common+0x7d/0xa0 Apr 15 16:02:45 hidden-username kernel: [18175.627572] [] warn_slowpath_null+0x1a/0x20 Apr 15 16:02:45 hidden-username kernel: [18175.627590] [] intel_dp_link_down+0x1a3/0x210 [i915] Apr 15 16:02:45 hidden-username kernel: [18175.627606] [] intel_dp_complete_link_train+0x105/0x360 [i915] Apr 15 16:02:45 hidden-username kernel: [18175.627622] [] intel_dp_check_link_status+0xb8/0x1a0 [i915] Apr 15 16:02:45 hidden-username kernel: [18175.627638] [] intel_ddi_hot_plug+0x28/0x30 [i915] Apr 15 16:02:45 hidden-username kernel: [18175.627652] [] i915_hotplug_work_func+0x1ec/0x310 [i915] Apr 15 16:02:45 hidden-username kernel: [18175.627657] [] process_one_work+0x182/0x450 Apr 15 16:02:45 hidden-username kernel: [18175.627660] [] worker_thread+0x121/0x410 Apr 15 16:02:45 hidden-username kernel: [18175.627663] [] ? rescuer_thread+0x430/0x430 Apr 15 16:02:45 hidden-username kernel: [18175.627667] [] kthread+0xd2/0xf0 Apr 15 16:02:45 hidden-username kernel: [18175.627670] [] ? kthread_create_on_node+0x1c0/0x1c0 Apr 15 16:02:45 hidden-username kernel: [18175.627673] [] ret_from_fork+0x7c/0xb0 Apr 15 16:02:45 hidden-username kernel: [18175.627676] [] ? kthread_create_on_node+0x1c0/0x1c0 Apr 15 16:02:45 hidden-username kernel: [18175.627678] ---[ end trace 947ede35b1816ec6 ]--- -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/142 Title: External screen turns grey or green after some random time. Status in xorg package in Ubuntu: New Bug description: As in the title the external screen attached to my laptop through Displayport suddenly turns grey and I have to unplug/replug it in order to get the environment to appear again. This bug started appearing after installing the latest updates (2015-04-14) that included linux-headers-3.13.0-49-generic:amd64. I have in the past installed the Intel Linux Graphics drivers which apparently are now causing some problems with 14.04 so the problem could also be caused by that. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: xorg 1:7.7+1ubuntu8.1 ProcVersionSignature: Ubuntu 3.13.0-49.83-generic 3.13.11-ckt17 Uname: Linux 3.13.0-49-generic x86_64 .tmp.unity.support.test.0: ApportVersion: 2.14.1-0ubuntu3.8 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugin
[Touch-packages] [Bug 1444442] [NEW] External screen turns grey or green after some random time.
Public bug reported: As in the title the external screen attached to my laptop through Displayport suddenly turns grey and I have to unplug/replug it in order to get the environment to appear again. This bug started appearing after installing the latest updates (2015-04-14) that included linux-headers-3.13.0-49-generic:amd64. I have in the past installed the Intel Linux Graphics drivers which apparently are now causing some problems with 14.04 so the problem could also be caused by that. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: xorg 1:7.7+1ubuntu8.1 ProcVersionSignature: Ubuntu 3.13.0-49.83-generic 3.13.11-ckt17 Uname: Linux 3.13.0-49-generic x86_64 .tmp.unity.support.test.0: ApportVersion: 2.14.1-0ubuntu3.8 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true CurrentDesktop: Unity Date: Wed Apr 15 14:17:51 2015 DistUpgraded: Fresh install DistroCodename: trusty DistroVariant: ubuntu EcryptfsInUse: Yes ExtraDebuggingInterest: Yes GpuHangFrequency: Several times a day GpuHangReproducibility: Seems to happen randomly GpuHangStarted: Today GraphicsCard: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:2214] InstallationDate: Installed on 2014-08-19 (238 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) MachineType: LENOVO 20AL00BYMS ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-49-generic root=UUID=58f7be01-3efd-41f5-adbb-d0a430268da1 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/09/2015 dmi.bios.vendor: LENOVO dmi.bios.version: GIET79WW (2.29 ) dmi.board.asset.tag: Not Available dmi.board.name: 20AL00BYMS dmi.board.vendor: LENOVO dmi.board.version: SDK0E50510 PRO dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvrGIET79WW(2.29):bd01/09/2015:svnLENOVO:pn20AL00BYMS:pvrThinkPadX240:rvnLENOVO:rn20AL00BYMS:rvrSDK0E50510PRO:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 20AL00BYMS dmi.product.version: ThinkPad X240 dmi.sys.vendor: LENOVO version.compiz: compiz 1:0.9.11.3+14.04.20150122-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.56-1 version.libgl1-mesa-dri: libgl1-mesa-dri 10.3.0-0ubuntu2intel1 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 10.3.0-0ubuntu2intel1 version.xserver-xorg-core: xserver-xorg-core 2:1.15.1-0ubuntu2.7 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.8.2-1ubuntu2 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.3.0-1ubuntu3.1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.911-0intel1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.10-1ubuntu2 xserver.bootTime: Wed Apr 15 10:59:44 2015 xserver.configfile: default xserver.errors: xserver.logfile: /var/log/Xorg.0.log xserver.outputs: product id 41106 vendor DEL xserver.version: 2:1.15.1-0ubuntu2.7 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug compiz-0.9 freeze third-party-packages trusty ubuntu -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/142 Title: External screen turns grey or green after some random time. Status in xorg package in Ubuntu: New Bug description: As in the title the external screen attached to my laptop through Displayport suddenly turns grey and I have to unplug/replug it in order to get the environment to appear again. This bug started appearing after installing the latest updates (2015-04-14) that included linux-headers-3.13.0-49-generic:amd64. I have in the past installed the Intel Linux Graphics drivers which apparently are now causing some problems with 14.04 so the problem could also be caused by that. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: xorg 1:7.7+1ubuntu8.1 ProcVersionSignature: Ubuntu 3.13.0-49.83-generic 3.13.11-ckt17 Uname: Linux 3.13.0-49-generic x86_64 .tmp.unity.support.test.0: ApportVersion: 2.14.1-0ubuntu3.8 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true CurrentDesktop: Unity Date: Wed Apr 15 14:17:51 2015 DistUpgraded: Fresh install DistroCodename: trusty DistroVariant: ubuntu Ecry
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1229618 Title: Saucy: /forcefsck not being removed after execution / completion of boot system check Status in e2fsprogs package in Ubuntu: Confirmed Bug description: '/forcefsck' not being removed after execution / completion of boot system check. ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: e2fsprogs 1.42.8-1ubuntu1 ProcVersionSignature: Ubuntu 3.11.0-8.15-generic 3.11.1 Uname: Linux 3.11.0-8-generic x86_64 ApportVersion: 2.12.4-0ubuntu1 Architecture: amd64 Date: Tue Sep 24 10:12:13 2013 InstallationDate: Installed on 2013-09-12 (12 days ago) InstallationMedia: Ubuntu-GNOME 13.04 "Raring Ringtail" - Release amd64 (20130424) MarkForUpload: True SourcePackage: e2fsprogs UpgradeStatus: Upgraded to saucy on 2013-09-12 (12 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1229618/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1415077 Title: resize2fs -P minimum size differs greatly between v1.42.10 and v1.42.9 Status in e2fsprogs package in Ubuntu: Invalid Bug description: I have a disk image created as part of lp:maas-images. This process takes a cloud image (http://cloud-images.ubuntu.com) such as http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64.tar.gz . Inside that .tar.gz is a .img file. The .img file is operated on by loop mount, chroot, apt-get install and other changes. Immediately upon download and extraction of a pristine image, resize2fs output on trusty, utopic and vivid differ. A summary of differences: a.) 'resize2fs -P' on trusty (1.42.9) : 230329 utopic (1.42.10): 236103 vivid (1.42.12): 236103 b.) vivid resize2fs requires running 'e2fsck -f' first. I do realize that 'resize2fs -P' reports "Estimated minumum size" and that a difference of ~6k blocks doesn't seem like too big of a deal, but I'm seeing this behavior on a much grander scale after doing some loop mount operations on the disk image as part of the maas-images build process (lp:maas-images). On that derived image, I see 'resize2fs -P' numbers like: trusty: 274500 utopic: 358400 vivid: 358400 The 83900 blocks out of a 358400 seems significant (23% of the fs size), and results in the image appearing full on utopic/vivid, even though a mount and df show only 74% full. See below for more information. ## The original image as downloaded. $ wget http://cloud-images.ubuntu.com/releases/14.04/release-20150123/ubuntu-14.04-server-cloudimg-amd64.tar.gz $ tar -Sxvzf ubuntu-14.04-server-cloudimg-amd64.tar.gz $ md5sum trusty-server-cloudimg-amd64.img 9fd4790c920aaeb0b503ebd2bf7f383c trusty-server-cloudimg-amd64.img ## Trusty $ resize2fs -P trusty-server-cloudimg-amd64.img resize2fs 1.42.9 (4-Feb-2014) Estimated minimum size of the filesystem: 230329 $ dumpe2fs trusty-server-cloudimg-amd64.img | pastebinit dumpe2fs 1.42.9 (4-Feb-2014) http://paste.ubuntu.com/9898743/ ## Utopic $ resize2fs -P trusty-server-cloudimg-amd64.img resize2fs 1.42.10 (18-May-2014) Estimated minimum size of the filesystem: 236103 $ dumpe2fs trusty-server-cloudimg-amd64.img | pastebinit dumpe2fs 1.42.10 (18-May-2014) http://paste.ubuntu.com/9898789/ ## Vivid $ resize2fs -P trusty-server-cloudimg-amd64.img resize2fs 1.42.12 (29-Aug-2014) Please run 'e2fsck -f trusty-server-cloudimg-amd64.img' first. $ cp trusty-server-cloudimg-amd64.img trusty-server-cloudimg-amd64.img.dist $ e2fsck -f trusty-server-cloudimg-amd64.img e2fsck 1.42.12 (29-Aug-2014) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information cloudimg-rootfs: 57885/90112 files (0.0% non-contiguous), 207837/360448 blocks $ resize2fs -P trusty-server-cloudimg-amd64.img resize2fs 1.42.12 (29-Aug-2014) Estimated minimum size of the filesystem: 236103 $ md5sum trusty-server-cloudimg-amd64.img.dist trusty-server-cloudimg-amd64.img 9fd4790c920aaeb0b503ebd2bf7f383c trusty-server-cloudimg-amd64.img.dist c38a3ca8cba7996c85365e122175d013 trusty-server-cloudimg-amd64.img $ dumpe2fs trusty-server-cloudimg-amd64.img | pastebinit dumpe2fs 1.42.12 (29-Aug-2014) http://paste.ubuntu.com/9898831/ $ dumpe2fs trusty-server-cloudimg-amd64.img.dist | pastebinit dumpe2fs 1.42.12 (29-Aug-2014) http://paste.ubuntu.com/9898832/ ## maas images image ## output below is for the maas build process output image ## This one specifically is an arm64 image, and the operations ## done (apt-get update) and such were done with the help chroot via ## qemu-static. ## build the image (works on trusty, fails due to resizing issues on utopic) $ time maas-cloudimg2eph2 -vv --kernel=linux-generic --arch=arm64 \ http://cloud-images.ubuntu.com/daily/server/vivid/20150125/vivid-server-cloudimg-arm64.tar.gz \ /tmp/maas_final/vivid/arm64/20150125/root-image.gz \ --krd-pack=linux-generic,/tmp/maas_final/vivid/arm64/20150125/vivid/generic/boot-kernel,/tmp/maas_final/vivid/arm64/20150125/vivid/generic/boot-initrd 2>&1 | tee out.log $ pastebinit out.log http://paste.ubuntu.com/9899165/ $ zcat /tmp/maas_final/vivid/arm64/20150125/root-image.gz > /tmp/root- image $ ls -l /tmp/root-image -rw-rw-r-- 1 ubuntu ubuntu 1468006400 Jan 27 14:56 /tmp/root-image ## see attached root-image.e2image.xz $ e2image /tmp/root-image /tmp/root-image.e2image e2image 1.42.9 (4-Feb-2014) $ xz /tmp/root-image.e2image
[Touch-packages] [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" 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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1415077 Title: resize2fs -P minimum size differs greatly between v1.42.10 and v1.42.9 Status in e2fsprogs package in Ubuntu: Invalid Bug description: I have a disk image created as part of lp:maas-images. This process takes a cloud image (http://cloud-images.ubuntu.com) such as http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64.tar.gz . Inside that .tar.gz is a .img file. The .img file is operated on by loop mount, chroot, apt-get install and other changes. Immediately upon download and extraction of a pristine image, resize2fs output on trusty, utopic and vivid differ. A summary of differences: a.) 'resize2fs -P' on trusty (1.42.9) : 230329 utopic (1.42.10): 236103 vivid (1.42.12): 236103 b.) vivid resize2fs requires running 'e2fsck -f' first. I do realize that 'resize2fs -P' reports "Estimated minumum size" and that a difference of ~6k blocks doesn't seem like too big of a deal, but I'm seeing this behavior on a much grander scale after doing some loop mount operations on the disk image as part of the maas-images build process (lp:maas-images). On that derived image, I see 'resize2fs -P' numbers like: trusty: 274500 utopic: 358400 vivid: 358400 The 83900 blocks out of a 358400 seems significant (23% of the fs size), and results in the image appearing full on utopic/vivid, even though a mount and df show only 74% full. See below for more information. ## The original image as downloaded. $ wget http://cloud-images.ubuntu.com/releases/14.04/release-20150123/ubuntu-14.04-server-cloudimg-amd64.tar.gz $ tar -Sxvzf ubuntu-14.04-server-cloudimg-amd64.tar.gz $ md5sum trusty-server-cloudimg-amd64.img 9fd4790c920aaeb0b503ebd2bf7f383c trusty-server-cloudimg-amd64.img ## Trusty $ resize2fs -P trusty-server-cloudimg-amd64.img resize2fs 1.42.9 (4-Feb-2014) Estimated minimum size of the filesystem: 230329 $ dumpe2fs trusty-server-cloudimg-amd64.img | pastebinit dumpe2fs 1.42.9 (4-Feb-2014) http://paste.ubuntu.com/9898743/ ## Utopic $ resize2fs -P trusty-server-cloudimg-amd64.img resize2fs 1.42.10 (18-May-2014) Estimated minimum size of the filesystem: 236103 $ dumpe2fs trusty-server-cloudimg-amd64.img | pastebinit dumpe2fs 1.42.10 (18-May-2014) http://paste.ubuntu.com/9898789/ ## Vivid $ resize2fs -P trusty-server-cloudimg-amd64.img resize2fs 1.42.12 (29-Aug-2014) Please run 'e2fsck -f trusty-server-cloudimg-amd64.img' first. $ cp trusty-server-cloudimg-amd64.img trusty-server-cloudimg-amd64.img.dist $ e2fsck -f trusty-server-cloudimg-amd64.img e2fsck 1.42.12 (2
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1321418 Title: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk Status in e2fsprogs package in Ubuntu: Confirmed Bug description: The last few times my root ext4 filesystem had its regularly-scheduled boot-time check, errors were reported. The first time it happened, I simply told the system to fix the errors, but since they kept coming up again, I decided to look more closely. I booted from a live USB drive, assembled my raid partitions, and ran fsck.ext4 manually. Without any options, fsck.ext4 simply reported that the filesystem was clean, and exited. Things got more interesting when I ran with -f. It reported several multiply-claimed blocks, and when I told fsck to go ahead and clone them, it failed with an internal error. Repeated runs of fsck revealed that the filesystem was still not fixed, and repeated attempts to fix the problem also failed, reporting that multiply- claimed blocks already reassigned or cloned. I was lucky in that the files in question were unimportant, so deleting one of them and running fsck again seems to have fixed my problem this time. However, fsck's internal error and failure to fix the problem in the first place is worrisome. Here's the full output: $ sudo fsck.ext4 -f /dev/md/1 e2fsck 1.42.8 (20-Jun-2013) Pass 1: Checking inodes, blocks, and sizes Running additional passes to resolve blocks claimed by more than one inode... Pass 1B: Rescanning for multiply-claimed blocks Multiply-claimed block(s) in inode 27528089: 73467268 9287 9288 9289 9290 9291 9292 9293 Multiply-claimed block(s) in inode 27528105: 73467268 9287 9288 9289 9290 9291 9292 9293 Pass 1C: Scanning directories for inodes with multiply-claimed blocks Pass 1D: Reconciling multiply-claimed blocks (There are 2 inodes containing multiply-claimed blocks.) File /home/user/dir/subdir/05.09.2013_13.15.48.300.jpg (inode #27528089, mod time Mon Jan 13 02:50:08 2014) has 7 multiply-claimed block(s), shared with 1 file(s): /home/user/.thumbnails/normal/51048a1138d61df87bf3fdc7deed50e3.png/WebpageIcons.db (inode #27528105, mod time Mon Jan 13 02:50:08 2014) Clone multiply-claimed blocks? yes clone_file_block: internal error: can't find dup_blk for 73467268 clone_file_block: internal error: can't find dup_blk for 73467268 File /home/user/.thumbnails/normal/51048a1138d61df87bf3fdc7deed50e3.png/WebpageIcons.db (inode #27528105, mod time Mon Jan 13 02:50:08 2014) has 7 multiply-claimed block(s), shared with 1 file(s): /home/user/dir/subdir/05.09.2013_13.15.48.300.jpg (inode #27528089, mod time Mon Jan 13 02:50:08 2014) Multiply-claimed blocks already reassigned or cloned. Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information root: * FILE SYSTEM WAS MODIFIED * root: 1038356/30285824 files (0.3% non-contiguous), 106319516/121119454 blocks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1321418/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1348431 Title: -O inline_data not supported by Ubuntu e2fsprogs Status in e2fsprogs package in Ubuntu: Confirmed Bug description: Since kernel version 3.8, ext4 supports the file system option inline_data to put file content into the inode itself as an extended attribute. However, this feature cannot be enabled using the included e2fsprogs in Trusty Tahr. If it has been enabled for a file system, boot e2fsck fails. Support for this is currently being worked on upstream in https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/log/?h=pu . Adding this bug to track when this is merged into mainline and/or the ubuntu e2fsprogs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1348431/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1348431 Title: -O inline_data not supported by Ubuntu e2fsprogs Status in e2fsprogs package in Ubuntu: Confirmed Bug description: Since kernel version 3.8, ext4 supports the file system option inline_data to put file content into the inode itself as an extended attribute. However, this feature cannot be enabled using the included e2fsprogs in Trusty Tahr. If it has been enabled for a file system, boot e2fsck fails. Support for this is currently being worked on upstream in https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/log/?h=pu . Adding this bug to track when this is merged into mainline and/or the ubuntu e2fsprogs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1348431/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1348431 Title: -O inline_data not supported by Ubuntu e2fsprogs Status in e2fsprogs package in Ubuntu: Confirmed Bug description: Since kernel version 3.8, ext4 supports the file system option inline_data to put file content into the inode itself as an extended attribute. However, this feature cannot be enabled using the included e2fsprogs in Trusty Tahr. If it has been enabled for a file system, boot e2fsck fails. Support for this is currently being worked on upstream in https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/log/?h=pu . Adding this bug to track when this is merged into mainline and/or the ubuntu e2fsprogs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1348431/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 14.04 does not support ext4 metadata checksumming Status in e2fsprogs package in Ubuntu: Confirmed Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1398434 Title: e4defrag has fatal CPU performance bottleneck Status in e2fsprogs package in Ubuntu: New Bug description: During defragmentation of a 5 TB ext4 filesystem with one 600 GB file with current value of 30 and optimal value of 300 shown by `e4defrag -c`, `e4defrag' seems to suffer from a huge CPU performance bottleneck. Over hours only one CPU core is used (-> no parallelization) and there's almost no I/O during that time <1 % of the underlying device's capabilities. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: e2fsprogs 1.42.10-1.1ubuntu1 Uname: Linux 3.17.4-031704-generic x86_64 ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Tue Dec 2 16:29:12 2014 SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1398434/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1393151 Title: mkfs.ext3 causes kernel panic on new WD 6 TB drive Status in “e2fsprogs” package in Ubuntu: New Bug description: mkfs.ext3 always causes a kernel panic on both of my WD 6 TB drives while writing the inode tables. Both drives were initialised using parted with a GPT and a single partition (mkpart primary 2048s 100%) sdc 8:32 0 5.5T 0 disk └─sdc1 8:33 0 5.5T 0 part sdd 8:48 0 5.5T 0 disk └─sdd1 8:49 0 5.5T 0 part mkfs.ext3 /dev/sdc1 mke2fs 1.42.10 (18-May-2014) Creating filesystem with 1465130240 4k blocks and 18318 inodes Filesystem UUID: 1a6458a3-908d-48a0-a532-e9cbc1eb5ca4 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968, 10240, 214990848, 51200, 550731776, 644972544 Allocating group tables: done Writing inode tables: 4937/44713 <-- KP occurs here --> mkfs.ext3 /dev/sdd1 mke2fs 1.42.10 (18-May-2014) Creating filesystem with 1465130240 4k blocks and 18318 inodes Filesystem UUID: 3d6537ee-78f6-4a68-a833-e5dda4b69028 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968, 10240, 214990848, 51200, 550731776, 644972544 Allocating group tables: done Writing inode tables: 4997/44713 <-- KP occurs here --> I'll have to try to take a photo of the KP since it's not being logged, I'm just seeing it on the screen. Creating an ext4 partition works fine but the crash just happens later after writing files to the partition. Disks seems to be fine smart- wise. It's unlikely that both disks are damaged in almost the same area without S.M.A.R.T. noticing it. -- apt-cache policy e2fslibs:amd64 e2fslibs: Installed: 1.42.9-3ubuntu1 Candidate: 1.42.9-3ubuntu1 Version table: *** 1.42.9-3ubuntu1 0 500 http://ch.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages 100 /var/lib/dpkg/status -- smartctl -H /dev/sdc smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.13.0-39-generic] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org smartctl -H /dev/sdc smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.13.0-39-generic] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED smartctl -H /dev/sdd smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.13.0-39-generic] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED -- lshw -short H/W path Device Class Description system H97N-WIFI (To be filled by O.E.M.) /0busH97N-WIFI /0/0 memory 64KiB BIOS /0/3d processor Intel(R) Core(TM) i3-4160 CPU @ 3.60GHz /0/3d/3e memory 128KiB L1 cache /0/3d/3f memory 512KiB L2 cache /0/3d/40 memory 3MiB L3 cache /0/42
Re: [Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1393151 Title: mkfs.ext3 causes kernel panic on new WD 6 TB drive Status in “e2fsprogs” package in Ubuntu: New Bug description: mkfs.ext3 always causes a kernel panic on both of my WD 6 TB drives while writing the inode tables. Both drives were initialised using parted with a GPT and a single partition (mkpart primary 2048s 100%) sdc 8:32 0 5.5T 0 disk └─sdc1 8:33 0 5.5T 0 part sdd 8:48 0 5.5T 0 disk └─sdd1 8:49 0 5.5T 0 part mkfs.ext3 /dev/sdc1 mke2fs 1.42.10 (18-May-2014) Creating filesystem with 1465130240 4k blocks and 18318 inodes Filesystem UUID: 1a6458a3-908d-48a0-a532-e9cbc1eb5ca4 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968, 10240, 214990848, 51200, 550731776, 644972544 Allocating group tables: done Writing inode tables: 4937/44713 <-- KP occurs here --> mkfs.ext3 /dev/sdd1 mke2fs 1.42.10 (18-May-2014) Creating filesystem with 1465130240 4k blocks and 18318 inodes Filesystem UUID: 3d6537ee-78f6-4a68-a833-e5dda4b69028 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968, 10240, 214990848, 51200, 550731776, 644972544 Allocating group tables: done Writing inode tables: 4997/44713 <-- KP occurs here --> I'll have to try to take a photo of the KP since it's not being logged, I'm just seeing it on the screen. Creating an ext4 partition works fine but the crash just happens later after writing files to the partition. Disks seems to be fine smart- wise. It's unlikely that both disks are damaged in almost the same area without S.M.A.R.T. noticing it. -- apt-cache policy e2fslibs:amd64 e2fslibs: Installed: 1.42.9-3ubuntu1 Candidate: 1.42.9-3ubuntu1 Version table: *** 1.42.9-3ubuntu1 0 500 http://ch.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages 100 /var/lib/dpkg/status -- smartctl -H /dev/sdc smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.13.0-39-generic] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org smartctl -H /dev/sdc smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.13.0-39-generic] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED smartctl -H /dev/sdd smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.13.0-39-generic] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED -- lshw -short H/W path Device Class Description ===
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1375640 Title: fsck should do some sanity checks to avoid damaging an ext3/ext4 file system Status in “e2fsprogs” package in Ubuntu: New Bug description: After some crashes due to a broken nvidia driver, the system didn't boot and presented me a shell to manually repair the file system. Then I didn't think and typed fsck without the -t ext4 parameter and the program asked me many questions, if I want to fix something which I answered with y. After some time I remembered, that I forgot to specify the -t ext4 parameter, but the filesystem was broken already, so it was already too late, when I do Ctrl-C. And I didn't think about that there could be already severe file system corruption, making the things even worse. Thus I would recommend that a warning message is displayed, when calling fsck manually with the wrong filesystem type. Also a big note that this is now the right time to make an image backup of the disk could be helpful for people like me that always tell other people how important backups are before working on something, but sometimes fail to make one, because they forget to turn their brain on before starting work. ;-) I would expect that when calling fsck on a filesystem, not just defaults are used, but the filesystem type is determined. Then a big scary warning message should say something like this: " You have called fsck on an ext4 filesystem. For an ext4 file system you *must* specify the filesystem type with option "-t ext4", otherwise severe damage to the file system will occur. NOTE: It is highly recommended that you make a backup image of your disk device before you continue, so that you have something to recover from, if things go wrong. This can be especially important, if the disk drive hardware you are trying to recover the filesystem on, is possibly dying. You can use dd_rescue or similar tools to try to get a disk image to recover as much as possible of your data from a damaged hard drive. Are you really sure, you want to continue (and probably damage the file system)? (yes/NO) " To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1375640/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1375640 Title: fsck should do some sanity checks to avoid damaging an ext3/ext4 file system Status in “e2fsprogs” package in Ubuntu: New Bug description: After some crashes due to a broken nvidia driver, the system didn't boot and presented me a shell to manually repair the file system. Then I didn't think and typed fsck without the -t ext4 parameter and the program asked me many questions, if I want to fix something which I answered with y. After some time I remembered, that I forgot to specify the -t ext4 parameter, but the filesystem was broken already, so it was already too late, when I do Ctrl-C. And I didn't think about that there could be already severe file system corruption, making the things even worse. Thus I would recommend that a warning message is displayed, when calling fsck manually with the wrong filesystem type. Also a big note that this is now the right time to make an image backup of the disk could be helpful for people like me that always tell other people how important backups are before working on something, but sometimes fail to make one, because they forget to turn their brain on before starting work. ;-) I would expect that when calling fsck on a filesystem, not just defaults are used, but the filesystem type is determined. Then a big scary warning message should say something like this: " You have called fsck on an ext4 filesystem. For an ext4 file system you *must* specify the filesystem type with option "-t ext4", otherwise severe damage to the file system will occur. NOTE: It is highly recommended that you make a backup image of your disk device before you continue, so that you have something to recover from, if things go wrong. This can be especially important, if the disk drive hardware you are trying to recover the filesystem on, is possibly dying. You can use dd_rescue or similar tools to try to get a disk image to recover as much as possible of your data from a damaged hard drive. Are you really sure, you want to continue (and probably damage the file system)? (yes/NO) " To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1375640/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 14.04 does not support ext4 metadata checksumming Status in “e2fsprogs” package in Ubuntu: New Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365864 Title: fsck.ext4 broken on FS created with "bigalloc" Status in “e2fsprogs” package in Ubuntu: New Bug description: Main reference: https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=744953 e2fsprogs in Ubuntu 14.04 is affected by this bug that, " caused e2fsck to abort a journal replay on a filesystem with bigalloc enabled." To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365864/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1363017] Re: Resolution breaks on external monitor after 3.13.0-35 update
Re-opened as re-installing the Intel drivers did not solve the problem, resolution was lost after two reboots. ** Changed in: xorg (Ubuntu) Status: Invalid => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1363017 Title: Resolution breaks on external monitor after 3.13.0-35 update Status in “xorg” package in Ubuntu: New Bug description: I have a second monitor on DisplayPort, and its list of supported resolutions was limited to 800x600 and 1024x768 after the latest kernel update. I was able to restore the native resolution (1440p) for the monitor using xrandr. I'm on Ubuntu 14.04.1 and the GPU is the integrated one on a Haswell CPU. DisplayPort is run through a Thinkpad laptop dock. What I did: Installed the latest Ubuntu kernel update, as recommended by Software Updater What I expected to happen: Resolution of external monitor should not have been affected What happened instead: Supported modes for external monitor were removed, had to use xrarnd to restore native resolution ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: xorg 1:7.7+1ubuntu8 ProcVersionSignature: Ubuntu 3.13.0-35.62-generic 3.13.11.6 Uname: Linux 3.13.0-35-generic x86_64 .tmp.unity.support.test.0: ApportVersion: 2.14.1-0ubuntu3.3 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true CurrentDesktop: Unity Date: Fri Aug 29 11:44:44 2014 DistUpgraded: Fresh install DistroCodename: trusty DistroVariant: ubuntu DkmsStatus: i915-3.15-3.13, 0.01, 3.13.0-32-generic, x86_64: installed i915-3.15-3.13, 0.01, 3.13.0-34-generic, x86_64: installed i915-3.15-3.13, 0.01, 3.13.0-35-generic, x86_64: installed EcryptfsInUse: Yes ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:2214] InstallationDate: Installed on 2014-08-19 (9 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) MachineType: LENOVO 20AL00BYMS ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-35-generic root=UUID=58f7be01-3efd-41f5-adbb-d0a430268da1 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/06/2014 dmi.bios.vendor: LENOVO dmi.bios.version: GIET69WW (2.19 ) dmi.board.asset.tag: Not Available dmi.board.name: 20AL00BYMS dmi.board.vendor: LENOVO dmi.board.version: SDK0E50510 PRO dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvrGIET69WW(2.19):bd02/06/2014:svnLENOVO:pn20AL00BYMS:pvrThinkPadX240:rvnLENOVO:rn20AL00BYMS:rvrSDK0E50510PRO:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 20AL00BYMS dmi.product.version: ThinkPad X240 dmi.sys.vendor: LENOVO version.compiz: compiz 1:0.9.11.2+14.04.20140714-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.54-1 version.libgl1-mesa-dri: libgl1-mesa-dri 10.2.2-0intel1 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 10.2.2-0intel1 version.xserver-xorg-core: xserver-xorg-core 2:1.15.1-0ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.8.2-1ubuntu2 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.3.0-1ubuntu3.1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.911-0intel1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.10-1ubuntu2 xserver.bootTime: Fri Aug 29 11:32:03 2014 xserver.configfile: default xserver.errors: xserver.logfile: /var/log/Xorg.0.log xserver.outputs: product id 16512 vendor DEL xserver.version: 2:1.15.1-0ubuntu2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1363017/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1363017] Re: Resolution breaks on external monitor after 3.13.0-35 update
Re-installing the Intel Drivers through the Intel Graphics Installer [1] seems to have solved the problem, some configuration files were probably over-written during the update. [1] https://01.org/linuxgraphics/downloads ** Changed in: xorg (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1363017 Title: Resolution breaks on external monitor after 3.13.0-35 update Status in “xorg” package in Ubuntu: Invalid Bug description: I have a second monitor on DisplayPort, and its list of supported resolutions was limited to 800x600 and 1024x768 after the latest kernel update. I was able to restore the native resolution (1440p) for the monitor using xrandr. I'm on Ubuntu 14.04.1 and the GPU is the integrated one on a Haswell CPU. DisplayPort is run through a Thinkpad laptop dock. What I did: Installed the latest Ubuntu kernel update, as recommended by Software Updater What I expected to happen: Resolution of external monitor should not have been affected What happened instead: Supported modes for external monitor were removed, had to use xrarnd to restore native resolution ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: xorg 1:7.7+1ubuntu8 ProcVersionSignature: Ubuntu 3.13.0-35.62-generic 3.13.11.6 Uname: Linux 3.13.0-35-generic x86_64 .tmp.unity.support.test.0: ApportVersion: 2.14.1-0ubuntu3.3 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true CurrentDesktop: Unity Date: Fri Aug 29 11:44:44 2014 DistUpgraded: Fresh install DistroCodename: trusty DistroVariant: ubuntu DkmsStatus: i915-3.15-3.13, 0.01, 3.13.0-32-generic, x86_64: installed i915-3.15-3.13, 0.01, 3.13.0-34-generic, x86_64: installed i915-3.15-3.13, 0.01, 3.13.0-35-generic, x86_64: installed EcryptfsInUse: Yes ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:2214] InstallationDate: Installed on 2014-08-19 (9 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) MachineType: LENOVO 20AL00BYMS ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-35-generic root=UUID=58f7be01-3efd-41f5-adbb-d0a430268da1 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/06/2014 dmi.bios.vendor: LENOVO dmi.bios.version: GIET69WW (2.19 ) dmi.board.asset.tag: Not Available dmi.board.name: 20AL00BYMS dmi.board.vendor: LENOVO dmi.board.version: SDK0E50510 PRO dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvrGIET69WW(2.19):bd02/06/2014:svnLENOVO:pn20AL00BYMS:pvrThinkPadX240:rvnLENOVO:rn20AL00BYMS:rvrSDK0E50510PRO:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 20AL00BYMS dmi.product.version: ThinkPad X240 dmi.sys.vendor: LENOVO version.compiz: compiz 1:0.9.11.2+14.04.20140714-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.54-1 version.libgl1-mesa-dri: libgl1-mesa-dri 10.2.2-0intel1 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 10.2.2-0intel1 version.xserver-xorg-core: xserver-xorg-core 2:1.15.1-0ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.8.2-1ubuntu2 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.3.0-1ubuntu3.1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.911-0intel1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.10-1ubuntu2 xserver.bootTime: Fri Aug 29 11:32:03 2014 xserver.configfile: default xserver.errors: xserver.logfile: /var/log/Xorg.0.log xserver.outputs: product id 16512 vendor DEL xserver.version: 2:1.15.1-0ubuntu2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1363017/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
