One of my proudest hacks came when I upgraded my old college computer (that 486 I talked about earlier) with a 1.2GB drive. This was back in the day when anything over 520MB wasn't visible to the computer without trickery. When I attempted to install Linux to it, I ran smack into that trickery and couldn't get it to work.
You see, trickery in this era was dependent entirely on the controller being used to get that high. In my case I picked up the drive and a VLB-based IDE controller to drive it quickly. Therein lays the rub. The DOS driver for this board wasn't the most configurable thing on the planet and I had to poke at it a lot to get the partitioning I wanted.
Sadly, when it came to the linux install, I was getting different return data when I ran FDISK from DOS, fdisk from linux, and the card's partition utility. I'd partition how I wanted in linux in FDISK, reboot, and DOS wouldn't show any signs that I'd done anything. Somewhere, somehow, the partition table wasn't getting updated.
So out I trot a handy DOS toolkit known as "PC Tools" (now defunct, done in by Norton) that had some truly wonderful disk-hacking tools. One of 'em was a handy utility called 'disk edit' that allowed you to hex-decode bits of the hard-drive. Things like FAT tables, boot sectors, and most importantly, partition tables. With this tool I was able to discover that the various FDISK utilities were indeed changing the data in the partition tables, but for reasons unknown those changes weren't taking place. My theory was the trickery involved in getting a 1.2GB drive visible. Many hours later, I notice an identical data-set two sectors over from the partition table that looked exactly like a partition table, in the wrong spot, but with the data the machine was actually looking at.
AHAH!
I hand edit those values to match the ones I pulled from the 'real' partition table and reboot. Suddenly, its respecting those boundaries. More tweaking to make sure I have things done the way they need to be, and I'm happy.
Kernel-level support for the trickery arrived in the 1.3.x kernels somewhere, and is still in there. I can't remember the name of the card anymore, that machine died a number of years ago, but I suspect it was the CMD640 line. Probably wrong, but that seems closest.
Update: It was a DTC-2278 card, not CMD-640.
You see, trickery in this era was dependent entirely on the controller being used to get that high. In my case I picked up the drive and a VLB-based IDE controller to drive it quickly. Therein lays the rub. The DOS driver for this board wasn't the most configurable thing on the planet and I had to poke at it a lot to get the partitioning I wanted.
Sadly, when it came to the linux install, I was getting different return data when I ran FDISK from DOS, fdisk from linux, and the card's partition utility. I'd partition how I wanted in linux in FDISK, reboot, and DOS wouldn't show any signs that I'd done anything. Somewhere, somehow, the partition table wasn't getting updated.
So out I trot a handy DOS toolkit known as "PC Tools" (now defunct, done in by Norton) that had some truly wonderful disk-hacking tools. One of 'em was a handy utility called 'disk edit' that allowed you to hex-decode bits of the hard-drive. Things like FAT tables, boot sectors, and most importantly, partition tables. With this tool I was able to discover that the various FDISK utilities were indeed changing the data in the partition tables, but for reasons unknown those changes weren't taking place. My theory was the trickery involved in getting a 1.2GB drive visible. Many hours later, I notice an identical data-set two sectors over from the partition table that looked exactly like a partition table, in the wrong spot, but with the data the machine was actually looking at.
AHAH!
I hand edit those values to match the ones I pulled from the 'real' partition table and reboot. Suddenly, its respecting those boundaries. More tweaking to make sure I have things done the way they need to be, and I'm happy.
Kernel-level support for the trickery arrived in the 1.3.x kernels somewhere, and is still in there. I can't remember the name of the card anymore, that machine died a number of years ago, but I suspect it was the CMD640 line. Probably wrong, but that seems closest.
Update: It was a DTC-2278 card, not CMD-640.