The mount that is currently shipped with rawhide doesn't work well with netboot. There are lots of complaints about out-of-range access to the ram drive, and mounting the nfs root fails without specifying the problem. I've concluded that the problem is with the mount command as the only change needed to get a working initrd is to steal 'mount' from an older machine (FC4 in my case).
I am seeing this too -- after upgrading to FC6 on both server and diskless client mount is having severe problems. Disclaimer: I'm using a homegrown diskless setup on the client which has a slightly modified FC userland. However, my investigations so far indicate that this is a legitimate FC bug. The symptom I am seeing is that the boot pauses for several minutes after printing the "Remounting root filesystem in read-write mode". Eventually the system does boot but root ends up being mounted twice and the overlaid one is in read-only mode, causing lots of things to fail. I added some debugging to /etc/rc.d/rc.sysinit and found that the line that it's pausing on: # Enter mounted filesystems into /etc/mtab mount -f / That ought to be pretty innocuous -- the "-f" flag after all SHOULD prevent any actual mount from happening. This doesn't seem to work on NFS mounts, however. Running that mount command under "strace -f" I see: execve("/sbin/mount.nfs", ["/sbin/mount.nfs", "MY-SERVER:/MY/PATH", "/", "-o", "rw"], [/* 18 vars */]) = 0 So it seems that when /bin/mount calls /sbin/mount.nfs it forgets to pass along the "-f" flag, causing breakage. I verified that calling mount.nfs with "-f" seems to work just fine. I suspect this might be the root cause of the problem
Can we get some action on this?
Hellooo? netboot is completely broken, so I would expect a little more attention to this bug.
Are you really sure that your initrd.img actually contains the /sbin/mount.nfs binary at all ? In my case the "system-config-netboot-0.1.41-1.FC6.noarch" package is forgetting (?) to copy/include the /sbin/mount.nfs into the initrd.img and therefore you get a cryptic mount error while the diskless client tries to mount the root-device from the NFS-server. By making the one line change below, the NFS-mount succeeds just fine (ie. copy the /sbin/mount.nfs into initrd.img) This broke in FC5 and the last kernel which worked without this modification as 2.6.17-2187 (in my case at least) Regards, Tomi Orava --- /usr/share/system-config-netboot/diskless/updateDiskless 2007-01-21 20:46:42.000000000 +0200 +++ /usr/share/system-config-netboot/diskless/updateDiskless.mod 2007-01-21 17:48:43.000000000 +0200 @@ -114,7 +114,7 @@ done; #/bin/cp "$ROOT"/usr/share/hwdata/pcitable $MNTPOINT/usr/share/hwdata/ || die; # disklessrc now uses modules.pcimap, not pcitable -BINS="/sbin/busybox.anaconda /sbin/insmod /sbin/modprobe /sbin/rmmod /sbin/dhclient /bin/bash /bin/mount /sbin/route /sbin/ip /usr/bin/expr /sbin/lspci /sbin/ifconfig /sbin/consoletype /sbin/pivot_root /bin/hostname /bin/domainname /usr/bin/host" +BINS="/sbin/busybox.anaconda /sbin/insmod /sbin/modprobe /sbin/rmmod /sbin/dhclient /bin/bash /bin/mount /sbin/mount.nfs /sbin/route /sbin/ip /usr/bin/expr /sbin/lspci /sbin/ifconfig /sbin/consoletype /sbin/pivot_root /bin/hostname /bin/domainname /usr/bin/host" # Set up links to all the busybox functions - # may be different for different versions of busybox! if [ ! -e $ROOT/sbin/busybox.anaconda ]; then
Now that's a very plausible explanation. I'll test it later tonight.
Works like a charm! Please apply ASAP!
/sbin/mount.nfs is only the beginning... it goes over, mounts nfs root, there appear some error which scrolls quickly, then it seems to lock after selinux prints on screen... after a while I get some message on 'vfs ... lockmanager' (don't remember well).
This is the same bug as 227903 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227903 The workaround that works for me is make that mount -f -i /.
Helloooo? Could we have this fixed?
fixed in 0.1.42