Make sure NFS is running with:
systemctl status nfs-server
Set the ownership of the images directory to user fog and group root like this:
chown -R fog:root /images
Then try again.
Also, see what this says:
showmount -e
You should see something similar to this:

Export list for fog-server:
/images/dev *
/images     *

Also, you may find this helpful: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_NFS

@finvader Yes, set your boot order in all the machine’s firmware to Network First, HDD second. By default, if there are no jobs in FOG for said machine, it’s sent to the HDD to boot.

This “sending to hdd to boot” is controlled by the exit type in the FOG Web interface. The default can be set in FOG Settings. The setting can be altered per-host or mass-applied via Groups. The default is SANBOOT and works on most things, for most of the ones SANBOOT doesn’t work on, GRUB usually works. And then there are other options for the really difficult boxes.

I set the boot order in the firmware for 500 systems at my old job. I didn’t do it all at once, I modified the machines one by one as I needed to image them. Over the course of a year and a half, I got them all.

Of course I was also planning on modifying all new machines to boot to the network first as we received them - but then I got a new job.

@UWPVIOLATOR I’d say run these maintenance/cleanup commands for good measure & try again. Bad entries in the DB can cause weird stuff. https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#Database_Maintenance_Commands

Assuming a 512 byte sector size, this is the dd command to read sectors 5 through 7 to a file from disk 1.

dd if=/dev/sda of=/images/someImage/sectors5_7 skip=5 count=3 bs=512

To write that file back to those sectors:

dd if=/images/someImage/sectors5_7 of=/dev/sda skip=5 count=3 bs=512

You would need to capture these sectors manually - then you would need to write a postdownloadscript to check for this file sectors5_7 in the image you’re deploying. and if it’s there, to write it.

@EuroEnglish said in Storage nodes not deploying images:

I am not registering my hosts and simply selecting deploy, therefore it seems to be ignoring settings as the hosts aren’t running as clients. Could that be right?

This is why random storage nodes are being selected for imaging despite location settings - The location plugin only works with registered hosts. FOG for all intensive purposes doesn’t really care a lot about non-registered hosts. All of FOG’s features come to life when hosts are registered.

It means the UUID from the reference partition could not be applied to the device’s partition you deployed to. I’m surprised it boots.

@Tom-Elliott an alternative if sgdisk fails is

tune2fs /dev/nvme0n1 -U `uuid`

We use SCCM for all our patches - I hate it.

@abu.raju said in Resize \image:

I know that by default FOG only allows 10GB.

That is not true, it’s how you laid out your OS that’s causing the limitations.
If you follow these instructions, you’ll be setup right - There’s even a video for the partitioning steps:
https://wiki.fogproject.org/wiki/index.php?title=CentOS_7

@UWPVIOLATOR What I would do is run the maintenance commands, and then I would open up notepad and change all the maintenance commands into select statements. I’d then ask the team to start noting what they do, when they do it concerning fog. Then I’d just start running those select statements every 15 minutes to every half hour - and when the bad row pops up, I’d ask around and see what people did during that time. I’d also look into the history table for things there during the same time. I’d look in the apache error log for something during that time. Even if you find no errors in these logs, it’s worthwhile to see what IS in there during that time, those can be clues. Then - I would begin the tedious task of reproducing the problem and identifying the single thing that is causing it. Reproducing the problem is a lot of educated guesswork based on what you think is causing the problem. If at the time the issue happens for example, someone was registering and imaging a new system - You’d have to test registering by itself - then imaging - using the same image they did - and possibly even in debug mode to identify the single thing that is doing it. Just as example. What I’m expecting though is it’s being caused by something being done in the web GUI - you guys just need to figure out what that thing is - and narrow in on it by separating out variables & unknowns and testing individual things. Example - I don’t know if my application isn’t working or if my antivirus is blocking it. Well, uninstall the AV and try. You have to isolate. And to begin isolating, you have to have a general idea of what you’re isolating.

@richard.cervelle I would suggest you try it. Here’s an article on it, includes a video explaining how to set it up at a basic level and how it works: https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin

@HaRD
Read this. https://forums.fogproject.org/topic/9952/use-windows-share-to-store-fog-image-with-cifs-on-ubuntu
But I think it’s a bad idea. If it explodes, we can’t help you with it.

@Joe-Gill Going off of this thread, I think your DB is dirty.
Please try the database maintenance commands here. Please report back with the outcome.

@plegrand said in snapin and batch script:

@Avaryan @Tom-Elliott @Quazz @Wayne-Workman
May be someone know a solution to launch remote command on mulitple computers without GPO’s ?

I already said it, Systems Manager from Amazon Web Services.

@EagleEnergy We need you to move to the latest stable fog release 1.4. I’m fairly certain the issue you have with zstd is already fixed in 1.4.

sudo -i
dnf -y update
dnf -y install git
git clone https://github.com/FOGProject/fogproject.git
cd fogproject/bin
./installfog.sh -y

If you set that column to null, the FOGSnapinHash service will re-hash everything. You can export the database before you do this for safety.
update snapins set sHash = null; Also, you should update. This problem could be one something that’s fixed in the latest stable release of FOG, 1.4.1.

@forte647 said in Should multicast speeds be comparable to unicast?:

Netgear ProSafe S3300-52x

Different switch models perform differently with multicast even though they advertise 1Gbps port speeds.

Switches with underpowered CPUs will perform worse, while switches with higher powered CPUs perform better. Why is this? Because with multicast, the switch has to use CPU cycles to duplicate the packets to all ports. This is a CPU-intensive activity for the switch.

I wouldn’t think the Netgear ProSafe S3300-52x is underpowered - but when the manufacturers don’t list the CPU specs or total throughput capabilities on the tech specs page we are left wondering.

Also, multicast can only go as fast as the slowest member. So if one of the members in the multicast group has a bad stick of RAM or a failing disk or a bent & kinked patch cable, that box will slow the entire group down to it’s speed.

@x23piracy This query will identify which MAC it is:
SELECT hmMAC, count(*) FROM hostMAC GROUP BY hmMAC HAVING COUNT(*) > 1;

Let’s re-evaluate where the issue is not.

It’s not the client. Why? Others are not complaining. Joe tests the client functionality throughly. The client’s code for this hasn’t changed in a while.

It’s not the fog server’s Code. Why? Others are not complaining. The fog community uses snapins heavily.

What’s left? Your server, it’s configuration, it’s environment.

Knowing that, we should start digging into what’s different about your server.

First, I would suggest upgrading to 1.4.1. Second, I’d start looking through /var/log/apache2/error_log after uploading a new snapin. I’d look for botched symlinks, misnamed directories, bad permissions, and incorrect configurations.

@user4000 said in Authentication:

Should I install the certificate on the server or the client machine?

The certificate should already be on the server. If it’s not, that’s a problem. Can you not see the certificate using the URL in the logs? If not, go check on the server itself via CLI, issue this command to view it:
cat /var/www/html/fog/management/other/ssl/srvpublic.crt
If that’s there, check permissions next. They should be www-data:www-data and 544.

The FOG Client pins the server’s certificate to the operating system at installation. If there’s some issue with that pinning process, we need to explore that. But from the sounds of it, your problem is that the cert on the server isn’t accessible or not there for whatever reasons.

@Sebastian-Roth We have an article for fixing that: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#Repair_broken_database