Victory!

After switching virtual network cards in my hypervisor, I was able to get RH7.1 online.  Textutils compiled as statically linked binaries just as expected, and ran like a mo-f'ing CHAMP on the dettuxx machine.  This allowed me to download coreutils-5.0 and compile/install it.

I ran into another circular dependency with awk (which was a pre-req of upgrading Bash), and was able to cross compile the latest gawk and get it installed just fine via the RH7.1 machine.  Now I'm going to try compiling binutils, as another pre-req of bash, and see what happens... Hopefully I won't have to cross compile too much more.

FML

FML... Just... network isn't supported...

Several failed attempts...

Apparently, in order to compile textutils, you need to have textutils installed...  Naturally (to me anyway), my first thought was Busybox.  I tried to compile it, no joy (unmet dependancies), I tried the appropriate binaries for my VM, also no joy... insta-segfault.

Fine, let's get the real sort util, and copy it over, perfect!  So I spend the next 20 minutes configuring another (32bit) VM to support SSH1 on the internal network (since, of course, the version of SSH with Dettuxx is ancient), and get scp working.  Copy the binary over, and it crashes complaining about libraries. File confirmed that it was dynamically linked, with libs that weren't installed in Dettuxx, no doubt.  Fine...

export CFLAGS="-static -O2 -g"
./configure --with-prefix=/home/peter/textutils_build
make
make install

This process went along nicely, and generated a statically linked set of textutils bins (the old textutils package wasn't exactly fun to find, mind you).  I scp these binaries over, and get:  "FATAL:  Kernel too old"

As we speak, I have RH7.1 installing in a VM, running a 2.4 kernel out of the box...  Wish me luck...

Back for more...?

So, all these years later, I decided to give DettuxX another try (I mean... we have VM's now... why not), and was able to get it installed, bootable, and on the interwebs last night...  Thats when I remembered just how much of a bitch it is.  I, by some act of God, was able to get gcc compiled, but that's about as far as I got before I started running into... problems.  In order to compile most things, you need to have sort (which was a part of textutils when the distro was released... now textutils has been rolled into coreutils).  Unfortunately, there's a circular dependancy there.  Textutils requires sort to successfully configure, and sort is a part of Textutils...  Guess it's time to evaluate busy box, and the prospect of cross compiling textutils on another machine and copying it over...  Joy...

Loopback Filesystem

Ok, so it took quit a bit of expirimentation and FM reading, but here's the lowdown on creating loopback filesystems:

Create a file to hold the system, in my case, it's gonna be 10 megs:

peter@slacktop:~$ dd if=/dev/zero of=/home/peter/fsfile bs=1k count=10240
10240+0 records in                                                     
10240+0 records out                                                    
10485760 bytes (10 MB) copied, 0.0606135 s, 173 MB/s

Next set up the loopback system and point it at your spiffy new file:

peter@slacktop:~$ sudo /sbin/losetup /dev/loop0 /home/peter/fsfile

From here you can create and mount your filesystem:

peter@slacktop:~$ sudo /sbin/mkfs.ext2 /dev/loop0
mke2fs 1.41.8 (11-July-2009)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
2560 inodes, 10240 blocks
512 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=10485760
2 block groups
8192 blocks per group, 8192 fragments per group
1280 inodes per group
Superblock backups stored on blocks:
        8193

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 37 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

peter@slacktop:~$ sudo mkdir /mnt/lo

peter@slacktop:~$ sudo mount /dev/loop0 /mnt/lo

Tada... loopback filesystem.

Part II

Goodbye Debian, Hello Hell

Ok... A few quick notes... First off... DON'T do a mkdir /boot accidently, because it wipes the boot directory in the ram disk... bad idea... Beyond that...

Instruction number 8 should read "umount /mnt/mnt" not "umount /mnt"
Instruction number 14 should read "/mnt/bin/lilo -v -C /etc/lilo.conf -r /mnt" not "/mnt/sbin/lilo -v -C /mnt/etc/lilo.conf -r /mnt"

Starting over from scratch SUCKS... More soon.

Rediculous...

I really should have noticed that the first disk had a lower block count than the other 7... Bad media right out of the box. Lets try again...

hackserv:/home/proto/Desktop# dd if=dettuxx_disk01.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 100.915 seconds, 14.6 kB/s

Ahhh... much better... now to see if she boots :-P