Thomas, I suspect Jan has it right. (Wouldn't be too surprising if he does - he wrote the book after all!) A useful test would be to try your image deployment after setting the T400 machines' BIOS to disable AHCI mode. This should allow the laptop to reboot successfully after imaging. Doesn't solve your problem though, just confirms that you're struggling with SATA drivers.
Check the HII Toolkit (referenced above in this discussion thread) and in particular section 6.4.1 - the part that talks about a third party script to enumerate all the mass storage drivers in your driver library. We use the HWIDS script and it works great! After running the script just plug the Device ID's into the [SysprepMassStorage] section of your SYSPREP.INF file.
(Note: The [SysprepMassStorage] section is processed during the initial phase of SYSPREP - before you save the OS image to your deployment share. It doesn't help if you add this section to the SYSPREP.INF file that LANDesk injects during the imaging process. It has to be there on the machine when you're creating your OS image.)
Just a further note about Mass Storage drivers, in particular with Lenovo laptops that we've imaged. Adding the downloaded drivers to your WinPE image should be fairly straightforward - just add the SYS and INF files as per LANDesk documentation. The trick with some of our Lenovo laptops is that the TXTSETUP.OEM file that comes with the Lenovo driver does not list the correct hardware ID for the specific laptop you are trying to boot with WinPE. The result is that you can boot into WinPE but if you open a console you'll find that C: drive is not available. This is not specific to the problem that Thomas Collignon reported, I just mention it in case you arrived here because of problems getting WinPE to recognize your SATA drive. Again the HII Toolkit provides guidance on how to modify TXTSETUP.OEM.
Thanks Jan for writing the HII Guide and for keeping it up-to-date!
Jayson
Hi,
Thank you for your response, Jan and Jayson.
Small clarification: The blue screen appears after changing the three files for the Multiprocessor HAL under WinPE.
If I did not change the files, I have a black screen just after the restart of the job.
Here is the message (nothing to do with an error 7b):
"STOP: c000021a (Fatal System Error)
The Session Manager Initialization system process terminated unexpectedly
with a status of 0xc000003a (0x00000000 0x00000000).
The system has been shut down. "
It can not therefore be the drivers for mass storage, which are the same that I injected into WinPE.
I had a test with an image with the HAL type is set to "ACPI Uniprocessor", in which case the sysprep is done properly.
The problem is therefore the HAL.
Other models Multiprocesseurs works properly with the image with HAL "Advanced Configuration and Power Interface (ACPI) PC". Only the model Lenovo R400.
The problem seems to be known on the Lenovo forums with Lenovo model T500, R400, W500, etc....
Regards,
Thomas.
Thanks for the clarification Thomas. I think you may be right - this does start to sound like a HAL problem. In fact, it sounds very similar to the problem I was having with our new Lenovo T-500's when I started this thread in the forums. My solution is described in post number 8 in this thread. I attached a modified "updateHAL" VBS script to that post. It works a bit differently from the standard one in the HII Toolkit - rather than just set a line in the sysprep.inf to load a specific HAL at next boot, it actually replaces the HAL files on the system drive while in the WinPE environment, based on what was detected by WinPE.
Just to summarize the problem, as I understand it...
The HII Toolkit states that almost all modern PC's are compatible with a base HAL "Advanced Configuration and Power Interface (ACPI) PC". They recommend that you build your image on a machine that uses this HAL, or force your image building machine to use this HAL. The toolkit documentation notes that Win-PE can always detect and load the correct HAL, and that SYSPREP.INF has a mechanism to change the HAL at first boot. So the kit includes "updatehal.vbs" which determines which HAL was loaded by Win-PE when you image another machine, and then sets SYSPREP.INF to load that same HAL on first boot. Since it is believed that pretty well any modern PC can at least boot with "Advanced Configuration and Power Interface (ACPI) PC" then everything should be fine - the system reboots, the syprep.inf file is processed, and the HAL is changed. The problem with the T500, and probably the T400, is that these laptops are not compatible with base HAL "Advanced Configuration and Power Interface (ACPI) PC". The system reboots, the HAL fails, and the sysprep.inf file is never processed.
Thomas, you stated that you changed "the three files for the Multiprocessor HAL under WinPE". Can you confirm a couple of things...
- Did you copy the three HAL files to the "%windir%\system32" folder on the system drive? (Just to clarify - that is drive C: under WinPE boot. I guess technically the system drive under LANDesk WinPE boot is "X:", but that's not where we want to copy the HAL files).
- Did you copy the correct files for "ACPI Multiprocessor PC"? That's the HAL that our T500's are using - I presume it's the same for T400's. The three files for that HAL (refer to the HII Toolkit Section 4.1) are "hal.dll" (original file name "halmacpi.dll"), "ntkrnlpa.exe" (original filename "ntkrpamp.exe") and "ntoskrnl.exe" (original filename "ntkrnlmp.exe").
I think that should do it Thomas, unless you've come up against a Lenovo hardware anomaly that is different from the T500's that we are imaging. To test this you should be able to copy and rename the HAL files manually on the C: drive under WinPE, or if you are following the HII document, and if your WinPE environment supports VBS scripting, you can try my modified version of "updatehal.vbs" which automates the file copying and renaming.
Apologies if I'm just telling you a bunch of stuff you already know from reading the HII documentation. <G>
Jayson
What seems to have happened is that the intel montevina chipset, so far only to be found in recent Lenovo laptops and Dell tablet PCs (but presumably on its way to becoming standard issue), is no longer compatible with the standard ACPI HAL. It will only run the the uniprocessor or multiprocessor HAL.
Looking at Jayson's UPDATEHAL.VBS, it seems to me that it really should do the job. I don't have hardware to try it out on, but the logic seems impeccable. This really should work. Other people on several forums suggest the same solution. If it doesn't work for you, then debug the situation as per Jason's suggestions above. Double check that you have the right versions of the 3 HAL files in the right place.
The current version of the HII paper no longer uses updatehal.vbs. It uses a compiled autoit script (HalConfig.exe) instead. I'll publish a revised version of it in the next few days.
A simple workaround if you're using HII V9 is usurp a feature of InjectMsd. As per documentation, injectmsd takes one command line parameter: a folder in which to find the mass storage driver files. If that folder has a subfolder called windows, that subfolder will be copied recursively to the target's windows folder. Even if you're not using injectmsd to inject mass storage drivers, you can usurp this feature to inject the correct HAL files.
Although the VBScript seems to work, an auto-it script enhancement would be ideal. I really like the fact the v9 does not require any WinPE modifications, such as loading WSH (other than the typical NIC and SATA Driver issues). Please keep us posted on your progress Jan.
Thanks!
| ||||||
