[syslinux] Etherboot & pxelinux (was: thank you)

[Josef Siemes]

Hi,

Peter Lister <P.Lister at sychron.com> schrieb am 06.02.02:
> > They don't like pxe, so they did the other way around (pxe boot etherboot).
> 
> It was a bit more complex than just hating PXE. :)
> 
> Yes, I realised quite soon that I didn't like pxe (distinct from
> pxelinux), mainly because of the time wasted to do an extra tftp cycle.

Why is this 'wasted time'? It leaves the decision to you if you 
like etherboot, grub, pxelinux or some NT Remote Installer or ...
as the bootloader. For loading a diskless client this is a second tftp,
but we talk about seconds, not microseconds while booting. Even this
tftp is quite small (<= 32 K? At least <64K), so this won't hurt
on boot time. Compare this to a kernel with 7xx K, and an additional
initrd.

BTW: On Intel eepro 100 cards (Bootix rom)the dhcp needs 10 seconds
(standard IBM AIX dhcp server without binld), tftp of pxelinux needs 
<1 second, getting the default config and showing the boot:-prompt 
needs less than 1 second. These are 9 tftp requests by pxelinux for 
the config file. If you like you can give the config file with
some dhcp option, so this would be one tftp instead of 9.

So what could be heavily speeded up here is the rom doing the dhcp.
Maybe one could implement some rom that takes the first dhcp answer
if it contains a special option, and don't wait for any special
pxe dhcp offers.

The need here is to have the dhcp and kernel configuration split into
different files: The dhcp config remains unchanged and is administered 
by one group. The other group administers the kernel and the 
filesystems. BTW, we boot some 1.500 clients via pxelinux.

> And - the "high level" bits of Etherboot are written in C, so I have a
> chance of adding to or fixing it if necessary (e.g. I'd like to help
> improve the multiple NIC support).

That's a different point - if the high level bits in pxelinux were in
C I'd have done something there. Since I only can read a bit assembler
but not write it I can see how it works, maybe why, but can't extend
it to my needs. I'd for example like to have blksize in pxelinux, 
but since it's too complicated for me to implement and hpa doesn't
have the time to do it I'll go on without it. Maybe sometime parts
of syslinux/pxelinux/isolinux will be available in C so I can do 
something about it.

> I do not find the pxelinux configuration style easy to use. If a minimal
> boot code written in assembler has to parse a text file, then the
> language won't be terribly powerful. I was not used to syslinux (other
> than indirectly in Red Hat kits), having only ever used lilo for disks,
> so I had no experience of the style. Yes, ISC dhcpd configuration
> language is clunky - v3 is an improvement on v2, but simultaneously too
> complex to be simple, and not complex enough to be powerful.

Consider booting without ISC dhcpd - take some IBM AIX or Sun Solaris
dhcp server, that the management refuses to change with ISC dhcpd.
The reason here is that there's a service with the server manufacturer
(here IBM), and if you take some other dhcp server you're on your own
if some update breaks your dhcp server or the dhcp server somehow
refuses to work.

> DHCP (distinct from ISC dhcpd and its language) is better than tftping a
> text file because the non-trivial config (i18n, conditional behaviour,
> maybe generated from a customer db) is server side; clients see just a
> string of easily parsed data in a well known extensible format with
> vendor hooks - and there is almost certainly a DHCP client in the boot
> rom anyway.

The standard today is PXE - quite a lot of cards are capable of pxe 
booting a client out of the box. And please don't tell that the 
PXE option extensions are easy - they are quite a mess if you have 
to use them. The whole DHCP(with PXE extensions and all the funny stuff)
protocol is a set of extended extensions that were further extended. I
sometimes suspect that vendors didn't implement some parts of these, 
since they didn't understand this part.

> This means that (a) I don't mind fairly complex DHCP config and (b) I
> know there's a better future.

For now there's DHCP/PXE for netbooting a client. Bootp is obsolete,
and I don't think that there is much need for the 'Etherboot' protocol.

Everything you get with etherboot may be get with portions
of specialized code derived from etherboot/pxelinux. So the low-level
code may come from etherboot (the rom code itself), giving PXE support
and maybe for backward compatibility support for the Etherboot style
loading some tagged image. Then there's pxelinux (or a conglomerate
of the etherboot and pxelinux code) which parses the dhcp options
and maybe loads some config file. Then there's some 'Kernel bootloader'
that tftp's a kernel and an initrd, and spits this things into the
correct memory position. I consider memdisk as part of a bootloader,
for loading (or better: reconfiguring memory for getting this as 'A:')
the floppy image. 

Don't take this too serious, it's just some thought how things could
be split up in some specialized package.

So I agree with HPA that there's no need for one big package, but
some free implementation of a pxe rom which in turn uses some
pxe bootloader.

Regards,

Josef



______________________________________________________________________________
Lotto online tippen! Egal zu welcher Zeit, egal von welchem Ort. 
Mit dem WEB.DE Lottoservice. http://tippen2.web.de/?x=5