Local filesystem with "Stale NFS handle" error - blocks F17 upgrade

[Arif Saleem]

Hi,
I have an odd situation, which is blocking my F16->F17 upgrade.
My system (Dell XPS 15z laptop) was installed fresh as F16 in January.
I created / as btrfs, /boot as etx4 and /home as encrypted btrfs.

The machine has been running fine since then. I tried to upgrade to F17
using the DVD but the "/usr merge script" failed.
Checking the other screens for errors, it appears that the following files
are causing the problem :

# ls -l /usr/lib/python2.7/site-packages/gnomedvb/ui/preferences/Dialogs.*
ls: cannot access
/usr/lib/python2.7/site-packages/gnomedvb/ui/preferences/Dialogs.pyc: Stale
NFS file handle
ls: cannot access
/usr/lib/python2.7/site-packages/gnomedvb/ui/preferences/Dialogs.pyo: Stale
NFS file handle
-rw-r--r--. 1 root root 8182 Dec 12 17:30
/usr/lib/python2.7/site-packages/gnomedvb/ui/preferences/Dialogs.py

# rpm -qf
/usr/lib/python2.7/site-packages/gnomedvb/ui/preferences/Dialogs.pyc
gnome-dvb-daemon-0.2.7-1.fc16.x86_64

# rm /usr/lib/python2.7/site-packages/gnomedvb/ui/preferences/Dialogs.pyc
rm: cannot remove
`/usr/lib/python2.7/site-packages/gnomedvb/ui/preferences/Dialogs.pyc':
Stale NFS file handle

The weird thing is /usr is a local filesystem - there are no NFS mounted
file systems at all. And this error occurs both within anaconda, and when
the system is running normally under F16.
(I have recently noiced that after a fresh boot into F16, the system load
goes to > 3 for about 5 minutes, with some tracker processes haveing very
high I/O waits. Perhaps these 'stale NFS handles' are causing that problem
too?)

How can I resolve this? Should I boot off a rescue disk and run btrfsck
/dev/sda2 and check the filesystem? Is that 'safe' at the moment?
Any help would be much appreciated.

TIA,
Regards
Arif
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20120605/085dfd2e/attachment.html>