On Wed, Apr 06, 2016 at 09:16:16AM +0200, Cedric Bosdonnat wrote:
On Tue, 2016-04-05 at 21:08 +0300, Roman Kagan wrote:
> > I'll talk to our guys doing similar things. I wonder what they do
> > --
> > they must have similar problems.
>
> Indeed they do. The solution we're considering ATM is
>
> 1) make the installer support running on a system where the drivers
> are
> already installed
Our installer is already able to handle this case.
> 2) make sure firstboot scripts aren't run before PnP is complete
>
> This should resolve the conflict you wrote about, by making the
> drivers
> brought in by v2v fully installed via standard Windows PnP manager
> first, and running the installer afterwards.
I think it can't hurt to get the firstboot script run before PnP... but
I have no idea how to do that, but may be you have one ;)
I meant vice versa: run firstboot strcitly *after* PnP completes
(including reboots if necessary). And yes Windows provides a way to
wait until it's over:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff537916(v=vs.8...
I think we'll cook up a patch to rhsrvany to make use of that; as I
said this will also benefit other firstboot scripts which then won't be
interrupted by reboots caused by PnP driver installation; you should be
able to do the same with your tool, too.
> Item (2) is also useful to avoid similar conflicts with other
> firstboot
> scripts, because PnP often requires a reboot, and those firstboot
> scripts may not tolerate a reboot in the middle of execution.
>
> Will this work for you?
Sure. If we manage to run the first boot before PnP this hack is no
longer needed.
According to your comment to item (1), the other way around (firstboot
after PnP) should also be OK, shouldn't it?
Thanks,
Roman.