Hello GRUB people,
I think, the file systems on the partitions shoud be
checked via magics and other things on the partition, not via
the ID byte in the partition table.
For TAB expansions on positions like `(hd0,TAB' GRUB can
output the ID byte together with a `guess' by ID-name, or
This is not the problem, the eepro100 chip is not know by the
OS now (I will port/write the driver). So this is no topic.
Etherboot problem, see below
The problem is that the kernel crashes in the very beginning,
as if the kernel images is destryed.
The last status of my investigation is,
You will not imagine, but these changes are very simple.
You have simply to edit the `/boot/grub/menu.lst' file.
In the first lines you find the entry `default' and `timeout'.
Timeout sets the time you have to select, and `default' sets
the entry of the menu, which should be loaded by default,
Christoph Plattner writes:
CP Hello GRUB people, I think, the file systems on the partitions
CP shoud be checked via magics and other things on the partition,
CP not via the ID byte in the partition table.
I like this idea, personally.
CP For TAB expansions on positions like `(hd0,TAB'
From: Christoph Plattner [EMAIL PROTECTED]
Subject: Re: [Etherboot-developers] Etherboot/GRUB driver for eepro100 - problem in
understanding !
Date: Wed, 14 Feb 2001 10:06:52 +0100
If I don't use GRUB in the "diskless" mode, and load the
kernel plus modules manually per tftp, the kernel
According to Christoph Plattner:
In the probe section of the driver, the RxFD structure is
initialized. Here the field
ACCESS(rxfd)rx_buf_addr = (int) nic-packet;
is setup with the address of the packet frame POINTER inside
the nic structure.
What does the field rx_buf_addr expect
Hallo Mr. OKUJI !
No, I don't blame GRUB, especially where the diskless stuff
comes from myself
I don't think, that it has to do with networking in any way.
The point is that GRUB always use the exactly same downloading
if booted diskless or local. The BOOTP/TFTP is working in both
modes
