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
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Sisuite-devel mailing list
Sisuite-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
