Need help getting bootp to work

Using IPFire 2.27 (x86_64) - Core Update 167

Want to install Slackware 15 via PXE on clients on the green network, with installation media on local machine (not the router):

IP addrs:
router (ipfire) 192.168.2.1
PXE client 192.168.2.3
installation media on 192.168.2.6

wanting to connect to the installation media via NFS

Can anyone help with that?

maybe this wiki page will help wiki.ipfire.org - Tftpd - IPFire as a Server

Thank you for the suggestion. I have looked at the page, but it was to general. I followed it as best I could and the following is what I did.

I set up the default file in pxeboot.cfg like this:

default slack15
prompt 1
timeout 10

label slack15
kernel /huge.s/bzImage
append initrd=initrd.img vga=0x314 \
install=nfs://192.168.2.6/mnt/slackware/15.0/slackware64

label local
LOCALBOOT 0

================================

The contents of the /var/tftpboot directory:

drwxr-xr-x 2 root root 4096 May 24 17:26 huge.s/
-rw-r–r-- 1 root root 50455140 Feb 2 03:21 initrd.img
drwxr-xr-x 2 root root 4096 May 24 17:32 memdisk/
-rw-r–r-- 1 root root 26941 May 24 2016 pxelinux.0
drwxr-xr-x 2 root root 4096 May 25 20:44 pxelinux.cfg/
-rw-r–r-- 1 root root 92 May 23 23:45 tftpd.remap

================================

and restarted the tftpd service by executing:

/etc/rc.d/init.d/tftpd restart

Which runs tftpd without the remapping (-m /var/tftpboot/tftpd.remap -vvv)

And at the bottom of the page you recommended, it says to set an appropriate link such as: ln -s /mnt/xxxx/tftpboot /var/tftpboot

The reason for that is not made clear, but I assume it is to link a directory for the kernel to sent to the pxe client to run as its kernel. With that assumption, I placed the directory huge.s which contains the file bzImage, which the Slackware kernel.

================================

Tried to PXE boot the client, only to get the same result as before:

================================

The following is salient part of the /var/ipfire/dhcp/dhcpd.conf file:

deny bootp; #default
authoritative;
ddns-update-style none;
subnet 192.168.2.0 netmask 255.255.255.0 #GREEN
{

pool {
range 192.168.2.2 192.168.2.250;
}

option subnet-mask 255.255.255.0;
option domain-name “my.domain”;
option routers 192.168.2.1;
option domain-name-servers 192.168.2.1, 74.40.74.40;
option ntp-servers 192.168.2.1;
next-server 192.168.2.1;
filename “pxeboot.0”;
default-lease-time 86400;
max-lease-time 172800;
} #GREEN

host fix0 # maggie
{
hardware ethernet 00:1b:fc:6e:c2:0e;
fixed-address 192.168.2.2;
}

host fix1 # snowball
{
hardware ethernet d0:50:99:5c:35:a7;
fixed-address 192.168.2.3;
}

(the remainder of the file is additional hosts)

The part of that file that I find suspicious is the very first line:
deny bootp;

It suggests to me that the dhcpd server will not allow bootp to happen, but I have found no way to change it except by manually editing it to say, “allow bootp;”, but doing that, then negates doing any further modifications of the DHCP setting using the web interface, because doing so completely rewrites the .conf file starting with the “deny bootp;” statement.

Does anyone see any errors in my attempt?
Got any suggestions where to go from here?

At the conclusion the file pxelinux.0 must be registered in IPFire under DHCP-server in the field file
you need to specify next server and filename in the DHCP Server settings.

See this thread, PXE file and server

5 Likes

bootp is not needed for the tftpd based pxe approach in the IPFire wiki.

If you need to use bootp then you can enable it on the dhcp WUI page. There is a checkbox labelled “Allow bootp clients:” for each of the Green and Blue dhcp sections so that bootp can be enabled by subnet.

In subnet definition section of my dhcpd.conf, near the bottom of the section are the two statements:

next-server 192.168.2.1;
filename “pxeboot.0”;

Is that representative of what you were referring to. That information was listed at the bottom of the top DHCP settings section (I believe as a global setting).

Those settings also appear in each of fixed leases section for specific hosts. I’ve tried populating those fields in both the global and the fixed leases combined as well as each individually without success either way. Do you know which method is preferable? Also, in the fixed leases section, there is also a “root path:” field. Is there any where to look for information on the difference between the two sections, and why one has the “root path:” field and the other does not?

Adolf, can you expand on that concept a little more? I thought that pxe was just one portion of the bootp process.

I did find that “Allow bootp clients:” check box, and checking it did add an “allow bootp;” statement to the bottom of the subnet definition. Even with that checked, though, I’m still getting the same result at the pxe client.

Thank you …

No. bootp was an earlier version of PXE but it had some limitations and difficulties to set up all the required parts. PXE was developed as a replacement for bootp with the idea to remove the earlier limitations and make setup easier.
EDIT: This link may help explain the history. https://en.wikipedia.org/wiki/Preboot_Execution_Environment

