From mboxrd@z Thu Jan 1 00:00:00 1970 From: neil.holmes@zoom.co.uk Subject: RE: Elks Distribution Date: Wed, 29 May 2002 07:31:23 +0100 (BST) Sender: linux-8086-owner@vger.kernel.org Message-ID: <1022653883.3cf475bb26644@webmail2.zoom.co.uk> References: Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: List-Id: Content-Type: text/plain; charset="iso-8859-1" To: Riley Williams Cc: Neil Holmes , Linux 8086 Hi Riley, Thanks for your analysis. I am on the road for a couple of=20 days now but will look at it more closely when I return. I think I may be already addressing some of the points that=20 you raise. Your support is much appreciated. Many Thanks Neil Quoting Riley Williams : > Hi Neil. >=20 > > I am very greatful to you for your support of what I am=20 doing. > > Basic, though it is at the moment, I do expect it to go=20 much, much > > further. > > > > The goal of the Distribution Edition is to create a=20 version of ELKS > > that is accessible to the less technically able of us out=20 there. > > Simply stated - to be able to boot from a floppy disk,=20 follow a > > procedure, and finish up with a PC that boots into=20 ELKS at the end > > of that process. (From my web page) > > > > I remember that, when I first started out with Elks, I had=20 a lot of > > trouble getting going from anything other than the disk=20 images. I > > had an 80286 PC that had been sat around gathering=20 dust and I > > decided that it should be my ELKS desktop PC. > > > > Even then it took me a long time to get anywhere far=20 with that. > > Although I have an IT career, its not as a 'C'=20 Programmer. And my > > low level knowledge is sketchy to say the least. I find=20 Tannebaum's > > tome very interesting but hard going. I guess that sort of=20 level is > > not my scene. > > > > But what I do have is a gritty determination. And that is=20 how I got > > going with the 80286. I resolved that I would get it self=20 booting > > and running ELKS. I achieved that after a lot of=20 experimentation and > > Newsgroup scouring. > > > > As I said in my email last week. I then got to the point=20 where I > > wanted to try and put something back into the project of=20 my own. But > > what could I do ? I certainly don't have, and probably=20 never will > > have, the low level skills that you guys have. But what=20 I did have > > was my own experience of getting started with ELKS. > > > > I realised that many others may be getting turned off to=20 ELKS > > because they don't possess the same kind of=20 determination that I do. > > So that was when I decided to pull together my=20 experience into what, > > I hope, will become a decent Distribution Edition for=20 people like > > me. >=20 > I'm certainly hoping so as well. >=20 > > So the roadmap that I have now goes something like=20 this :- >=20 > I've swapped your sections (2) and (3) over as they=20 logically belong > the > other way round, and I've also reformatted the result to=20 make it > easier > to read. Here's my comments on the result... >=20 > > 1. Bootable Install Floppy > > - Shell Scripting > > > > - Maybe look at some of the mini "curses" code=20 that is lying > > around to try and make it look prettier later. > > > > - I would appreciate some feedback on what I can=20 do with the > > bcc version of "curses". I noticed it in the=20 ELKSCMD source. > > > > - I am thinking that for a Distribution I need to be=20 able to, > > pretty well, automate everything. But, of course,=20 with manual > > options for those who prefer that way. >=20 > First, we need to ask precicely what the boot/install=20 diskette is > supposed to achieve. Here's my take on that, in the order=20 they need to > be achieved... >=20 > 1. Boot into an ELKS system that does not require the=20 floppy > drive to run. We can't assume that every system will=20 have > two floppy drives, as most do not. >=20 > One thing that would help here is if ELKS implemented > something akin to MS-DOS's "virtual floppy" system, in > which a system with just one floppy drive can refer to > that drive as both A: and B: and the two drives remain > completely independent, with the OS just asking the > user to put the relevant diskette in the drive. >=20 > 2. Partition the primary hard drive with a partition of type > 80 that is at most 31M in size, as that is the largest > partition that can be handled. >=20 > This basically consists of a loop running fdisk /dev/bda > and then checking for a valid partition on the result. >=20 > 3. Auto-detect the correct partition and format it, then=20 mount > it at a fixed location in the install file system. >=20 > We can limit ourself to the four primary partitions at this > stage for the simple reason that the ELKS hard drive=20 code > does not currently support logical partitions. >=20 > 4. Drop into a loop asking the user to put a diskette in the > floppy drive, then mount it and copy everything off that > floppy to the same place on the target filesystem. >=20 > A working `tar` command would help here. Given that,=20 this > would reduce to the following bash script (converted=20 to ash > script): >=20 > function another_disk() { > local Y >=20 > echo > echo 'To copy another diskette, insert it in the' > echo 'diskette drive, then type "Y" and press=20 ENTER' > echo > echo 'Copy another diskette ? ' > while read Y ; do > case "`echo .$Y | tr A-Z a-z`" in > .n) return 1 ;; > .no) return 1 ;; > .y) return 0 ;; > .yes) return 0 ;; > esac > done > } >=20 > function locate() { > find "$1" -type $2 | sed "s=AC^$1/=AC=AC" > } >=20 > while another_disk ; do > mount /dev/fd0 /mnt/fd0 > locate /mnt/fd0 d | while read DIR ; do > mkdir /mnt/tgt/"${DIR}" > done > locate /mnt/fd0 f | while read FILE ; do > cp -pf /mnt/fd0/"${FILE}" /mnt/tgt/"${FILE}" > done > copy /mnt/fd0 /mnt/tgt > umount /dev/fd0 > done >=20 > That basically does that entire step. >=20 > 5. Once the user has finished copying diskettes, reboot=20 the system. >=20 > > - The key installation issues that I see my needing to=20 consider > > are :- > > > > - How do I resolve the kernel configuration for each > > platform/disk layout ? Maybe Linux controlled as=20 per > > your information. >=20 > Two basic options: >=20 > 1. Assume that the kernel on the install image is the=20 correct one > for the final system. >=20 > 2. The first diskette the user enters should have the=20 kernel image > on it as boot/elks relative to the root of the diskette.=20 Refuse > to accept it if that file isn't there. >=20 > There's little other than those two options to choose from. >=20 > > - How do I control partitioning during install ? > > Again your suggestions are likely to help here. >=20 > Initially, drop steps (2) and (3) in a loop such that step (3)=20 loops > back to step (2) if no suitable partition is found. >=20 > > - How do I deal with different types of install=20 images ? > > Your suggestions, again, will be key. >=20 > There's basically two scenarios that you need to worry=20 about: >=20 > 1. The user has a 360k floppy drive. >=20 > In this configuration, you're probably looking at a=20 boot+root > configuration, where the boot diskette only has the=20 kernel on > it, and the root diskette has everything else. >=20 > 2. The user has a 720k or larger floppy drive. >=20 > In this configuration, you're looking at a single 720k=20 image > that can be written to any of the larger drives and will=20 work > on all of them. >=20 > You will probably need to answer some questions=20 differently when > designing for each of these scenarios. If you can=20 squeeze the entire > install system on a single 360k image, then it's much=20 easier, but that > is unfortunately not likely nowadays. >=20 > > - How do I Resolve the multi-booting issue ? This=20 may be > > a lilo answer ? Not really thought about it yet. >=20 > Initially, you don't - just design for using fdisk to switch=20 the > active > partition to the one you wish to boot from next time. That=20 question > can > then be dealt with later when the answer is probably=20 much clearer. >=20 > > 2. Package Installation > > - Look to install package sets as part of the=20 installation > process > > - Here I will need suggestions and contributions. I=20 can start > work > > on this now so, if anyone has anything then please=20 let me know. > > Please be sure that I am ok with licensing before=20 submitting > > anything. Documentation would be very helpful too !=20 I will try > > them out on my desktop before I include them. > > - SmallC I expect to be one > > - Elvis perhaps > > > > 3. SLIP Network Installation > > - Automatic installation of a SLIP connection and test=20 during > > install > > - I have not really played with this yet though I do=20 have Harry's > > notes in my file. > > > > So there you have it. Thats what I am up to. The=20 feedback that I get > > is vital and I very greatful for all the encouragement=20 that I have > > had thus far. >=20 > Best wishes from Riley. >=20 >=20 Get your own zoom email - click here - http://www.zoom.co.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-8086" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html