No problem!

Reporting back gets things better for everyone.

Regards,
Galapo.

Hi,

Report about viaide.sys had nothing to do with the issue.

Issue relates to the wrong driver being assigned to HWID. AHCIX869.SYS was being used rather than ahcix86.sys.

Test results here: http://galapo.net/gena/forum/index.php?topic=119.0

Mass Storage INI file needs the following change:

This needs to be changed from this

[AM2]
ms_count=1
ms_1_deviceName="AMD AHCI Compatible RAID 7xx"
ms_1_tag="ahcix86"
ms_1_sysFile="ahcix86.sys"
ms_1_hwids="PCI\VEN_1002&DEV_4380&SUBSYS_101E1462,PCI\VEN_1002&DEV_4380&SUBSYS_10221462,PCI\VEN_1002&DEV_4380&SUBSYS_10201462,PCI\VEN_1002&DEV_4380&SUBSYS_280A103C,PCI\VEN_1002&DEV_4380&SUBSYS_2814103C,PCI\VEN_1002&DEV_4380&SUBSYS_305817AA,PCI\VEN_1002&DEV_4380&SUBSYS_305717AA,PCI\VEN_1002&DEV_4380&SUBSYS_2A89103C,PCI\VEN_1002&DEV_4380&SUBSYS_00421B0A,PCI\VEN_1002&DEV_4380&SUBSYS_00431B0A,PCI\VEN_1002&DEV_4380&SUBSYS_3054103C,PCI\VEN_1002&DEV_4380&SUBSYS_3055103C,PCI\VEN_1002&DEV_4380&SUBSYS_0184107B,PCI\VEN_1002&DEV_4380&SUBSYS_0FFF0FFF,PCI\VEN_1002&DEV_4380&SUBSYS_B0051458,PCI\VEN_1002&DEV_4380&SUBSYS_B0031458,PCI\VEN_1002&DEV_4380&SUBSYS_02131025,PCI\VEN_1002&DEV_4380&SUBSYS_02111025,PCI\VEN_1002&DEV_4380&SUBSYS_02161025,PCI\VEN_1002&DEV_4380&SUBSYS_6B311462,PCI\VEN_1002&DEV_4380&SUBSYS_6B321462,PCI\VEN_1002&DEV_4380&SUBSYS_021D1025,PCI\VEN_1002&DEV_4380&SUBSYS_43821002,PCI\VEN_1002&DEV_4380&SUBSYS_43811002,PCI\VEN_1002&DEV_4381&SUBSYS_43811002,PCI\VEN_1002&DEV_4392,PCI\VEN_1002&DEV_4391,PCI\VEN_1002&DEV_4393"
ms_1_isBusExtender=false
ms_1_exc_disableIfOS="w2k"

to this

[AM2]
ms_count=1
ms_1_deviceName="AMD AHCI Compatible RAID 7xx"
ms_1_tag="ahcix86"
ms_1_sysFile="ahcix86.sys"
ms_1_hwids="PCI\VEN_1002&DEV_4380&SUBSYS_101E1462,PCI\VEN_1002&DEV_4380&SUBSYS_10221462,PCI\VEN_1002&DEV_4380&SUBSYS_10201462,PCI\VEN_1002&DEV_4380&SUBSYS_280A103C,PCI\VEN_1002&DEV_4380&SUBSYS_2814103C,PCI\VEN_1002&DEV_4380&SUBSYS_305817AA,PCI\VEN_1002&DEV_4380&SUBSYS_305717AA,PCI\VEN_1002&DEV_4380&SUBSYS_2A89103C,PCI\VEN_1002&DEV_4380&SUBSYS_00421B0A,PCI\VEN_1002&DEV_4380&SUBSYS_00431B0A,PCI\VEN_1002&DEV_4380&SUBSYS_3054103C,PCI\VEN_1002&DEV_4380&SUBSYS_3055103C,PCI\VEN_1002&DEV_4380&SUBSYS_0184107B,PCI\VEN_1002&DEV_4380&SUBSYS_0FFF0FFF,PCI\VEN_1002&DEV_4380&SUBSYS_B0051458,PCI\VEN_1002&DEV_4380&SUBSYS_B0031458,PCI\VEN_1002&DEV_4380&SUBSYS_02131025,PCI\VEN_1002&DEV_4380&SUBSYS_02111025,PCI\VEN_1002&DEV_4380&SUBSYS_02161025,PCI\VEN_1002&DEV_4380&SUBSYS_6B311462,PCI\VEN_1002&DEV_4380&SUBSYS_6B321462,PCI\VEN_1002&DEV_4380&SUBSYS_021D1025,PCI\VEN_1002&DEV_4380&SUBSYS_43821002,PCI\VEN_1002&DEV_4380&SUBSYS_43811002,PCI\VEN_1002&DEV_4381&SUBSYS_43811002,PCI\VEN_1002&DEV_4392,PCI\VEN_1002&DEV_4391,PCI\VEN_1002&DEV_4391&SUBSYS_43911002,PCI\VEN_1002&DEV_4393"
ms_1_isBusExtender=false
ms_1_exc_disableIfOS="w2k"

