@mike-fahey said in Free space is always 0:

/dev/mapper/Notus-root 1.8T 1.8T 0 100% /mnt/fogimages

That says it’s full. Have you tried to clear out the images/dev directory? Also, what is the output of:
du -sh /mnt/fogimages/images/*

@phishphan said in Issue Imaging HP EliteDesk 800 G3:

On the machine that is working I have a boot option under UEFI that says M.2 Windows Boot Manager which does not exist on the machines that I’m attempting to image. I’m still getting the operating system not found on those.

This is interesting. What do you mean the other does not have this setting? Is it simply not available to choose, or is it there but not enabled? Can you post a photo?

@Boyan-Biandov said in upgraded to Ubuntu 18.04.1 LTS:

Is it really necessary to copy the images to a folder, other than /images on the new fog server and then once they are copied there “rearrange” them by moving them again into the final destination of /images (assuming fog defaults)?

Yes, because FOG’s NFS configuration does not allow writing to /images, it’s a read-only share. /images/dev is read+write. I kept the walkthrough as simple as possible, leveraging things already setup on the servers. If you wanted to use something like SCP, you could put the images directly where they need to go.

@sapeurorca Try to reset encryption for that host, try to re-install the fog client on that host.

Have you seen this tool? https://github.com/FOGProject/fog-community-scripts/tree/master/updateIP

For future readers, the updateIP tool also covers updating the config.class.php file.

@george1421 The makeFogMobile script does update dnsmasq, but the updateIP script does not.

@atessin Great job triaging the issue, it’s good to see that. Are you aware that the storage nodes do not have a web UI for administration? All the things done with storage nodes use the master server’s web interface.

Does the storage node actually image? Does it work?

Have you tried this link on the storage node? What does it say?
http://node_ip/fog/service/getversion.php

@Sebastian-Roth said in Issues during installation on Debian 9.6 stretch:

We haven’t tested Debian 9.6 yet I think.

The automated installation tests use the latest version of both debian 8 and 9. Before the fog installer runs, basically something like this runs:
apt-get update;apt-get -y dist-upgrade
Same for the other OSs. The daily tests are hitting a moving target every day.

@george1421 IMHO, if SELinux is set to enforcing, I think the installer should set it to permissive mode and just inform the user of this. When somebody comes up with a working SELinux policy, then that can change.

This is just me, but if my FOG server was in a VM (it is), I’d snapshot it, and then delete everything in /var/www/html and re-run the fog installer.

@mstrolo Good thing we have a wiki article addressing this exact issue: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#Repair_broken_database

@Sebastian-Roth I don’t have access to their articles anymore - but when I did have access back at a previous job, I found if I google’d enough I could find the same stuff elsewhere.

Has a duplicate IP been looked for yet, for the fog server and for the VMs?

@Sebastian-Roth said in Adding needed repository... Failed!:

@Wayne-Workman The installer test seems absolutely fine but possibly that’s because you have the package software-properties-common pre-installed? Can you check on that? I have had a look at the logs from your installer tests but the package is not mentioned and that’s why I guess you have it pre-installed…

Yes, it’s pre-installed. This is on Ubuntu 18.04 server, minimal installation.

root@ip-10-0-0-165:~# dpkg -l | grep software-properties-common
ii  software-properties-common     0.96.24.32.7                      all          manage the repositories that you install software from (common)

@carmonj probably an ftp credential problem, just guessing. This maybe will help: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

You need to very closely pay attention to the end of the capture for errors. Record it on video with your phone if you need to, because we would need the exact errors to best help you.

@george1421 said in Change the boot order automatically:

But we do it this way to make sure we don’t reimage the CFOs computer by accident (again) if everything was automatic.

That must have been a bad day.

@EduardoTSeoane I think snapins have always executed in alpha-numeric order.

@JGwinner Please create a new thread with all the details of your problem.

@zfeng said in How to do remote management:

How can that be possible if they are not under the same network?

Fog of course needs a network path to the target.
Beyond that, you can make things more efficient with storage nodes, which are sort of like remote fog slave servers under the control of the master server - they hold images so that you don’t have to image across a WAN. Also there is the FOG Client which allows for OS level management of all the workstations you’re managing.

Look at these wiki articles for some insight:

• https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin
• https://wiki.fogproject.org/wiki/index.php?title=Managing_FOG#Storage_Management
• https://wiki.fogproject.org/wiki/index.php?title=FOG_Client
• https://wiki.fogproject.org/wiki/index.php?title=Snapin_Examples
• https://wiki.fogproject.org/wiki/index.php?title=SnapinPacks

Do you have fresh installs or upgraded FOG master node?

It’s an upgraded master.

Do you have DB setup with root password set?

No.

I’m going to just blast this master and make a new one. I’ll see how that goes.