Posts made by dvlsg

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).

Hmmm, interesting. I haven’t had any problems using a single resizable partition. I wonder if that’s because all of our machines still have the 100mb partition still in place when they are imaged, and perhaps the image just replaces the OS partition instead of the system reserved.

Our machines are all typically the Dell Latitude series (couple of Precisions, but they work too), and the master image came from a modified e6510 build (it’s been converted to a VM, since).

So I’m running into a bit of an issue (sort of. I already have a workaround in place, but it would be nice to resolve it without the workaround).

I want to use FOG’s HostnameChange option to set the hostname of the computer before the computer boots up into the fresh image. And I believe this is working correctly.

However, in order to have a fully sysprepped, unattended image, unattend.xml requires that <ComputerName> is included. I currently have the computer automatically being named to ReplaceMe, and then FOG will typically shut down the computer and handle the renaming. However, if I could bypass that first restart find a way for unattend.xml to [I]not[/I] rename the computer (since it seems a little silly to go CorrectHostname -> ReplaceMe -> CorrectHostname again), that would be fantastic.

Has anyone run into this issue before?

I’ve tried a couple things already:
using <ComputerName></ComputerName> with nothing inbetween,
deleting the <ComputerName> line entirely (this causes the OOBE to ask for a hostname input),
and using <ComputerName>%computername%</ComputerName> (don’t do this one - Windows won’t even load, haha).

Oh, just a heads up (and I just noticed this) – we just ran a Full Host registration and Inventory, and that [I]did[/I] do a chkdsk, after I switched the setting in the console.

Oh yeah, I see it.
(ie - my first image includes “imageid=1” at the end of the URL)

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.

Yeah. I tend to swap between disables/enables as well as if/not-if and my own code gets thrown off like that all the time. I completely understand, haha.

Easy fix though! Might want to report it as a bug, as well.

Yup! Same result with any quick image I try. I still haven’t had a chance to look at the init myself, but I’m glad you’re finding it! Does the if-then selection seem backwards in the php?

[quote=“astrouga, post: 4910, member: 907”]Has anyone tried setting “FOG_DISABLE_CHKDSK = 0” to see if chkdsk runs? I just finished a couple of quickimage tasks with the setting on “0” and it did not run a chkdsk. Of course, I didn’t try it with “1”.

astrouga[/quote]

I think you’re right - the setting seems backwards. I swapped FOG_DISABLE_CHKDSK to 0, and the quick image didn’t try running a chkdsk. I’ve only had a chance to try it once on one computer. I’ll see if I can push out a quick image to another.

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.

[quote=“astrouga, post: 4885, member: 907”]
BTW, I realized a long time ago that it takes mere minutes to do a complete reinstall of a fog sever (minus images and such). So I just take a spare system set it up with ubuntu and the latest version of fog. Whenever I want to test a system, I just take my fog server offline and bring the test one up. I don’t have to worry about whacking my working server that way and I don’t have to go to the trouble of backing it all up.
astrouga[/quote]

mmmhm. i do the same thing, actually. i have FOG running as a VM in VMWare, and i have a copy i can test out.

i’m just glad i know where the chkdsk’s are coming from. i didn’t realize they were a scheduled part of the quick image until i saw this thread, haha.

[quote=“Kevin, post: 4871, member: 3”]Personally, I would like to see what jdd49 changed in the .29 bypass file and replicate it once .33 comes out. AFAIK the new version of FOG used Part Image? It would be nice to run the bypass with the new “imaging software”.

astrouga, what are you using the modify the file. I tend to use gedit to modify my files but init is to big to open. Are you using something else like Vi?[/quote]

my guess would be he’s mounting it to a temporary folder. the process is actually documented here:

[url]http://www.fogproject.org/wiki/index.php/Modifying_the_Init_Image[/url]

I also have this “problem”. my FOG_DISABLE_CHKDSK is set to 1 in the webserver, but it doesn’t actually skip the chkdsk on a quick image. I haven’t had the chance to dig around in the init yet, but let us know if you find anything!

I wonder if that’s by design. I wouldn’t mind seeing this implemented again, if it is. That is a useful bit of information.

A work around would be to include the image number in the description, since description does show up when you list all images. It’s a little ghetto, but it could work at least as a temporary solution.

Yeah, I’m kind of stumped. I looked into the BIOS, and the primary drive is currently SDA, and the secondary drive is currently SDB. It’s also showing up as Primary drive and Modular bay drive as expected.

The image is single partition, resizable, ntfs (I’ve never had any problems with it before, and I’ve pushed it correctly to the exact same setup - Latitude e6520 with a drive bay secondary hard drive).

Is there a log system in place on the FOG server where I could check which drive the image got pushed to, or see if any errors were logged? I wasn’t the one who imaged the machine, so I wasn’t able to verify that FOG was pushing to /dev/sda

Hi all,

I’ve got a FOG system up and running to image the Dell laptops we have on our campus. A few of our end users have secondary hard drives installed in a drive bay in addition to their internal hard drive.

We had someone get a virus and opt for the reimage, as opposed to attempting to clean it (he was due for a fresh image anyways). However, FOG automatically pushed an image onto his secondary hard drive instead of his primary hard drive, overwriting a bunch of his VMs and saved data (not to worry, it was all backed up elsewhere as well).

I believe FOG searches for hard drives, and pushes to /dev/sda (that’s my understanding of it, anyways). So I have a question, on the chance that someone would have more insight… Why would FOG have automatically pushed to the second hard drive? Both hard drives were properly installed and found by the BIOS. My first thought was that the virus somehow threw off the drive tables, and the second hard drive ended up as sda instead of sdb. I’m second guessing that thought, though…

Any ideas?

Interesting. Makes sense, though. Thanks for the response! I’ll keep that in mind whenever I’m working with Dell machines.

Used BryceZ’s instructions to help resolve my problem with bootlooping as well (we typically only have the Dell Latitude E series in our organization).
Just wanted to say thanks for the wiki, it was very helpful.

Is there any talk of including chainloading in newer versions of FOG?

[quote=“chad-bisd, post: 4110, member: 18”]I have updated the WIKI article: [url]http://www.fogproject.org/wiki/index.php/Clamav[/url]

I need to get back to school and verify the steps I took, but it’s enough to get you on the right track.[/quote]

That’s certainly enough to point in the right direction! Thanks again for all your help.

No worries! I appreciate the help, and I look forward to seeing that article from you.