Very Computer

Hi everybody!

I am currently trying to port a Jumpstartserver onto LINUX (SLES8) and
running into a mayor problem.

I set up all the services (bootparamd, tftpd, rarpd, nfsd) und copied
the bits to the certain directories. That should all be OK!

The SUN-Machine boots (gets its IP config & tftps the bootkernel) and
then hangs saying
"Requesting Internetadress for x:x:x:x:x:x
panic - boot: Could not mount filesystem"

The last syslogentry on the Linuxbox is:
"bootparamd whoami got questin from x:x:x:x:x:x:x
bootparamd This is host hostname
bootparamd Returning hostname SERVERIP"

The weird thing, that sometimes it boots quite some steps further. Then
it actually starts to mount the filesystem - sometimes even configure
/dev and the networkinterfaces - and then hangs at "whoami: no domain name"

As I said before, the weird thing is, that is sometimes boots further,
then the other time.

Did anybody try this before and experienced similar problems???

THX for any help!

-- Manfred

Looks to me like it requested (and received) the a server:/path for the
root filesystem, but the NFS mount for that failed.

Snoop/tcpdump the wire and look for NFS mount requests.

Quote:> The weird thing, that sometimes it boots quite some steps further. Then
> it actually starts to mount the filesystem - sometimes even configure
> /dev and the networkinterfaces - and then hangs at "whoami: no domain name"

Ugh.  If it hangs after NFS starts up, there may be a problem with how
the NFS server handles device files.  Make sure you have all patches for
the NFS stuff on the Linux server.

Quote:> As I said before, the weird thing is, that is sometimes boots further,
> then the other time.

Two servers?  

--

Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

It mounts it!

Quote:

> Ugh.  If it hangs after NFS starts up, there may be a problem with how
> the NFS server handles device files.  Make sure you have all patches for
> the NFS stuff on the Linux server.

My server is on the latest Patchlevel, is there a way to modify the
server in order to handle those files correctly?

Thx for help!
Manfred

Then what crosses the wire just before the panic?  NFS packets?

You might try playing with the server to either have it run only tcp/udp
or v2/v3 and see if some combination is better.  

--

Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

YES

Quote:

> You might try playing with the server to either have it run only tcp/udp
> or v2/v3 and see if some combination is better.  

