Jump to content

Change the HAL and add mass storage drivers


Mordac85

Recommended Posts

The version of UIU I was using that would do all of the HALs and SCSI was from March/April timeframe this year.

Sounds like they have gone backwards since my testing earlier this year. Sad if they have, the version I had worked very well for what we wanted to do.

I don't think that work will let me use ntldr from vista beta 1. And I suppose the detecthall switch is not in XP. So I guess I'll be stuck with the slightly more dificult methods.

About UIU: You really give it too much credit. Granted, they do a fine job on most systems... possibly all pc's in your company, but they will NOT detect just any Hal (or have just any driver issue resolved for just any system, which I know you haven't stated)

If you read the documentation of UIU (even that of march/april) you can read under the topic troubleshooting that when you've captured an ACPI image and deploy it to an non-acpi system, it will crash on boot. So you would still need 2 images with UIU, like I said before. UIU is therefore not really "universal", which they like to claim.

Other things they admit they cannot do is:

- deploy to RAID

- capture from SCSI and deploy to IDE, Pata/Sata

They also have missing/incorrect mainboard drivers sometimes, which crashes the deploy pc. And driver bangs (missing drivers) for bleeding edge hardware is also an issue.

About the longhorn NTLDR: You could use it only once and swap back the XP one on second boot once the HAL is properly detected and installed. If even that is out of the question, then use the method of WinPE reg HAL detect/swapped described in my long post. If you're not allowed to HAL swap at work (because it DOES break MS support!), then be prepared to make and manage multiple images... and also throw the word "universal" out the window, because it is simply not applicable anymore.

indeed, the "/detecthal" switch only works on Longhorn beta 1 NTLDR. XP's NTLDR is unaware of it.

extract all kernels to system32 folder

What do you mean extract all kernels? I thought there was only one so could you be more specific?

And I take it the Longhorn Beta 2 that's out there now won't cut it, right?

This is really an interesting topic for me. I know there are several commercial solutions out there, but I can't see paying the money for something that can be done just as easily w/a script or utility. Plus, I'm always intrigued by finding out how it works under the hood.

well, I mean kernels like: ntkrnlmp.exe, ntkrnlpa.exe, ntkrnlup.exe and ntkrpamp.exe

Yes, sadly Vista Beta 2 is of no use for us in this HAL swap thing.

Edited by Scrapple
Link to comment
Share on other sites


is there someplace that all of the switches for setup.exe are, I'm referring to the one which is run on first boot after sysprep is run.

-newsetup

-mini

are the two I know of off the top of my head, are there others that might do things that would help this effort?

Well factory and audit mode exist, of which factory can process winbom.ini (like winpe), but even if some secret setup.exe parameter existed... it wouldn't be of great use for switching hals, because XP has to be almost completely boot up, before it kicks setup.exe. If you had captured an image with a hal that was incompatible with the deployed system... it would've never even made it that far into the boot-process and would just reboot/blue screen before it could detect the HAL... and THAT is exactly why UIU has a big limitation and detecting/swapping the HAL with WinPE/BartPE is the way to go.

BTW, msoobe.exe is usually the program that's run with the cmdline reg-entry on a new system... most OEMs use it to enter the WinOOBE mode many of you are familiar with.

Link to comment
Share on other sites

As far as the UIU, I built my test image on an ACPI system and deployed it to the Standard HAL, ACPI uni/multiprocessor HAL, ACPI without any problems. These machines ranged from a Dell GXA to the current Lenovo M52 desktop, there were a few drivers missing on the newest machines but all it took was a phone call and a days wait and they gave me an update to their driver pack.

The driver issue I've had with BTS's packs also so it's not a complete solution for drivers either.

I did not try going from SCSI to PATA/SATA but I did go the other way without issue.

The only driver issue they could not solve was for the TPM on the thinkpad systems which was not properly signed by the manufacturer.

I don't think that HAL swapping would be an issue but using beta compinents usually is.

Link to comment
Share on other sites

well, I mean kernels like: ntkrnlmp.exe, ntkrnlpa.exe, ntkrnlup.exe and ntkrpamp.exe

I knew about the various HAL's being used to create hal.dll, but I never thought they did the same thing for the kernel. Are there any references, that you know of off the top of your head, for which one is used in a particular instance?

So we'd have to include placing the correct kernel as well as the HAL? Doesn't seem like a major deal, unless there are other supporting files that follow the same concept. Thanks for the tip.

I think the premise of making this switch via a script, or coded utility, is possible. Granted MS won't touch it, but I never bother with that avenue anyway cause it usually takes way too long to get a resolution. I think I have enough to get started, now I just need to find the bandwidth. :}

Link to comment
Share on other sites

As far as the UIU, I built my test image on an ACPI system and deployed it to the Standard HAL, ACPI uni/multiprocessor HAL, ACPI without any problems. These machines ranged from a Dell GXA to the current Lenovo M52 desktop, there were a few drivers missing on the newest machines but all it took was a phone call and a days wait and they gave me an update to their driver pack.

