My first Linux HOW-TO

I’ve been using Linux on and off for a long time. Best I can recall, my first Linux experience was with kernel 0.11 (do WHAT??) back in 1991. The Linux landscape was very different back then, in particular the breadth of offerings of Linux distributions. To wit: none existed. If you wanted Linux, you downloaded two disk images: one for a boot disk and a second with a root filesystem. You’d boot the boot disk, then when prompted to do so you would swap the boot disk for the root disk and continue booting. Once fully booted, you had a tiny filesystem to play with that had almost no free space on it.

Fun? Back then, yes, it was very fun. However, before anything serious would could be done you had to get the Linux root filesystem on your hard drive, and that required some sweat.

It was totally doable, though. There were instructions within the documentation for the boot and/or root disks that explained (roughly) how to do it. However, booting directly to that hard disk…well, not so simple, at least not for someone with no computer science background and only limited knowledge of computer hardware.

That’s where I was when I started experimenting with Linux. I was a DOS guy (shut up) but I had a thirst for more, and the appeal of a free UNIX-like operating system was just the ticket, even though it was buggy as hell and software-wise quite limited. Evidently, the challenge of getting this damn thing on my hard drive was too good to resist.

So, using the boot disk instructions that described how to edit the disk image to boot to the hard drive (again: do WHAT??), I embarked on my journey. Instructions were terse and cryptic and perfectly sensible to folks that know what hexadecimal numbers and offsets are, but holy shiz, I wasn’t one of them. The instructions may as well have been in Klingon.

To top it off, they required the use of a “byte editor” and I didn’t have a “byte editor”. I did, however, have DOS’ “debug” program, probably the creepiest damn thing ever to grace an end-user operating system. Debug was a ticking time bomb that sat on your hard drive waiting for a clueless newbie to say “hey, what’s THIS” and then run it and enter gibberish and send your drive heads crashing into the drive platters. Who thought it would be a good idea to include this in an operating system like DOS? Yikes, not smart, Microsoft.

I didn’t know much about using debug, but I did know this: you could do byte editing with it.

(Before anyone says “why didn’t you just download a byte editor?”, I’ll say this was the early 1990s, an era of 2400 baud modems and BBSes, and if the sysops on your favorite BBSes didn’t post byte editors for downloading, well, you didn’t download byte editors. Simple as that. I needed to do this and I needed to be resourceful, so…debug.)

I’ll spare you details about the profanity-laden day or two that I spent trying to figure this out. Debug wasn’t intuitive and its documentation sucked. NOBODY on Fidonet or the BBSes I frequented used it for anything other than decoding encoded batch file utilities (Fidonet BATPOWER peeps, represent!). No help, no way.

Somehow I managed to get it working, though. To be honest, I don’t fully recall the process of figuring it out. I did, though, and when it was all over I quickly wrote a verbose, horrible document explaining how it’s done. I then uploaded it to a couple of programmer BBSes and figured that’s that. Not long afterward, I heard that someone on one of the BBSes shared my new HOW-TO on USENET. I can’t say it was wildly popular, but stories that made their way back to me indicated people far and wide were using it to install Linux to their hard drives. That blew my mind.

Anyway, enough of that. With tremendous shame and embarrassment, I now present to you (ta daaaa) my first ever Linux HOW-TO in all its craptastic glory. Enjoy and try to not judge me too harshly. I know what a hexadecimal number is now, and I know that carpal tunnel syndrome has nothing whatsoever to do with eyes, so…

