I had run into this when trying HII . For me at least, when imagineg Dell's, I had to set the BIOS ATA/AHCI settings. It imaged ok for me then. Also, is the chipset AMD? If so this article may be what you are looking for?
But I never really got the HII to run well, might be time to look back into it since updating Ghost images with patches is a huge time killer
Okay first, i have to say that this link is not working ;-)
but this is no amd chipset
but it's very strange because my first sysprepped Hi Image worked very well on this pc type
i customized this image and sysprepped it and captured it , and this is not working
i can't understand it
What is the blue screen code? If it's 7B we know the problem is mass storage drivers.
If the problem is wrong HAL, then the "typical" symptom is machine hangs (black screen) before it gets to the WinXP splash screen. But there are probably several possible symptoms.
I wonder why you decided to change the HAL type to ACPI. You don't say what your hardware is, but some of the newer computers will no longer work with the ACPI HAL. When you do a bit of research on the subject, you still find many articles that recommend forcing your master computer to the ACPI HAL. Ignore them. Things have changed and this is no longer a good idea now - although it shouldn't matter if you are using halconfig (one of the tools in the HII toolkit) in what the HII 9.1 document describes as "the new process".
okay there is no 7K screen....so it think it's not the mass storage driver
it's more like black screen and then the windows splash screen.
so i will look again for this manual hii 9.1 and try to customize my image with no acpi config.
i will tell if it has worked for this image
Okay i customized my image and i didn't configure the hal.
so on my base image the hal is acpi uniprocessor
I also had a closer look at the HII 9.1 manual, and the new process says that i don't have to downgrade the hal and it will work with any hal on the base image
i checked that there is a SP3.cab under C:\windows\drivercache\i386 and in my provisioning template there is an action HalConfig.exe /cab=sp3.cab
so it has to work right ?
I put my Template in this discussion.
HII Dispo_AVN.xtp 17.4 K
Looks fine to me... Does it also work?
Nope it does not work....now i modified my image with ACPI Multiprocessor and i'm trying it again right now
i can give you a log file from the configure hal action, maybe you can find something in this log file
i put the logfile in this discussion
and i will tell you if it has worked now when it's finished.
thank you very much
It is not working with ACPI Multiprocessor
now I'm really stumped
1 of 1 people found this helpful
I can see nothing unusual in the halconfig log... HalConfig is copying the multiprocessor HAL files.
We've never established that this was a HAL issue in the first place. It's not clear from what you are saying how and when the machine is crashing. Does it get as far as the WinXP splash screen? Can you press F8 and select safe mode? Does it hang? Does it blue screen? Does it reboot itself (reboot loop)?
If you are seeing the splash screen, then my hunch is this is not a HAL problem. Indeed, if your target machine is multiprocessor and your source machine is virtual (i.e probably using uniprocessor HAL), then it's actually quite hard to get yourself into trouble hal-wise. You would have to -1- force your source machine to ACPI HAL -2- not use halconfig /cab= -3- deploy to one of those newer machines that no longer tolerate ACPI HAL. Unless you get it wrong on all 3 counts, your machine should at least boot because, as you will remember, uniprocessor and multiprocessor HAL are compatible. So even if you do nothing (no halconfig, no forcing hals), an image from your source machine (uniprocessor hal) should boot on your target machine (multiprocessor hal).
One thing I do notice in your InjectMsd log is that no .reg file was processed. This raises a question. Either, as you write above, the mass storage drivers are included in your image (SysprepMassStorage section and so) and you don't need InjectMsd. Or they aren't and you do need InjectMsd. In which case you need to use it correctly or it's not going to make a difference.
looks like i have found the fault...
i was creating my hi image completely new now and i was running a sysprep
i created my sysprep.inf with the command -bmsd (do i need this when i will use injectmsd?)
after the sysprep i tried to start my master image and i get a bluescreen, so i don't wonder why there is a blue screen when i try to deploy that image.
so what went wrong now.....do i have to do the sysprep without the mass storage section in the sysprep.inf ?
or do i have to put my driver files in the mass storage section ?
for example ?
or do i not need this stuff when i use the capturemsd and the injectmsd stuff ???
i was running the capturemsd.exe file now on all the machines i want to deploy my image and now i have a regfile....
maybe you can give some tipp here..
thanks a lot
i think i found my fault......now i created the image and ran sysprep without the mass storage driver section....and now it works and the
deployed pc's are running through mini setup
now i use the capturemsd and the injectmsd stuff and it works.....yeahhh....
thanks for the good help....it helped me a lot to find my understanding problems :-)
thanks a lot
If you had a correct [SysprepMassStorage] section in your sysprep.inf, you should not have needed injectmsd. If it took injectmsd to make things work, that can only mean you didn't have a correct SysprepMassStorage at the time you ran sysprep.
Note also that you don't have to make choice between SysprepMassStorage and injectmsd. It's perfectly OK to use both. The guideline should be: think of injectmsd as plan B. Plan A should be to include al the mass storage drivers that you are going to need in the image, correctly enabled with a SysprepMassStorage.