How to use FOG to supply machine specific drivers for Windows 7 Sysprepped machines
-
i can’t get the script to work even if i follow the instructions step by on the first page and have the same directories etc… i’m close to giving up
-
Hmm… the difference that stands out to me is the fact that you currently have the folder in place on the image, but the other scripts are creating it. Maybe a permissions issue? But then the fact that you can do it by “hand”… I guess i’m not sure.
If using just “$machine” is working for you, is there a reason you cant just use that?
-
If it makes you feel better, I uploaded a new image over the weekend and now I’m having errors too, haha.
Something about not having enough white space for the CP. Reuploading right now to see the error again…
-
Ah. Yeah, it doesn’t actually perform the clean up, and as a result doesn’t perform the ntfs extend.
The only real difference I can see here is that one image is single partition resizable, and one image is multi-disk single partition non-resizable.
I’m guessing that it’s not running an ntfs extend by design for the multi-disk single partition image. Maybe. Is anyone else who is using this function using an image type other than single partition?
-
using “$machine” only works if i manually hardcode the variable (machine =“Optiplex 755”).
that’s strange about the new image! -
Ahhh okay.
Tell you what, since I’m going to go dig around in the FOG init anyways to see about that ntfs resize, maybe I’ll add a dummy function that involves using $machine and see what I can find. I’m hardly a linux expert though (never even touched it before FOG), so hopefully someone else can give you some advice too.
-
cheers dvlsg! you’re a star
-
Just to rule it out, i got the script to create a new folder and also changed the permission on the drivers folder on the server/node but still no go
-
anyone who has this working in their funcs.sh/fog could i get a copy just so i can see what’s different to mine?
-
I’m running another upload - just got my init changed (work’s been busy). I’ll let you know if I can get it working for me.
I do have a question for you though (for my own problem): are you by chance using a single partition image, or a multi partition non-resizable?
-
Ah. I think I have it figured out – one more check quick, just to verify (I’ll get back to you as soon as I get a chance).
[I]Edit:[/I] Sort of good to go on my end… It actually ends up creating a file named “machinetest” instead of a folder. Maybe I didn’t have my file structure quite right on the server. Maybe someone else has more insight. But it seems to be finding $machine, since it’s not erroring out and saying the “Latitude E6510” folder doesn’t exist. Here’s all the relevant code:
Note: I don’t know much about links, but I believe the bolded part of the code below is important: my suggestion would be try to copy it that way if you haven’t already.
Other notes: Testing with a Latitude E6510, relevant folder on the FOG server is /images/Latitude E6510. Permissions are 777 and root:root. c:\machinetest does [I]not[/I] exist on the test computer, but is created through this script. /root/mydrivers also does [I]not[/I] exist pre-function, but is a
[FONT=Calibri] machine=
dmidecode -s system-product-name;[/FONT]
[FONT=Calibri] machine=“${machine%”${machine##[![:space:]]}“}” #Remove trailing spaces[/FONT]
[FONT=Calibri] echo " “;[/FONT]
[FONT=Calibri] echo " * FOG Scripts Copy for $machine”;[/FONT]
[FONT=Calibri] echo " ";[/FONT]
[FONT=Calibri] mkdir /ntfs &>/dev/null[/FONT]
[FONT=Calibri] if [ “$osid” = “5” ][/FONT]
[FONT=Calibri] then[/FONT]
[FONT=Calibri] ntfs-3g -o force,rw $win7sys /ntfs[/FONT]
[FONT=Calibri] elif [ “$osid” = “1” ][/FONT]
[FONT=Calibri] then[/FONT]
[FONT=Calibri] ntfs-3g -o force,rw $part /ntfs[/FONT]
[FONT=Calibri] fi[/FONT]
[FONT=Calibri] [B]ln -s “/images/${machine}/” /root/mydrivers[/B][/FONT]
[FONT=Calibri] cp -r /root/mydrivers/ /ntfs/machinetest[/FONT][I]Edit #2: [/I]Ah. The only file I had in /images/Latitude E6510 was a file called test.txt that only said “TEST”. I opened c:\machinetest with a text editor and it said “TEST”. FOG must’ve copied the test.txt over and converted it to machinetest. I’m guessing if I had a legitimate folder structure/set of files in my drivers location it would’ve worked fine.
-
t’s worked! it’s worked!!! i hadn’t upload the change fog but thankyou! it was the way i was mounting ntfs by the looks of things because where i was putting the code ntfs was already mounted but i had it mounted as: [B]mount.ntfs-3g $part /ntfs [/B]but should of been: [B]ntfs-3g -o force,rw $part /ntfs[/B]
-
Hmm… Here’s something else I noticed (probably should’ve noticed this earlier… it’s been a long Monday already – trying to do a lot of IT work with some FOG stuff on the side):
cp -r /images/Drivers/WinXP/[B]“[/B]{$machine}[B]”[/B]/* /ntfs/WINDOWS/TestDrivers;
I noticed that you sometimes have quotes around {$machine} in your code, but in the code I got to work, the quotes went around the whole directory, like this:
cp -r [B]“[/B]/images/Drivers/WinXP/{$machine}/*[B]”[/B] /ntfs/WINDOWS/TestDrivers;
Maybe that’s the cause of the problem, if they’re still there?
-
Ahhh okay. Good! I’m glad you got it all worked out. Sorry I couldn’t have been more help, haha.
-
actually, it wasn’t the way i had mounted the ntfs, it was actually because i was adding a ; at the end of these lines when i obviously shouldn’t of!..
machine=“${machine%”${machine##[![:space:]]}“}” #Remove trailing spaces
ln -s “/images/Drivers/WinXP/${machine}/” /root/mydrivers
cp -r /root/mydrivers/ /ntfs/testmachineso actually dvlsg you have helped ALOT! thanks for all your help
-
I’ve done that quite a few times myself, actually, haha. I’m still not sure what exactly determines whether or not the end of a line requires a semicolon in linux scripting.
-
[quote=“dvlsg, post: 4971, member: 1186”]Oh that reg bit is interesting too. I like that.
[/quote]I feel that I should tell you I am not really using the same exact approach for driver installation anymore. I do copy the drivers as described in my posts in this thread, and modify the registry to make Windows able to find the new drivers when my generalized sysprepped image start installing devices.
However, since Windows skips unsigned drivers in this process, it didn’t completely fill my needs. So in addition, I also modify or create a [URL=‘http://technet.microsoft.com/en-us/library/cc766314(v=ws.10).aspx’]SetupComplete.cmd[/URL] script, that amongst other things run dism.exe with the /Add-Driver and /ForceUnsigned switch, for the drivers that are unsigned.
-
Ahh okay. I haven’t run into any issues with unsigned drivers. I found that adding this to my unattend.xml was enough (I have the script copying the relevant drivers to c:\drivers and then some vbs down along the line cleaning it up) –
<DriverPaths>
<PathAndCredentials wcm:action=“add” wcm:keyValue=“1”>
<Path>C:\Drivers</Path>
</PathAndCredentials>
</DriverPaths>But the only machines I have to deploy to are Dells. I suspect all of the relevant drivers are signed.
-
That is nice, I like the unattend.xml approach better than modifying the registry.
(Taking notes for next FOG hacking session.)
I actually had a lot of unsigned drivers from Dell, using their [URL=‘http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-driver-cab-files-for-enterprise-client-os-deployment.aspx’]system cabs[/URL], but that might be because we have a lot of older models.
-
Yeah, a lot of people I talk to are starting to move away from the unattend.xml approach, since it’s [I]technically[/I] not necessary. I prefer to have as clean of an image as I can though, so I still use it. That <DriverPaths> code is embedded in the <settings pass=“windowsPE”> by the way.
Ah, yeah that would make sense. We get all laptops, and our oldest model floating around is in the Latitude E6400 series, which really isn’t that old. We also only deploy Windows 7 - not sure how Windows XP would handle using the unattend.xml.
