Bad documentation on XP installs for T400

[clasys]

Anyone who has any notions of what to do with this info? Purely by direct observation. In any case, it's verifiable:

Lenovo would have you do the F6 stuff and use an A: diskette with the IMSM stuff on it to prevent the BSOD crash and that works per se, but I have an important distinction to report:

If you instead install in compatibility mode and follow the directions to AFTERWARDS set it to AHCI and then reboot and provide the driver info [either their way or with a diskette, whatever] there is actually an important difference between the two results. [They falsely claim they are identical ways to get to the same place, but it's just not true]:

If you do the recommended procedure, that XP system will BSOD on every bootup if you set the BIOS to compatible SATA mode while doing it the way that starts with compatible mode will in fact boot with the BIOS set to either Compatible or AHCI. If you are like me and use bootable CD a lot, it's a needlessly larger PITA problem because you have to remember to switch to Compatible when booting the CD and then change it back to AHCI before booting to the hard disk, etc. If there are several iterations involved, you have to make twice as many BIOS changes, thus the compatible mode-starting install is clearly not identical to the F6 start method, it is superior.

Thus, if you read their doc literally ["they are equivalent"] you aren't really there.

So far I haven't been able to figure out how to remedy this; you're stuck with the inferior install unless you literally start over again [perhaps a repair install, but that doesn't always work; would be a bit foolish to risk that over this silly an issue.

If you noodle around the PREPARE directory there seems to be some undocumented files, but this may be irrelevant. In any case, some of us have elaborate installs that don't want to be paved over; too much work, etc. but is there any way to get there without a repair install?

[Of course for any new work I just use it the compatible way which always works; after all, it is documented as "identical" isn't it?]

cjl [so this is at least a word to the wise, but also a plea for help to remedy what a missing step might look like; solving this can turn into a demand for replacement documentation that these are actually NOT identical as written or if figured out amend it so they then would actually be what they claim it is, etc.]

[dr_st]

This is an important observation indeed. I'd like to make sure I understand exactly.

Are you saying the T400 will not boot from CD if the SATA in the BIOS is set to AHCI? This seems to be a serious limitation if that's the case.

Also - the F6 method (install in AHCI mode) will only make XP work in AHCI mode. But if you install in compatible mode and add the SATA driver later - XP will work well in both modes? Or is it the other way around?

Can you link to the explanation on how to add the SATA AHCI driver to an existing XP install?

My experience (with a different laptop - the T60) was that I installed in IDE mode, then added the SATA driver and changed to AHCI, and I seem to recall that now XP won't like it if I switched back to IDE and would BSOD on me.

However, I have no problem booting from the CD/DVD while the BIOS in in AHCI. This may be because the CD/DVD in T60 is IDE, while in the T400 it is SATA.

[clasys]

I see this is somewhat confusing, so I'll do it the complete [and hardest way] starting with a direct quote from 6iim10ww.txt [with comments interspersed]

__________________________________________________________________________________________________________________________________

[Windows XP] CLEAN INSTALL


Before installing the operating system, install Intel Matrix Storage Manager
Driver, as follows:

Notes:
- Be sure to install Intel Matrix Storage Manager Driver before installing the
operating system. Otherwise your computer will not respond; it will only
display a blue screen.
- In RAID mode, the following procedures is the ONLY procedure to install
Windows XP successfully.


This is of course true. However, the hardware in the T400 is the ICH9M-E/M SATA AHCI which is NOT RAID. The update language is generic and thus needs to be interpreted with respect to a T400, not the entire world of Intel SATA, etc.

1. Attach a floppy disk drive to your computer.

Windows XP requires an A: drive to provide the OEMSETUP diskette during the F6 phase.

2. Download Intel Matrix Storage Manager Driver from the Web site and extract
the driver to C:\DRIVERS\WIN\IMSM and copy the driver to a floppy disk.

The only way XP can install [Vista and up can use a flash drive].

3. Make sure that SATA AHCI or RAID is enabled;
3-1. Power off the computer.
3-2. Power on the computer.
3-3. Press the F1 key to enter the BIOS Setup Utility when the "ThinkPad"
logo is seen on the screen. The BIOS Setup Utility menu will be
displayed. If a password prompt appears, type the correct password.
3-4. Select Config.
3-5. Select Serial ATA (SATA).
3-6. Make sure RAID* or AHCI is selected. (* ThinkPad W700/W700ds only)
3-7. Press the F3 key, and then press the F3 key to go back to main menu.

On those other machines it would say RAID but on the T400 and most others it is AHCI.

4. Make sure that Operating System can be installed from Windows XP CD;
4-1. Select Startup.
4-2. Select Boot.
4-3. In Boot Priority Order, set "ATAPI CD0:" to the top of the list, "1".
4-4. Press the F10 key to save the new setup, and then select Yes.
The computer will restart.

Or you could use the ThinkPad key and then F12 to select the Boot from a CD.

Bear in mind that by a lot of modification of the install CD, a descendent bootable CD could be created that includes the driver [in theory] but it's a lot of work over doing this [and my point is that even this is NOT the way to go on this machine!]

5. Insert the Windows XP CD into the optical drive, and restart the computer.

Yes, this is all fine. I also use a DOS bootable floppy and have an appropriate I386 directory on my D: drive and then run D:\I386\setup.exe etc. after running SMARTDRV. Either way, you get to the same place, etc.

6. To install a third-party SCSI or RAID driver first, press F6.
7. When prompted, select S for Specify Additional Device.
8. When prompted, insert the floppy disk that you created in step 2, and press
Enter.
9. - If your system has Intel 82801HEM/HBM SATA AHCI Controller, select
Intel(R) ICH8M-E/M SATA AHCI Controller, and press Enter.
- If your system has Intel 82801GBM SATA AHCI Controller, select
Intel(R) ICH7M/MDH SATA AHCI Controller, and press Enter.
- If your system has Intel ICH9M-E/M SATA AHCI Controller, select
Intel(R) ICH9M-E/M SATA AHCI Controller, and press Enter.

This is the one relevant to the T400.

- If you selected RAID mode in ThinkPand W700/700ds, select
Intel(R) ICH8M-E/ICH9M-E/PCHM SATA RAID Controller.
10. To continue the installation, press Enter again. Leave the floppy disk in
the drive until the next reboot; the software may need to be copied from
the floppy disk again when the files are copied during setup.

Correct but also subtlety adds a nuanced tip: You CAN remove the floppy, but it will prompt you again for it explicitly if you do. When you press enter in that circumstance, it copies what it needs and then you can remove it [as demanded further in the install anyway].

14. Follow the instruction to complete the Operating System installation.

Gee. that's one short statement to cover so much! But of course totally accurate.


If you do not have a floppy disk drive, you can install Intel Matrix Storage
Manager Driver by the following alternative procedure (applicable to other
SATA settings except RAID):

This is the start of the controversy. Yes, it is an alternative BUT IT'S SUPERIOR!

NOTE:
If you select AHCI for Serial ATA (SATA) in the BIOS Setup Utility before
installing Intel Matrix Storage Manager Driver, your computer will not
respond; it will only display a blue screen.

Yes, the mini-kernel does its own form of BSOD if you don't do the F6 thing OR do this instead!

1. Power off the computer.
2. Power on the computer.
3. Press the F1 key to enter the BIOS Setup Utility when the "ThinkPad" logo
is seen on the screen. The BIOS Setup Utility menu will be displayed. If a
password prompt appears, type the correct password.
4. Select Config.
5. Select Serial ATA (SATA).
6. Select Compatibility.

I think it actually says "Compatible" but I am being needlessly picky

7. Press the F10 key to save the new setup, and then select Yes.
8. Restart the computer.
9. Install Windows XP and Service Pack 2.
10. Download Intel Matrix Storage Manager Driver from the Web site and extract
the driver to C:\DRIVERS\WIN\IMSM.

This part is the same as in the first procedure, or any other method you get the same files available, just that you don't involve a floppy.

11. Go to C:\DRIVERS\WIN\IMSM\PREPARE, and double-click install.cmd.

This is something meant to be run in Windows that sets up for a plug and play hardware discovery later.

12. Power off and on the computer.
13. Press the F1 key to enter the BIOS Setup Utility when the "ThinkPad" logo
is seen on the screen. The BIOS Setup Utility menu will be displayed. If a
password prompt appears, type the correct password.
14. Select Config.
15. Select Serial ATA (SATA).
16. Select AHCI.
17. Press the F10 key to save the new setup, and then select Yes. The computer
will reboot and Windows XP will start.

There is no step 18!

As it gets going, you do get one of those as described in 19. below.

19. The Welcome to the Found New Hardware Wizard appears. Click No, not this
time, and then click Next.
20. Select Install from a list or specific location (Advanced), and then click
Next.
21. Select Search for the best driver in these locations. Then select Include
this location in the search:, specify the path, C:\DRIVERS\WIN\IMSM, and
click Next. The Completing the Found New Hardware Wizard appears.

Actually, if you have a diskette and use the diskette created as needed for the first procedure, that also satisfies this and it does have an option to search removable media and that would also work, save a couple of clicks, but remember this is to avoid even dealing with a diskette at all, just I have done it both ways so I already have the diskette and a plugged-in TEAC/IBM USB diskette drive, etc.

22. Click Finish.
23. When the System Settings Change window appears, click Yes. The computer
restarts.

Yes, and you are nominally in the same exact place save the IMPORTANT DIFFERENCE:

The first way when you set the BIOS to compatible XP will crash when it tries to come up, and I don't know any way to fix that.

The second way it comes up in either compatible OR AHCI.

The rest of the answers in a separate [and much shorter!] followup.

cjl

[clasys]

OK, to your points:

1) The only way to boot a CD [other than an XP or similar disk] on the T400 is to set it to compatibility mode, NOT AHCI. On some machines, the access to the rest of the CD comes about after DOS loads a driver floating around derived from Gigabyte that generally works. [If you have a bootable DOS CD, it has to be able to access the rest of the CD itself, not the virtual diskette part that is the A: section. The MS-DOS MSCDEX is how you get access to the rest of the disk, but you have to first load a driver to talk to the specific hardware. On most machines that GCDROM.SYS is what applies. But not on T400, etc. this works by being more "compatible" in a way no other manufacturer does. This fakes out the IDE CD-ROM driver to believe the hardware is true-blue IDE and the CD-ROM main portion is fine this way. I have a utility DOS bootable CD with GHOST and Partition Magic, etc. not to mention it is the whole-nine-yards MS-DOS and not just the boot floppy used to make the virtual A: portion, etc. That way, I can setup the disk, partition and format it, use Ghost to recover or back it up, etc.

So, yes that's the only general way to do it. However, you do NOT have to do that step in compatibility mode if your media contains XP or newer itself per se. This still has nothing to do with any subsequent problems. But if you need access to a CD-ROM and you are not booting to XP itself, there is no other way to do it, ever. Clearly I use this disk and related stuff a whole lot. There are many CDs that have the same exact restriction, but perhaps not many are familiar with them.

In any case, this is pretty much contrary to the way the rest of the industry works. If the hardware MUST operate in a raid, it is impossible to access a CD from DOS because you cannot operate the hard disk in compatible mode. [Note: I have worked on Dell machines where you CAN access the disk in compatible mode as long as there is only one hard disk as most have, but technically the machine supports a two-disk raid and then the compatibility mode is not allowed, etc. [And I cannot use my boot disk there at all because only the compatibility mode supports the Gigabyte driver; in that sense the T400 is better because you don't need the extra driver, but you do have to change the BIOS on both machines, etc.]
Thus, having an internal RAID in a laptop is inherently compromised in terms of rational backup choices. Better to use an external SATA RAID of external disks if you really want that and just have a smaller boot disk; the higher performance will be performed from an operating system you can backup and restore; the data would then be on entirely different partitions and actually different hardware to be dealt with only when you are certain the operating system itself can be trusted, etc.

You have the bootup issue correct. If you use the first method as described, then the O/S crashes if you leave it set to compatible mode; you have to remember each time to set it back to AHCI first. This is a compounded problem if you do things such as I do booting up say a few times in a row between Windows sessions, so you have to switch it back and forth each time a bootable CD is in the picture between Windows booting, etc.

But it's all avoidable if you use the "alternative method" because yes, that boots fine in either setting of the SATA config in the BIOS. Thus, this is NOT merely an alternative, it is clearly preferable because it does more, not different or less like the other first more "usual" method.

I know this shouldn't be, but it is observable fact. I am hoping that someone in Lenovo can be "leaned on" [I have no pull there, perhaps someone here does.] to review this mistake; perhaps some after-the-fact thingie they forgot about could "upgrade" the drivers within XP so that it is more "tolerant" of the settings the way the "alternate" method does. Perhaps someone knows enough to look where the differences might be [in the registry? and all of this could be fixed by just a quick .REG file registry patch?]

I gave the file's contents, but of course you can get the entire IMSM file on their website, etc.
Just go here: http://support.lenovo.com/en_US/downloa ... D=DS000795

You may be right about the other ThinkPad, but I think you have found the same problem and it's the same root cause. In any case, the key issue would be this: Did you use the F6 method and OEMSETUP diskette to install in AHCI mode? It's all downhill from there. Using compatibility mode install has to work and then the drivers are added merely to make Windows THEN get "smarter" about SATA, but apparently the "path" to getting there matters, despite the obvious assumption it ought not to!

In any case, clearly the "alternative" method is NOT "wrong" and has the side-effect bonus of eliminating the BSOD problem should it exist while the other way just invites predictable problems; do your own due dilligence per model to see what does and does not apply. However, I see no problems whatsoever for the vast bulk of models that just are not RAID-worthy or even RAID-possible.

And clearly on machines such as the T42,they made sure that there is no AHCI versus compatibility issues; the SATA is only there "internally" as there is a SATA->PATA convertor after the SATA hardware, so on that machine you have the grief of adding in SATA manager drivers, but no relevant SATA devices extant to even use. I have read of some home-brew modifications that would set the stage for this problem as discussed here to then surface, etc.

[I am not going to hack into the hardware and/or the BIOS; enough problems just working with it as it exists!]

cjl [Hopefully that clears some of it up]

[dr_st]

Thank you very much for the detailed write-up. It makes perfect sense. After reading your post, I went back and checked, and turns out my findings are consistent with yours - I was just confused.

I have two T60 machines with XP, where the SATA is configured to AHCI in the BIOS. I clearly remember a BSOD issue if it is accidentally changed to IDE. Here's why:

On my personal T60 I installed XP myself, in compatible mode. I knew about the F6 option but didn't want to bother and didn't have a floppy drive. Then, since it is said that AHCI (in theory) improves performance, I injected the driver post-installation as detailed in your post. I just checked, and this machines does not BSOD, and XP boots fine whether SATA is set to AHCI or Compatibility.

On my other, corporate T60, I do get BSOD when trying to work in Compatibility mode. That machine was not installed by me, and I can only conjecture that they used the F6 or similar method to inject the SATA driver during the initial install. It makes sense that after doing so, the Compatibility mode won't boot because this way the XP installation never put the IDE driver there in the first place!

So, you are 100% right that the post-boot option is superior - this way you get both drivers in place, and either mode will work.

XP in general is a very finicky OS when it comes to IDE controller drivers. I will go as far as to say that the entire mode in which its installation works in regards to these drivers is heavily flawed (thankfully in Vista/7 Microsoft seems to have remedied it somewhat - to date XP remains the most finicky Windows version when you try to move it around between different hardware).

A friend of my works in IT and a while ago had spent a lot of time trying to prepare an XP image that would boot and run on a variety of platforms. This is of course very difficult, since if you move it to an IDE controller for which XP has no driver, it will BSOD. Manually running Sysprep or equivalent for every new platform would defeat the purpose of having a common image.

The solution he found clearly explains how dumb the XP installation is. What he did was to first install the OS on a platform so old/generic/obscure, that XP had no driver for its IDE controller. As a result, it would install the most generic IDE driver in existence. This driver would not get installed if XP had recognized the platform during the installation. Only by presenting it with a controller it did not recognize, the OS would try the generic solution.

Now, once the driver with that generic driver is cloned, turns out it would boot just fine on 99% of the IDE controllers out there, whether PATA or SATA set to compatible mode. Once booted once, for that specific installation one could install any specific SATA/AHCI/RAID driver and XP would continue to function. But should the drive ever get moved to a new platform, the presence of the generic IDE driver would allow it to at least boot in compatibility mode without BSOD.

[dr_st]

Now, to address your other point - about booting from CD when in AHCI mode.

If I understand you correctly - the problem is that the T400 CD drive, which is SATA-based does not get detected by DOS ATAPI CD-ROM drivers, and as a result, many legacy bootable disks will fail to boot?

However, the newer bootable disks, which do not rely on a DOS boot sector (such as XP or newer Windows or relatively new flavors of Linux) will boot fine. Am I right?

This situation is bad but understandable. I think this is why some desktop BIOSes allow you to set AHCI/IDE modes separately for each SATA port (or autodetect the port and force it to IDE if an ATAPI device is connected). It seems that they could have / should have implemented something similar for the SATA ultrabay on the Thinkpads.

I never ran into such issues with my T60s (which are set to AHCI). Not sure if it's because I haven't tried bootable media which relies on DOS drivers, or whether because the Ultrabay is PATA.

Final remark: you mentioned T42, but the first Thinkpad to have SATA (masked by the SATA-PATA bridge) is the T43. The T42 only had legacy ATA.

[clasys]

Yes, I meant the T43; the T42 is the last nothing-but-IDE machine, etc.

The odd thing here is that many machines can access the main contents of the CD during the DOS virtual floppy portion of the CD boot process by using the Gigabyte driver GCROM.SYS which saves the day at all, but usually it depends on being able to set compatibility mode. On any SATA situation I've seen, that means SATA Raid is out of the question. But many people only use one disk, thus it defaults back to more a matter of performance and not disk contents, etc.

But the T400 makes the IDE drivers associated with the 98SE boot disk [that is generally what DOS-type bootable CDs are based on] be faked out completely fine when the BIOS is in compatibility mode and the GCDROM.SYS driver completely fails! Thus, all of my boot diskettes and DOS-type BOOT CDs have both drivers [actually the laundry list of them; that's the way it always was released, so why not just leave well enough alone; I just added on the GCDROM.SYS driver first].

In my experience, the bloated factory preloads will crash in compatibility mode, thus even their own installs are as flawed as I pointed out, and of course it could have been avoided.

My only open issue is who/where to contact in Lenovo to make a complaint that wont fall on deaf ears to point this problem out so that a post-install fix can be worked up so that either method [suitably modified] WOULD in fact be equivalent. And of course, anyone can complain because this is a factory install issue; if you do your own installs and you screw up, that's YOUR fault! Hopefully I have helped people with how to tell the difference and at least next time you won't have this problem [but we need THEM to fix existing installs!].

With regard to a dumbed-down image, isn't there some equivalent trick as we did in the 9x days to trash the ENUMerated hardware section of the registry so it is obligated to figure it out each time, thus will come up very generically? [It would have a lot of plug-n-play discovery, but I assume that would work?]

A side subject: Over the years, some installs were problematic in that it really had problems recognizing things. One stands out was an HP machine with a modded name-brand chip maker's [Nvidia?] video section that could not use the original drivers. Windows Update could get you a proper driver eventually, [and it correctly identified as an HP modified whatever] and less troublesome it also couldn't figure out the sound at all.

The point is this: It was really a PITA installing it in 640x480 2-color mode! [No sound was minor.]. Yet, when I installed a second operating system on it [after the first one had some drivers figured out the hard way] the second install "stole" info from the first one and got "smarter". During the install I had 800x600 256 colors [much better!] and initial sound support that worked. Even Windows Update was able to dredge up the correct final drivers from that point [on the first install on the other partition it never could!]. So, since I hadn't really done anything beyond the 39 minute install on the other one, I wiped and did the first one over after Windows Update had fleshed out the drivers on the 2nd. And of course the new 1st was as easy.

Thus, in the above scenario about using a dumbed-down generic installable image disk, unless there was that other installed system smart enough to "help" it would just stay with unacceptable video on this particular HP machine! [Of course, you are ultimately responsible for locating the current drivers on any machine!]

CD booting a bit more:

As long as you don't need to access the bulk of the CD-ROM itself, and all you need is a virtual diskette, it works fine on just about any machine, but that means 1.44 MB unless someone has a way to better fake 2.88 MB diskettes.

I use Ghost 11.5 DOS on the boot CD which in and of itself needs a bit of discussion:

As of 11.5, it pretty much finally works. Along the way [going back to the 5.5 days] there have been so many bugs that for awhile I refused to use anything newer than 8.3 [11.0 was a step up in performance if you could get it to work, but very unstable in terms of GETTING it to work!].

Symantec added some "features" in 11.5 that allow you to make various boot CD versions, one is linux and the other is WinPE for Vista with various amounts of drivers built-in. Ultimately it does run Ghost 11.5 as Ghost32. However, the linux version has no means of modifying it and the WinPE one would be fairly difficult to modify.

Often the DOS one runs faster [you'd think it would be the reverse] and the MB/Min figures don't lie.

More importantly, the DOS version makes it quite easy to integrate BATCH operations that support Ghost with command-line options.

One of the problems we all have is when you give out a support disk in a situation where some panicky newbie is the only one on-sight you know the worst case could easily happen: a) Instead of backing up important work as it is currently is [with no backup] they will accidentally restore an obsolete one over it! b) They will fail to back it up with some problems even though you need it to diagnose what is wrong with it [malware perhaps] and want them to back it up and temporarily use a viable backup for the immediate present. And of course they'll fail to back it up and maybe even restore it i) the wrong backup, or ii) not at all.

You can't always be there at that critical moment. But Ghost for DOS is that rare animal that by being LESS automated allows a total fix:

You can create a very simple old-fashioned menu system [mouse-driven] that simply states what do you want to do right now, and better still, it can have as many hand-holding safeguards as you feel the user needs/wants to make them warm and fuzzy and comfy to more likely not screw up. Log files can be created incorporating the current date/time into the file name so you have proof positive that the proper backup/restores were done.

They have to read and respond correctly as you force them to jump through appropriate hoops. Unlike Windows, they have no choice of something else to click because unless they pass your screens and responses, they can do no harm, etc.

You can do similar with GHOST32 in Windows of course, but that presupposes there *is* a working Windows, thus the beauty of using the DOS version.

Thus, they can just follow the directions, forcing them to read just the right amount you have decided is "good for them" and they can sit back, relax, and watch now-automated GHOST do its thing and automatically exit. And of course, the batch could be as large and elaborate as you need, such as multiple partitions being dealt with intelligently.

And all you need to do this is batch file tailored to each user and burned on their disk that is otherwise 100% the same as everyone else's, etc.

I generally give users two copies of the O/S, one for maintenance-only. But if the partition table gets blown, they are screwed without the boot CD; perhaps all they'll ever use it for is to restore the maintenance-oriented Windows which in turn has all the Windows-oriented Ghost batch files, but that's just a collection of clever and friendly icons that run similar GHOST32 batches; you can be as ornate as possible.

But a key point about backup and restore programs is no one ever figures in the hand-holding [or lack thereof] factor; there is no one size fits all, nor need there be. But without a DOS boot CD you can't get there!

[Ghost32 on one bootable partition cannot backup itself, but can backup the other one and vice-versa; either can backup all data partitions; all are dead if the table gets blown; the boot CD can put back the maintenance partition to allow the normal partition system and/or data to be managed. Therefore in theory, there is nothing that cannot be gotten out of even with hardly-qualified people on site.]

cjl

[twistero]

I find it hard to believe that you can't modify a Linux boot disk, and putting extra stuff into WinPE should be even easier. But then again, I don't use Symantec Ghost, so who knows.
If you want to boot DOS from CD-ROM in AHCI mode, here's something to try: Make a plain hard disk image large enough to hold Ghost and whatever extra you want, put that image on the CD, and use the ISOLINUX boot loader and its MEMDISK module to load the hdd image into memory and boot it from there. The software will run entirely from memory, and you can even remove the CD after that if you wish.
(But then you may find that DOS cannot access the internal SATA hard drive in AHCI mode, so it doesn't do you much good. It may be worth it to migrate to the more advanced boot disk formats, since all future machines will be SATA, and even the "compatibility" BIOS setting may be gone soon.)

[jdrou]

and putting extra stuff into WinPE should be even easier.

I think the best way to build a generic WinPE is to use DriverPacks (http://www.driverpacks.net ) which includes basically every relevant storage driver which exists for Windows XP/2003.

EDIT: At least the T400 can be switched to IDE mode; my stepdad's Vostro 1000 doesn't even have the option. It's simply not possible to use the CD in DOS at all. This combined with the limited support for USB means moving away from DOS-based solutions is something that is necessary, much as I wish it weren't.

[clasys]

I am having problems getting Symantec's version of WinPE to accept drivers in any meaningful way. I did "everything they said to do" but I am not holding my breathe as to how accurate that is, etc.

In any case, they describe a procedure as to how to add an MSCP device but it won't access the device [a PC-Express E-SATA card that I can in turn hook external SATA devices to], and I really don't know all that much of this particular corner of the universe [WINPE is of the Vista era]. Any specific pointers as to how to add this onto an otherwise existing WinPE [Symantec's] would be appreciated.

With some effort, I can get the command-line aspects of GHOST32 to run from this environment, but I would still have to create any levels further "up" from there myself. DOS makes that a whole lot easier.

In any case, with respect to the T400, all can be done either way; if someone can get me my e-SATA support into WinPE that would effectively "tilt the scales" in favor of the direction newer machines will likely force me to as stated, etc.

cjl