SOLVED Overclockix diskless system

[Johnny5]

So I got bored the other day and set myself up a PXE boot server with some system utilities and a couple of Linux distros like Parted Magic and Arch. It's a slightly different setup than most tutorials as I have PFSense setup as the DHCP server and it redirects the clients to the PXE server which is CentOS 6.4 running on an old broken laptop (I mean physically broken. I've removed the built in display and keyboard since they had malfunctioned). Everything is working other than its not the greatest network speed but that isn't a big deal to me since this is more for learning. So then I decided Overclockix would be a good distribution to try this out on.

I cannot get it to work. First attempt I thought maybe I'd get lucky and just took the .iso file and pulled vmlinuz, initrd.img and the squashfs and set the pxelinux to boot with something like

LINUX images/overclockix/live/vmlinuz
INITRD images/overclockix/live/initrd.img
APPEND root=/dev/nfs ip=dhcp noipv6 nfsroot=<localip>:/nfs/overclockix netboot=nfs
IPAPPEND 3

But it became clear quickly that it was not receiving an IP. After studying how Arch was doing it, my guess was despite that the initramfs was built with auto and includes the nfs script it was missing something to support netbooting.

So I downloaded the live-build auto/config and config files from GIT and have been trying to build it with root NFS support. I've made several attempts at this so far changing things like --boot-images netbook and the like and have gotten so far as I know the initramfs is receiving an IP. But it still gets stuck on mounting the NFS share. It just keeps looping say device or resource is busy. I've checked and the NFS share can be mounted and its not SELinux or a firewall issue. I'm rebuilding the image now with --interactive shell enabled so hopefully I can drop to busybox and verify it can be mounted manually in the initramfs. NOW THE ACTUAL QUESTION:

I want to change /etc/initramfs-tools/initramfs.conf from
BOOT=local to BOOT=nfs

I've been studying the live-build documentation (this is my first time I've even messing with Debian before) and I'm not sure how to position my changes in the auto files correctly. From what I've understood it looks like if I write a .chroot file with something like

sed 's/BOOT=local/BOOT=nfs/' -i /etc/initramfs-tools/initramfs.conf

its going to be executed AFTER the filesystem is built which I assume means the initramfs will also have already been built. Does anyone know how to do this in the auto files? I'd rather do that than unsquash the filesystem, chroot it, change the initramfs.conf and update-initramfs, then repack. But in all the documentation I haven't found an explanation on how to change this that is clear to me.

Also if I've just missed something obvious and made an enormous project out of a very simple solution that would be great to hear as well

Thank you to anyone who could offer any suggestions.

 

[mbentley]

Hey, you're in luck! I've done PXE booting with Overclockix Here are some snippets from my configuration file. I have my PXE boot configured a bit differently as this is on a Microsoft Windows Deployment Server but the idea is similar as it steals a number of files to provide a chainloaded PXE boot environment where it can load Linux distros and still provide WDS. I have my Overclockix build server configured to share via NFS (which is 192.168.1.105).

#---
LABEL overclockix
MENU LABEL overclockix i386
kernel \Linux\overclockix\i386\vmlinuz
append initrd=\Linux\overclockix\i386\initrd.img netboot=nfs boot=live config nfsroot=192.168.1.105:/srv/nfs/overclockix_i386 persistent quiet splash
#---
LABEL overclockix
MENU LABEL overclockix amd64
kernel \Linux\overclockix\amd64\vmlinuz
append initrd=\Linux\overclockix\amd64\initrd.img netboot=nfs boot=live config nfsroot=192.168.1.105:/srv/nfs/overclockix_amd64 persistent quiet splash

As you can see, this is just the contents of the .iso file pre-packaging so extracting that from the .iso file should not be a problem.

root@ocxbuild2:/srv/nfs# ll overclockix_i386/ overclockix_amd64/
overclockix_amd64/:
total 12
drwxr-xr-x 2 root root 4096 May 20 14:53 isolinux
drwxr-xr-x 2 root root 4096 May 20 14:53 live
-rw-r--r-- 1 root root 1164 May 20 14:53 md5sum.txt

overclockix_i386/:
total 12
drwxr-xr-x 2 root root 4096 May 20 14:05 isolinux
drwxr-xr-x 2 root root 4096 May 20 14:05 live
-rw-r--r-- 1 root root 1164 May 20 14:05 md5sum.txt

Hopefully this helps you out. Let me know if I can be of further assistance!

 

[Johnny5]

Thanks for the response! I think my problem is my DHCP and PXE servers are on different machines. Last night after building a custom system using live-build I managed to get to the point where I dropped into the initramfs sh shell and I could verify I had mounted my nfs share on root, but didn't manage to figure out where in the init scripts or hooks it mounted the squashfs and just trying to do "exec init" or "exec switch_root blah blah" surprisingly caused a kernel panic So reading your response I've gone back to the to the normal iso.

Running with debug=1 on and this in my pxelinux .cfg

