You'll also find this file in cLIeNUX itself when you boot the bootkernel/rootTree floppy combo cLIeNUX "booted with floppies" walk-through Congrats. Getting to this point is often the worst. You *are* at a unix shell, albeit a very limited one. In order to get a complete install of cLIeNUX together you'll need to be functional with commands partition, gzip -d, filesystem, mount, unmount, cp, get and rootdevice. The traditional Linux/unix names of those commands are fdisk, gzip -d, mke2fs, mount, umount, cp, cat and rdev, respectively. Either name should work for each case, i.e. fdisk or partition. Note that those are things that are fundamental to Linux use, and you very much want to at least know what they do. Other distros attempt to automate the install process. That's wonderful when it works, but it frequently doesn't, given all the platforms and variants Linux and cLIeNUX run on. It's also a huge effort to properly maintain something like that, and I'm not huge. Worst of all, you learn nothing that way. cLIeNUX' approach is to give you the tools, and the documentation, and general guidelines. This root image floppy has lots of documentation on it, which is rather unusual for an install floppy. This method also allows taking a couple extra reboot steps to check on things in valuable ways that scripts can't. In other words; this guide is slow, but is very likely to get you there. You have 3 virtual terminals. You can switch between them with alt&arrow_key. Keep this doc in view on one, and follow along on another. You now have a mini-cLIeNUX in RAM. To make a bootable cLIeNUX Core on HD you have to make a Linux partition, format it with filesystem, get cLIeNUX Core onto the partition, unpack cLIeNUX, and make a boot floppy to boot to the partition, and/or install the LILO Linux bootloader. The LILO step is optional, and I recommend postponing it, but nobody listens. How you do these things, and to some extent in what order, depends on your current setup. I'll discuss a worst case. Possibly the worst case is you DLed cLIeNUX to a box with some non-Linux OS on it, and you have to preserve the non-Linux OS. This non-Linux OS cannot make, see, or write to a Linux filesystem. Installing then is a matter of booting a small cLIeNUX off floppies to have a running Linux to prepare the HD from. How you make a partition for cLIeNUX without torching your current stuff is on you. It needs to be about 40 meg at least, twice that if you want the X Window System. The partition-HOWTO is in /help in this root filesystem image. It's excellent. I now assume you have made a boot and root floppy, which you are now booted to, and that you made a second copy of the bootkernel floppy, and that you have HD space for a cLIeNUX partition. The firstfloppy floppy is the kernel, the secondfloppy floppy is a small cLIeNUX filesystem with everything else. Write-protect one firstfloppy floppy and the secondfloppy floppy and label them if you haven't already. You make Linux partitions with cLIeNUX "partition". It's much nicer than DOS fdisk. partition -l will show you every partition Linux can see. Linux partition names are device names plus a partition number. There are docs here on partition in /help, and partition has menus. IDE drives are called /dev/hd and a letter. The first IDE drive is /dev/hda. SCSI drives are /dev/sd and a letter. For example, the 3rd partition on the second SCSI drive would be /dev/sdb3 . If your other OS is on "C:" it probably is called /dev/hda1 in Linux. If you have lots of space just leave some free. All you need right now is one Linux partition. Leaving parts of a HD unpartitioned is harmless, and a good idea at this point. OK, you format a Linux partition with filesystem. That makes what's called an ext2 filesystem, which is the standard for Linux. You run filesystem on a partition like ... filesystem /dev/hda3 , JUST AS AN EXAMPLE. I don't know where your cLIeNUX partition actually is. MAKE SURE YOU INCLUDE THE PARTITION NUMBER. /dev/hda without a suffixed partition number means the whole drive, not just partition 3 or whatever. Carefully now, filesystem /dev/hda3 will format partition 3 of the first IDE drive. Formatting is a matter of creating a filesystem, which is a big complex data structure spanning a partition. When you have a valid filesystem made on a partition, it can then be made visible to and part of the overall filesystem with the "mount" command. You can then copy stuff to it as regular files. mount is documented in /help. mount attaches a filesystem to the main filesystem on an existing directory. The directory in question is called a mountpoint. You can make directories with makedir. Three directories are already provided here for mountpoints in the /mount directory, and there's also the /floppy directory for mounting the floppy. . If you have an ext2 partition on e.g. /dev/hda3 you can now mount it with..... mount /dev/hda3 /mount/destination Then if you do ls /mount/destination you should see a lost+found directory, which is a standard part of an ext2 filesystem. If so, you now can write to the HD. That means you can put a cLIeNUX on it. The simplest thing at this point is to just clone the mini-cLIeNUX in RAM onto the HD. That's not what we're ultimately after, but it's a good step to take, because it tests some things as soon as it's possible to test them. That's always the way to go. The cp command has a lot of nifty options. What we want is to copy (cp) everything on the RAMdrive to /mount/destination. cp -ax / /mount/destination will do just that. cp --help will show you what the -xa is about. Moving files around in unix is heavily cached. Unix is very good at pretending HD is RAM and vice versa. When things actually get written to permanent storage is subject to some very sophisticated schemes, but this sophistication is just in the way at install time. If you power-off without a flush lots of things get lost. At this point we want to be utterly sure all the writes to HD were completed, so do a flush when the copy is completed, which flushes all cached changes to HD. OK, you did that? Now do ls /mount/destination and it should look exactly like ls / . When that is the case you have a mini-cLIeNUX on the HD that is suitable for booting to from floppy. The phrase "boot to such-and-such" in unix means "start a kernel with it's root (main) filesystem on such-and-such". The kernel has to know ahead of time where it's filesystem is. What you need now is a kernel image on floppy that will attempt to boot to that partition. This is why you made 2 copies of the boot image, firstfloppy/bootkernel. We are now going to modify one with rootdevice so that it will boot with / on the HD. There are docs on rdev/rootdevice in /help . If you do just rootdevice it should say --> root device: /dev/ram . That's where / is, on device /dev/ram . rdev also changes several variables in a kernel image that pertain to where a kernel looks for / when it boots. Put the kernel image floppy that you *didn't* write-protect in the drive and do rootdevice /dev/fd0 . It will say /dev/fd0 or /dev/ram or something. We need to change that and a couple other things. You want to rootdevice that kernel on the floppy to look for a filesystem on the partition you put cLIeNUX on. Let's assume hda3 again for example. rootdevice /dev/fd0 /dev/hda3 will flick the floppy light at it changes a couple bytes in that kernel to try to boot to /dev/hda3. You also should do these two commands... rootdevice -r /dev/fd0 0 rootdevice -R /dev/fd0 0 which removes some things about prompting for a second floppy. rootdevice -r /dev/fd0 should now answer with a zero. You may be ready at this point to try to boot to the HD. If you did flush after the cp, reboot with the hand-rootdevice'ed kernel in the floppy drive. Get to the point where you can boot to the mini-cLIeNUX on HD that is a copy of the secondfloppy RAMdisk file tree. This is an advantage of not doing this automatically. A script can't check how things boot. OK, you're booted to a mini-cLIeNUX on HD? Great. It's all down hill from here. Write-protect the rootdevice'ed bootkernel floppy and label it. Make note of the partition it boots to. If you haven't been able to boot to the HD go over the *preceeding* instructions. You did get booted? Fabulous. You could learn a lot of unix just with what you have working now. This was just a test though. This mini-cLIeNUX will interfere when we unpack the main one. You can wipe it off now, or do the moving and assembly of the Core# files first, and then remove the mini-cLIeNUX directory-by-directory. Either way, you're going to have to reboot with the first 2 floppies to do the wipe. I'll explain the "move first, wipe later" option. In order to get all of cLIeNUX Core unpacked you have to get it onto the cLIeNUX partition, and you have to assemble it into a single "tarball" archive. Then, you want to untar it while booted to RAMdisk. Where you may have options is in terms of how to get the Core# files onto the cLIeNUX partition. The cLIeNUX install kernel is compiled for support of about a dozen different filesystem types. If your cLIeNUX Core# files are on a supported filesystem, you can just mount the partition and cp the files to the cLIeNUX partition. If the Core# files are on a different box then you have a floppy-brigade situation. If you have to move the Core# files via floppy, you have to do so by mounting and unmounting the floppy drive and cp'ing the Core files to and from the floppies. This is because they are not raw floppy images, they are regular files. Stick to a mount-cp-unmount sequence, because unmount does a flush. If you don't have enough floppies for all the Core# files you will have a remove (rm) step also. Keep the Core# files in thier original names, Core1 etc., so that the get command given below will combine them in order. Assuming you're still booted to the HD, and you have mounted a partition on /mount/host that contains the cLIeNUX Core files Core1 through Core8 in the top directory of that partition. You can then do cp /mount/host/Core* / and the files will be copied to /, the cLIeNUX partition. ls / will show them in thier new home. In order to unpack cLIeNUX Core, it has to be re-assembled into a single tarfile. cd to the directory the Core# files are in. Now you can do get Core* >> clienux.tgz which will concatenate all the Core# files in numerical order into one file called clienux.tgz. The ">>" is essential. A single > is wrong. The "clienux.tgz" can be any unique name I think, but I like that one. Do an ls -l and check that clienux.tgz is roughly the size of the sum of all the Core# files. I've had a couple reports of problems with get Core* >> name . If that doesn't work try for f in Core* ; do get $f >> name.tgz ; done If that doesn't work email me. OK, now you have to get the test-install out of the way, and you're using it at the moment, so do flush and reboot with the first 2 floppies. OK, you're booted to RAMdisk, right? Mount the cLIeNUX partition. Then cd to the directory the cLIeNUX partition is mounted on. Now do ls and you see all the directories from the test mini-install, all the Core# files, and clienux.tgz right? You need to remove all the main directories. Be sure you cd'ed to the cLIeNUX directory on the HD, and do rm -rf command subroutine configure log suite boot EXACTLY that command will remove all the named directories, but leave some things. Now it's time to do tar xzvf clienux.tgz and the full cLIeNUX Core will unpack into place. That takes a little while. Lookit all dem files! When it's done, see if you can do any of the commands that unpacked. You can test that by giving thier full pathname from /. An example might be /mount/destination/command/date if you mounted the cLIeNUX partition on /mount/destination. Some commands won't work, but if any command in /mount/destination/command works you are ready to reboot to cLIeNUX Core, which is not much different from the cLIeNUX I'm using now. You want to hang on to the three write-protected floppies. The first two make a fair rescue set, and of course the 3rd is your boot floppy. As far as keeping Core# files and clienux.tgz, you probably want to keep clienux.tgz unless you're really tight for space. Most people consider being able to boot without a boot-floppy, directly from the harddrive, to be essential. That involves the lilo command. Do see lilo for the pertinent documentation. Copyright 1999 Richard Allen Hohensee