RE: Elks Distribution

Riley Williams
2002-05-28T23:11:06Z

Hi Neil.

> I am very greatful to you for your support of what I am doing.
> Basic, though it is at the moment, I do expect it to go much, much
> further.
>
> The goal of the Distribution Edition is to create a version of ELKS
> that is accessible to the less technically able of us out there.
> Simply stated - to be able to boot from a floppy disk, follow a
> procedure, and finish up with a PC that boots into ELKS at the end
> of that process. (From my web page)
>
> I remember that, when I first started out with Elks, I had a lot of
> trouble getting going from anything other than the disk images. I
> had an 80286 PC that had been sat around gathering dust and I
> decided that it should be my ELKS desktop PC.
>
> Even then it took me a long time to get anywhere far with that.
> Although I have an IT career, its not as a 'C' Programmer. And my
> low level knowledge is sketchy to say the least. I find Tannebaum's
> tome very interesting but hard going. I guess that sort of level is
> not my scene.
>
> But what I do have is a gritty determination. And that is how I got
> going with the 80286. I resolved that I would get it self booting
> and running ELKS. I achieved that after a lot of experimentation and
> Newsgroup scouring.
>
> As I said in my email last week. I then got to the point where I
> wanted to try and put something back into the project of my own. But
> what could I do ? I certainly don't have, and probably never will
> have, the low level skills that you guys have. But what I did have
> was my own experience of getting started with ELKS.
>
> I realised that many others may be getting turned off to ELKS
> because they don't possess the same kind of determination that I do.
> So that was when I decided to pull together my experience into what,
> I hope, will become a decent Distribution Edition for people like
> me.

I'm certainly hoping so as well.

> So the roadmap that I have now goes something like this :-

I've swapped your sections (2) and (3) over as they logically belong the
other way round, and I've also reformatted the result to make it easier
to read. Here's my comments on the result...

> 1. Bootable Install Floppy
> - Shell Scripting
>
> - Maybe look at some of the mini "curses" code that is lying
> around to try and make it look prettier later.
>
> - I would appreciate some feedback on what I can do with the
> bcc version of "curses". I noticed it in the ELKSCMD source.
>
> - I am thinking that for a Distribution I need to be able to,
> pretty well, automate everything. But, of course, with manual
> options for those who prefer that way.

First, we need to ask precicely what the boot/install diskette is
supposed to achieve. Here's my take on that, in the order they need to
be achieved...

1. Boot into an ELKS system that does not require the floppy
drive to run. We can't assume that every system will have
two floppy drives, as most do not.

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.

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.

This basically consists of a loop running fdisk /dev/bda
and then checking for a valid partition on the result.

3. Auto-detect the correct partition and format it, then mount
it at a fixed location in the install file system.

We can limit ourself to the four primary partitions at this
stage for the simple reason that the ELKS hard drive code
does not currently support logical partitions.

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.

A working `tar` command would help here. Given that, this
would reduce to the following bash script (converted to ash
script):

function another_disk() {
local Y

echo
echo 'To copy another diskette, insert it in the'
echo 'diskette drive, then type "Y" and press 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
}

function locate() {
find "$1" -type $2 | sed "s¬^$1/¬¬"
}

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

That basically does that entire step.

5. Once the user has finished copying diskettes, reboot the system.

> - The key installation issues that I see my needing to consider
> are :-
>
> - How do I resolve the kernel configuration for each
> platform/disk layout ? Maybe Linux controlled as per
> your information.

Two basic options:

1. Assume that the kernel on the install image is the correct one
for the final system.

2. The first diskette the user enters should have the kernel image
on it as boot/elks relative to the root of the diskette. Refuse
to accept it if that file isn't there.

There's little other than those two options to choose from.

> - How do I control partitioning during install ?
> Again your suggestions are likely to help here.

Initially, drop steps (2) and (3) in a loop such that step (3) loops
back to step (2) if no suitable partition is found.

> - How do I deal with different types of install images ?
> Your suggestions, again, will be key.

There's basically two scenarios that you need to worry about:

1. The user has a 360k floppy drive.

In this configuration, you're probably looking at a boot+root
configuration, where the boot diskette only has the kernel on
it, and the root diskette has everything else.

2. The user has a 720k or larger floppy drive.

In this configuration, you're looking at a single 720k image
that can be written to any of the larger drives and will work
on all of them.

You will probably need to answer some questions differently when
designing for each of these scenarios. If you can squeeze the entire
install system on a single 360k image, then it's much easier, but that
is unfortunately not likely nowadays.

> - How do I Resolve the multi-booting issue ? This may be
> a lilo answer ? Not really thought about it yet.

Initially, you don't - just design for using fdisk to switch the active
partition to the one you wish to boot from next time. That question can
then be dealt with later when the answer is probably much clearer.

> 2. Package Installation
> - Look to install package sets as part of the installation process
> - Here I will need suggestions and contributions. I can start work
> on this now so, if anyone has anything then please let me know.
> Please be sure that I am ok with licensing before submitting
> anything. Documentation would be very helpful too ! 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 during
> install
> - I have not really played with this yet though I do have Harry's
> notes in my file.
>
> So there you have it. Thats what I am up to. The feedback that I get
> is vital and I very greatful for all the encouragement that I have
> had thus far.

Best wishes from Riley.

-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html