From: Friedrich L. <fl...@fl...> - 2003-05-22 15:29:03
|
John van V. wrote: > The optional boot process can take a lot of turns all of which, except yours, > dilute security and make DL dependent on some external source. > > The method I created in my eLSD version of DL simply finds no floppy and boots > w/o it requiring manual configuration manual input. > > At the end of the day, there are a huge number of boot options. The most > interesting is a net config, most simply where it gets /etc from an https > server. > > The most important part of the boot process is configuring the network card. > To do this successfully, the PCI ether recognition process will have to be as > sophisticated as Knoppix. > > Knoppix uses Anaconda where the detection subset is Libhardware. The question > is, "where should this happen in the boot process?" All the ethernet modules > will have to be in the distro in such a place that the boot kernel can find > them. Is this just planned or do you have anything working right now? Because we are restructuring things quite heavly now might be time to post your stuff to get it integrated before changes are too big which might complicate adapting your stuff. > Initrd should be kept as small as possible since it requires size configuration > in the kernel. That's true but we only need a minimal system ramdisk that creates a ramdisk, loads the needed drivers to access the cdrom, loads stuff from there and finaly the whole system boots. > This is why I am tending towards a whole new build, where the majority of the > process occurs in a boot kernel built under uClibc. I guess this will have to wait for 2.6 and its initramfs. > One problem I have found, say with busybox, is that the init process guides you > to the tradioinal boot sometimes locking you into a process that the BB group > has determined is desireable, mostly for utility/setup linuxes. Sorry I don't understand what you are talking about. > the LinuxBIOS folks are using uClibc linux and offer a reboot process called > kexec. The word "monte" also appears on their lists as well. Yes I know of two-kernel-monte but that does not actually work for 2.4 anymore. uClinux is actually kernel 2.0. But that's embedded stuff. And kexec I think is for kernel 2.5/2.6. > I am trying to do recall on the whole thing, but my conclusion has been to > restart with a whole new Linux and to build it in BOCHS rather than VMWare to > keep it a fully open source project. > > BOCHS seems to do compression very poorly, but then decompressing images also > slows down the DL boot process. > > LinuxBIOS, by comparison boots in 3 seconds. But.. you have to have a kernel > hacked for the specfic hardware. None the less, I think the rest of the > LinuxBIOS suite is desirable for a future DL. > > GRUB, PartEd and LVM would benefit from uClibc compiling as well to help make a > HD version of DL. My vision of this is to have Linux boot in Initrd or VFS and > do a complete check on the disks before using any of them. Traditional Linux > boots from the root disk, of course, in read only and then goes through the > familiar fsck process and dropout to a single user shell. For me the uClibc and initramfs stuff will have to wait for kernel 2.6. For kernel 2.4 we'll have to live with the current schema but we'll for sure will try to optimize that. > I am presently insanely busy trying to: find a job, get college started, and > flesh out my dream of bring DL type linuxes a focus for the UNESCO WSIS > conferences coming up soon. I wish you the best. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |