# No NFS kernel module in latest minimal install ISO?

## kamikaze1

Hi,

I'm trying to setup a pxelinux boot server that serves out multiple distro installs on the network.

Basically my setup is like this (I will paste configs after the description):

deimos is my DHCP/TFTP/NFS server

client1 is the client I'm trying to install to

deimos mounts different distribution install ISOs in a directory, which are NFS shared, and then bind mounted back to /var/lib/tftpboot/<distro>/x86/mnt so tftpd-hpa can access them for the kernel and initrd (as it's chroot is /var/lib/tftpboot)

I'm setting kernel params in the pxelinux.cfg to attempt to NFS mount the share, and then switch to the squashfs image, I am not 100% sure this works yet, but based on other forums I've read, this is possible.

deimos correctly gives an IP, and serves out the kernel, and initrds of the different distros via a menu. The point I'm getting to, is just attempting to mount the NFS share. I'm finding this to be a real issue.

I'm using install-x86-minimal-20120710.iso, but have used the previous install-x86-minimal-20120703.iso also. I've had to modify the provided gentoo.igz (initrd) that came with the ISO to include a realtek network card kernel module to even get it to detect my network card. I did this by temporarily mounting the squashfs image, getting the 8139too.ko and 8139cp.ko from there, extracting the gentoo.igz and recreating it with cpio and gzip, then moving it to /var/lib/tftpboot/gentoo/x86/initrd

The relevant pxelinux.cfg that serves the gentoo install is:

```

LABEL gentoo-install-x86-minimal-nfs 

   MENU LABEL Install Gentoo x86

   KERNEL gentoo/x86/vmlinuz 

   APPEND ip=dhcp loop=/image.squashfs root=/dev/ram0 init=/linuxrc looptype=squashfs doscsi initrd=gentoo/x86/initrd console=tty1 vga=791 nfsroot=192.168.4.1:/srv/dists/gentoo/x86/mnt,vers=3 cdroot=1 real_root=/dev/nfs 

```

On bootup, client1 gets an IP, shows the pxelinux menu, I select 'Install Gentoo x86' and it successfully retrieves vmlinuz (symlinked to the kernel bind mounted at gentoo/x86/mnt/isolinux/gentoo), and then successfully retrieves my modified initrd. It begins booting, and starts loading all the modules, and then gets this:

```

--snip--

Scanning for 8139too...8139too loaded.

Scanning for 8139cp...8139cp loaded.

Scanning for sha256_generic...sha256_generic loaded.

>> Activating mdev

>> Making tmpfs for /newroot

>> Determining root device...

>> Mounting root...

>> Attempting to mount NFS CD image on 192.168.4.1:/srv/dists/gentoo/x86/mnt with options ro,nolock,rsize=1024,wsize=1024,vers=3

mount: mounting 192.168.4.1:/srv/dists/gentoo/x86/mnt on /mnt/cdrom failed: Invalid argument

!! NFS Mounting failed. Is the path corrent ?

>> Determining looptype ...

!! Invalid loop location: /image.squashfs

!! Please export LOOP with a valid location, or reboot and pass a proper loop= ...

!! kernel command line!

```

and drops me to busybox.

In here I can see that:

1. My network card shows up, and the 8139too module is loaded, however it has not retrieved an IP.. don't know why. This previously worked on 20120703.iso, though I don't think I had the ip=dhcp option passed in then?

2. I can set an IP and ping my server, no problem.

3. At this point if I try and mount the NFS share using this or any kind of variant of it (e.g. different options):

mount -t nfs -o ro,nolock,vers3 192.168.4.1:/srv/dists /mnt/cdrom

I always just get "mount: mounting 192.168.4.1:/srv/dists on /mnt/cdrom/ failed: Invalid Argument" back from mount. I also get no output from dmesg showing anything further. Using mount -vv doesn't give me anything useful either.

4. Doing the same command on a different, booted system (Arch) successfully mounts the NFS share.

I'm starting to think that NFS isn't compiled into this kernel, and I can't see any nfs kernel modules available in the squashfs image to copy across to a modified initrd? Is this the case (and how do I check for compiled-in modules rather than loadable modules?) or am I doing something stupid? Perhaps this isn't even a possible thing to do?

My /etc/exports on deimos:

```

# /etc/exports: NFS file systems being exported.  See exports(5). 

/srv/dists 192.168.4.0/24(crossmnt,insecure,insecure_locks,async,no_subtree_check,ro,no_root_squash)

```

mount | grep gent on deimos shows:

```

/dev/loop2 on /srv/dists/gentoo/x86/mnt type iso9660 (ro)

/srv/dists/gentoo/x86/mnt on /var/lib/tftpboot/gentoo/x86/mnt type none (ro,bind)

```

And it shouldn't matter, but deimos is an ARM box running Ubuntu 9.04. 

Any help ?? Thanks for reading all of this...

----------

## richard.scott

There is no NFS support in any recent Genkernel booted system including the LiveCD's

I tried getting it fixed:

https://bugs.gentoo.org/show_bug.cgi?id=389755#c20

NFS Support was removed due to a bug that nobody seems to want to fix   :Rolling Eyes: 

You need to find a CD using genkernel-3.4.16 for it to work   :Shocked: 

Rich

----------

## John R. Graham

Have you tried SystemRescueCD?

- John

----------

## richard.scott

 *John R. Graham wrote:*   

> Have you tried SystemRescueCD?
> 
> - John

 

I can only speak for myself here as kamikaze1 may have other reasons for pxe booting a livecd image. 

I want to create my own NFS bootable LiveCD to use in part of a custom storage solution. i.e. To increase my available storage I plug in a brand new server, boot it via PXE and it merges its self into my storage cluster automatically... I currently have a working system that is getting older by the day as I'm unable to upgrade it due to this limitation of Gentoo's Genkernel   :Embarassed: 

I am considering moving distro because of it which is a shame as I love gentoo and have it on every server I own!

Rich

----------

## krinn

Rich,

```
+  08 Oct 2011; Fabio Erculiani <lxnay@gentoo.org> defaults/initrd.defaults,

+  defaults/initrd.scripts, defaults/linuxrc:

+  Do not hardcode /mnt/cdrom path across the whole code, use CDROOT_PATH

+  instead. At the same time, mount cdrom into /mnt/cdrom instead of

+  /newroot/mnt/cdrom (which is now just a bind mount), this avoids

+  losetup to expose unavailable paths inside the live system, breaking

+  mkfs.btrfs (next upstream version, which does silly things with

+  /proc/mounts).

```

Breaking a stable feature to fix a bug from an upstream version of an immature fs is not really a good step forward, why didn't you ask a rollback from this update ?

----------

## richard.scott

Hi krinn,

AFAIK the problem is with compiling busybox with NFS support rather than anything directly to do with genkernel:

http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=commitdiff;h=b977d66940fdbbe552bb735a54141b69da873b5b

Rich.

----------

