@ismith-hpu said in Failure in Capturing an image:

This worked before changes were made to the post-init script. Any idea?

Can you please post the full post init script here so we see what modifications you make!

The error we see in the video is definitely caused by a partclone parameter as mentioned by Tom. The issue is you use init file from 14.07.2019 (see in the video) which came with partclone 0.2.89 and modified the scripts to match parameters that only work with partclone 0.3.12 (which we updated to in September 2019).

So what you want to do is download the latest proper build of the inits and use those: https://dev.fogproject.org/blue/organizations/jenkins/fos/detail/master/105/artifacts

Not exactly sure about the error you posted on MacOS X. Please post the pull post-init script here so we know your mods.

Edit: Ahhh wait! The scripts only count NTFS adn EXT2/3/4 as possible resizable filesystems. So on your Mac it doesn’t find any and bails out. Which version of Mac OS X do you have? Resizable is a huge problem in Mac OS - see here: https://forums.fogproject.org/topic/13881/help-with-mac-imaging

@tomhtil Thanks for bringing this up. As Tom said, the fog-client maintains a strict security trust relationship to the server. This design has the obvious drawback of not being able to maintain two trust relationships for one MAC address at the same time. Probably something Joe left out when he initially created the fog-client. But I can see why people want to use it this way and I will look into this.

Be aware, this will probably take some major changes in the code and won’t be fixed in a matter of a few days.

There might be some kind of quick fix (copy token from one OS to the other) but I have not looked into this. Will do so.

After some intense work on this I pushed a commit to the db-security branch. Just looks terrible because I created a bit of a mess when trying to pull the latest changes from dev-branch into db-security as well and merge it all in. But should still be all fine I hope. https://github.com/FOGProject/fogproject/commit/2f70a7872c379ec3c6b4a433b02c48b2b7c03d81

To see the actual diff of todays work see here: https://github.com/FOGProject/fogproject/compare/dev-branch...db-security

Just posting this here as I feel we are on a good track with this but it takes some very rough changes as well. @Tom-Elliott would you take a look at this. If you feel like it you are more than welcome to comment on things. May I ask you to not add this to working-1.6 before I have some more testing done!

So far only tested on CentOS 7 - looking forward to the results on Wayne’s great test environment.

@Daniel-Miller Thanks for reporting! Obviously hasn’t been noticed in a while. I just pushed a fix to working-1.6.

Moving this to section bug reports and marking as solved.

@TaTa said in FOG installation errors:

ERROR 1396 (HY000): Operation CREATE USER failed for ‘fogstorage’@’%’

No more error message???

@mcarrara said in Migrating to Windows 10:

As far as I can tell FOG doesn’t care if I am imaging Windows 7 or Windows 10

It’s not much of a difference. Though I don’t have all the bits and pieces of the cloning scripts in my head and would still argue you properly set Win 10 as image type in FOG!

@ismith-hpu It’s probably wise to focus on one issue at a time. Mixing up things is not helping much. Would you mind opening new topics for the other problems you posted as they seem unrelated to me.

Now about the “Invalid Storage Group” error. Tom found and fixed an issue just a few days ago. You can update to the latest dev-branch and see if that fixes the issue for you as well.

@LittleTux You need to manually edit your /etc/exports file to match the images location you use (/media/administrateur/images

@TaTa What about Apache und PHP logs?

@Kevin-Talbot Well, the version with the most bugs fixed (even some you have in 1.4.4) is the latest 1.5.7 as of now. But it’s not without bugs.

Why is it that you can’t wait for 1.5.8 as you have used the very dated 1.4.4 for quite some time? Just wondering…