Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 158161 - x86_64 slave gives RPC error with i386 master
Summary: x86_64 slave gives RPC error with i386 master
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: ypserv
Version: 3
Hardware: x86_64
OS: Linux
medium
low
Target Milestone: ---
Assignee: Chris Feist
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-19 10:02 UTC by Robert Schumann
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-31 20:37:37 UTC


Attachments (Terms of Use)

Description Robert Schumann 2005-05-19 10:02:42 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4

Description of problem:
Recently installed FC3 x86_64 on a dual Xeon processor machine,
[robert@callista: ~] uname -a
Linux callista.physics.nat 2.6.11-1.14_FC3smp #1 SMP Thu Apr 7 19:36:23 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux

It is part of a network with NIS server xena,
[robert@xena: ~] uname -a
Linux xena 2.6.11-1.14_FC3smp #1 SMP Thu Apr 7 19:38:19 EDT 2005 i686 i686 i386 GNU/Linux

Callista has ypserv.x86_64 installed, and after having issued "ypinit -m" on the xena and added callista as one of the slaves, I then tried to start callista as slave
[root@callista ~]# /usr/lib64/yp/ypinit -s xena.physics.nat
We will need a few minutes to copy the data from xena.physics.nat.
Transferring auto.home...
Trying ypxfrd ...rpc.ypxfrd doesn't support the needed database type
call to rpc.ypxfrd failed: RPC: Can't decode result

 (failed, fallback to enumeration)

and similar error messages for all the other maps.

Someone else has reported this problem, http://lists.debian.org/debian-amd64/2005/01/msg00232.html, and suspected it was related to x86_64 architecture.

I downloaded and installed (from the FC3 repository) ypserv-2.13-5.i386.rpm. I had to "yum remove ypserv" first, because there were conflicts. Now issuing "ypinit -s xena.physics.nat" succeeded.

Version-Release number of selected component (if applicable):
ypserv-2.13-5

How reproducible:
Always

Steps to Reproduce:
1. Run ypserv as master on an i386 machine A, with slave machine B an x86_64
2. Run "/usr/lib64/yp/ypinit -s A" on machine B to start slave NIS server
3.
  

Actual Results:  RPC errors, but it appears the maps were transferred

Expected Results:  No errors

Additional info:

Comment 1 Chris Feist 2005-05-31 20:37:37 UTC
Because yp uses a non-platform independent database for its backend it cannot
transfer those db files between yp servers of differing architectures.  When
rpc.ypxfrd notices that it's transfering files to a sever with a different
architecture it prints out a message that it couldn't transfer the db file and
then falls back to enumeration.  This is expected behavior.


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