SOLVED: NFS server fails after upgrade to lenny
On Thu, 30 Jul 2009 09:03:44 -0400, hendrik wrote: > I upgraded the server on my LAN to lenny a few months ago (after making > a backup of the etch system (everything except user file systems)) in > another partition. > > Now when I run lenny on the server, an NFS mount from a client machine > fails with the message (hand-transcribed from screen; there may be > typos) > > lovesong:~# mount /farhome > mount.nfs: mount to NFS server '172.25.1.11' failed: RPC Error: Program > not registered > lovesong:~# > > > But when I reboot the server to etch using the etch I saved in the > backup partitions: > > lovesong:~# #mount /ferhome > [514.141911] RPC: Registered udp transport module. [514.143371] RPC: > Registered tcp transport module. > lovesong:~# > > So the upgrade seems to have damaged something. Where should I look? It appears that the map_identity option is no longer valid, to such an extend that when it appears on a line in the /etc/exports file, it invalidates the entire file, not just the line it appears on. Removing the option fixed the problem. Is this something that should have been detected and reported or adjusted by the upgrade process? -- hendrik -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Subversion segmentation fault for 1 repository
> open("graphics/db/__db.001", O_RDWR)= 5
The failing repository is a BDB repository.
> > >This repo is very big - server repo directory is 7.1 GB. Maybe this is a
> > >reason
> > >for that? All other repositories work fine, although they are much smaller.
Are the other repositories using BDB or FSFS? Look in
repository/db/fs-type to find out.
Which version of Berkeley DB is used on the two machines? Oldstable
appears to be libdb4.4, stable is libdb4.6, unstable is perhaps
libdb4.7.
BDB databases are supposed to be portable from 32 to 64 bits:
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am_misc/faq.html
but if for some reason that doesn't work the last ditch solution is to
dump the database on the 32 bit machine, transfer the dump, and load
it on the 64 bit machine.
--
Philip
--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Subversion segmentation fault for 1 repository
Philip Martin writes: > BDB databases are supposed to be portable from 32 to 64 bits: > http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am_misc/faq.html > but if for some reason that doesn't work the last ditch solution is to > dump the database on the 32 bit machine, transfer the dump, and load > it on the 64 bit machine. It might be sufficient to remove the BDB shared-memory files repository/db/__db.00? on the 64 bit machine, they will get recreated automatically when you access the repository. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Subversion segmentation fault for 1 repository
> > >I've changed hardware in my server from i386 to AMD64 and everything works > > >fine > > >except one SVN repository. > > > > > >When I try to access it, there is following error: > > > svn: OPTIONS z 'http://some.local.ip.address/svn/repo-name': Could not > > > read status line: connection was closed by server > > > (http://some.local.ip.address) > > > > > >in Apache error log: > > > [notice] child pid 3504 exit signal Segmentation fault (11) > > > > > >I've thought it might me dav_svn issue but: > > > svnadmin verify repo-name > > >gives following result: > > > Segmentation fault > > > > > >The same is with: > > > svnadmin recover repo-name > > > > > > Repository lock acquired. > > > Please wait; recovering the repository may take some time... > > > Segmentation fault > > > > > >This repo is very big - server repo directory is 7.1 GB. Maybe this is a > > >reason > > >for that? All other repositories work fine, although they are much smaller. > > > > > >On i386 machine this repository, just copied from amd64 works fine. > > > > > >Any help will be appreciated. > > > > > >Regards, > > >Jakub For me it seems as there is a bug in some libraries compiled for amd64. I've made following checks: - I downloaded newest subversion sources and compiled it. Result was the same as above that is "Segmentation fault". - I installed ia32 chroot system with debootstrap and repository works fine on the same machine! Should I file a bug somewhere? Regards, Jakub -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
