5

(This is my first post so hopefully I'm formatting it correctly). I've added in as much information as possible without being TL:DR.

My basic issue is that I hit walls when trying to do a PXE diskless boot to an NFS server (CentOS 6.7 or CentOS 7). I have tried various things and I can't seem to replicate the success that I initially had with a CentOS7 server and client. Every time I follow my notes now I'm getting nowhere.

The most common errors I am getting (depending on what initrd.img file or initramfs*.img I use) is

A ticker of *** that shows a text-based progress bar and the message

A start job is running for dev-nfs.device (xx s / 1min 30s)

Then it times out and says

Timed out waiting for device dev-nfs.device
Dependency failed for File System Check on /dev/nfs
Dependency failed for /sysroot
Dependency failed for Initrd Root File System
Dependency failed for Reload Configuration from the Real Root

The above error occurs when I copy (any of) the initramfs-3.10.*.img from /boot/ to the PXE image location.

If I try to generate a new initramfs image file from dracut, it also throws the above error.

dracut initramfsnew.img

It could be that I either don't know how to generate a proper initramfs or I'm really not understanding the initrd.img and initramfs functions. I believe that the timeout is happening because the NFS drivers are not yet loaded at that stage of the boot process so the client cannot properly mount the NFS share. The reason I think this is because I've booted up the exact same PXE client into its local OS and manually mounted the NFS share and it works 100%, so the NFS share is active, and works. I believe that I have the wrong understanding of how initrd.img and initramfs*.img work.

If I download initrd.img from a CentOS mirror site, I get 90% of the way there and then the error changes to

No /sbin/init trying fallback

I am now in a (for want of a better term, half-loaded) shell that gives me basic navigation of the NFS share. I can go to the /home/disklessuser/ and even write to the NFS or read new files from the NFS (tested simple 'touch' commands on both server and client). What seems to be missing, primarily, is the login option in this instance, as well as a proper boundary for the directories (i.e. I seem to be logged in as root at this point in the boot-up).

The basic configuration is pretty standard AFAIK:

/var/lib/tftpboot/pxelinux.cfg/default contains (I've left out the bits that I know work - the PXE works and points to the right image etc):

menu label ^1) CentOS 7
  kernel /images/centos7/vmlinuz
  append root=/dev/nfs initrd=/images/centos7/initrd.img nfsroot=10.10.10.10:/srv/nfs/diskless/images/centos7/root rw selinux=0

I've tried variants of the above, like replacing the initrd.img with initramfs3.10*.img (various versions located in the server's /boot/) and have tried adding in parameters like

ip=dhcp

because dracut documentation suggests this will tell it to get the nfsroot path from DHCP instead of the PXE menu.

I've currently got my DHCP configured as so:

subnet 10.10.10.0 netmask 255.255.255.0 {
   option broadcast-address 10.10.10.255;
   option routers 10.10.10.1;
   range 10.10.10.100 10.10.10.150;

   next-server 10.10.10.10;
   option root-path "10.10.10.10:/var/lib/tftpboot";
   filename "pxelinux.0";
}

Possibly this is conflicting with the NFS share prescribed in the PXE menu?

Anyway, I would appreciate any guidance - perhaps most pertinently for me is what to do about the initrd or initramfs. I presume there's not much different about both, but how would one generate a new one that should (hopefully) include basic network drivers to allow an NFS mount?

Secondly, why is /sbin/init missing when I'm near as heck at the solution when I use the initrd.img stored in the CentOS mirror directory under /os/x86_64/isolinux ?

Brattex
  • 51
  • 1
  • 2

2 Answers2

0

you can boot CentOS-7.0-1406-x86_64-DVD.iso with HTML instead of NFS with

kernel   = /NWA_PXE/$HEAD_DIR$/images/pxeboot/vmlinuz 
append   = initrd=/NWA_PXE/$HEAD_DIR$/images/pxeboot/initrd.img root=live:http://$IP_BSRV$/$HEAD_DIR$/LiveOS/squashfs.img ksdevice=bootif repo=http://$IP_BSRV$/$HEAD_DIR$/ 
ipappend = 2

source Serva

you can easily change it to NFS if really needed

Pat
  • 3,339
  • 2
  • 16
  • 17
  • 1
    Thanks for the tip but the problem with that solution is that it isn't tapping into an existing pre-installed diskless solution. I'm trying to configure an offline copy of a live system that any number of clients can boot up through PXE and run as if it is a live DVD boot. This approach will start a new installation every time, instead of booting up a pre-configured system instead. For example: I want to have a node boot straight into CentOS7 with NMAP installed, for example. – Brattex Mar 16 '16 at 18:23
  • what I gave you can boot a live system as you want... – Pat Mar 16 '16 at 23:03
0

Based on your informations it is hard to say what exactly causes the timeout. A few suggestions to try:

  • Boot the system with selinux disabled, using rd.brak to enter the initrd pre-boot.
  • Check what causes the timeout. Verify if the network driver is loaded, and dhcp assignment worked. See if a manual nfs mount would succeed. Try to manually start the dev-nfs.device.
  • Verify your steps against various documentations, e.g http://www.iram.fr/~blanchet/tutorials/diskless-centos-7.pdf
  • Try to fully understand the boot process and creation of initramfs files.

Just some words on the booting of an instance:

  • vmlinux/vmlinuz contains only the kernel image with drivers
  • initramfs contains a basic root file system which is fully loaded to ram
  • Typically (on desktop and server systems) the initramfs responsibilities are preparing the kernel (e.g loading relevant kernel drivers), mounting the root file system (rhel 7 usually the real root fs will be in /sysroot after rd.break), and then handing boot over to the real root filesystem.
  • In this case, I assume that someting goes wrong at preparing the kernel, it looks like domething is missing or cannot be found inside the initramfs. eventually the nfs driver modules.
hargut
  • 3,848
  • 6
  • 10