I suppose you could try opening up the initrd and seeing what is inside. I
had to do that at one stage in debugging. You can put in echo statements
in the nash script, and/or say set +x or something like that to echo all
of what mkinitrd is doing.
Sorry I can't be of more help.
- Alex
On Thu, 15 Nov 2007, David A. Kennel wrote:
Tried adding --with=nfs and --fstab=../etc/fstab. No change in the behavior
of the client. No visible attempt to mount an NFS root.
Alex Aminoff wrote:
Our setup is rather different, not using LTPS but instead adapting
FreeBSD's /etc/rc.initdiskless.
My mkinitrd is like this:
mkinitrd --with=nfs --with=e100 ... --with=via-rhine --with=forcedeth
--fstab ../etc/fstab netinitrd.$FC.img $kversion
This is not chrooted or anything, the IP address and path to the nfs root
is in ../etc/fstab.
Maybe --with=nfs would work?
On Wed, 14 Nov 2007, David A. Kennel wrote:
OK, I got some time to work on this and I'm bumping into trouble:
I've got NFS, DHCP, and TFTP all up and working. When my client boots I'm
getting the following error:
No filesystem could mount root, tried: ext2 iso9660
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(9,1)
I'm creating the initrd while chrooted inside the root for my ltsp
clients. Here's the vitals:
initrd is being created by this script:
#!/bin/bash
# script to create an LTSP initrd for RHEL 5
kernelver=$1
mkinitrd -v -f --preload=3c59x \
--preload=amd8111e \
--preload=epic100 \
--preload=mii \
--preload=ns83820 \
--preload=skge \
--preload=sungem \
--preload=via-velocity \
--preload=8139cp \
--preload=b44 \
--preload=dl2k \
--preload=fealnx \
--preload=myri10ge \
--preload=r8169 \
--preload=sky2 \
--preload=sungem_phy \
--preload=8139too \
--preload=bnx2 \
--preload=dummy \
--preload=forcedeth \
--preload=natsemi \
--preload=pcnet32 \
--preload=s2io \
--preload=slhc \
--preload=sunhme \
--preload=8390 \
--preload=ifb \
--preload=ne2k-pci \
--preload=sis190 \
--preload=tg3 \
--preload=typhoon \
--preload=acenic \
--preload=cassini \
--preload=e100 \
--preload=sis900 \
--preload=starfire \
--preload=tlan \
--preload=via-rhine \
--preload=winbond-840 \
--preload=xircom_cb \
--preload=de2104x \
--preload=uli526x \
--preload=tulip \
--preload=de4x5 \
--preload=dmfe \
--preload=smsc \
--preload=libphy \
--preload=lxt \
--preload=cicada \
--preload=marvell \
--preload=qsemi \
--preload=fixed \
--preload=vitesse \
--preload=davicom \
--preload=cxgb /boot/initrd-${kernelver}.img ${kernelver}
/etc/fstab inside the chroot looks like this:
192.168.1.1:/opt/ltsp/i386 / nfs dhcp 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
/etc/sysconfig/mkinitrd looks like this:
rootdev=nfs
NET_LIST=eth0
rootfs=nfs
Using mkinitrd-6.0.19-1 and kernel-2.6.18-8.1.14.el5
It looks like the client isn't even attempting the NFS root mount. What am
I doing wrong here?
Thanks,
Jeffrey Law wrote:
On Fri, 2007-10-26 at 15:30 -0600, David A. Kennel wrote:
That is the idea exactly. All of the client nodes share a single
/etc/fstab.
So if I understand you correctly, if my /etc/fstab looks like the one
below the clients will ignore the "192.168.0.1:/opt/ltsp/i386" part and
get the NFS server from the DHCP response.
#bogus nfs server for client roots to make initrd work
192.168.0.1:/opt/ltsp/i386 / nfs dhcp 0 0
proc /proc proc defaults 0 0
Correct. I don't have experience passing them via DHCP (instead I've
passed in the correct root via tftpboot), but the net result should be
the same.
Basically whatever you have in your fstab gets embedded into the initrd,
but can be overridden via tftpboot (and presumably DHCP).
This is important as it allows you to share an initrd across
clients, even if the clients mount their root filesystem from
different servers.
Jeff
--
- Alex Aminoff
BaseSpace.net
National Bureau of Economic Research (nber.org)
_______________________________________________
Stateless-list mailing list
[email protected]
http://www.redhat.com/mailman/listinfo/stateless-list
