@arduinoAndMore Well, something screwed up your first partition I’d say. Good to hear that you got this solved by a simple filesystem check!

@Sebastian-Roth I have fully functioning .32 Fog server with images saved on them. I deployed one of these images from the .32 fog onto a host computer. Separately I had set up a 1.2 Fog server and using the same host computer I uploaded the image to the new fog server.

I think my issue might be this partclone vs partimage thing. I got impatient and upgrading to TRUNK, hoping that would solve some issues but now I can’t even capture an image. I’ll start a new post and detail out my new set up. Thanks again.

@Wayne-Workman I am not in the business to hack FOG either. But as I work in healthcare and we are a small shop one of my many hats is security, with PHI concerns I think about all possible attack surfaces. We have regular audits of our security and have to justify any thing that is of questionable nature. Right now I am working on closing up a few other areas, and I have been thinking of ways to harden software deployment through snapins. Currently we have a separate vlan for FOG and only deploy snapins at time of imaging, then remove the log and use the client just for user tracking and rebooting basically. I will push small single file snapins, if I need to, but nothing that needs to connect to a share due to not having a good way to do so. I love FOG and it works great, just like to include my thoughts on things to help further FOG and keep it as secure as possible along the way.

FOG 2.0 will be a huge advancement again I am sure. Just like 1.3 is truly leaps and bounds better than .3x was. I thought .3x was great, but the issues were definitely addressed. With all software there is always compromises to maintain backwards compatibility for longer than any @Developers would really want to do. In my opinion 1.3 is not just a decimal increment to 1.2, it is much closer to a 2.0 version. But with the true 2.0 they can finally drop support for the legacy client, partimage, and it sounds like move away from PHP. It will definitely be a more robust and modern system.

Tom is absolutely right about shutdown before the job actually finishes is not a good idea.

But just in case people want to do other things in the postdownloadscript and run into the same “command is unknown” issue. My guess is that the PATH environment is not properly set within the scripts. So you’d need to call /sbin/shutdown to make it work…

@Tom-Elliott Hi, good to know that this was a bug. in between time i just removed the entry in database and it was gone. (Before i deleted the file in filesystem.

Ok thanks for letting us know. So I guess we are save to solve this now.

@Junkhacker Didn’t even notice that.

@Wayne-Workman Thank you, I’ll post if I see anything else happening.

@SneakR What you need is in this thread: https://forums.fogproject.org/topic/7131/fog-on-ubuntu-16-04-php7/27

With any luck your system will start uploading as expected.

And if you see any error along the way please take a picture with your smartphone and upload here. As Wayne would put it: A picture is worth a thousand words!!

As well please run lsblk and show us the output before starting the capture with fog command. From what I read between the lines this might be a special case of yet unknown major ids - which we can add without much effort as soon as we know.

@Developers @Moderators
I messaged him in chat and ping’d him here in the thread.

I’m thinking that forking threads isn’t good because people may bookmark the original thread they posted in. He might have came back to the original thread via a bookmark and seen that all his new posts were just gone…

I think that locking threads is a better option once the issue is solved, or we have looser customs about people addressing their next issue in their original thread. With the forums searching functionality, it may not be such a bad idea to just let folks keep going in the original thread. Also, another option is after forking, leave a link behind for them to find where the fork went to. Maybe that should be a feature in nodeBB? Auto-link to the fork, and maybe even send an email to the individual who’s posts were forked? Maybe even auto-message them too with the link and a short message of what happened.

@Hanz said:

Am I the only one that has this setup in such a large environment?

No I am sure we have others with similar large setups! As this has been around for a months without much new information and we solved most of the latest multicast issues with other users I am going to move this to the problem section. Please don’t get me wrong. I am very interested in finding out where the problem is with this. But as we don’t have others reporting a general multicast issue from 7088 upwards I kind of doubt this being a bug in FOG - although I might as well be wrong. Feel free to move it back if you can give us more solid information. For example full multicast.log as well as ps ax | grep -e udp -e FOG when partclone is waiting.

@Tom-Elliott
Thanks Tom, whatever you changed seems to have fixed things right up!

Reboot after is now working without causing tasks to be re-created when next checkin occurs.

You guys are awesome - did I mention that before?

@boeleke It’ll cause problems whenever you want to change anything with an image.

@Wayne-Workman You were right. I followed the link and followed its instructions and it is now pushing the image. Really appreciate the assistance.

GGQ

@herrpommesfrite For most, 60 is fine. Especially with the improvements that FOG Client 0.10.x brought.

If you have less than 1,000 computers, 60 is probably fine. In excess of that I’d probably recommend 3 or 5 minutes. Esp. when you get to around 15,000.

@phil_guy It’s not a linux or fog question. When the computer turns on, you usually hit F2 to enter the BIOS. On some HPs, it’s the Esc key, for Lenovos it’s usually the Enter key. Then just compare each item line for line on both the golden machine and target machine.

@GoodGuyQ My guess is you’re entering the wrong user/password. You can add a new user in the webgui to test that out.

Here is my quick image item for reference

set username foglogin set password foglogin params param mac0 ${net0/mac} param arch ${arch} param username ${username} param password ${password} param qihost 1 isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme

With foglogin being a valid username and password

@Sam-Wennerlund for what it’s worth, i’m running the latest trunk on Ubuntu 12.04.5 LTS. it works fine.

@Junkhacker This looks promising… and it’s open source.

Regshot is an open-source (LGPL) registry compare utility that allows you to quickly take a snapshot of your registry and then compare it with a second one - done after doing system changes or installing a new software product.
https://sourceforge.net/projects/regshot/