PXE and grub (was: Re: Intel PRO/100 M Mobile Connection)

[Yedidyah Bar-David]

Hi all,

This isn't a reply to the specific message/thread, but a more general
discussion.

First, though, I want to encourage you with your efforts towards
better network support for grub.

I am on an etherboot ML for some time now, but only today subscribed
to bug-grub. I did search the archives a bit, but of course still
don't know the ML "atmosphere" yet, excuse me if I am not on-topic.

I am a sysadmin at cs.tau. We have here around 150 machines that
boot from the network. Most of them have PXE, almost all the rest
etherboot, I did have some occasions where only pxelinux worked.
All of them load pxegrub/nbgrub (no etherboot menus), then choose
either Linux (from the net) or local disk (usually Windows). I
sometimes add new Linux versions and other stuff (such as memtest86),
and find grub much more comfortable for that than the native etherboot
menu.

I think the general direction of these projects should be this:

etherboot should mostly concern itself with supporting hardware.
It doesn't have to have fancy menus and support for tons of image
types. What it does have to do that it doesn't currently (but seems
to be worked on) is something like UNDI - an api for the program it
loads that lets it use the network. This, of course, isn't of great
concern to grub, though, at least not until it's ready :-).

grub should be a great (the best?) second-stage boot loader.
It doesn't have to deal with network drivers itself (I know this is
currently not an option, until "etherboot/UNDI").

Generally speaking, it should load anything possible and be loadble
by anything possible. It already does much of this.
What it has to do that it currently doesn't (at least for my needs):

1. As others said, use PXE/UNDI when available. Lets face it, most
NICs sold today (on-board and PCI) that have any boot capabilities,
have PXE. Having PXE support in grub will solve one of the most
annoying problems, that of supporting newer cards.
A few years ago there were a few messages here about that, but I
could not find any code. The closest I could find is
<http://mail.gnu.org/archive/html/bug-grub/2001-04/msg00035.html>,
but the email address does not exist any more. Anyone knows about it?
Is Jean-Jacques Michel still on this list (or does someone know
how to contact him)?

2. When etherboot has its own API, use it (just like 1 above).

3. Be able to boot other PXE NBPs. I personally need this mostly
to add to the grub menu an option to start Windows RIS, but other
uses are possible.

4. 4 to 3 is as 2 is to 1 :-) - Be able to start another etherboot
NBI (if being booted by etherboot, and if there is real need, and
the grub dev team decides to keep etherboot inside, even if booted
by other means).

5. Load anything other that any other open-source bootloader can
load - either itself or indirectly. An already solved example is
to load a floppy image - and it can do that with memdisk.
Another example, that I did not look into - FreeDOS (both load
FreeDOS from grub and have a "grub.exe").

6. Load anything other and be loadable by anything other :-)
I really have only one important example, that I consider useful:
Have a grub version that can be loadable by ntldr and use its API.
This will allow installing Linux on an NT machine without changing
anything from outside NT - only by adding/changing files inside NT.
This will make most people that still feel uncomfortable with the
need to repartition and to change the boot sequeunce be able to
install Linux without taking such risks. This is not at all important
for my usuall work, but is very useful for instaparties. I hope to
reach a point where I can prepare an already-installed Linux image
inside a file, that students will be able to simply copy to their
disk (plus maybe a few other files - such as a kernel and a loader),
add an entry to boot.ini, and have Linux "installed".

Of course, when I write Linux I actually mean 'any OS/FS OS' - it's
just that we here use mostly Linux. I do have high hopes for hurd,
and do intend to play with *BSD when I have time.

I would love to hear any ideas anyone has on this subject, and
will also be happy to help (however I can - I do not have a long
experience of low-level programming) with anything related - at
least in testing.

Sorry for the long (and boring?) post,
-- 
Didi