LABEL Overclockix amd64
        LINUX images/overclockix/live/vmlinuz
        INITRD images/overclockix/live/initrd.img
        APPEND netboot=nfs boot=live config nfsroot=192.168.1.10:/srv/nfs/overclockix debug=1 noipv6 ip=dhcp
        IPAPPEND 3

It gets stuck at IP-CONFIG dhcp request and poops out with eth0: no IPv6 routers present. I've removed the noipv6 ip=dhcp and IPAPPEND lines and this doesn't fix it.

Arch did the same thing to me until I added the IPAPPEND append line which as far as I understood it was suppose to aid the client machine in remembering its IP address and gateway. I'm not sure if I need to direct PFSense with extra args in the DHCP setup, right now it just says where the pxelinux.0 file and tftp server is located.

Looking at tcpdump the client is doing something with udp on port 47031 with the PXE server and I'm not seeing any common services defined for that port.

I'm sure I'm going to discover this is some enormously stupid configuration error I've done but at least I got to learn how the live-build system works and some other things.

 

[mbentley]

Hmm, that does sound like the client machine is not getting an IP from the DHCP server. On my configuration, DHCP and the PXE server are different. When I did that, I had to set option 66 & 67 on my DHCP server. I do not know if that is something that is Windows DHCP specific or not.

066 Boot Server Host name     192.168.2.121
067 Bootfile Name     boot\x86\wdsnbp.com

Option 66 is specifying my PXE server, option 67 is specifying the path to the boot file. Of course I doubt that any of that is going to matter if you are not getting an IP address.

 

[Johnny5]

That is what I have on PFSense. next-server is 192.168.1.10 and the file is pxelinux.0. I'm stumped, it is getting an IP though because it loads the kernel and the initramfs but then for some reason loses everything while the initramfs does its job. I was just watching tcpdump again, and got this. 192.168.1.168 is the client, and the udp packets go on forever and are where the kernel and initramfs load. Right after that when the initramfs is working the PXE server gets the ARP messages.

15:20:05.634847 IP pxesrv.home.39940 > 192.168.1.168.49170: UDP, length 1412
15:20:05.636817 IP 192.168.1.168.49170 > pxesrv.home.39940: UDP, length 4
15:20:05.636903 IP pxesrv.home.39940 > 192.168.1.168.49170: UDP, length 1262
15:20:05.639059 IP 192.168.1.168.49170 > pxesrv.home.39940: UDP, length 4
15:20:08.828759 ARP, Request who-has 192.168.1.168 tell pxesrv.home, length 28
15:20:09.828759 ARP, Request who-has 192.168.1.168 tell pxesrv.home, length 28
15:20:10.828737 ARP, Request who-has 192.168.1.168 tell pxesrv.home, length 28

and then the client locks up with IP-CONFIG trying to setup eth0. I was thinking about trying to change the initramfs scripts to use busybox's dhcp client but I'm sure I shouldn't have to, as this is most likely something I'm doing wrong.

I am not a networking guy so making complete sense of this is difficult for me. But it looks like perhaps the PXE server is the one that does not recognize the client? As I mentioned this same thing happened with Arch without the IPAPPEND line. So I'm sure there is a solution. I have Gentoo, Parted Magic, Debian (the installers) and Arch all setup this way, but Parted Magic has no NFS share. So I'm stumped and not finding a lot of decent documentation on the problem with PXELinux.

 

[Johnny5]

Okay reading through this
http://frank.harvard.edu/~coldwell/diskless/

This PXE ROM is receiving the IP address but the kernel isn't recognizing it afterwards. I just removed all append lines, dropped to busybox, ran

ip link set eth0 up

and it recognizes the hardware, has the right MAC. But then if I run ipconfig eth0, it freezes and if I use busybox's dhcp client it says it gets the IP 192.168.1.168 but then if I do ifconfig eth0, it has no ipv4 address.

This is gonna bug me if I can't figure it out.


****SOLVED (kinda)
Okay figured it out. I've been testing inside a VM for all of this, and that seems to be the problem. I just went and booted my netboot into it just fine. I'm not sure why VirtualBox only has an issue here though and works with other distros. And yes I am configured for bridged adapter

Thank you for the help.

********MORE SPECIFIC
Its because I'm using bridged adapter on a laptop through my wireless card. Ethernet, bridged works. I'd really like to know why this configuration will work on some kernels and not others. On Gentoo I had problems till I compiled e1000 in. But reading the debug output from the Debian initramfs, when it brings eth0 up to request an IP it labels to the dev as e1000, so that doesn't seem to be the problem.

 

[Stratus_ss]

Virtualbox requires you to use PCnet-FASTIII network adapter in order to network boot.

There was some bug report from ages ago.

I would have chimed in immediately if I knew you were using virtualbox. Since I netboot my vms often I have gotten very familiar with this issue

 

[mbentley]

Ah, using VirtualBox does make a bit of a difference I use it as well to do my testing to save wear and tear on flash drives as well as using PXE boot. Glad to hear that you were able to get it to work!