Honest Guvnor wrote:
> On 9/21/07, John Summerfield <[log in to unmask]> 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 [summer@numbat ~]$ 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 [summer@numbat ~]$
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
[log in to unmask] [log in to unmask]
Please do not reply off-list
|