Sorry... but how? :(

Well, what kind?  What are the contents?  Use -v and look.  It should be
readable with the client attempting to find a file and the server either
returning data or an error message.  I think reading that should be a
good first step.

*something* happens just before the panic.  If you knew what, it might
point to a problem or misconfiguration that you can resolve.

Quote:>> You might try playing with the server to either have it run only tcp/udp
>> or v2/v3 and see if some combination is better.  

> Sorry... but how? :(

You've got a linux server.  I have no idea.  Presumably running a man on
nfsd might return something useful.

--

Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

Well... there is data crossing the wire! Shortly before it freezes,
there are "normal" reads, lookups, access etc... then it certainly stops
- no error message!

Quote:> > You've got a linux server.  I have no idea.  Presumably running a man on
> nfsd might return something useful.

Well.. I tested around with that, but obviously the client uses both
protocols (V2 at the beginning and V3 later on). So I finally
recompliled my kernel (included all available NFS-Options) - dind't help!

Any further ideas??? Somebody must have done this before!

thx,
-- Manfred

This help any? It's for Solaris 7, but shows specifying an rsize option
in the rootopts.

http://www.unixpeople.com/HOWTO/jumpstart_on_linux.html

     I was getting the same.

Quote:> > > You've got a linux server.  I have no idea.  Presumably running a man
on
> > nfsd might return something useful.

> Well.. I tested around with that, but obviously the client uses both
> protocols (V2 at the beginning and V3 later on). So I finally
> recompliled my kernel (included all available NFS-Options) - dind't help!

> Any further ideas??? Somebody must have done this before!

   Me the other day.. I have it working now!!! tcpdump and even ethereal did
not help
   much!

   If the Sun box already has Solaris on it and it has not been overwritten
run

       bpgetfile -v

   from the Sun box  to check that the root path is correct.

   On the Linux box change the /etc/rc2.3 or /etc/rc3.d or /etc/xinetd.d
script which starts
    bootparamd.

    For Fedora Core 1 I changed

    daemon bootparamd

    to

    daemon bootparamd -d -s

    Then run the script with a stop argument and again with a start
argument.
    The bootparamd script will hang there with bootparamd running.

    I think the script hangs because bootparamd does not fork and go into
    background but runs in foreground but it is still working
     (use ps -ef to see that it is running).)

    boot net - install

    again and look in the syslog on the Linux machine.

    My linux machine has two network cards in it (192.168.0.4 and 10.0.0.4).
    My Sun box is on the 192.168.0.0 network but bootparamd was sending
    10.0.0.4 to the Sun box (something like default route!!).

    Changing the bootparamd startup to

     bootparamd -r 192.168.0.4

    to force the correct IP address in the conversion between bootparamd and
the
    Sun box worked!

    (The reason tcpdump and etherreal do not work was that I think the sun
box was
     trying to sending packets to the wrong ip address and finding no route
to my 10.0.0.0
     network!).

Quote:> thx,
> -- Manfred

Hmm..  That shouldn't cause a "can't mount fileserver" error.

Quote:>> > You've got a linux server.  I have no idea.  Presumably running a man on
>> nfsd might return something useful.

> Well.. I tested around with that, but obviously the client uses both
> protocols (V2 at the beginning and V3 later on). So I finally
> recompliled my kernel (included all available NFS-Options) - dind't help!

The client will start high (tcp vs udp and 3 vs 2).  But if the server
doesn't support them, it will do 2 and udp.  The server should be
configurable in what it will advertise to clients.

Quote:> Any further ideas??? Somebody must have done this before!

Yes.  In general I assume that issues people run into are not the ones
you are seeing.  The howtos I see on google don't go into the server
configuration, so it must not normally be a problem.

http://www.unixpeople.com/HOWTO/jumpstart_on_linux.html

--

Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

I don't when or with what kernel versions (of Linux) this ever worked, i
couldn't get it to work with a vanilla kernel. After lots of debugging, i
finally found the difference between SUN and Linux NFS (or better: the one
difference that kept netbooting a SUN from a Linux NFS server):
When determining access rights to a special file, Solaris apparently uses
different criteria than Linux. In other words: Although the root directory
is exported as read-only, when the client requests access rights to a
special file (/dev/console or the like) and the file attributes are -rw-rw-rw
write access is granted. IMHO that's ok, because special files only have
meaning on the client anyway.
Linux, on the other hand, just sees the read-only exported file systems and
tells the client 'No write access here', which causes the booting Sun to
coredump (at least try, it's r/o after all) and die. If you need it, i can
send you the patch (it's just three lines in vfs.c)

Ciao,
        Arty

--
Bernd Raschke                                              NetAge Solutions GmbH
Opinions expressed herein are my own and may not represent those of my employer.

Thank your for the answer!

Please send me the patch

Very interesting analysis!  That fits perfectly with the anecdotal
evidence I've seen over the years, especially with the fact that the
blowups happen when accessing device files on the root filesystem.

Of course I've also read lots of reports of this working on pretty much
out-of-the-box Linux machines around the beginning of the 2.4 kernel
timeframe.  

Do you know of any versions of Linux NFS that would *not* be subject to
the behavior you mention?

--

Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

   I have it working on Fedore Core 1

A coworker of mine had a jumpstart server running on RedHat 7.2, but this
was with a r/w NFS export, so the symptom did not show. As r/w is supposed
to frell your boot environment (although i do not know _how_ exactly), i
tried to do it r/o and had to come up with the patch. Why it works with
different setups (and there are many reports that it does), i do not know.
Maybe things changed from Solaris 7 to 8 and Linux 2.2 to 2.4? I started
with Sol8 12/02 and Linux 2.4.21

Cheers,
        Arty

--
Bernd Raschke                                              NetAge Solutions GmbH
Opinions expressed herein are my own and may not represent those of my employer.