Bug 524285 - Stale NFS Handle error on local library file after system suspend
Stale NFS Handle error on local library file after system suspend
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: LVM and device-mapper development team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-18 12:31 EDT by Matt Anderson
Modified: 2010-04-28 06:27 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-04-27 12:19:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt Anderson 2009-09-18 12:31:35 EDT
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.
Comment 1 Ondrej Vasik 2009-09-18 13:16:11 EDT
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).
Comment 2 Matt Anderson 2009-09-21 11:11:51 EDT
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.
Comment 3 Dave Wysochanski 2009-12-08 13:55:19 EST
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?
Comment 4 Alasdair Kergon 2010-04-27 12:19:25 EDT
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.
Comment 5 Bug Zapper 2010-04-28 06:27:42 EDT
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

Note You need to log in before you can comment on or make changes to this bug.