Honest Guvnor wrote:
On 9/21/07, John Summerfield <[EMAIL PROTECTED]> wrote:
I have used etherboot, but I wouldn't if I had a proper boot rom, and it
seems every system on the market these days does.
I would opt for something else also if I had the time to get it going
or, preferably, could persuade someone else to take the time. Neither
of the current binary versions of etherboot seemed to work when used
to initiate PXE or download a boot file directly. But we had some
etherboot floppies from a few years ago that did work and so we are
using those. Not the best of situations.
PXE is described in
the RHEL documentation available from www.redhat.com.
It is described but the package that contains it is missing from
RHEL5.0 distribution because of unspecified issues according to a post
I saw on the web. The Fedora equivalent was claimed to work.
Eh?
PXE is "Pre eXecution Environment."
For it to work, one needs
1. A BIOS that supports it
2. A boot manager. Linux has this:
07:53 [EMAIL PROTECTED] ~]$ rpm -qif /usr/lib/syslinux/pxelinux.0
Name : syslinux Relocations: (not relocatable)
Version : 3.11 Vendor: Scientific Linux
Release : 4 Build Date: Tue Mar 27
17:47:56 2007
Install Date: Fri Jun 15 10:40:04 2007 Build Host: norob.fnal.gov
Group : Applications/System Source RPM:
syslinux-3.11-4.src.rpm
Size : 1311536 License: GPL
Signature : DSA/SHA1, Sat Apr 14 06:19:06 2007, Key ID da6ad00882fd17b2
Summary : Simple kernel loader which boots from a FAT filesystem
Description :
SYSLINUX is a suite of bootloaders, currently supporting DOS FAT
filesystems, Linux ext2/ext3 filesystems (EXTLINUX), PXE network boots
(PXELINUX), or ISO 9660 CD-ROMs (ISOLINUX). It also includes a tool,
MEMDISK, which loads legacy operating systems from these media.
07:54 [EMAIL PROTECTED] ~]$
which you will note is part of SL5.
3. A DHCP or similar server to hand out IP addresses and other
configuration.
PXE works on our nodes but the BIOS is not configured to boot from it
which would mean getting at and changing it on the nodes. The BIOS
does not seem to talk to a serial console which would mean
experimenting to determine if something else could get at the BIOS
settings. Perhaps but it all takes time and we are engineers not
sysadmins. Experience has taught us that our sysadmin support can/will
not do this sort of thing and so we do it ourselves. In a hurry which,
of course, takes ages.
You don't need physical access to boot from a floppy? My recent machines
tend to not have floppies - I never ask for one. OTOH, many allow
someone sitting at the console to choose a boot device "for this time."
On some machines it's F12, on some it's something else, but it doesn't
require a BIOS change which one then needs to undo.
I would fully expect KS to work from a SUSE server of any age, though
one with DHCP3 is to be preferred. One can do magical things with DHCP3.
It is now working with the old SUSE server but I do not know what
version of DHCP is being used. It seems to do the job.
rpm -qa 'dhcp*'
It's probably DHCP3; DHCP2 is now really old - think back to RHL7.x/RHAS
2.1.
It allows capers like this:
class "anaconda"
{
match if substring (option vendor-class-identifier, 0,
8) = "anaconda";
option vendor-class-identifier "anaconda";
}
...
pool {
allow members of "anaconda";
deny members of "pxeclients";
default-lease-time 900;
filename "http://Fedora.demo.lan/5/i386/os/Fedora/";;
max-lease-time 1800;
range 192.168.9.170 192.168.9.179;
option log-servers 192.168.9.4;
}
Unfortunately, I've failed to persuade the Anaconda folk to actually use
this filename, but it does allow me to specify an IP address range
usable for installs but nothing else.
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
Please do not reply off-list