The driver issue I've had with BTS's packs also so it's not a complete solution for drivers either.

I did not try going from SCSI to PATA/SATA but I did go the other way without issue.

The only driver issue they could not solve was for the TPM on the thinkpad systems which was not properly signed by the manufacturer.

I don't think that HAL swapping would be an issue but using beta compinents usually is.

Sure, it's possible to check the "Install Standard HAL" checkbox in UIU before you capture the image. It will install perfectly on most any system, but with very limited Advanced Power Capabilities on ACPI machines afterwards and lower performance for Hyperthreading machines.

But... I have the feeling you're gonna tell me you deployed a real ACPI image to a non-acpi machine and suffer no APC disadvantages. :-) If you succeeded in doing that... that's really "wonderful?" and pretty rare scenario... but it's really not something UIU anticipated on or even supports, let alone MS. Because HAL/Kernel wise it would be the most undesirable situation you could boot a pc under... HAL-wise, that is. It will drastically affect the way some drivers communicate with the hardware. I would be very surprised if it would even run stable.

I very much agree on the BTS packs... they are not the be-all-end-all solution. It needs updating and sometimes tuning too... but you can do it yourself...offline... so you don't need to include/update them IN the image, which is a big plus.

Yes, PATA->SCSI works flawless with UIU. They state/support that. I wouldn't expect any different.

About the thinkpad:Exotic unsigned drivers (usually laptops) will always be a pain in the a**... I've had my experiences...:-)

I wouldn't use the longhorn NTLDR in a heavy production environment too... but it works and is a pretty novell way of doing HAL detection/installation, so that's why I shared it with you deploy geeks... :-)

How much do you pay for the UIU license per seat if I may ask? I thought it was something like $19 dollars or $10 bucks high-bulk. For some that is cheap... other might find it very expensive... the same goes for Acronis and Symatec's solutions.

A tip: You could also write a tool like UIU yourself... check ta.exe (from XP Embedded) for hal detection and rundll32 or devcon for hal installation. And sysprep with -noreboot switch to change the HKLM\system\setup\cmdline reg-entry to your own hal-routine after sysprep has run.

Link to comment
Share on other sites

well, I mean kernels like: ntkrnlmp.exe, ntkrnlpa.exe, ntkrnlup.exe and ntkrpamp.exe

I knew about the various HAL's being used to create hal.dll, but I never thought they did the same thing for the kernel. Are there any references, that you know of off the top of your head, for which one is used in a particular instance?

So we'd have to include placing the correct kernel as well as the HAL? Doesn't seem like a major deal, unless there are other supporting files that follow the same concept. Thanks for the tip.

I think the premise of making this switch via a script, or coded utility, is possible. Granted MS won't touch it, but I never bother with that avenue anyway cause it usually takes way too long to get a resolution. I think I have enough to get started, now I just need to find the bandwidth. :}

Check your C:\windows\inf\hal.inf file for which is which and what names they should get to "activate" them... :-)

Good luck with scripting it and keep us posted. I might be able to advise you, even though I'm not a coder.

If you can code really well you shoud also check wimgapi.dll of the new BDD2007 WAIK... the help file is included for those function calls... so you could write your own imagex.exe or GUI it with a nice progress bar like Vista's setup.exe on the DVD does.

Link to comment
Share on other sites

Thanks for the ref, I'll check it out. I haven't had time to even install the Vista beta yet so it may be relased by the time I get around to it. I understand they're using a different method for unattended installs. So much to do, so little time.....

Link to comment
Share on other sites

Actaully I did not run into any problems in testing but that doesn't mean they would not have come up. And I wasn't really concerned about going all the way back to the standard HAL. I mean who in their right mind would really want to run XP on a PII 300mhz machine in the first place.

From the reports I've collected it looks like 70% of the machines we are concerne about are ACPI Uni/mutiprocessor, another 20% are ACPI. The remaining 10% are standard and personally I'm not really concerned about them, but I'm still trying to convince my managers and directors of that.

We have not yet purchased the UIU but the quote we had was around $10 a machine. Cheap when you consider what we are paying to build a machine from scratch or maintain over 30 images across our organization. We won't ever get down to 1 image, but we could get it down to 10 images instead of 30. Some of our images contain over 12gb of software, others are just the os and updates, but most exist because of differing hardware.

And until recently when I changed jobs I did not have time to pursue this endeavor and no one else even considered it. After seeing what the UIU could do and what Acronis can do I began pursuing it further. And actually at the time this post was started I began working on an application to run at first bootup after sysprep to replace the HAL, right now it's mostly pieces and testing but it's getting there.

As I'm really writing it for work I will likely only design it to target the machines we wish to target, but I have to convince managment of that first. So we'll see how it goes.

Link to comment
Share on other sites

Glad to see so many responses over here - it's still 0 in 911 forum as of now :}

