Working in Server Version 7669 as well. Thanks for the help!

@Tom-Elliott Thank you for your help, Tom! It turns out something failed the first time I tried to update.

Now I am on 7671 and everything appears to be in order. You guys are very responsive, and that is awesome.

it’s possible that when you installed trunk, it changed the fog user password

@Wayne-Workman yes as i told you i tried to download it to other pc and its working fine LOL

@Wayne-Workman So updating didn’t completely work. It also required removing the task and the host computer. Then setting up host computer and task in the updated version. That solved the problem. Thanks for the help!

@Tom-Elliott said in Deploy problems:

fixparts /dev/sda

I have made the task “Upload-debug” and put the command fixparts /dev/sda and fog now returns me the next error:

EBR signature for logical partition invalid; read 0x0000, but should be 0xAA55
Error reading logical partitions! List may be truncated

just to give you some more information to work with, in addition to the “hosts” table, there is also the associated “inventory” table that contains hardware information about all registered hosts, including the serial number

@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?