This is a continuation of my last post on recovering a thinkpad to its factory state.
I was able to move the thinkpad's hard disk to another laptop and mess with it under knoppix. An "fdisk -l /dev/hda" showed that the first partition wasn't actually missing, as I had assumed, but in fact was of type W95 FAT32. For some unknown reason the FreeBSD boot manager wasn't seeing this partition.
"If you were reinstalling XP, how on earth did you end up with a Win95 FAT32 partition?" Well, this goes back to the whole IBM Access "Recover to factory contents" option I was using. There are a number of stages in the process. In total I think the machine reboots about 10 times. I kid you not. Between some of these reboots, there's some partition games being played. The first stage, which appears to run from a Win98 image loaded from the HPA, sets up a Win95 FAT32 filesystem on the first partition and unzips a bunch of files onto it. In one of the last stages, the filesystem is converted up to NTFS. I never made it this far initially.
So I thought, ok, I'll just restore a default MBR. Using knoppix in the other laptop I did an "install-mbr /dev/hda." This however resulted in "MBR ... NTLDR is missing ... press any key to restart." Something's not quite right about the MBR from install-mbr; it must differ from the standard Windows MBR.
The best way to fix this is of course to just install the standard Windows MBR. But how? Luckily, I have a Win2k Pro CD on hand. Once the setup program booted, I hit "R" and "C" to get to the recovery console. This has a small set of commands. The two that did the job for me were fixmbr and fixboot. Voila, using this MBR the Windows OOBE was able to boot okay again. But trouble was just around the corner...
Halfway through the "IBM Customizations" process, I started getting weird error balloons: "Delayed write failed for such-and-such a file." Task manager showed that the currently running installer process (IBM Customizations fires off a number of them via a big batchfile) was eating 100% CPU, probably spinning on the disk write. I had to kill it, but every subsequent installer hit the same problem. Soon enough the system was hosed.
On the advice of this KB article I decided to try to turn off disk write caching, quickly, before the second stage OOBE booted. This required going through the whole recovery process from the beginning again, and didn't work.
Another KB article suggested I could be running out of disk space. That's entirely possible I thought, when I repartitioned the disk under FreeBSD I made the first partition a 5G OpenBSD partition. While that's more than enough for a typical OpenBSD install, it may not be enough for a typical Windows install esp. on a laptop.
Indeed, this was the case. I popped the disk back into my other laptop and checked out the partition table under Knoppix. The Win95 FAT32 partition had assumed the place of the OpenBSD partition; Windows was not using the whole disk, just the first 5G.
Using fdisk, I deleted all existing partitions and created a new big NTFS partition spanning the whole available disk. Then I used qtparted to create an NTFS filesystem on it.
Then I started the recovery process over from the beginning. I made it pretty far this time. After several OOBE reboots the desktop started to look familiar. Norton Antivirus (blech) got installed as well as the IBM Wireless tools. Eventually, the OOBE must have finished, and it booted to the FAT32 -> NTFS converter. After this finished and rebooted I ended up booting to a big black screen that just sat there. "If you stare too long into the abyss, the abyss will stare back at you..."
What could I have done wrong? I took a look at the drive again under Knoppix and discovered that the first partition ended on cylinder 4698. When I originally set up the ntfs partition, I had made it end on cylinder 4697, so this was weird. Even weirder, 4698 was past the end of the disk. Then I remembered that at the beginning of the recovery process, I was told in a dialog that the partition table was messed up and there was an offer to fix it by enlarging the first partition. I had said yes. In an effort to end the NTFS partition on a nice boundary the recovery process had extended it beyond the limits of the disk.
This turned out to be the problem. Back in qtparted land, instead of creating an NTFS partition over the whole disk this time, I left some space at the end. The recovery process again told me there was a problem with the partition table, but this time when it resized upwards it didn't pass the disk boundary.
I should also mention that after creating the partition in qtparted, I booted the Windows Recovery Console and did an fdisk on it to set up NTFS. I'm not sure if this step is really necessary; the recovery process may take care of it when it creates the Win95 FAT32 filesystem and then converts it up to NTFS. It may be that you just need your primary partition sized appropriately.
To summarize, these are the steps you should take if you've wiped out Windows in favor of another OS and you want to use IBM Access Recovery:
That's it. I would also recommend making emergency CDs in case you want to get rid of that silly HPA and buy yourself another 3+ Gigs of disk space. And they're probably a good thing to have around anyway.
Shit. I think I just bricked my Thinkpad T40, which I bought less than a week ago. Bricked at least for the moment; there are several avenues still left. Here's the progression of things.
The guy I bought it from had, it turns out, bought it from another guy who does corporate resells. I.e. HP decides to upgrade all their laptops and pushes the old ones along to this reseller. Now the fact that this 'top was used in a corporate environment is important and has bearing on any of you thinking about buying a used thinkpad.
Newer thinkpad models have, in addition to an optional BIOS user password, an optional BIOS supervisor password that prevents silly users from messing up their machines. During my testdrive we discovered this supervisor password was actually set, and the guy didn't know what it was. Without it, however, I couldn't change the boot order, so I couldn't boot the Knoppix cd I'd brought along to check things out. A temporary workaround was to remove the hard drive from the thinkpad; the CD was second in line and subsequently booted ok.
"Why not just take out the CMOS battery? Or why not just clear some jumpers?" Unfortunately, these newer thinkpad models store the BIOS passwords on a separate EEPROM chip. There is no software way to get at the chip; if you're adventurous, you can solder together a reader for the EEPROM.
This is one of the remaining options I'm now forced to consider. Now of course if the laptop is still under warranty (mine is) another option is sending it back to IBM, where they'll clear the EEPROM for you (actually, they replace the whole mobo). The cost of this procedure however is comparable to the price of the laptop. This is basically a theft-deterrent. If you think about it, there's something kind of criminal about the whole EEPROM soldering / reading procedure. This is what a criminal would resort to if he stole your password-protected thinkpad.
So perhaps against my better judgment I bought this thinkpad, telling myself I'd be able to figure it out some way or another. For a few days, I used Windows, the only OS on there--and without the ability to boot from somewhere other than the HD, likely to remain the only OS. But I just couldn't stand it anymore. I think the final straw was when IBM's wifi config software started fighting with wireless zero config. "ipconfig /renew "*Wireless*" sat there for about 15 seconds, during which of course it printed no status and refused to respond to ^C, like so many other Win32 console programs elect to do. Then finally there was some error message like "all pipes are currently in use." Enough I said.
At this point I discovered a way to boot from CD via boot.ini. This clever fellow who probably also owned a locked-down thinkpad realized that boot.ini could be used to load grub, which in turn could load Smart Boot Manager, which recognizes and can boot from a variety of devices found on PCs. Your CD drive is probably among them. Note: tracking down the files he mentions (sbm.bin aka sfbootmgr.dsk, memdisk, and grldr) requires some work.
Using this approach, I was able to successfully boot a FreeBSD 6.0 install CD. I partitioned and reformatted the whole drive, intending to install OpenBSD, FreeBSD, Linux, and possibly some 4th experimental OS (DragonFly BSD or Plan 9). I put FreeBSD on the 2nd partition and let it install the FreeBSD boot manager. I planned on replacing this with grub so I could add another option to boot from CD or USB. Remember, the BIOS boot order is still not under my control. But I never got around to it.
I booted up FreeBSD and quickly found that the Cisco MPI350 wireless mini pci card, which uses the an(4) driver, sucked unpardonably. Connectivity was constantly disrupted by "an0: device timeout" which also seemed to lock up the whole system for an interval. dmesg showed that nearly everything was on IRQ 11. Possibly this was the problem, possibly not. At any rate, I was unable to change the IRQ of the an0 device via /boot/device.hints, nor via disabling apic, nor via booting with ACPI disabled. Eventually I concluded that I should go back to an earlier firmware version.
To do this, however, I would invariably need to boot back into Windows, which was long gone. "But wait! There's more." Newer thinkpads have a Hidden Protected Area (HPA) at the end of the hard disk that contains a full factory image of the disk as well as a lot of other junk. Ahem, I mean useful utilities. In my case, for a brief moment the extra 3+ gigs of space the HPA consumes did seem worth it to me: I could restore Windows, downgrade the wireless card's firmware, and then go back to my FreeBSD install.
So I rebooted and did the Access IBM thing. From there I launched the "Recover to factory contents" app, which appears to run off a limited Win98 kernel and basically PKUNZIP's all the files in a standard XP install back onto the hard disk. Before actually doing this part, it reported that it had found a problem with the CHS values in my partition table and offered to fix it. I allowed it to do so.
Eventually the PKUNZIPping came to an end and the system rebooted. I was a little suprised when I was then greeted with the FreeBSD boot manager: apparently, this system restore procedure had not touched the MBR. Ok, all the better I thought, and booted the first partition which was listed as DOS. After a time XP booted up, and then proceeded to do post-install configuration which consisted of adding the various OEM drivers. Then it did a restart cycle without any warning.
To my horror, I was confronted with a FreeBSD boot manager screen which did not list the windows partition, only the two Linux partitions I had allocated space for but not actually installed anything to yet. The default selection was displayed as "F2" with the 2 being the ASCII graphics character for squared. Periodically, I would get a beep as the boot manager attempted to boot this faulty default selection. Clearly, the system was hosed.
What has happened here is this. Contrary to what you might think, the "Recover to factory contents" option of Access IBM doesn't do the full job: it doesn't recover the MBR, which is the first 512 bytes of the hard disk, nor some of the subsequent sectors which contain second-stage bootloaders. So FreeBSD's boot2 actually passed control not over to loader(8), which is the first bootloader stage to reside inside the FreeBSD partition, but instead to some random chunk of the "restored" windows partition. Amazingly, loader appears to be somewhat intact, but /boot/loader.rc definitely is not, as evidenced by the funky characters in the default boot selection.
Aside: you'd think that rather than all that file-by-file unzipping driven by a secret Win98 system image, they'd just have a very minimal linux image that bunzipped the factory hard disk image onto the first N sectors of the disk. But no. Perhaps different CHS geometries of the various disks you could choose for your thinkpad muck this all up. Or maybe it's a licensing issue with Windows. Who knows?
So now the hard disk is unbootable. Normally, you can just change the BIOS order to boot from CD or usb first, and then repair the mbr. Again, however, this is not an option for me until I crack / learn the supervisor password. This leads us to formulate
Used thinkpad buying rule #1: always always always get the bios passwords from the previous owner. Your system is crippled without them. If the previous owner can't produce them, are you sure the goods aren't hot?
In my case, I'm not really sure. I do have traceability back to the owner before the previous owner, who happens to be out of town but will be back soon. I'm really hoping as a "corporate reseller" or whatever that he keeps careful track of this sort of thing. At least, I'll wait and see about it before I start building this crazy EEPROM circuit. Which may be fun anyway, I've never soldered anything significant before. These are of course famous last words.
One avenue I haven't explored fully is switching the thinkpad's hard disk out into my Toshiba Satellite and restoring the standard PC MBR thusly. An earlier attempt to do this resulted in the hard disk not booting, so I concluded that the hard disk was also password protected / encrypted in some way. This may not be the case however; what remains of the original FreeBSD-created master partition table has no entry for a Windows partition. Maybe, under the original thinkpad boot loaders, it was just assumed to begin at some particular sector and they didn't even bother setting up the partition table. If Knoppix on my Satellite recognizes the disk, I'm back in business.