Thanks,
Galapo.

Thank you indeed for these two releases. I can only guess how many hours of work they represent.

Regards,
Galapo.

Hi nullifx,

Please 1) post a screenshot of the error; and 2) post the contents of sysprep.inf.

Thanks,
Galapo.

5

(41 replies, posted in Universal Imaging)

"Auto Configuration" sets the HAL to that of the current system (in the case of a single system, for example).

"Auto Configuration at First Boot" detects required HAL at first boot of system and sets HAL accordingly (in the case of applying a base image to different systems, for example).

Hope this helps.

Regards,
Galapo.

matias101 wrote:

1) When using OFSP to change the HAL on first boot I was under the assumption that in the new version it will now auto re-boot instead of giving the "It is now safe to turn of your computer." message. Am I wrong here? and if so what would be / is there a work around for this yet?

Automatic rebooting was with older versions. I discovered there was a bug and that the rebooting with devcon did not solve what I wanted it to. Details here: http://forum.driverpacks.net/viewtopic. … 583#p37583

If we do a reboot rather than a shutdown, then we get the side-effect here: http://www.911cd.net/forums//index.php? … p;p=161778.

Regards,
Galapo.

Registered wrote:

i'm confused a little concerning what tools should be used,

Offlinesysprep
Sysprep driver scanner,
Mysysprep,

for example, if offlinesysprep is used, does that mean we don't need the other two tools listed

Yes, that's correct. At one point in time if you needed to do HAL detection at first boot then you needed to use MySysprep. But I've now added that capability to OfflineSysPrep. In fact, OfflineSysPrep handles a couple extra HALs that MySysprep doesn't support: MySysprep will only handle swaps between uniprocessor and multiprocessor, whereas OfflineSysPrep handles those as well as acpipic and standard HALs.

Also, OfflineSysPrep used to make use of Sysprep Driver Scanner, but that task has now been replaced by an internal function so Sysprep Driver Scanner is no longer needed too.

Regards,
Galapo.

8

(41 replies, posted in Universal Imaging)

A couple of things which can cause this to occur:

1. admin password of system not blank
2. not using the same version of sysprep that was originally used

Regards,
Galapo.

Jack_F wrote:

As for the DevPath entry, where would I be looking for that - I looked through 'RegEdit' and couldn't find a thing...

I assume by that you mean: HKLM\Software\Microsoft\Windows\CurrentVersion,DevicePath'

Regards,
Galapo.

Jack_F wrote:

Also as I am using the MassStorage pack that comes with LiveXP, I currently don't download it manually - OFSP/LiveXP compiles it own MassStorage when creating the LiveXP .iso.
Jack

That'll be version 9.01 then.

Regards,
Galapo.

11

(6 replies, posted in Universal Imaging)

If you're making a backup for different hardware, generally you might want to use different images for different HALs. That is, you might take an image for ACPI and another for multiprocessor machine.

If you want to remove the particular HAL from the system you indicated with devcon, you would type this at a command prompt:

devcon.exe remove acpi_hal*

However, this does not remove files, only registry entries etc. Upon next boot, the same HAL as before will be used by the system. Just a pnp device reconfiguration is performed at first boot, but you'll notice that the same HAL is configured in Device Manager.

Which means all of this is basically useless. Either take an image of systems with different HALs set, or use OfflineSysPrep or MySysprep to detect and set HAL at first boot.

Regards,
Galapo.

12

(6 replies, posted in Universal Imaging)

Maybe something like this reg file will do what you want:

Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\ACPI_HAL\0000]

Regards,
Galapo.

13

(41 replies, posted in Universal Imaging)

eethball wrote:

The only sort of weird hang up thing that I'm assumed is caused by the Update HAL on First Boot option is the first time the machine boots it says It is now safe to shutdown your computer".

The reason this occurs is because on first boot a standard HAL is utilised so as to be universally compatible. The side effect of this is that you get the message mentioned. Upon second boot, then the HAL detected at first boot will then be used.

I power the machines off and then back on and the mini setup begins.  Is this normal?

Yes.

eethball wrote:

Alright, I saw that it was normal for the PC to shut down after the HAL is updated, but does anyone know if there is a way to turn that into a reboot instead of a shutdown?

Yes, all I would need to do is call NtShutdownSystem with reboot rather than shutdown. However, the side effect of that is mentioned here: http://www.911cd.net/forums//index.php? … p;p=161778.

As such, we just have to live with the shutdown.

Regards,
Galapo.

New version of OfflineSysPrep has now been uploaded at 911cd and boot-land.

Regards,
Galapo.

beltaine wrote:

Edit:

Have hit a new snag. On first reboot, Windows starts, I see my background image and the mouse pointer. Within a couple of minutes, it drops to the Windows XP logo "It is safe to turn off your computer" screen. Upon restart, I get back into Windows and am greeted with the following message:

The system is not fully installed. Please run setup again.

