Issues with restoring original factory software to a t42

[Glaurung-quena]

I wanted to set up a T42 with the original factory software for an authentic vintage experience. It hasn't gone well. Advice welcome.

The first road block was that the restore disks do not work with generic hard disks. It has to have the right firmware, or the restore process fails at the point of creating the primary OS partition. Original thinkpad HDDs work, and some other disks work, but otherwise, you are SOL. Also, naturally, cloning the original disk to a newer, faster one does not produce a bootable system, at least not with the software I normally use.

The second problem, once I finally realized I needed a blessed hard drive, was that the original wifi software does not understand WPA2 wifi connections. Unpatched (SP2), it throws an error before even trying to connect. Patch it to SP3, and it tries to connect for several minutes before failing silently.

I tried uninstalling the driver and installing the newest driver from Lenovo's EOL site. I tried uninstalling the driver and uninstalling Access Connections, then installing the updated driver. Neither worked.

What worked:
1. Disable the wifi card in BIOS.
2. do a factory restore, without wifi.
3. Uninstall the access connections software.
4. Enable wifi and install drivers manually.

Wifi works fine after that, but the radio control software (invoked with FN+F5) throws an error about needing to update your drivers, then only shows the bluetooth radio. So I guess I have to uninstall/reinstall the hotkey utility as well.

Things I would like help with:
Searching the forum for info on the hotkey software suggests that I need to install it and the wifi drivers in a specific order - what is that order?

Has anyone else found a better way to get modern wifi to work with the factory installation, without doing all the disabling/re-enabling of the wifi card?

Semi-related: the restore disks contain many encrypted zip files with an IMZ extension, and text files of the same name with a CRI extension. The CRI files appear to provide the password (usually HURRICANES) for unzipping the IMZs. However, using both 7-zip and winrar, that password does not work. Both programs recognize the IMZ files as encrypted zips and are able to show the files contained in them. But they can't unzip them. Is the password not actually "HURRICANES"? Or is there some other reason that I can't unzip those files with those tools?

[Gonzaleitor]

