From: Brian Elliott Finley [mailto:[EMAIL PROTECTED]
Sent: Sat 06/08/2005 21:16
To: [EMAIL PROTECTED]
Cc: sisuite-dev; Bernard Li
Subject: Re: [Sisuite-devel] to floppy install, or to not
Brainstorming is good.
These thoughts are good.
:-)
Some thoughts on these thoughts:
* The only
architecture for which we offer a boot floppy is x86.
* If
we can conclude that we can (programatically, consistently,
and
in a way that's easy for the consumer)
make grub, or some other
pxe-boot-loader-on-a-floppy work with any (or almost any)
net
driver on x86, then I think this may be a
very clean exit from
continuing to limit boel
to a floppy.
Advantages:
* I would also like to
see a perl or python (or both) interpreter in
boel.
* It could simplify our build environ -- no more
uClibc, less need
to rely on busybox.
Busybox rocks, but it would be nice to
use
some of the full featured tools from the
get-go (tar).
* Who knows what kinds of cool solutions our
developers would come
up with if we were to
tear down the limitations imposed by the
boot
floppy constraint!?!
So, Andrea,
Can you provide us with
additional justification for providing a grub,
or other pxe-capable generic
floppy, and some specifics on driver
support to help us make this
decision? It sounds good so far...
Please let us know, and make a
specific proposal if it still looks
feasible to you. :-)
I'm also very
interested in the bittorrent idea. It's something that
Bernard
approached me with at the last LinuxWorld (or was it
SuperComputing?), but we
haven't been able to pursue much yet. We
should engage Bernard on this
one regardless of the floppy decision, but
deciding on removing the floppy
constraint could certainly make a
bittorrent implementation
easier.
Cheers, -Brian
Andrea Righi wrote:
>
Brian Elliott Finley wrote:
>
>> What should we do about floppy
installs with 3.5.x and higher? There
>> may be other options,
but here are a couple that come to
mind:
>>
>> 1. Stop supporting floppy
installs as of 3.5.x.
>> 2. Offer an even more
minimalist kernel with the most
popular
>> hardware only.
Ie:
>> *
e100, e1000, tg3 net drivers
only
>> *
IDE plus the top 3 scsi drivers
>> 3. Put up a good
"HOWTO Build Your Own Boot Package" on the Wiki.
>>
>>
Thoughts?
>>
>>
>>
>
> Hi
all,
>
> I agree with both the points 1 and 3. IMHO it is not a good
solution to
> sacrifice the kernel and offer less hardware support only to
put the
> kernel & initrd in a single floppy...
>
>
Moreover there are many programs that allow to use the PXE boot feature
>
using a floppy disk... and that programs support a lot of network
cards.
>
> For example GRUB implements the BOOTP protocol and a lot
of network
> drivers, so it can be used to boot from network; I think you
must
> recompile it to use this feature... but, who cares? for example we
could
> also distribute a pre-compiled floppy image with GRUB already
installed,
> or include the grub code + an opportune config file in
SystemImager
> (analogous to each external software we're
distributing).
>
> With this approach you are forced to setup a PXE
server, but there is
> the image-server that can do this in a simply way
(si_mkbootserver).
> Otherwise you should always use a
CD-ROM...
>
> Moreover if you break the 1.44MB constraint we could
consider to
> implement a lot of new features inside the BOEL
kernel.
>
> For example we could use the same kernel that will be
installed in the
> clients to test some hardware compatibilities at the
installation time.
>
> Or imagine to put a perl/python interpreter
inside the initrd... doing
> so we should consider to put some evolved
technologies to propagate
> the images on client... we could also use a
peer-to-peer approach...
>
> I mean bittorrent for example; in a
scenario like this, I'd be able
> to strongly reduce the time to deploy
the operating systems on the
> clients... probably in a way faster than
flamethrower), exploiting
> also the output band of each clients: the
image-server should be the
> tracker, for example, and the clients
leechers and seeders...
>
> I think that massive installations
should gain a lot of benefits with
> this kind of approaches. Here in
CINECA, for example, we should be very
> interested in such
functionalities and maybe I could dedicate some
> time to port, for
example, bittorrent (or something similar... I know
> only that...) inside
SystemImager..
>
> Opinions? (I've a little digressed with some
brainstorming...;))
>
> Best regards,
>
-Andrea
>
>
--
Brian Elliott Finley
Mobile:
630.631.6621