There's some glitch that I don't know why it happens for some that produces this issue. I have it fixed in my local version and there's a test version at 911cd forums. It happens with the option of automatically setting HAL upon first boot.

I hope to upload a new version soon. I would like to include the option of injecting out-of-the-box HWIDs first.

Regards,
Galapo.

OverFlow wrote:

wont there need to be two merge files... one for each platform ?

Yes, that's correct.

Hi bigfoot,

Sure if you have the time for that and it would benefit you (that is, if you use OfflineSysPrep).

I'm going to add the option to inject these entries, so if there's something more complete, that will definitely help. I'm personally really strapped for time at the moment. So if the details can be supplied, then I'll use them to add the option.

Thanks,
Galapo.

Thanks bigfoot! That's just what I was after.

Does your sysprep.inf file for XP contain the extra HWIDs that the microsoft link missed? That is, is it the result of running -bmsd option?

Thanks,
Galapo.

Hi Jack_F,

I'm after a Mergeide.reg file for 2k3 like the XP one given here: http://support.microsoft.com/kb/314082. It contains a list of hwids supported by default with XP. This is what is injected by a 'sysprep.exe -bmsd' call: it populates sysprep.inf with the default entries and then when sysprep is run, the entries are added to the registry (the equivalent to double-clicking the Mergeide.reg and have it copy entries to registry).

Thanks,
Galapo.

Yes, it would be there.

I was just hoping someone had already gathered it as I don't have much spare time these days and would like not to replicate if possible.

Regards,
Galapo.

Hi,

See here for a list of HWIDs supported out-of-the-box with XP: http://support.microsoft.com/kb/314082. I'm wondering if anyone has a comparable Mergeide.reg for 2k3. I'd like such a list so that can get OfflineSysPrep to inject such entries into an offline system so that one doesn't have to perform a 'sysprep.exe -bmsd'.

Thanks,
Galapo.

Jack_F wrote:

Is that all I should/need to be selecting to achieve what I want between both DriverPacks, OfflineSysPrep and my ULTIMATE GOAL of total annihilation- aka Universal image???

These are the ones I'd be using:

http://img195.imageshack.us/img195/5651/20100217154729.png

Regards,
Galapo.

Jack_F wrote:

5. Run OfflineSysPrep on the offline VMWare HDD, using Administrator Profile and Automatic HAL detection on First Boot.
Please help oh mighty ones tongue

You don't state whether you actually injected the DriverPacks mass storage drivers. Did you?

http://img109.imageshack.us/img109/2277/20100217150910.png

Regards,
Galapo.

OverFlow wrote:

Well your situation is slightly different... you have a registry.

Yes, very true!

It would be easier for me to add to txtsetup.sif but again i am not exactly sure how that would be accomplished. Further I am uncertain if i need other entries too or just the one line.

As far as I'm aware, just this entry is needed. Take a look here for a way of adding registry entries by INF through txtsetup.sif: http://gosh.msfn.org/infresh.htm.

PS i have never understood what the difference was between BartPE and LiveXP / nativeEx? can you enlighten me?
Are they simply two different peoples attempt at creating a PE environment from XP?

Yes, that's correct: BartPE and LiveXP/nativeEx are basically different attempts at creating a PE from XP or 2k3. However, they start with different philosophies: BartPE adds in large amounts of base files etc. while LiveXP/nativeEx only adds what is absolutely necessary for those build options which are selected. For LiveXP/nativeEx, much file registration etc. is done at build-time, dramatically reducing boot time. I get a booted explorer shell with hotplug support just as quickly as nu2menu but without the slow wait with XPE, all in under the build size of a default BartPE (I also remember days of autobuild post-processing to try to cut out what was unnecessary).

Regards,
Galapo.

OverFlow wrote:

There is also another known issue, mostly with Nvidia chipsets.
I could probably get a few more drivers to work if I were to mod a few windows files (some registry entries added to the hal) the instructions are on here - posted by both cdob and Galapo. The short story is: The ONLY drivers that do not work are PnP only mode drivers, (has nothing at all to do with AHCI mode, although an affected driver could be an AHCI mode driver) they simply don't support legacy mode (IE text mode). If they don't support text mode then you can't find them from text mode setup. This is a problem with the driver not the integration of the driver. An easy way to tell is to search the drivers inf for "Parameters\PnpInterface,5,REG_DWORD,1", if it contains that line then the following will / may be helpful.

Search the forum for "value = Parameters\PnpInterface,5,REG_DWORD,1"

here is a good example --> http://forum.driverpacks.net/viewtopic. … 158#p32158

Hi OverFlow,

Not sure exactly what you mean by having to modify some windows files. For OfflineSysPrep and also for mass storage drivers in LiveXP, I took cdob's advice and added the PnpInterface entry for drivers which reference scsiport.sys or storport.sys. No modification of files is necessary, just do a search within the driver file for scsiport.sys and storport.sys text strings. Examples:

http://www.911cd.net/forums//index.php? … p;p=153143
http://forum.driverpacks.net/viewtopic. … 358#p30358

Regards,
Galapo