Some instructions on how to put the LINUX root on your hard drive and be 
able to boot to it (as written by someone who doesn't know jack about UNIX)


In my humble opinion, there isn't any way that following these instructions 
(with the limited "doc's" for LINUX close by) can mess anything up; 
probably the worst that can happen is you'll have to start the whole setup 
process over again. Nonetheless, I hereby wash my hands of any and all 
liability for damages sustained as the result of following these 
instructions. As long as you do things exactly as they're written here, 
and honor the limitations as listed in the doc's for LINUX, I really don't 
see any problems... Just be sure to read EVERYTHING before doing this 



There I was; hard disk containing the successfully transferred 
filesystem from LINUX, and no way to access it. After reading the so- 
called "doc's" about 100 times, I figured it was time to do a little 
hacking from the DOS end. In order for the hard disk to contain the LINUX 
root, the word starting at byte 508 in the boot image file had to be 
changed to 0x0302; no mention on whether this was a decimal or hex 
address... (This is for my configuration; yours may be different...) The 
problem is, the "doc's" refer to a sample program that they conveniently 
forgot to include in the .ZIP that could take care of this. Nice guys...


Not being the most experienced person in the DEBUG field, I had to do 
numerous different alterations to the BOOTU.IMG file from the DOS end until 
I finally got the HD to boot as the root drive. Hopefully, this text file 
will clear up a few things that I learned so that others out there who want 
to play with this UNIX clone can do so. (Note: these instructions will tell 
you how to make the hard drive the "root", but you'll still need to boot 
from a LINUX boot floppy. If there's a way to have the entire operating 
system bootable from the hard drive from the very beginning, I haven't seen 
it yet. Possibly if LINUX is in the first partition it'll do it, but I'm 
not adventurous enough to hassle with that. I still like DOS, and have no 
intention of making my entire computer run off of a beta release of LINUX.)

Side note: You may want to print this out, in case you're in LINUX and 
can't get back to this file without FDISKing back to DOS...


Without this, you will exit DOS and never be able to get it back until some 
generous person brings his DOS system diskette to your house!!! Also, 
unless you really don't like the files on your system, you need to do a 
backup of your hard drive. It's all going to be erased, so...

The first thing that needs to be done is to partition your hard drive with 
TWO primary partitions (the key word is "primary"; LINUX won't recognize 
"extended" partitions yet). Older versions of FDISK have been known to do 
this (I used Disk Manager). Perhaps DOS 5.0's FDISK can do it, but I 
didn't bother to check. I know that 5.0's FDISK can switch between two 
primary partitions, so chances are good that it can set them up too. 
You'll have to refer to your DOS manual to see if you have this capability. 
Obviously, all of the data from your hard drive will be wiped out, so I'll 
say once again to backup everything from your hard drive that you want to 
keep before doing this.

After setting up the two partitions, make the XENIX/UNIX partition (or 
whatever your FDISK says your soon-to-be-LINUX partition is called) active. 
Reboot with the LINUX boot disk (this assumes that you've already set the 
boot and root disks up with RAWRITE. If not, refer to the doc's for 

Next, after you're in LINUX (at this point, you've booted up with the boot 
disk, the root disk is in your floppy drive, and you're at a "#" prompt), 
type FDISK to see what partitions LINUX can read from your HD. If you get 
garbage, I can't help you; either go back and do the RAWRITE stuff all over 
again, or don't bother to continue (stick with DOS...). LINUX needs to use 
"AT" type drives; this isn't too clear to me, but basically you can use IDE 
drives but not SCSI ones. There just isn't any support for some HD's yet.

Pay special attention to the partition that DOESN'T contain DOS. This is 
the one that you're installing LINUX on. At the beginning of the partition 
display lines, there should be something that looks like "/dev/hd1" or 
"/dev/hd2"; these are device names that LINUX is giving to the partitions. 
After this information, there should me a number with the word "blocks" 
next to it; this is the amount of space in kilobytes that the partition 
contains. You need both the partition device name and the number of 
"blocks" to transfer the filesystem to the hard drive.

To transfer the filesystem to the hard drive, you type (at the "#" prompt):

mkfs -c /dev/hdX blocks

in all lower-case letters, replacing the "X" in "/dev/hdX" with the number 
that LINUX named the partition, and the number of kilobytes in the 
partition in place of "blocks". So if you have a 10 meg partition, and 
LINUX's FDISK reported it as:

/dev/hd2 : 10200 blocks: undetermined partition device 0x02
(I forget what it looks like; it's something like this)

you would type: mkfs -c /dev/hd2 10200

The filesystem transfer may take a while if you have a large partition. It 
may look and sound like your controller card is locked up, but bear with it 
for a few minutes. The "-c" is for checking the blocks in the partition to 
make sure that they're ready for the new operating system. (Think of it as 
another form of DOS's FORMAT command.) Note: EVERYTHING in the partition 
will be completely wiped out, so make sure that you're performing this on 
the correct one!!!

Now you're ready to "mount" the filesystem. For consistency, I'll refer to 
the drive as /dev/hd2, because that's what my system is set up to. Use 
whatever drive you used in the "mkfs" line.

Type this:

cd /
mkdir user
mount /dev/hd2 /user

If you get errors, then mkfs screwed up. I don't know what to do in this 
case. (I guess, once again, stick with DOS...) Remember that `/dev/hd2'
is appropiate for my circumstances, you will have to use the device number
correct for your own particular situation.

At this point you need to transfer all of the files from the root floppy 
onto the hard drive. When at the "#" prompt, this is what you type:

cd /user
for i in bin dev etc usr
cp +recursive +verbose /$i $i

After the files are through being transferred, execute "sync" three times, 
each time waiting for the sync process to end. Reboot your computer with 
your DOS system diskette.

When you're in DOS, you're going to use DEBUG to change the 508th and 509th 
byte in BOOTU.IMG so that it'll look on the hard drive for the root as 
opposed to the floppy drive. Here's where things get a little sticky...

First of all, you don't want to do anything with the LINUX boot diskette; 
that's going to be overwritten by the new version of BOOTU.IMG that you're 
going to create. You want to alter a new copy of BOOTU.IMG as extracted 
from the original LINUX archive file. Copy it onto a floppy, log onto the 
floppy drive, and call up DEBUG, using the path that points to it, and 
passing it the BOOTU.IMG filename:


[ NOTE: Read HEXED.DOC if you don't want to use DEBUG to patch the boot
image Essentially with HEXED you will move the cursor to byte 01FC
and 01FD of bootu.img and directly enter the changes. Push
F10 when finished entering the changes. That's it. Use rawrite to
transfer the patched image to your boot diskette. But first finish
reading this doc ... ] 

When you're at the "-" prompt, type "E 2FC". This will take you to the 
508th byte, and will show you the contents. [ NOTE: IF USING HEXED YOU
WILL BE PATCHING BYTE 01FC NOT 02FC -- DEBUG ADDS A 100 byte hex offset
to files--thus 02FC for DEBUG, 01FC for HEXED. ] At this point, you enter 
the numeric value that points to the device number of the drive partition. 
(Keep reading...) After hitting ENTER, type "E 2FD", which takes you to 
the 509th byte, at which time you enter "03", which is the LINUX code for a 
hard drive. So, if you set up your system for /dev/hd2, you would enter 
"02" at 2FC, and "03" at 2FD. Or, if you set it up for /dev/hd6, you would 
enter "06" at 2FC and "03" at 2FD. (The reason that you don't go to the 
hex address of byte 508 directly is that DEBUG loads files starting at byte 
100h, which is byte 256 in decimal. You need to add 508 to 256, giving you 
764. The address of the 764th byte in a DEBUG session is 2FC in 
hexadecimal. It took me TOO LONG to figure this little trick out, not 
being the most frequent DEBUG-er...). After entering the new bytes, type 
"w" to write the changes to BOOTU.IMG, then "q" to quit from DEBUG. The 
process will look something like this (this is just a visual aid for those 
people who aren't familiar with DEBUG. The "XXXX's" will be different for 
every computer.):

-e 2fc
-XXXX:02FC 00.02 <---(the "02" is entered by you)
-e 2fd
-XXXX:02FD 00.03 <---(the "03" is entered by you)
-writing 2A700 <---(I don't remember how many bytes
-q                  it was... It isn't important...)

The boot image file is now ready to read the hard drive as the root. Use 
RAWRITE to copy BOOTU.IMG to the LINUX boot floppy (overwriting the old 
version), and with the newly revised LINUX boot disk in the bootable disk 
drive, reboot the computer. If all works well, after hitting ENTER when 
prompted to, instead of a prompt to "Insert Root Diskette" you should be 
seeing the continuation of the boot process as executed from the hard 

Again, this doesn't eliminate the use of the boot diskette. It only 
enables you to use the hard drive for the LINUX root (which is a hell of a 
lot better than a 1.2meg floppy that has only 30k of space left on it!). 
This opens up the operating system to let you use other binaries downloaded 
from BBS's and such; otherwise, you'd be stuck with a small amount of space 
on a floppy to play with. Besides, the hard drive runs a HELLUVA lot 

(Now, to learn UNIX... Iggghhh...)

Erik Ratcliffe
(Eyes bugging out from carpal tunnel syndrome after
spending 5 hours trying to get LINUX loaded right)
This entry was posted in DOS, Linux.

Comments are closed.