UNSOLVED Issues after image done

  • Server
    • FOG Version: 1.3.0-RC-23 SVN Revision: 6017
    • OS: Ubuntu 16.04

    After setting the image capture for a Linux system, everything goes ok (about 4 hours for the capture, nevertheless), however, when the image capturing is finished, everything goes OK up to the database update. There goes with the same error as the following image:


    I already checked access details, services and firewall/IPTables. Everything is correct and still comes back with that error.

    Some help please? Any other ideas??


  • @koelhomem Why do you think things are “correctly configured”?

    Based on the message I’m seeing, there’s a problem with mounting the NFS share to perform the download from.

    I’d say try:

    1. Restart the server’s nfs service (Redhat typically service nfsd restart or service nfs restart, ubuntu typically service nfs-kernel-server restart)

    2. Check the exports file It should look something like:

    /images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
    /images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)
    1. Ensure permissions are correct and the .mntcheck files exist in both directories:
    touch /images/.mntcheck
    touch /images/dev/.mntcheck
    chmod -R 777 /images
    1. Make sure firewalls are disabled on the server. Or at least the right ports are opened up.

  • HI guys,

    I managed to finish the imaging successfully, however, when trying to deploy the image, although having all correctly configured, it gives this error:


    I realy like FOG but my boss is plucking hairs out already XD

  • @koelhomem said in Issues after image done:

    I restarted the image upload now and let’s wait (all 4 hours…) for everything to be in working order.

    Most likely you’re using something besides Ext4 for your partitions on the reference machine, this would cause it to upload as RAW and take forever. It’s worth your time to build an image that uses Ext4 for everything but swap.

  • Moderator

    @koelhomem If it was me I’d test it on a small windows box where you are not using a raw image format. 4 hours between testing cycles is a bit long. If you are capturing your image to a fog server (not storage node) then mysql password should not matter. Check your /images/dev folder to see if the captured images are in there listed under the mac address of the device you are capturing.

  • Hi George,

    I thought of that as well, so I set the passwords to be the same and reviewed the all password settings on the FOG Server.

    Only one user had a different password (User: fogstorage on MySQL) and I updated the password to the same one… just in case.

    I restarted the image upload now and let’s wait (all 4 hours…) for everything to be in working order.

    Thanks 🙂

    (To be continued…)

  • Moderator

    intuition is telling me this is a permission issue, probably with the fog (linux) user account, where the storage node fog user settings do not match what linux thinks the user/password should be.

    Understand this fog (linux) user is not the fog (web admin) account, but a real linux user called fog. Make sure these settings are synchronized between the for user listed in the storage node configuration and the storage node’s linux fog account.