Hi, Peter Lister <P.Lister at sychron.com> schrieb am 06.02.02:> In way way better and easier? When I have criticised pxelinux I think > I've always stated *why* etherboot seems better for our environment. > > I'm not trying to be religious, or get anyone to change a working system > - I'm genuinely interested what differences others perceive.I've looked into etherboot - my problems were: - Network card must be supported, and should (must?) be ethernet. I am booting token-ring clients with pxelinux. - Configuration directly burned into the rom - no easy way to 'just change' the configuration. - The etherboot rom is card specific - no 'all purpose'-driver available These come in part from the purpose it's designed for - it's designed as a boot rom, not a bootloader. In some part one could argue about doing things different in etherboot. I personally don't like the concept of putting together one file that contains everything (configuration, kernel, initrd etc.pp), but like to have these in separate files as in pxelinux. BTW, would it really be possible to have some extension for etherboot to support PXE booting (e.g. via pxelinux)? So could etherboot create some PXE stack that other bootloaders would use? Did anybody already try this? Regards, Josef ______________________________________________________________________________ Die Nummer, die man nie vergisst: Ihre pers?nliche Wunschrufnummer von WEB.DE! Jetzt einsteigen http://freemail.web.de
On Wed, 6 Feb 2002 16:30:25 +0100, Josef Siemes <jsiemes at web.de> wrote:>- Configuration directly burned into the rom - no easy way to 'just change' the configuration.If nic is pxe you can avoid this by downloading etherboot-rom via network. The other problems you listed remain.>BTW, would it really be possible to have some extension for etherboot >to support PXE booting (e.g. via pxelinux)? So could etherboot create >some PXE stack that other bootloaders would use? Did anybody alreadyThey don't like pxe, so they did the other way around (pxe boot etherboot). -- giulioo at pobox.com
> > In way way better and easier? When I have criticised pxelinux I thinkOr "what way"... finger trouble, sorry> I've looked into etherboot - my problems were: > - Network card must be supported, and should (must?) be ethernet. > I am booting token-ring clients with pxelinux.Fair enough. It would be nice to have Etherboot ignore PXE's DHCP/TFTP but use UNDI. I don't think there's inherently anything restricted to ethernet, despite the name; IEEE 802 addressing, perhaps, and the availability of polling drivers.> - Configuration directly burned into the rom - no easy way to 'just change' the configuration. > - The etherboot rom is card specific - no 'all purpose'-driver availableAs mentioned, Etherboot can be pxe'd, and booted from other media; it's pretty configurable via DHCP; indeed that made me prefer it to pxelinux.> These come in part from the purpose it's designed for - it's designed > as a boot rom, not a bootloader. In some part one could argue about > doing things different in etherboot. I personally don't like the concept > of putting together one file that contains everything (configuration, > kernel, initrd etc.pp), but like to have these in separate files as in pxelinux.I concede that etherboot's origins as a rom image still show through, but "not a bootloader"? OK, to be accurate, NBI is the OS specific loader which knows about Linux or DOS, not Etherboot itself. Etherboot loads an NBI image with OS specific bootloader, kernel and initrd; I perceive that as a *good* thing. Together they start Linux with no other help, so that sounds like a bootloader to me. Etherboot and NBI could be extended to tftp a separate initrd, but equally, pxelinux could be ported to Etherboot.> BTW, would it really be possible to have some extension for etherboot > to support PXE booting (e.g. via pxelinux)? So could etherboot create > some PXE stack that other bootloaders would use? Did anybody already > try this?I don't know if anyone has tried (Ken Yap would probably know). If NILO can be bugfixed and ported to Etherboot's dhcp, tftp and drivers, why not? It could give a degree of control over PXE not normally possible with Intel derived clients "free" with nic roms and wouldn't be as broken. No need for pxelinux as such, since Etherboot is perfectly capable of initiating Linux directly by NBI. It might also be interesting for the 'doze users - e.g. an image with the pxe stack and NTLOADER in one (no reason to go through the PXE cycle if you don't need to), maybe BIOS code for a ramdisk and an "initrd", or even a "hard vmware" virtual machine.
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
Hi, "H. Peter Anvin" <hpa at zytor.com> schrieb am 07.02.02:> Josef Siemes wrote: > > > > > That's a different point - if the high level bits in pxelinux were in > > C I'd have done something there. > > At some point I might do a C-based bootloader -- probably an actually > working implementation of Genesis -- but the *LINUX series are designed to > be as small as possible, which means that going to C, using a 16-bit C > compiler, isn't really practical -- free 16-bit compilers are uniformly > nonoptimizing.It's just some idea to have it C-based. I think of it as some asm routines with C interface, so if you want to deal with A20 handling or some other complicated task you'd still have asm, some high-level processing (like e.g. parsing the config file) would be in C. I think this is how etherboot handles this.> Since you have to turn off blksize anyway if you want to support early PXE > stacks, how much does this matter?It would be nice to have this option (e.g. set via a DHCP option), usually this would be turned off, and only activated for clients were one knows that it works.> Now, questions: > > a) Is this worthwhile enough that I should spend time on it? How much do > you think it will buy you?Since we have some of the clients booting over an 1 MBit line it would save some seconds booting these. It's just an idea and nice to have, but it also works without blksize. Since you already told me a while ago that blksize support is quite much work I think it isn't needed. Maybe you could keep blksize in mind while restructuring the code.> b) Should we aim for an even larger blksize by default? What about PXE > stacks that don't handle defragmentation correctly?I think that the standard behaviour should stay with 512 Bytes blksize (read: without the blksize option at all). This works reliably with almost all PXE stacks. We made some measurements about different blksizes at different bandwidth, and it turned out that you gain few with LAN lines, but the lower the bandwith the more you gain with higher blksize. So higher blksize is only needed if you have some WAN line with low bandwidth. Regards, Josef ________________________________________________________________ Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr! Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13