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