How to use FOG to supply machine specific drivers for Windows 7 Sysprepped machines
-
Added function copyDrivers() to funcs.sh:
copyDrivers()
{
machine=dmidecode -s system-product-name;
machine2=${machine// /};
echo " “;
echo " * FOG Driver copy for $machine”;
echo " ";mkdir /ntfs 2>/dev/null
echo -n " * Mounting Windows File System…“;
mount.ntfs-3g $win7sys /ntfs 2>/tmp/mntfail
mntRet=”$?";
if [ ! “$mntRet” = “0” ]
then
echo “Failed to mount C:”;
echo " ";
echo -n " * ";
cat /tmp/mntfail
echo “”;
sleep 5;
else #Mount successful
echo “Done.”;mkdir /ntfs/Drivers 2>/dev/null
echo " “;
echo -n " * Copying Common Drivers…”;
cp -r /images/drivers/Common /ntfs/Drivers
echo “Done.”;
echo -n " * Copying $machine Drivers…";
cp -r /images/drivers/${machine// /} /ntfs/Drivers
echo “Done.”;
echo " “;
echo " * Driver copy completed.”;
sleep 2;
fi
}(Sorry about the formatting, the tabs got eaten)
I have FOG triggering this function after the Disk Cleanup stage, where it does the NTFS extend. It’s then copying drivers from /images/drivers/Common, and then /images/drivers/Optiplex745 (Or whatever model it pulls)
The real reason for doing it this way, is that you can include the network driver for a new model that’s not in Win 7 in the driver folder for that model, and just go image it without having to worry about building a new base image. There’s also no scripts running post sysprep, it’s all done via the windows sysprep process. With a GUI for driver management, and the community sharing model specific driver packs, I think this would really add to the complete usefulness of FOG.
We’re going to setup a core FOG server with the drivers folder, then rsync to each of our 42 schools. A big benefit for us, is that because we won’t be building a new base image very often now, it’s easier to keep all our school images up to date. New drivers popping in from rsync will happen automatically & quickly, even on some of our slow links. We’d only rarely have to pull down a new 10-15 gig image
-
Fernando: You don’t run into issues with Dell Optiplex pulling the wrong audio driver?
-
[quote=“Andrew Single, post: 3131, member: 1006”]Fernando: You don’t run into issues with Dell Optiplex pulling the wrong audio driver?[/quote]
No. At least we have not had any problems with Optiplex. No one has reported anything
, and we use these models for years.
But we don’t use sysprep to deploy this model’s images. I have test the SAD method and my 3rd party DrivePack, and works fine, but in laboratory, not in producction environment.Which are your issues?
-
Andrew: We tested a similar solution. The script is saved in the database (you write it in the WEBUI in a text area, and fog saved it via form), and the fog script accesses it from a web service after deploy process, before restart PC.
If you want to test the driverPack, I can share it.
-
F[quote=“Fernando Gietz, post: 3144, member: 13”]Andrew: We tested a similar solution. The script is saved in the database (you write it in the WEBUI in a text area, and fog saved it via form), and the fog script accesses it from a web service after deploy process, before restart PC.
If you want to test the driverPack, I can share it.[/quote]
Fernando, I’d love to test your driverpack/script. I deal with many of the same model workstations in our environment. -
[quote=“boon, post: 3244, member: 833”]F
Fernando, I’d love to test your driverpack/script. I deal with many of the same model workstations in our environment.[/quote]
You can download the driverpack from [URL=‘http://www.ehu.es/fogenehu/download/driverpack/softpack.7z’]here[/URL].
I call to DP_Tools from runonce.cmd script. You must uncompress the .7z file in c:\drivers folder, and post-sysprep call to runonce.cmd script. -
[quote=“Fernando Gietz, post: 3253, member: 13”]You can download the driverpack from [URL=‘http://www.ehu.es/fogenehu/download/driverpack/softpack.7z’]here[/URL].
I call to DP_Tools from runonce.cmd script. You must uncompress the .7z file in c:\drivers folder, and post-sysprep call to runonce.cmd script.[/quote]
How do you avoid the Found New Hardware Wizard? It seems this causes the DPInst process to hang until all New Hardware Detected windows are closed.Thanks again for all of your help.
-
You are right. You need suppress the Found New Hardware Wizard.
To do it, in XP 32 bits:
[QUOTE]
[I]To fix the issue in Windows XP 32-bit versions, add a DWORD value that is named “SuppressNewHWUI” to the following registry subkey: [/I]
[I] HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceInstall\Settings [/I]
[I] To configure this registry setting, follow these steps: [/I]
[LIST=1]
[][I]Click [B]Start[/B], click [B]Run[/B], type regedit, and then click [B]OK[/B].[/I]
[][I]Locate the following subkey in the registry, and then click it: [/I]
[I] HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceInstall\Settings [/I]
[][I]On the [B]Edit[/B] menu, point to [B]New[/B], and then click [B]DWORD Value[/B]. [/I]
[][I]Type SuppressNewHWUI for the name of the DWORD entry, and then press [B]ENTER[/B].[/I]
[][I]Right-click [B]SuppressNewHWUI[/B], and then click [B]Modify[/B]. [/I]
[][I]Do one of the following: [/I]
[LIST]
[][I]To suppress messages, type 1 in the [B]Value data[/B] box, and then click [B]OK[/B].[/I]
[][I]To stop suppressing messages, type 0 in the [B]Value data[/B] box, and then click [B]OK[/B].[/I]
[/LIST]
[*][I]Exit Registry Editor, and then restart the computer. [/I][I][B]Note[/B] The setting does not take effect until the computer is restarted.[/I][/LIST][/QUOTE][LIST=1]
[/LIST]
To see all microsoft article, [URL=‘http://support.microsoft.com/kb/938596/en-us’]here[/URL] -
I really liked Andrew’s idea of copying machine specific drivers.
I changed his script slightly and incorporated it with some other changes I have done to funcs.sh
[quote=“Andrew Single, post: 3130, member: 1006”]
machine=
dmidecode -s system-product-name;
machine2=${machine// /};
…
echo -n " * Copying $machine Drivers…";
cp -r /images/drivers/${machine// /} /ntfs/Drivers[/quote]
Became
[CODE]machine=
dmidecode -s system-product-name;
machine=“${machine%”${machine##[![:space:]]}“}” # Remove trailing whitespace
ln -s “/images/drivers/${machine}/” /root/mydrivers
…
echo -n " * Copying $machine Drivers…";
cp -r /root/mydrivers/ /ntfs/Drivers
[/CODE]The symbolic link is just a simple way to overcome the space-in-path-names problem, so I can have folder names just as they appear under “System Product” in the FOG hardware inventory.
Bjorn
-
Solid solution. I like it.
[quote=“Andrew Single, post: 3130, member: 1006”]
I have FOG triggering this function after the Disk Cleanup stage, where it does the NTFS extend. It’s then copying drivers from /images/drivers/Common, and then /images/drivers/Optiplex745 (Or whatever model it pulls)
[/quote]I know this is a bit of a thread resurrection, but if you still check this thread, could you quickly walk us through how to set up the script so FOG automatically kicks it off? I’m sure I could figure out the syntax, but I’m not sure where to look.
-
In order to make use of Andrew’s modification, you start by [URL=‘http://www.fogproject.org/wiki/index.php/Modifying_the_Init_Image’]modifying the init image[/URL]. The modifications you want to do is as follows:
Edit the file initmountdir/bin/fog (path as in wiki link above), and add a call to the new function. I added it just before the call to changeHostname() around line 606, like this:
[CODE]…
if [ “$capone” != “1” ]; thencopyDrivers #Copy machine specific drivers changeHostname…[/CODE]
Then, you add the function to the file initmountdir/usr/share/fog/lib/funcs.sh, somewhere in the file, i put it at the very end:
[CODE]copyDrivers()
{
machine=dmidecode -s system-product-name;
machine=“${machine%”${machine##[![:space:]]}“}” #Remove trailing spaces
echo " “;
echo " * FOG Driver copy for $machine”;
echo " “;
mkdir /ntfs &>/dev/null
if [ “$osid” = “5” ]
then
ntfs-3g -o force,rw $win7sys /ntfs
elif [ “$osid” = “1” ]
then
ntfs-3g -o force,rw $part /ntfs
fi
ln -s “/images/drivers/${machine}/” /root/mydrivers
mkdir /ntfs/Drivers >/dev/null
echo -n " * Copying Common Drivers…”;
cp -r /images/drivers/Common/ /ntfs/Drivers
echo “Done.”;
echo -n " * Copying $machine Drivers…";
cp -r /root/mydrivers/* /ntfs/Drivers
umount /ntfs
echo “Done.”;
echo " “;
echo " * Driver copy completed.”;
sleep 2;
}[/CODE]Follow the wiki link on how to save the modified init back into place.
Then you add your drivers to your fog server, placing them under /images/drivers/<product name>, and modify your Windows 7 image, so that it [URL=‘http://support.microsoft.com/kb/254078’]looks for new drivers[/URL] under C:\Drivers (use the registry mod, adding the path to
[LEFT][FONT=Segoe UI][COLOR=#333333]HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\DevicePath.)[/COLOR][/FONT][/LEFT] -
This post is deleted! -
If you are lazy, like me, you can let FOG change the registry setting in your images, so you don’t have to create new ones. Then the function should look like this:
[CODE]copyDrivers()
{
machine=dmidecode -s system-product-name;
machine=“${machine%”${machine##[![:space:]]}“}” #Remove trailing spaces
echo " “;
echo " * FOG Driver copy for $machine”;
echo " “;
mkdir /ntfs &>/dev/null
if [ “$osid” = “5” ]
then
ntfs-3g -o force,rw $win7sys /ntfs
elif [ “$osid” = “1” ]
then
ntfs-3g -o force,rw $part /ntfs
fi
ln -s “/images/drivers/${machine}/” /root/mydrivers
mkdir /ntfs/Drivers >/dev/null
echo -n " * Copying Common Drivers…”;
cp -r /images/drivers/Common/ /ntfs/Drivers
echo “Done.”;
echo -n " * Copying $machine Drivers…";
cp -r /root/mydrivers/* /ntfs/Driversregfile="/ntfs/Windows/System32/config/SOFTWARE" key1="\Microsoft\Windows\CurrentVersion\DevicePath" devicepath="%SystemRoot%\inf;C:\Drivers" reged -e "$regfile" &>/dev/null <<EOFREGed $key1
$devicepath
q
y
EOFREGumount /ntfs echo "Done."; echo " "; echo " * Driver copy completed."; sleep 2;}[/CODE]
-
Oh that reg bit is interesting too. I like that.
I actually currently have all the drivers saved locally to c:\drivers on my image, and the reg pointed in the right direction. What I was really interested in was using that script, but instead of copying drivers over, copying over some scripts to silently set up the computer post-image. I currently have the scripts located on the image, but it seems a bit ridiculous to take the hours to update the VM, take a snapshot of it, copy the scripts over, seal it up, and reupload it when I could just use this fantastic bit of code to push the scripts to my FOG server, have it upload them to the newly imaged computer, and be done with it.
-
Here’s another question for you: is there a way to pull drivers/scripts/whatever off of a network drive or shared drive?
My FOG server is currently in a guest VM with the host’s hard drive mounted as /media/localshare. What I would like to do is have the script also kick off this command:
cp -r /media/localshare/scripts/* /images/scripts
to make sure the scripts being pushed are the most recent, without having to log in to the VM and run that command by hand every time I make an update to them. Will I have to re-mount the network drive inside of the FOG script, even though the drive is always mounted on the FOG server? (my first thought was to use ln -s to make a link to the network drive, but that didn’t work for me either).
-
The Drivers function is a fantastic addition to FOG but i struggle with drivers for each dell model. What do you guys do for drivers? because the driverpacks are quite outdated or bloated with unneccessary drivers, the .cab files on the dell website aren’t as up to date as the individual drivers listed and downloading each driver is tedious and time consuming and also only want to have whats required (.inf and files) to keep it as unbloated as possible. what do you recommend?
Cheers
-
I actually use the cab files on the Dell site, plus a few extra (my company often orders different network cards, and those aren’t in the cab files by default). A lot of the files may not be 100% up to date, but they sure are close.
If you absolutely must have the newest drivers, you could look into using Microsoft’s Deployment Toolkit (MDT). You can use the deployment workbench to strip drivers down to the minimum using the Import Drivers function for the “Out-of-Box” drivers. You can use it to pull drivers off of a 100% functioning computer too (but be careful: it’ll often pull in a bunch of drivers that are unnecessary, depending on what’s all been installed on the computer).
That being said, it’s a little bit tedious as well. You could always try Dell’s automatic update client, allow it to download drivers, then use MDT to convert them to a deployable form. I’ve never had much luck with their update client, though.
-
Thanks for the info, it’s not so much having the newest but the minimal without having an in-complete drivers set. will start with the .cabs and see how it goes
thanks again dvlsg -
No problem. And if you need to fill the holes, you can always use the MDT to grab the extra stuff. My only experience is with the D and E series laptops, but the only extra driver I had to add in with MDT was an Intel Centrino wireless driver, and I believe that’s only because they aren’t standard parts for Dell machines.
-
Hi all,
i’m getting “can’t stat no such file or directory” when trying to copy the drivers… example directory is /images/Drivers/WinXP/Optiplex 755 on imaging node and relevant code is:
ln -s “/images/Drivers/WinXP/${machine}/” /root/mydrivers;
cp -r /root/mydrivers/* /ntfs/WINDOWS/TestDrivers; # folder already exists on the imagei must be doing something silly because when i run the code directly on the server through ssh it works! (change destination directory obviously)… i’ve checked all paths and been conscious of case sensitive. what am i doing wrong? :-S oh and $machine is working it (correct name without trailing space etc… got that code above this section. i’m also not adding it as a function, i want to include it directly into fog code itself (bin/fog)
