PXE Boot - Linux server & OpenBSD client

12,679

Solution 1

I build the netkit tftp server, and this worked first time with my pxeboot file.

This tftp server is packaged as tftpd on debian/ubuntu, but doesn't seem to be packaged for fedora, which uses the tftp-hpa server.


This is the working config I used to boot the system.

#/etc/xinetd.d/tftp
service tftp
{
        disable = no
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/local/sbin/in.tftpd
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}

#/etc/dhcpd.conf
host longshot {
  hardware ethernet 00:0b:db:07:83:35;
  fixed-address 10.0.2.21;
  next-server 10.0.2.5;
  filename "pxeboot";
}

Since this was a diskless client, I needed bootparams and rarpd so the kernel could use the filesystem over nfs. This isn't needed to boot the ramdisk kernel (bsd.rd).

#/etc/bootparams 
longshot root=10.0.2.5:/export/longshot/root swap=10.0.2.5:/export/longshot/swap
10.0.2.21 root=10.0.2.5:/export/longshot/root swap=10.0.2.5:/export/longshot/swap

#/etc/sysconfig/rarpd 
OPTIONS="-e"
INTERFACE="eth0"

# /etc/ethers 
00:0b:db:07:83:35   10.0.2.21

# /etc/exports
/export/longshot 10.0.2.0/255.255.255.0(rw,no_root_squash,sync)

Solution 2

The 1st thing I've spotted was that you are using "-s /tftpboot" in xinetd.conf and adding the dhcpd.conf "root-path" option. Setting the "-s" option for tftpd means that is the "/" directory as seen for tftp client. So your dhcpd.conf should only have "filname /pxeboot", without the root-path option.

From "man tftpd":

-s

Change root directory on startup. This means the remote host does not need 
to pass along the directory as part of the transfer, and may add security.
When -s is specified, exactly one directory should be specified on the command
line. The use of this option is recommended for security as well as compatibility
with some boot ROMs which cannot be easily made to include a directory name 
in its request.

Solution 3

katriel has already given the answer i would have given, so i'll give some more generic advice instead...

NOTE: this does not answer your original question (getting the pxe client to boot at all), it addresses what to do AFTER that problem is solved.

i would highly recommend using gpxelinux.0 from the syslinux project instead of the pxeboot program you're using (which is probably an old version of syslinux' pxelinux program anyway).

don't be fooled by the name, gpxelinux.0 is a generic PXE bootstrap program which can be used to boot any operating system. I use it to boot linux, windows, clonezilla, and various floppy and CD images (mostly MS-DOS/Freedos images with some firmware update on a floppy - which beats the hell out of burning an update to CD or floppy and carrying it around to every machine).

One of the major advantages of gpxelinux.0 over other pxe boot programs is that it understands more than just the tftp protocol, so you can make it fetch kernels, initramfs and other compressed filesystems, and anything else by http or ftp rather than tftp. this is a LOT faster and, in my experience, a LOT more reliable. you still need a tftp server, because the actual gpxelinux.0 file and it's default cfg file still have to be served by tftp.

it also includes a handy command line option allowing you to manually override boot options (similar to what you can do with grub).

just switching to http for boot images almost eliminated the net booting problems i was having (all but some minor config details like path/filename)

Solution 4

Have a look at the howto I wrote several years ago. Although it doesn't describe booting BSD, it does describe the entire process in quite a lot of detail. Perhaps this helps you in finding out what went wrong.

Solution 5

The first thing I'd be trying is to tcpdump the tftp traffic, to see if the transfer is actually completing successfully; if it is, then presumably the client doesn't like the pxeboot file -- either it's corrupted, the wrong architecture, or otherwise not suitable.

Share:
12,679

Related videos on Youtube

AWesley
Author by

AWesley

Andrew mostly works with Debian/Ubuntu servers, but is a big fan of OpenBSD and Fedora. Andrew doesn't like Solaris.

Updated on September 17, 2022

Comments

  • AWesley
    AWesley over 1 year

    I have an old machine here I'm trying to setup as a diskless client running OpenBSD, booting from my fedora 10 machine.

    I've setup tftp and dhcp and both appear to be correct, yet the client just timesout trying to load the pxeboot.

    # /etc/xinetd.d/tftp 
    service tftp
    {
        disable = no
        socket_type     = dgram
        protocol        = udp
        wait            = yes
        user            = root
        server          = /usr/sbin/in.tftpd
        server_args     = -s /tftpboot -vv
        per_source      = 11
        cps         = 100 2
        flags           = IPv4
    }
    
    [root@blueblock ~]# ls -la /tftpboot/
    total 12100
    drwxrwxrwx  2 root root    4096 2009-07-25 03:12 .
    drwxr-xr-x 26 root root    4096 2009-07-25 02:41 ..
    -rwxrwxrwx  1 root root 6696212 2009-02-28 22:41 bsd
    -rw-r--r--  1 root root 5592688 2009-02-28 22:41 bsd.rd
    -rwxrwxrwx  1 root root   53276 2009-02-28 22:41 pxeboot
    
    # /etc/dhcpd.conf
    host longshot {
      hardware ethernet 00:0b:db:07:83:35;
      fixed-address 10.0.2.21;
      next-server 10.0.2.5;
      option root-path "/tftpboot/";
      filename "pxeboot";
    }
    

    I can connect to the tftp server from other machines on the network and succesfully get the pxeboot file.

    The client is getting the right ip address settings, and i can see it connecting to the tftp server.

    Jul 25 04:11:51 localhost dhcpd: DHCPDISCOVER from 00:0b:db:07:83:35 via eth0
    Jul 25 04:11:51 localhost dhcpd: DHCPOFFER on 10.0.2.21 to 00:0b:db:07:83:35 via eth0
    Jul 25 04:11:53 localhost dhcpd: DHCPREQUEST for 10.0.2.21 (10.0.2.5) from 00:0b:db:07:83:35 via eth0
    Jul 25 04:11:53 localhost dhcpd: DHCPACK on 10.0.2.21 to 00:0b:db:07:83:35 via eth0
    Jul 25 04:11:53 localhost in.tftpd[1457]: RRQ from 10.0.2.21 filename pxeboot
    Jul 25 04:11:53 localhost in.tftpd[1457]: tftp: client does not accept options
    Jul 25 04:11:53 localhost in.tftpd[1458]: RRQ from 10.0.2.21 filename pxeboot
    

    Is there something simple I've missed here? Or is there anything else I can do to try diagnose the problem.


    Edit: I put the pxeboot and bsd files on an openbsd machine I had, and changed the next-server to this machine's ipaddress, enabled it's tftp server, and the client booted first time.

  • Alnitak
    Alnitak almost 15 years
    yup, dump the "root-path" option from dhcpd.conf
  • AWesley
    AWesley almost 15 years
    Yea, that's what I thought too, but it wasn't working anyway so I figured I'd try it. I removed it now, hasn't worked though.
  • katriel
    katriel almost 15 years
    Look at the next answer. Seems you have the pxeboot file, but you're missing the configuration files that go with it.
  • AWesley
    AWesley almost 15 years
    It's a great howto - I remember reading that previously when I was trying to set up a pxe install of fedora. Didn't spot anything though.
  • AWesley
    AWesley almost 15 years
    The openbsd pxeboot doesn't need any configuration files
  • cas
    cas almost 15 years
    which version of netkit tftpd did you use? AFAIK, the netkit tftpd (up to 0.17 at least) doesn't support PXE, you have to use atftpd or tftpd-hpa instead. i use atftpd with no problems. you also need a PXE daemon on the network, such as the one at kano.org.uk/projects/pxe
  • cas
    cas almost 15 years
    actually, whether you need a PXE daemon or not depends on which pxe boot loader you're using. some need it, some don't. the syslinux ones don't need it.
  • AWesley
    AWesley almost 15 years
    I used v0.17, which is the same version in ubuntu hardy heron (and, presumably later releases). I didn't use any pxe daemon (in fact, I'd never heard of such a thing). I used rarpd and rpc.bootparamd to allow the openbsd kernel to mount it's filesystem over nfs because I wanted to build a diskless client, but those wouldn't have been needed if I just wanted to use a ramdisk kernel for an install/rescue shell.