Say if the plugin is done, which method of ongoing Net/SCSI driver management do you prefer?

1.Copy the drivers from Bart PE CD -

The Good

-The driver management is once and for all process as you have to do the same when build the Bart PE CD.

The Bad

-This approach will not support P2V or V2P if you need to deal with NT4,3.51 as the Bart PE CD is for 2k/2k3/XP

2.Build a seperated Net/SCSI directory tree

The Good

-More flexibility in supporting various Windows OSes.

The Bad

-Duplicate works in driver side.

While driverpack should address most people needs, I would prefer the way how Bart handles it in PEbuilder. In any cases,the control of drivers should be left to the users but not a third party.

BTW, shall we build up a wish list of the features and tools we need?

Edited by nivlacckw
Link to comment
Share on other sites

Say if the plugin is done, which method of ongoing Net/SCSI driver management do you prefer?

1.Copy the drivers from Bart PE CD -

2.Build a seperated Net/SCSI directory tree

While driverpack should address most people needs, I would prefer the way how Bart handles it in PEbuilder. In any cases,the control of drivers should be left to the users but not a third party.

BTW, shall we build up a wish list of the features and tools we need?

I'd actually prefer to put the drivers on a distribution-share from which you're able to build both the master-pc unattendedly and the PE ISO. That way the ISO only has to include the NIC/MSD (to be able to connect to the net-share and to be able to change stuff on the harddrive after deployment). The rest of the drivers and even the "SysWrap"-script could reside on the net-share. It's then also easy to update the pnp-drivers and even the script.

A script could be controlled by a GUI and/or .ini file and therefore could also be able to turn on/off some of the features provided like:

-Install detected HAL

-Disable stale drivers/services (old stuff from the master-pc, you don't want to be loaded on the deploy pc)

-Inject to load upon boot the detected MSD (IDE/SCSI/SATA/RAID/FiberCh/USB-Stor)

-Inject to load upon boot the detected HID (Keyb/Mouse, so on first-boot other features could be turned on/off)

-Inject detected PNP to (CHIP/CPU/Video/Audio/NIC/MSD/HID/TV/etc...)

-Inject Mini-setup call (a sort of post-sysprep! Sysprep.inf (updatable on server!) and setupcl.exe (for a new sid))

-Inject startup scripts (i.e. WPI with a custom software folder)

@Nivlacckw, judging from your sig (OPK techie) you probably know MS's msdinst.exe (or the newer: drvload.exe). How good are they? Because the most difficult routine would be to write our own generic MSD injector, instead of having to create all the .reg files (to update the offline registry with proper CriticalDeviceDatabase and Services sections). Most free P2V tools do it by this less-than-optimal .reg mergin. Probably because there isn't a free tool like msdinst.exe, which can be fed an .inf file of an MSD.

Link to comment
Share on other sites

Now for the Mass Storage drivers it's more difficult. But basically comes down to: Detect the PNP-ID of the boot-device, find the correct .inf file on a driver distribution share mounted from BartPE and install the .sys, .cat files in the offline image. AND very important to import the proper entries in the CiriticalDeviceDatabase and Services section of the loaded hive so the pc will not get a bluescreen (7B error). To do this is too much to explain here in detail.

If you could go into more details on this, I'd much appreciate it ! I'm currently trying to see if I can image older servers to newer hardware. The older servers are using the same HAL (halmacpi) and always Intel CPUs, so I"m hoping that isn't an issue as much as the RAID controllers being different.

I'm guessing you've experimented with this in the past and had success, and your knowledge would be much appreciated.

Edited by stickzilla
Link to comment
Share on other sites

on a different note in regards to the HAL. If when you run BartPE/WinPE it detects the correct HAL of the system you are booting in wouldn't we be able to use the same process to install the correct HAL to the system we are imaging.

Maybe just a pipe dream but I thought maybe worth a few heads banging against it. I have not had a chance to look at it yet but hopefully later I can.

Link to comment
Share on other sites

I thought I was working with old hardware with some Compaqs that are from 00/01 ! I'm guessing you guys are working with imaging boxes so old that the sysprep line :

UpdateUPHAL="ACPIAPIC_UP,%WINDIR%\Inf\Hal.inf"

to go from MP ACPI to Uniprocessor ACPI isn't helpful ?

Link to comment
Share on other sites

That line works fine, and if all of our boxes were MP/UP ACPI I'd be in heaven. Or if I could convince the powers to be that those are the only systems we are going to target since anything alse should be removed from service in the next year (hopefully) anyhow.

But until then i have to look at all the options.

Actually if it wasn't for the HAL issue I'd be set.

I already have an image which I can drop to over 14 different models as long as it uses UP/MP ACPI HAL.

Link to comment
Share on other sites

Wow, I can't imagine the trouble of servicing machines that aren't even ACPI.

The real tragedy of it all is that y'all are working hard to come up with a fix for this, spending company time, for hardware that is completely outdated !

Link to comment
Share on other sites

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
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...