With regard to the problems of the client not finding the file I can’t help you on that as PXE is not something i have had a go at yet, although it is on my list of things to explore with my vm testbed.

I am sure that there will be other people who have experience with using the PXE/tftpd combination on IPFire and will be able to help.

2 Likes

Adolf, thank you for the reply. I’m looking forward to further assistance using the PXE/tftpd combo. Again, thank you for the assistance you provided …

@mr_ckw I managed to get PXE to boot ubuntu18.04 from ipfire.

  • On ipfire, only two things needed, next-server 192.168.1.15 and filename pxelinux.0

  • next-server is 192.168.1.15 Installed tftpd-hpa, nfs-kernel-server. I made /netboot/{nfs,tftp} dirs, mounted the ubuntu18 iso and extracted components. My pxelinux.0 has a diff size that what you listed.

  • connected a laptop to boot from network, the request went to ipfire which then sent it to 192.168.1.15 looking for pxelinux.0 and it gave me the pxelinux.cfg/default menu as I defined it.

ls -l /netboot/tftp
total 408
drwxrwxrwx 4 tftp tftp   4096 May 26 20:09 ./
drwxrwxrwx 4 root root   4096 May 26 13:11 ../
-rw-r--r-- 1 root root 120820 May 26 20:09 ldlinux.c32
-rw-r--r-- 1 root root 176044 May 26 20:09 libcom32.c32
-rw-r--r-- 1 root root  24708 May 26 20:09 libutil.c32
-rw-r--r-- 1 root root  43140 May 26 20:06 pxelinux.0
drwxr-xr-x 2 root root   4096 May 26 13:44 pxelinux.cfg/
drwxrwxrwx 2 root root   4096 May 26 13:14 u18/
-rw-r--r-- 1 root root  28176 May 26 20:09 vesamenu.c32

I will try with slackware 15 tomorrow.

5 Likes

I found some links about Slackware network installation, maybe they will be helpful:

https://wiki.alienbase.nl/doku.php?id=slackware:pxe

ftp://slackware.osuosl.org/pub/slackware/slackware-current/usb-and-pxe-installers/README_PXE.TXT

https://docs.slackware.com/slackware:pxe_install

Greetings

Thank you very much @tphz for giving the links to the Slackware network installation. So far, it seems that instructions are present in a very user-friendly manner. However, let me follow them before giving a final conclusion.

1 Like

Paul, Your clarification of my misunderstanding of the difference between bootp and PXE was, for me, very enlightening. The message you sent me regarding your experience with the Arizona Linux Group helped me focus on getting to the core issues I was having.

Certainly, I wished the information was more informative on the basics of what & how pxe worked, but, unfortunately the Ubuntu information was more directed at running scripts that did the work in Ubuntu without really telling what it was actually doing. As a Slackware devoted user (I’ve been using it since it was called SLS, before it became generally known as Slackware), Slackware doesn’t employ dnsmasq so I was unaware of what it was or how it worked, so I knew I needed to find out what Slackware used instead. At any rate, my focus turned to pxelinux and Syslinux.

I turned to the Syslinux site (www.syslinux.org) and begin reading about pxelinux. The latest version is 6.03, and was giving me great info with specific details on how to set it up. One of the details was, that starting in version 5.x of the Syslinux, pxelinux.c32 was added to the mix and should be included in the tftpboot directory. So, I looked around in the Slackware 15.0 distribution in order to include it in my tftpboot directory, but was unable to find it anywhere. So, I finally checked the syslinux installation package to discover that Slackware is using syslinux v4.07, so I abandoned looking for pxelinux.c32.

Through the detailed information given in the PXELINUX Section at the Syslinux site, and, “Tftpd - IPFire as a Server” page on the ipfire wiki site, I was able to cobble together a working iteration of a working pxe boot from the client I am working on. I was very excited when the client machine completed the pxe boot and loaded the kernel and the initrd.img. It presented the well know, at least to me, initial text before the OS installation login. All I had to do was hit the Enter key twice and begin the installation. However, the keyboard input was not being accepted, so I could go no further. In fact, I had to push the reset button to reboot.

I was very happy that the pxeboot had occurred, and I decided to try the pxeboot from another machine on the network to see if I had the same “no keyboard input” issue there. I started the PXE boot sequence on that second client, and it seemed to be loading the kernel, but something caused the pxeboot to fail, and it reverted to booting the existing hard disk.

So, I’ve made some partial progress AND now have a new issue to resolve (the “no keyboard input” issue).

My original issue has been resolved, I have successfully PXE booted the intended client computer, even though I was unable to complete the install. So, I now have two new issues to work on.

I’m not sure whether to close this thread or not. If there is no further input from folks here, then I have my answer.

Thanks to all who have (and may continue to) contributed to helping me in this resolution.

Clark

For better understanding of the tftpd wiki page, I have restored some old entries.


@ummeegge @jon @bonnietwin (or someone else) If the restored entries are incorrect, please fix me.

Greetings
Tom

1 Like

Tom, thanks for the clarification regarding that link. Now I understand its purpose (and, it really does make a lot of sense).

Clark