Description of problem: I was working on my laptop the other night when the battery got low. The system automatically started to suspend but I was able to plug it in before it shutdown. I used the system for a while longer after that, with no noticeable issues, but then when I booted it up the next morning the system would not boot. Removing "rhgb quiet" from the kernel command line I saw that there was an error 116 with the /lib/libdbus-1.so.3 library file. I then tried booting the system into single user mode. The system was able to come up just fine in single user mode, but when I tried to access the /lib/libdbus-1.so.3 file I got errors: # ls -l /lib/libdbus* ls: cannot access libdbus-1.so.3: Stale NFS file handle lrwxrwxrwx+ 1 root root 23 Sep 17 08:23 libdbus-1.so -> /lib/libdbus-1.so.3.4.0 -rwxr-xr-x+ 1 root root 261756 Jun 27 19:14 libdbus-1.so.3.4.0 Version-Release number of selected component (if applicable): How reproducible: Everytime, now that it is in this state. Steps to Reproduce: I'm not exactly sure, but the system had been working before the attempted suspend so I think that is what did it. 1. Let your system run low on power and initiate suspend. 2. Plug in power to the system before suspend finishes so that the system stays up. 3. Cold boot, the files may appear as Stale NFS Handles then. Actual results: The system doesn't boot, because it cannot access the required library file. Expected results: Linux always boots :) Additional info: I have tried to fsck the system several times from rescue CDs and other installs on the laptop, but for now nothing seems to fix the messed up entry for /lib/libdbus-1.so.3. rm, touch, and ln all get access denied errors. # rm libdbus-1.so.3 rm: cannot remove `libdbus-1.so.3': Stale NFS file handle From looking around this appears to be an error given with stat() fails.
Thanks for report, but filesystem is just system package with basic directory layout and it has nothing to do with filesystems generally. As you reported the issue on LVM channel at http://osdir.com/ml/linux-lvm/2009-09/msg00059.html , I guess reassign to lvm2 is step forward (although it might be kernel issue).
I thought I would try to tar up my lib directory and `rm -rf /mnt/lib` from a rescue CD and then untar the files back in place. This didn't work out however since tar failed from previous errors. Then I started looking and found out that I have several more Stale NFS handles: orb:/mnt # ls -lR > /dev/null ls: cannot access ./etc/audit/auditd.conf: Stale NFS file handle ls: cannot access ./etc/gconf/schemas/apps-evolution-template-placeholders.schemas: Stale NFS file handle ls: cannot access ./etc/rc.d/init.d/psacct: Stale NFS file handle ls: cannot access ./etc/rc.d/init.d/crond: Stale NFS file handle ls: cannot access ./etc/rc.d/rc0.d/K89portreserve: Stale NFS file handle ls: cannot access ./etc/sysconfig/auditd: Stale NFS file handle ls: cannot access ./lib/libdbus-1.so.3: Stale NFS file handle ls: cannot access ./lib/firmware/COPYRIGHT-usb.atmel-firmware: Stale NFS file handle ls: cannot access ./lib/firmware/COPYING.atmel-firmware: Stale NFS file handle ls: cannot access ./lib/firmware/iwlwifi-3945-2.ucode: Stale NFS file handle ls: cannot access ./lib/firmware/atmel_at76c502.bin: Stale NFS file handle ls: cannot access ./lib/firmware/ipw2100-1.3.fw: Stale NFS file handle ls: cannot access ./lib/firmware/rt73.bin: Stale NFS file handle ls: cannot access ./lib/firmware/iwlwifi-3945.ucode: Stale NFS file handle ls: cannot access ./usr/lib/libgphoto2/print-camera-list: Stale NFS file handle ls: cannot access ./usr/lib/nss/unsupported-tools/atob: Stale NFS file handle The only one that is keeping me from booting is /lib/libdbus-1.so.3, but the error seems more widespread over my filesystem then I previously thought.
Unlikely LVM is the right place for this. Were you using NFS on your laptop? If not, perhaps a suspend-related filesystem corruption. If so, perhaps something related to NFS?
laptop + NFS confuses us. Not much can be done really - to diagnose things like this you really need to take a complete image of the disks for investigation at the first moment you notice something has gone wrong - it can even be the automated repair process (filesystem journal replay or fsck) that *causes* the damage.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 WONTFIX if it remains open with a Fedora 'version' of '11'. 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 prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping