Jump to content

Recommended Posts

Posted

I have just taken delivery of 30 dell machines which all have dual core procs. i have tried to image them using ghost and it wont boot, keeps looping.

 

I know that the immediate responce is hardware issue but we use a product called UIU (made by Big Bang, google it) which removes the hardware issues.

 

I think that it is due to moving from a single core to a dual core.

 

anyone got any eperiance of similar or know how to remove the core issues from a windows installation with the disk set up as a slave, therefore allowing access to the file stucture?

 

Oh, also, the new ones are Sata old ones Pata however this has never caused a problem before.

 

please any discussion, help, adivce etc more than welcome as a bit stuck on this one. Might have to start from scratch and insall all software again!!!!

Posted

Hah, this takes me back..um..IIRC, I had a batch file, the HAL.DLL, NTOSKRNL.EXE, and..no, I'll have to look that up again. I did the "slave disk, change files on slave disk" thing too. I had a dig around the XPCD looking at th different HAL files and the loaders for them, then wrote a .bat to rename/decompress them accordingly on a USB stick, so I could copy them over.

 

In the end, I just did the base ghost as a "standard PC" one that'll run on anything, with a sysprep line to sort the HAL out for itself on first boot. I looked at the UIU as well, but TBH I've not seen anything that my method has failed on yet.

Posted
I have just taken delivery of 30 dell machines which all have dual core procs. i have tried to image them using ghost and it wont boot, keeps looping.

 

I know I couldn't get our new Vostro 200 Dell PCs to boot from SystemRescueCD initially, I had to switch the SATA harddrive to "legacy mode" in the BIOS settings. Might be worth a try for your situation too.

 

--

David Hicks

Posted
I know I couldn't get our new Vostro 200 Dell PCs to boot from SystemRescueCD initially, I had to switch the SATA harddrive to "legacy mode" in the BIOS settings. Might be worth a try for your situation too.

 

--

David Hicks

 

Almost certainly right (especially as the old machines were parallel IDE).

 

Look for something to do with OHCI in the BIOS and try turning it off if it's there. It will make the machines marginally slower but should get you going!

Posted (edited)

The following KB article tells you able the various HALs avalible.

 

http://support.microsoft.com/kb/309283

 

Basically Single CPU and Dual Core CPUs use different HALs. At worst, the machine wont boot. At best, you'll be missing a cpu.

 

You will need a new image with the correct HAL.

Edited by Geoff
Posted

Another thing to look out for, on new Dells at least, is the HDD setting in the Bios. I was pulling my hair out yesturday when i used a Optiplex 745 DC image on a Optiplex DC755 and had BSOD both after ghosting and trying to run XP setup from CD.

 

Went into the BIOS and changed the HDD settings from AHCI to ATA and it booted into windows fine.

Posted

Right..ok..lets see if I can recreate this on the fly. I deleted the bat months ago when I realized the versatility of making the source workstation a “standard PC” HAL based one before sysprepping it, and having sysprep choose the best HAL for me..

 

I used the XPSP2 CD (for XPSP2), XPSP1 and RC2600 discs. The HAL seems to alter slightly between versions. Get the right ones off the right CD for your intended version.

 

http://support.microsoft.com/kb/309283

 

^^ as said, that page lists the HAL files for differing types.

 

Find them on the CD (in their compressed form, they’ll be “.dl_”). Copy them to a directory, and copy expand.exe (or is it extract.exe? One of those.). Run “Expand(or extract) hal.dl_ hal.dll” to decompress them changing the names for each one.

 

Then I wrote a .bat to ask me which one I wanted, and act on my choice to copy the related HAL file to the target disk, renaming it HAL.DLL on the way.

The files and BAT file sat on my pen drive, and I booted the machines with the pen plugged in, using PEBuilder.

 

It DID work, quite well..but then I did a bit of digging and found that simply doing this made life much easier:

 

Boot a working PC with the build/image on you want to deploy.

Log in as local admin

Disjoin the PC from the domain

Go into control panel, system, device manager, and expand “computer”

Right click on the expanded computer branch, choose “Update Driver”

Tell windows to get stuffed, and select “I’ll choose..”

From the list, pick “Standard PC”..nothing ACPI or in any way advanced, just the bog-basic Standard.

Reboot when asked.

Log in as local admin, let the machine do all of the hardware redetect, and so on.

Uninstall any and all “non-already-on-the-WinCD” drivers..no extra video, sound, or anything. Even if you have warnings in Dev manager, ignore them.

Copy your Sysyprep setup to c:\sysprep, run “sysprep –BMSD” from CMD to populate the mass storage. Then open the sysprep.inf and add this under

 

[unattended]:

UpdateUPHAL=ACPIPIC_UP,%systemroot%\inf\hal.inf

 

Close file, run Sysprep with the reseal, don’t reset grace period, and no activation” boxes ticked. Once done, ghost it and deploy to a test rig.

 

That's all I do for ours..and as I say it runs on P2 to P4HT, AMD Duron-AMD Athlon X2, Celeron D - C2Ds..not had it baulk at ANY of our kit since. I keep a "non-domain" simple image ready for staff PCs as well, so if I get a staff machine "needing a reinstall", I can hand it back in 20 minutes.

 

We use that same domain image on our virtuals..it seems to be fairly indestructible..

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...