@george1421 I completely forgot I have a USB ethernet adapter. I’ll give that a try.

@Tom-Elliott said in How to get FOG to capture while host is logged in?:

Now there are utilities like “DeepFreeze” which allow you to essentially do a “snapshot” of a device, and revert to that snapshot. I don’t know that I would call this an image though.

At my job before my last job, we used a product called Centurion SmartShield that did HDD locking. Really, all they built was a fancy HDD driver that their software installs. But we locked systems before capturing them with Norton Ghost.

I wouldn’t advise locking anymore as it makes patching basically impossible to do, and every single little thing you might be asked to change is a huge P.I.T.A.

@Sebastian-Roth said in Cannot upload image to FOG... log files?:

FOG

I have a postinitscript that sends logs to a share as imaging goes https://github.com/FOGProject/fog-community-scripts/blob/master/fogAutomatedTesting/postinit.sh

@zionda said in Help with Mass Hard drive cloning station:

Wish me luck guys

good luck and don’t forget to report and don’t hesitate to ask if you have any setup problems.

@Wayne-Workman It was capture. I was testing the bits about having a mounted (local) file system under /images This was the first issue I ran into.

@Tom-Elliott Yeah I got that on the mounting.

/images/vol1 (which points to a directory on /dev/sda1) images correctly.
/images/vol1 --> /dev/sdb1 errors out

From FOS with the mount point in place if I stop the script where it errors out. I can move to /images/vol1 no problem. I can’t touch a file in /images/vol1 because /images on the fog server is shared out read only. There must be some conditional check that is failing above where it works when /images/vol1 is a directory and failing when /images/vol1 is a mountpoint. I’m just not seeing it.

@Tom-Elliott @george1421 - Here is the latest news.

I removed the mount points on the server in /etc/exports
so they only show

0_1495714432985_Screen Shot 2017-05-25 at 8.13.42 AM.png

I uploaded an image to /images/vol1/… (and it looks successful

0_1495714471319_IMG_1604.JPG

However, after looking into the restart on the server, the image file copies the name only with 0 kb.

0_1495714500576_IMG_1605.JPG

Then after the temp files remain in /images/dev/macaddress, ect. and don’t move.

0_1495714539402_Screen Shot 2017-05-25 at 8.09.29 AM.png

Now, I am confirming that a “directory” outside of a directory volume in /images/sample do work properly. Where as /images/sample is the directory with the proper rights.

0_1495714617956_Screen Shot 2017-05-25 at 8.16.33 AM.png

Image is complete and computer restarts

0_1495714756696_IMG_1606.JPG

Then the image is moved correctly into the directory /images/sample

0_1495714811668_Screen Shot 2017-05-25 at 8.19.55 AM.png

My other thoughts are that I may try. Is it an ext4 thing or should I go back to ext3, and try it.

Let me know know what you think. I am willing to work with you guys for the success of this project as always! Thank you

@xutianhong I’m glad you have it working. Tom and I are very skilled with FOG. Since fog is built using many other linux parts we know those parts too. iPXE is a great tool if you want to use it.

FOG also has a great pxe boot menu tool built in. I know some people install FOG just for pxe booting and don’t use FOG for computer imaging purposes.

You may ask a question here, we will help if possible.

If you can SSH to your NAS then go ahead and try (after backing up of course)! Quite a few NAS do support an awful lot of things; looking at my own synology, that has a dashboard where you can install web servers, MySQL, bulletin boards - all sorts really so it isn’t too much of a stretch to imagine FOG can be installed on the NAS. It all comes down to what flavour of Linux the NAS is running and how friendly it is to repo’s vs recompiling…

@Avaryan SVN or a package download most likely.

You can safely delete that directory and intialize git in /root where it will create the folders as needed. These are only the installation folders (as in everything needed to install FOG, not where everything is installed), they don’t contain any settings or the like.

Sorry on the late response. Yes to what @Tom-Elliott said, I went to /var/www/fog/lib/hooks/ and set active = true on the aforementioned hooks.

@george1421 I’ve actually looked into this - I have to emulate ARM on x86_64. I’ve found one good article on it for the platform I use, KVM + libvirtd + virt-manager

No need for multiple posts: https://forums.fogproject.org/topic/10060/acer-laptop-uefi-pxe-works-in-general-wds-but-i-tried-it-with-fog-and-it-runs-through-code-and-boots-from-hard-drive/2

@Tom-Elliott don’t slap me, i will not use the script i was just fighting for the op 😉

If you upgraded your main fog server to 1.4.0RCx without issue then your storage nodes will update without issue. The storage nodes use a subset of the features of the master node. In that they do not have a local database (mysql and ftp) seem to cause us the most issues during the upgrade.

With that said, expect issues (we are here to help). When it works successfully be happy and move onto the next issue.

@george1421

I added a Cisco switch in the mix, but I couldn’t get it to pass any traffic, even from the switch itself. I don’t know if adding a layer 3 switch into the mix confused everything?

Anyway, I’ll wait until we get new equipment and then debug it from there, like you suggested. We’re going to be reimaging multiple machines at a time before we get new network equipment anyway, so I most likely need to get a RAID 10 set up.

Once we get new equipment in, I’ll give the Multicast a shot and then reply back to this thread. But, that’s way in the future. Probably several months or more.

I appreciate all the help you guys have put in to this! Thanks a bunch!

@Joe-Gill You should have no problems running a node on CentOS.

This is a slight alternative if you updated your workflow.

When the computer is checked back in and placed in the dock.
The staff member would boot the computer up in the dock and either press F12 to get to the boot menu and select network to reach the fog menu (or based on the boot order it would boot to the FOG Menu right away). Once at the fog menu the staff member would pick quick image (or what ever its called now). Then fog will lay down the image. There is no need to touch the web console. I’d have to check but I think we can even set the quick image feature as a default FOG Menu option. In FOG 1.4.0 (soon to be released) there is an option to limit the quick image menu to only display the image you defined for that host system. Today it will list all images defined in the FOG environment.

There is another option that may take a little hacking (very little). When you schedule an image deployment FOG creates a task for this. At the very end of the image deployment the target computer checks back into the fog server and tells it “I’m all done”. When the fog server gets the “I’m all done” signal it will remove the task from the list. If that “I’m all done” signal is not sent by the target computer the task will remain in the queue. Someone with little computing skills could make this change to the inits to disable this signal. I’m not in favor of this route, but it is possible to do without much effort.

@Wayne-Workman Thanks so much! Setting up auto updates will be next on the list 🙂

@Quazz said in Post Sysprep Driver Install:

But say you work repair service where every possible model under the sun gets dumped for you to fix, then you need a broader solution.

warning with snappy driver installer… the project was hijacked and now includes malware… therefore a fork was generated called snappy driver installer origin…

https://sourceforge.net/projects/snappy-driver-installer-origin/