I've got an fstab which looks like this:

192.168.0.1:/raid/clients/diskless      /       nfs     rsize=8192,wsize=8192  
0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

and then I run
mkinitrd -f --fstab=fstab --with=natsemi initrd.img 2.6.21-1.3228.fc7

on a fedora 7 machine with the i586 version of the kernel-2.6.21-1.3228
rpm (from which I also take the kernel).

For the vmware image, I replace natsemi with pcnet32, otherwise
everything else is the same. Since the image with pcnet32 works for the
vmware image, my first guess at whether I'd got the process right was
that I had. Granted, the net4826 version winds up picking up some extra
modules, because mkinitrd guesses they're necessary based on the
configuration of the machine it's running on (another vmware image, this
one with a disk, from which I copied the nfsroot directory, and with an
i586 kernel installed), but I wouldn't think the extra modules would
hurt anything, at least as a first guess.

Given that the nfs server sees some packets and responds, but the actual
connection isn't working, I would have guessed some sort of driver
issue.

-Ben Scarlet


On Wed, 2007-07-18 at 08:13 -0600, Kannaiyan Natesan wrote: 
> May I know what parameters you have used for initrd to do the nfs boot
> ?  Something might have missed out there.
> 
> Kannaiyan
> 
> On 7/18/07, Benjamin S. Scarlet <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > I'm trying to get a net4826 running Fedora 7, using an NFS root
> > filesystem. When my boot process (dhcp, pxelinux, initrd, remount nfs as
> > root) gets to the point of mounting the nfs root, it has trouble
> > contacting the nfs server.
> >
> > For purposes of validation, I'm comparing to a VMware image, booting
> > with the same procedure. The only differences between the two are the
> > (perhaps virtual) hardware, the network cabling, and that the
> > initrd.img's differ in which network driver kernel module is included -
> > the VMware image gets an initrd with pcnet32, while the net4826 gets one
> > with natsemi.
> >
> > The vmware image boots fine.
> >
> > The net4826 pxeboots fine. Since the dhcp server and the tftp server are
> > on the same machine as the nfs server, I think the hardware and network
> > cabling are functional.
> >
> > The boot proceeds through the pxeboot to mount the initrd, load the
> > contained kernel modules including natsemi.ko, and re-acquire for linux
> > the ip which the pxe code  got a few seconds before. (This is
> > interesting to me because that step presumably uses the ethernet through
> > the natsemi.ko, successfully).
> >
> > Then the initrd continues to boot, and tries to nfs mount the final
> > root. At this point all I get are a (very) slow progression of
> >
> > nfs: server 192.168.0.1 not responding, still trying
> >
> > messages, with an occasional
> >
> > nfs: server 192.168.0.1 OK
> >
> > thrown in.
> >
> > tcpdump on the nfs server does show some packets in both directions, but
> > I don't know what to look for beyond that.
> >
> > I've checked the code of the Fedora 7 natsemi kernel module, and it does
> > seem to include some form of the short cable patch, though a newer form
> > than the old one I found googling soekris-tech.
> >
> > Would anybody perhaps have any ideas what could be going wrong? I can
> > provide net4826 console logs and tcpdump logs and such if they'd help.
> >
> > Thanks,
> > Benjamin S. Scarlet
> >
> >
> > _______________________________________________
> > Soekris-tech mailing list
> > [email protected]
> > http://lists.soekris.com/mailman/listinfo/soekris-tech
> >

_______________________________________________
Soekris-tech mailing list
[email protected]
http://lists.soekris.com/mailman/listinfo/soekris-tech

Reply via email to