Description of problem: Version-Release number of selected component (if applicable): kernel 3.12 or 3.11 How reproducible: Steps to Reproduce: 1. install system with btrfs as root and home 2. boot with usb 3. check with btrfsck Actual results: root 256 inode 754 errors 400, nbytes wrong Expected results: correct Additional info: It occurs in both of my machine. I resolve the inode and find it is shadow- and the error can be fixed by removing this file.
It always occurs.
Any comments?
There's really not enough information for us to do anything with this bug. You might have better luck contacting the btrfs developers directly.
But this seems always occur after I have installed the system. It should be easy to reproduce.
Changing to btrfs-progs since btrfsck (now 'btrfs check') is part of that component. Can you confirm the file system was created by a Fedora 20 installer? This would mean btrfs-progs-0.20.rc1.20131114git9f0c53f-1.fc20 for mkfs. I think these messages, while confusing, are benign because otherwise the btrfs kernel code would complain, and if serious enough it will only mount the fs ro or not at all. Out three Btrfs file systems, one also exhibits such messages but otherwise behaves as expected. Upstream thread, which I've just refreshed and cross referenced. http://www.spinics.net/lists/linux-btrfs/msg30617.html
It's created by default installer of fedora 20.
This looks like a plausible explanation. It sounds like there's a patch to fix this in 3.14. Once the problem has happened though the current btrfs check --repair code can't fix it yet. I'm still not exactly sure how big of a problem it is, as at least in my case I'm getting clean scrubs with no errors. I'll have to try the comment 1 inspect+truncate and see what happens. https://bugzilla.kernel.org/show_bug.cgi?id=68411
I attempted to shrink a '/' btrfs partition and ran into this problem with a btrfs check:root 256 inode 48328 errors 400, nbytes wrong. Finding the instructions at the site in comment #7 and using a non Fedora rescue disk, I found /etc/passwd- to be the problem. I could not do anything with this file (perhaps due to 3.10 kernel in the rescue). Booted to Fedora 20 and was able to truncate and 'rm' /etc/passwd-. Back to the rescue disk and the same inode problem appeared with the file being /etc/shadow- I was able to truncate and remove this file from the rescue disk. Gparted then ran to successful completion. I hope you will agree that this seems like more than a btrfs problem. The same file being a problem (/etc/shadow-) seems to be too much of a coincidence.
btrfs-progs-3.14.1 has been pushed to Fedora 19 and 20 for testing. I frankly have no idea if this will resolve your bug or not, but if you test it and find that it does, please take the opportunity to close this bug. :) Thanks, -Eric
I was under the assumption that this issue was encountered with a fresh brtfs install. If it is widespread, many may be unaware unless they do a filesystem check (btrfsck?). If I am correct, then the brtfs-progs-3.14.1 would need to be pushed to stable Fedora. I could then do a network install and see if the problem exists. I have already deleted /etc/shadow- using instructions from the web so I could shrink the btrfs system. I am willing to try a fresh network install to a virtual machine when the above rpm is pushed to stable. Any other suggestions (or I am in error in my logic), let me know.
A Rawhide boot.iso (netinstall) will contain a recent kernel and already has btrfs-progs 3.14-1. I can't reproduce the btrfs check results in this bug with Rawhide or Fedora 20 install media.
(In reply to Chris Murphy from comment #11) >I can't reproduce the btrfs check results in this bug with Rawhide or >Fedora 20 install media. More specifically: install F20 minimal from DVD, to Btrfs rootfs, reboot rescue mode from DVD and run btrfs check (this would be btrfs-progs 0.20rc1), no errors reported. Same if I check this install with btrfs-progs 3.14. And if I install Rawhide and check the install with btrfs-progs 3.14 it also has no errors. So I don't see how this is being reproduced.
The original reporter seemed to indicate the bug was immediately apparent with an install. I did not notice the issue for many weeks. In the mean time, I had "monkeyed" around with users; changing GID UID numbers for users, changing passwords, adding users, you name it. Perhaps that is a source of the problem. Or maybe I just got "lucky". I will attempt to do an install from rawhide by May 25th and mess around with accounts and then report back.
Installed from Rawhide boot.iso with no btrfs issues. Altered accounts with no impact on /etc/shadow- (though I don't know how this file works). NOTE: Fresh install was from December 2010 on the machine with btrfs problem and has been fedup (or equivalent) ever since. Not in charge today, but I have no issues with closing this bug at this time.
FWIW, I'm also having this problem on CentOS 7.0. Finding and deleting the problematic inode fixed the problem and allowed be to continue with expanding the btrfs filesystem in gparted. sudo find /media/ubuntu/centos_usbosnavdev-ghosts/ -inum 293268 My problematic file turned out to be /var/tmp/abrt/last-ccpp so my problem very likely did not exist immediately after OS installation.
I am affected by this, and it has also hit /etc/shadow- -- F21 with 3.18.9-200.fc21. When the problem hit, after a hard poweroff (ran out of battery), the system would fail to boot under 3.18.9-200.fc21. Exploring with the emergency shell I found that the system would refuse to even fsck the sys root partition (Couldn't open file system). It would freeze trying to mount it. It would however boot under liveUSB F21, and ran btrfs fsck reporting the error mentioned in this bug, then btrfs fsck --repair completed successfully. However running btrfs fsck again still shows the error. Interestingly, after the "repair", the system still failed to boot with 3.18.9-200.fc21 (now, it timed out during mount), however it did boot correctly under 3.18.7-200.fc21 . Alternating boots between the two kernels a few times (6 probably) the FS got to a point where it now does boot correctly under 3.18.9-200.fc21. The whole process got documented in an email thread. My suspicions at this time are that... - 3.18.9-200.fc21 has a regression, and it will fail to boot, and even to run fsck with the FS in some conditions that 3.18.7-200.fc21 handles right. - There is something about /etc/shadow- -- we have several users independently hitting this problem over the same damn file. Something in the yum/rpm stack rubs the fs the wrong way...
The current set of deadlocks happening after a crash is explained by today's "Please add 9c4f61f01d269815bb7c37be3ede59c5587747c6 to stable" post on linux-btrfs@ But I'm not sure how it relates to this bug, which is still something of a mystery.
Start of a very long thread discussing my debugging of this issue - http://www.spinics.net/lists/linux-btrfs/msg42940.html
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.