I'm replying using my T42p with Windows XP SP3. I never tried to install from the recovery disks, but from the multiple threads in the forum, IIRC, they are somewhat problematic. Why don't you install from a vanilla XP Install and install the software manually? Maybe it's less problematic that way. It's not the same setup experience, but the result should be the same, and you can use any disk you want (I'm using an M2 SSD in an IDE adapter from AliExpress).

[ajkula66]

I wanted to set up a T42 with the original factory software for an authentic vintage experience. It hasn't gone well. Advice welcome.

The first road block was that the restore disks do not work with generic hard disks. It has to have the right firmware, or the restore process fails at the point of creating the primary OS partition.

There's something very wrong with that picture.

The only systems which required proper firmware (or a modded BIOS) in order not to trigger the boot error were T43/p. All other T4x series could use any old IDE laptop hard drive and be happy with it.

My best guess is that there's something wrong with the recovery media in this case.

[Glaurung-quena]

I wanted to set up a T42 with the original factory software for an authentic vintage experience. It hasn't gone well. Advice welcome.

The first road block was that the restore disks do not work with generic hard disks. It has to have the right firmware, or the restore process fails at the point of creating the primary OS partition.

There's something very wrong with that picture.

The only systems which required proper firmware (or a modded BIOS) in order not to trigger the boot error were T43/p.

All other T4x series could use any old IDE laptop hard drive and be happy with it.

My best guess is that there's something wrong with the recovery media in this case.

This isn't a boot error. It's the recovery software erroring out.
And I have confirmed with experimentation that the recovery process works perfectly if the hard drive has an IBM FRU# on it. They don't work with generic hard drives bought off of Ebay. With a generic hard drive, the recovery process errors out at the point where the recovery partition's software is supposed to create the C: partition (it doesn't create the partition and instead says it could not restore the system).

The recovery disks I have are the ones distributed by forum member theterminator93, the contents of which are byte for byte identical with the ones available for download from Archive.org.

[ajkula66]

This isn't a boot error. It's the recovery software erroring out.

I understood that the first time around.

And I have confirmed with experimentation that the recovery process works perfectly if the hard drive has an IBM FRU# on it. They don't work with generic hard drives bought off of Ebay. With a generic hard drive, the recovery process errors out at the point where the recovery partition's software is supposed to create the C: partition (it doesn't create the partition and instead says it could not restore the system).

The recovery disks I have are the ones distributed by forum member theterminator93, the contents of which are byte for byte identical with the ones available for download from Archive.org.

Sorry, I'm not buying that explanation. Having restored hundreds of T4x systems with original software in the past, I've never come across such a problem.

You're looking at something along the lines of:

Bad recovery media.

Bad HDD.

All of the above.

Good luck.

[Glaurung-quena]

Sorry, I'm not buying that explanation. Having restored hundreds of T4x systems with original software in the past, I've never come across such a problem.

You're looking at something along the lines of:

Bad recovery media.

Bad HDD.

All of the above.

Good luck.

You made me realize I had only tried to restore using a Samsung hard disk. I rummaged around and found a non-IBM hitachi disk, and what do you know, that works perfectly.

There is nothing wrong with the samsung disk that I can tell - it works fine for installing an OS directly, crystal disk info says it's healthy. It's just the restore process that errors out on it. Weird.

Now I just need to figure out how to get working wifi and working hotkey software at the same time, and I'll be able to get this T42 up and running again.

[ajkula66]

Now I just need to figure out how to get working wifi and working hotkey software at the same time, and I'll be able to get this T42 up and running again.

Glad to hear that you got it to work in the end...

What's the issue with hotkeys and wireless ?

[Glaurung-quena]

Now I just need to figure out how to get working wifi and working hotkey software at the same time, and I'll be able to get this T42 up and running again.

Glad to hear that you got it to work in the end...

What's the issue with hotkeys and wireless ?

Using the restore disks gives you drivers that don't understand WPA2.
Feeding the system updated drivers does not work for reasons I cannot understand - it sees the network, tries to connect, fails, tries again, repeat until it gives up.

Turning off the wifi card until after the restore process completes gives you working wifi once you feed it drivers, but then the hotkey for turning radios on and off does not work. Whatever process causes the hotkey software to "see" the wifi card doesn't seem to kick in if you do an uninstall the hotkey/install wifi drivers/reinstall hotkey dance.

What I ended up doing was hacking the restore ISO to have updated drivers on it (find the encrypted zip on the restore disk that contained the relevant wifi drivers, create a (non encrypted) zip with the exact same batch and CMD files but the updated drivers, replace the encrypted zip on the ISO). The restore process still ends with out of date drivers installed (IDK where they're coming from, I can't find any other instances of the files outside the zip that I updated), but now pointing it at the updated ones in device manager produces a working wifi connection, so I called it good enough.

I still haven't figured out why I can't unzip the encrypted zip files on the restore disks using 7-zip and the alleged password HURRICANES, but everything unzips to drive C during the restore process, so I just made a copy of the hard disk in between the rescue/recovery phase and the "windows XP boots and starts running command scripts" phase, and used that to recreate the relevant zip file.

[RealBlackStuff]

Have a look at this: https://forum.thinkpads.com/viewtopic.php?f=8&t=136090

[dr_st]

Using the restore disks gives you drivers that don't understand WPA2.

That's part of the authentic vintage experience.

What I ended up doing was hacking the restore ISO to have updated drivers on it (find the encrypted zip on the restore disk that contained the relevant wifi drivers, create a (non encrypted) zip with the exact same batch and CMD files but the updated drivers, replace the encrypted zip on the ISO). The restore process still ends with out of date drivers installed (IDK where they're coming from, I can't find any other instances of the files outside the zip that I updated), but now pointing it at the updated ones in device manager produces a working wifi connection, so I called it good enough.

Clever. Glad it worked in the end, even if you needed that extra step.

[micrex22]

You made me realize I had only tried to restore using a Samsung hard disk. I rummaged around and found a non-IBM hitachi disk, and what do you know, that works perfectly.

There is nothing wrong with the samsung disk that I can tell - it works fine for installing an OS directly, crystal disk info says it's healthy. It's just the restore process that errors out on it. Weird.

I noticed that IBM's restore media sometimes has very specific and touchy hard-coded parameters. For instance on the IntelliStation recovery media (for certain models), you need to use the IDE CD-ROM drive rather than SATA. Else the recovery media errors out. I guess the disk type may induce a similar behaviour.

[SoftwareMethods]

Semi-related: the restore disks contain many encrypted zip files with an IMZ extension, and text files of the same name with a CRI extension. The CRI files appear to provide the password (usually HURRICANES) for unzipping the IMZs. However, using both 7-zip and winrar, that password does not work. Both programs recognize the IMZ files as encrypted zips and are able to show the files contained in them. But they can't unzip them. Is the password not actually "HURRICANES"? Or is there some other reason that I can't unzip those files with those tools?

I've gotten the passwords...

I was just trying to put my C:\Users folder on D:\Users using an Unattend.xml file, but I have to modify Lenovo's because mine just keep ignored (too late by the OOBE Select a Language screen).

There's a macro-expansion function wrapped around the password (usually either "lenovo" or "HURRICANES") that looks like this: !E()
Seems it is part of Lenovo's Hardware Integration & Image Technology (HITT) system.

I was able to see the actual passwords by modifying the STDOUT command in just a couple of the .CRI files... I used LCAFOC1KA4.CRI & M9DSIGA9A.CRI
[*]Within LCAFOC1KA4.CRI:
stdout=7z.exe x -y -p!E(%Password%) !F(%ModuleName%) -o%target%\ & cmd /c echo !E(%Password%) > "%target%\pwdH.txt" & cmd /c echo !E(%Password%) > "C:\pwdH.txt" & cmd /c echo !E(%Password%) > "D:\pwdH.txt"

[*]Within M9DSIGA9A.CRI:
stdout=7z.exe x -y -p!E(%Password%) !F(%ModuleName%) -o%target%\ & cmd /c echo !E(%Password%) > "%target%\pwdL.txt" & cmd /c echo !E(%Password%) > "C:\pwdL.txt" & cmd /c echo !E(%Password%) > "D:\pwdL.txt"

Then I ran it all. Once far enough along, I used Shift+F10 to get to a Command Prompt, navigated to the drive where files were saved using cd /d (path), and use "type filename.txt" to see the passwords within.
Those modified stdout lines put it in three places, just to ensure they'd be easy to find somwhere... The & makes it run regardless of the success of the previous command, and having them go to seperate files means I didn't have to worry about deliminators when appending a file.

Bottom line, for me:
!E(lenovo) = dq0xav (<--that's a zero in there)
!E(HURRICANES) = xwbdbgmlbu (<--that's a lowercase L in there)

If those passwords don't work for you, then you can replicate what I did to get passwords for your own 7z files.