Bug 523566 - --nfsroot for mkinitrd doesn't generate valid init script
Summary: --nfsroot for mkinitrd doesn't generate valid init script
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mkinitrd
Version: 5.3
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Peter Jones
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-16 01:02 UTC by Rich Rauenzahn
Modified: 2010-11-09 13:25 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-07-02 03:13:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Rich Rauenzahn 2009-09-16 01:02:26 UTC
Description of problem:

The init generated by mkinitrd doesn't seem to actually issue a command to mount the nfs root.

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

redhat 5.3,

# rpm -qi mkinitrd
Name        : mkinitrd                     Relocations: (not relocatable)
Version     : 5.1.19.6                          Vendor: Red Hat, Inc.
Release     : 54                            Build Date: Wed 17 Jun 2009 10:52:14 AM PDT

# uname -a
Linux localhost.localdomain 2.6.18-128.el5 #1 SMP Wed Dec 17 11:42:39 EST 2008 i686 i686 i386 GNU/Linux

How reproducible:

everytime

Steps to Reproduce:

# mkinitrd -v -f --omit-raid-modules --omit-scsi-modules --omit-lvm-modules --net-dev=eth0 --rootfs=nfs --rootdev=10.0.0.2:/nfsroot initrd.img `uname -r`

boot the shipping redhat kernel with that initrd from pxe

# mkdir initrd.contents 
# cd initrd.contents && gunzip < ../initrd.img | cpio --extract

Take a look at this part of the init script --

echo Creating root device.
mkrootdev -t nfs -o defaults,ro 10.0.0.2:/nfsroot
echo Mounting root filesystem.
mount /sysroot
echo Setting up other filesystems.

That creates an /etc/fstab within the ramdisk during boot with the following contents:

/dev/nfs /sysroot nfs defaults,ro 0 0

I think that is possibly a meaningless mount line.

I manually changed it to 

10.0.0.2:/nfsroot /sysroot nfs nolock,ro 0 0

by adding an echo  10.0.0.2:/nfsroot /sysroot nfs nolock,ro 0 0 > /etc/fstab

in the initrd's init script

And got a successful boot.  (nolock is necessary because there is not a lock daemon running locally yet...)
  
Actual results:

mount error during nfs root boot

Expected results:

root should be mounted nolock,ro from the server specified in the mkinitrd command, and then remounted after switchroot from the actual/live /etc/fstab

Additional info:

apparently the root_nfs option in the kernel isn't necessary.  Unless /dev/nfs is trying to somehow point to what the kernel mounted at boot.. but I don't think it is.

Comment 1 Rich Rauenzahn 2009-09-16 01:11:05 UTC
One other item that I need to still validate on other platforms, but I'm reasonably sure this is true --

The network drivers need to be loaded AFTER netname, or they don't come up:

echo "Loading mii.ko module"
insmod /lib/mii.ko
echo "Loading vmxnet.ko module"
insmod /lib/vmxnet.ko
echo Bringing up eth0
network --device eth0 --bootproto dhcp

This probably ought to be...

netname 00:0C:29:62:76:C8 eth0

echo "Loading mii.ko module"
insmod /lib/mii.ko
echo "Loading vmxnet.ko module"
insmod /lib/vmxnet.ko

network --device eth0 --bootproto dhcp

Comment 2 Rich Rauenzahn 2009-09-16 18:00:49 UTC
Update on the netname -- looks like having netname at all is what is messing up the driver load.  Commenting it completely out fixes the ethernet driver problem -- at least with pcnet32 under vmware.

It would be nice not to have netname in there at all as this makes each diskless server require its own initrd with its own mac address embedded in it!

Comment 3 David Cantrell 2010-07-02 03:13:23 UTC
The netname line is written out because your /etc/sysconfig/network-scripts/ifcfg-eth0 file has a HWADDR line.  Comment that line out to prevent mkinitrd from writing out the netname line.


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