@Junkhacker well, this happens from time to time 😄

All should be fixed in latest.

I am actually imaging a bunch of 7040’s. My test deployment went well, but I am also on Trunk. I updated from 7565 to 7671 yesterday, and other than a small installation snafu, it has worked perfectly.

Hope we can get your web gui up again as well. Please see my signature on where to find the apache error logs. Valuable information will be in there…

Hi,

all that problems are solved with 7671.

Regards X23

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.