Then I am happy:-)
-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich@lanl.gov]
Sent: Monday, November 01, 2004 3:58 PM
To: Dave Aubin
Cc: Li-Ta Lo; YhLu; LinuxBIOS
Subject: RE: FILO fixups
On Mon, 1 Nov 2004, Dave Aubin wrote:
> Although...sniff I do like it in etherboot;)
it will stay in etherboot, no question about that!
ron
Filo does need a home and it can run outside of etherboot
So I would concede that is ok to have a home for it.
Although...sniff I do like it in etherboot;)
-----Original Message-----
From: Li-Ta Lo [mailto:ollie@lanl.gov]
Sent: Monday, November 01, 2004 3:46 PM
To: Dave Aubin
Cc: Ronald G. Minnich; YhLu; LinuxBIOS
Subject: RE: FILO fixups
On Mon, 2004-11-01 at 13:21, Dave Aubin wrote:
> Hi,
>
> I'll voice my desire to have etherboot with filo.
> I love the fact that I can first try to boot remotely And then if not
> use filo. For this reason alone I am A fan of the mechanism. Try
> remote first then if fail Use local storage. If we can, can we please
> put the Etherboot flavor in utils that has both network & filo
> support?
>
First of all, we didn't say we don't want choice. Actually we want more,
including the choice of not having some choices.
The problems of FILO/Etherboot are:
1. Some people have hard time building Etherboot.
2. Some people don't want the feature provided by
Etherboot, they are satisfied by FILO itself.
3. FILO (as FILO itself) does not have an official
host. If we want to continue maintain FILO to serve
people in 1. and 2., we have to put it somewhere.
If you want FILO as FILO+Etherboot, why don't you get it from etherboot
project?
Ollie
Ah, that could be the culprit. I'm using reiserfs, not ext2
With filo. Although it says it supports it. Perhaps it is
The file system that caused my hair loss!!!! ;)
Yes, having the net connection does make things nice...if ya have it:)
-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich@lanl.gov]
Sent: Monday, November 01, 2004 3:42 PM
To: Dave Aubin
Cc: Li-Ta Lo; YhLu; LinuxBIOS
Subject: RE: FILO fixups
On Mon, 1 Nov 2004, Dave Aubin wrote:
> Consider the redundancy aspect of it. First try remote.
again, if you have remote to try, that's fine, go for it.
If you don't have that ethernet connection, then counting on etherboot
is kind of pointless :-)
> There is also the error in filo where it can not handle an elf With
> both a kernel and initrd. It can only handle a kernel.
> To use filo I had to pack it up with initramfs, i.e. one big kernel.
> Etherboot remote boot doesn't have this problem.
??
in an ext2 on filo, i've got a kernel and initrd and it loads it up just
fine, so I don't see what you mean.
ron
On Mon, 2004-11-01 at 13:21, Dave Aubin wrote:
> Hi,
>
> I'll voice my desire to have etherboot with filo.
> I love the fact that I can first try to boot remotely
> And then if not use filo. For this reason alone I am
> A fan of the mechanism. Try remote first then if fail
> Use local storage. If we can, can we please put the
> Etherboot flavor in utils that has both network & filo support?
>
First of all, we didn't say we don't want choice. Actually we
want more, including the choice of not having some choices.
The problems of FILO/Etherboot are:
1. Some people have hard time building Etherboot.
2. Some people don't want the feature provided by
Etherboot, they are satisfied by FILO itself.
3. FILO (as FILO itself) does not have an official
host. If we want to continue maintain FILO to serve
people in 1. and 2., we have to put it somewhere.
If you want FILO as FILO+Etherboot, why don't you get it from
etherboot project?
Ollie
On Mon, 1 Nov 2004, Dave Aubin wrote:
> Consider the redundancy aspect of it. First try remote.
again, if you have remote to try, that's fine, go for it.
If you don't have that ethernet connection, then counting on etherboot is
kind of pointless :-)
> There is also the error in filo where it can not handle an elf
> With both a kernel and initrd. It can only handle a kernel.
> To use filo I had to pack it up with initramfs, i.e. one big kernel.
> Etherboot remote boot doesn't have this problem.
??
in an ext2 on filo, i've got a kernel and initrd and it loads it up just
fine, so I don't see what you mean.
ron
Consider the redundancy aspect of it. First try remote.
If that fails go local or vs versa. Kinda like if mom is
Around listen to her, if she's not around well then think
For yourself;)
Consider embedded size aspect of it as well. A kernel and
Initrd in my situation is about 4Meg. On my local drive it
Is about half that. Size costs more on my embedded local side.
I do like the versatility of etherboot having both local and
Net in one, but I totally understand why you'd want just filo
As the kernel can do the remote side.
There is also the error in filo where it can not handle an elf
With both a kernel and initrd. It can only handle a kernel.
To use filo I had to pack it up with initramfs, i.e. one big kernel.
Etherboot remote boot doesn't have this problem.
-----Original Message-----
From: linuxbios-admin(a)clustermatic.org
[mailto:linuxbios-admin@clustermatic.org] On Behalf Of Li-Ta Lo
Sent: Monday, November 01, 2004 3:05 PM
To: YhLu
Cc: Ronald G. Minnich; LinuxBIOS
Subject: RE: FILO fixups
On Mon, 2004-11-01 at 12:00, YhLu wrote:
> The reason for put filo in etherboot.
> 1. It can let boot from HD or net according to CMOS setting.
> 2. Etherboot can produce zelf. We may got more space to put other
> stuff such as USB support...
> 3. Etherboot structure and support...
>
> I may check if filo.zlef only include FILO ..., even it is not, we
> still can make it clean.
>
You have the same blind spot as Eric. For many people, boot over net is
irrelevant. Why do they need to live with the overhead of network
protocol stack and driver if all they want to to boot form some mass
storage device ?
Ollie
_______________________________________________
Linuxbios mailing list
Linuxbios(a)clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
On Mon, 1 Nov 2004, Dave Aubin wrote:
> I'll voice my desire to have etherboot with filo.
that's fine. choice is good. I have no complaints about that at all.
That's why I am saying we chose filo. At some later time we might choose
etherboot.
ron
Hi,
I'll voice my desire to have etherboot with filo.
I love the fact that I can first try to boot remotely
And then if not use filo. For this reason alone I am
A fan of the mechanism. Try remote first then if fail
Use local storage. If we can, can we please put the
Etherboot flavor in utils that has both network & filo support?
Kind thanks,
Dave:)
-----Original Message-----
From: linuxbios-admin(a)clustermatic.org
[mailto:linuxbios-admin@clustermatic.org] On Behalf Of Ronald G. Minnich
Sent: Monday, November 01, 2004 2:56 PM
To: YhLu
Cc: Li-Ta Lo; LinuxBIOS
Subject: RE: FILO fixups
On Mon, 1 Nov 2004, YhLu wrote:
> 1. It can let boot from HD or net according to CMOS setting.
only useful if your ethernet is hooked up. 15/16 of our nodes here have
no ethernet.
> 2. Etherboot can produce zelf. We may got more space to put other
> stuff such as USB support...
not that important to us.
> 3. Etherboot structure and support...
not clear at the moment if this is a plus or minus. Seeing that it has
trouble building under certain tool chains, there still seem to be
problems with it.
> I may check if filo.zlef only include FILO ..., even it is not, we
> still can make it clean.
We still need to add my performance improvements.
ron
_______________________________________________
Linuxbios mailing list
Linuxbios(a)clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
I've just finished fixups to filo that make it quite a bit faster.
First, it used to scan the bus twice, the first time to do a count. That's
slow, although it was a nice algorithm. But it only needed to find at most
2 devices.
Now it scans until the device is found and returns it. Even in the worst
case, the new pci scan is always faster than the old.
There are new options in addition to PCI_BRUTE_SCAN.
PCI_BRUTE_SCAN means:
scan everything ...
PCI_BRUTE_SCAN_START
... but start at this bus (VERY good on k8, as the scan of 0:19.* takes
FOREVER).
PCI_BRUTE_SCAN_LIMIT = 2
... and end here -1(useful when you know that the busses don't range to
256)
And the 'instant gratification' option:
IDE_HINT_BUS
IDE_HINT_DEV
IDE_HINT_FUNC
All three must be set or not set or you get a compile-time warning. IF all
three are set, FILO will probe the device and IF it is an ide controller
use that. If it's not an ide controller, filo will scan busses as usual.
This last option REALLY speeds things up
ron
