While I don’t use snapins in my environment, I might think that the batch file has caused a pop-up message to be displayed. But since the applications are being installed in a hidden window no one is there is acknowledge the pop-up message so the task is stuck.
So how would you go about debugging this? I would copy the batch file to the target computer and run it as Administrator. See if it executes without any prompts.
@Sebastian-Roth Are we running into the mount timeout issue we’ve tried to debug before? I also wonder if we could add a bit more debugging information in that unable to find image store message, similar to the when the path was set incorrectly.
Let me see if I can come up with a patched fog.upload
@pnwbsi if you are willing to help us test this, hopefully we can squash this issue once and for all.
If someone changed the linux password for fogproject or messed with the setting for that account within the web ui that error will be thrown.
Work through this document: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password
What do you have configured for dhcp option 67?
Also do you have a linux or windows 2012 or newer dhcp server?
@rogalskij fwiw the relevant lines in regards to which interface is here
Command: /usr/local/sbin/udp-sender --interface em1 --min-receivers 3 --max-wait 1200 --portbase 56590 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/BaseImage/d1p1.img;/usr/local/sbin/udp-sender --interface em1 --min-receivers 3 --max-wait 10 --portbase 56590 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/BaseImage/d1p2.img;
Task startedUdp-sender 20120424
Using mcast address 238.155.1.70
UDP sender for /images/BaseImage/d1p1.img at x.x.x.x on em1
Broadcasting control to 224.0.0.1
So the first question I would have is: Are the target systems and the FOG server on the same subnet (vlan)?
@rogalskij ok so here is where we are:
We still don’t know if the infrastructure is setup correctly for multicasting (i.e. igmp snooping is enabled on vlan 1).
We don’t know if the multicast settings are right in the fog configuration.
We don’t know if the fog server’s firewall has been enabled but multicasts not allowed.
@Sebastian-Roth from a previous post:
Additionally, the output of the command you specified “sudo ps aux|grep udp-sender” is:
root 13864 0.0 0.0 115300 1480 ? S Aug30 0:00 sh -c /usr/local/sbin/udp-sender --interface em1 --min-receivers 3 --max-wait 1200 --portbase 56590 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/BaseImage/d1p1.img;/usr/local/sbin/udp-sender --interface em1 --min-receivers 3 --max-wait 10 --portbase 56590 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/BaseImage/d1p2.img;
root 14393 0.0 0.0 8688 660 ? S Aug30 0:00 /usr/local/sbin/udp-sender --interface em1 --min-receivers 3 --max-wait 10 --portbase 56590 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/BaseImage/d1p2.img
root 31094 0.0 0.0 112708 992 pts/0 S+ 11:39 0:00 grep --color=auto udp-sender
There appears to be some stale multicast tasks running since 30-Aug.
@FogNewUser Ok this one almost tells me what I need to know, from the picture perspective it would be handy to see more to the left edge to get the complete interface name.
But what I see you have built in network adapters (knowing its a P710) helps with the guessing and maybe 3 riser card network adapters. At this point I don’t see any interfaces with IP addresses, so it looks like you have a bunch of unconfigured interfaces.
From the screen shot it looks like you have a debian based OS (could be ubuntu which is debian based). So you will need to use the network manager if you have the gui loaded to define an IP address for your fog server. IF you have fog installed AND it was working you can refer to the file /opt/fog/.fogsettings to what the IP address of the fog server was when FOG was installed. You need to move it back to that IP address or you will have to make several changes to the fog configuration since the IP address is hardcoded in a few spots.
@Redbob This reminds me of a communication problem. You should not get a connection reset…
It kind of makes me think its a spanning tree issue or a faulty cable. But if everything is the same other than bios/uefi switch on the same computer it really can’t be communications. If it is a communication issue, can you confirm the switch that the pxe booting client is on is using one of the fast spanning tree protocol like Fast-STP, RSTP, MSTP, port fast, etc? Another test would be to put a dumb unmanaged switch between the pxe booting computer and the building switch as a test. If it works with the dumb switch then its a spanning tree issue with the building switch.
If the firmware up to date on this target computer?
The other thing to test is to put the pxe booting computer on the same subnet, same switch as the FOG server. This would rule out any devices in between the two causing this issue. It still makes me think of a communication trouble because its failing at random different steps in the booting process.
@David-Osinski said in Multicast off of bond:
–mcast-rdv-address 10.10.10.74
This is what bugs me a bit. The rendezvous address should be a multicast address. That is where all of the multicast clients go to find each other. I would expect that to be at least 224.0.0.1
udp-sender --interface rope --min-receivers 1 --max-wait 600 --mcast-rdv-address 10.10.10.74 --portbase 56854 --full-duplex --ttl 32 --nokbd --nopointopoint
When you don’t define an multicast address, the address is created by udpsender as a composite of the FOG server’s IP address. I think it should be in the range of 239.10.10.74, possibly the second octet is something different. But the data channel IS calculated so its important for the rendezvous address to be defined, so the targets can locate the data channel.
Off the top of my head I can think of a few things (not in line with the OPs question about Galera).
I have to say that FOG really hasn’t been performance tuned for such a large campus. I know there are some forum members that do have large campuses that are using fog for imaging.
@Sebastian-Roth @Jay-Bosworth Understand I’ve only read the last 2 posts, so I’m not sure where the thread is headed.
BUT I can offer a comment. During Windows golden image development I’ve used a modified post download script (similar to the one for sending the drivers to the target computer) to patch the unattend.xml and replace dlls in a previously captured image. I only did this during golden image development or until the next time I built a golden image.
The principles of this is outlined in this article: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed
The fog.copydrivers script could be modified to just copy over the one needed file from the fog server. In this section. Where clientdriverpath is the destination path and remotedriverpath is the path of the files to copy.
dots "Preparing Drivers"
clientdriverpath="/ntfs/Drivers"
remotedriverpath="/images/drivers/$machine/$osn/$arch"
debugPause
if [[ ! -d "${remotedriverpath}" ]]; then
echo "failed";
echo " ! Driver package not found for ${machine}/$osn/$arch ! ";
debugPause;
return;
fi
echo "Ready";
debugPause
[[ ! -d $clientdriverpath ]] && mkdir -p "$clientdriverpath" >/dev/null 2>&1
echo -n "In Progress"
rsync -aqz "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1
[[ ! $? -eq 0 ]] && handleError "Failed to download driver information for [$machine/$osn/$arch]"
debugPause
@xburnerx00 I would still consider replacing that HDD with a new SSD just because around 4-5 years of daily use the drives do fail. If you have the budget replace is and avoid having to replace it later, plus even a cheap ssd will make that laptop seem new again.
@Dinesh The problem is that your dhcp server isn’t telling the pxe booting client the ip address of the fog server. I have the idea that you have 2 dhcp servers on your network. One is configured correctly because it tells the PXE rom the name of the of boot server and boot file name because iPXE is starting, but then when iPXE starts it sends out a dhcp request again and the second dhcp server answers without the boot server information that is why iPXE asks.
If you look in the picture, the IP addresses coming from your dhcp server look… strange. The pxe booting computer gets an IP address of 192.168.6.14, but the gateway is 192.168.6.15. This is not something I would expect to see.
I was able to get the OP going by doing this and that.
We are not sure if it was this or that that got the kernel to boot. What I did was unlocked the max CPUs (that was capped at 
in the kernel and I also enabled almost all of the ACPI modules in the kernel. We also tried the acpi_osi=Linux kernel parameter.
We ruled out the acpi_osi=Linux kernel parameter fixing the issue so it must be something I enabled in the kernel. Tomorrow AM I’m going to reset the kernel environment and only unlock the max CPUs. The OP is going to test that new kernel to see if it was unlocking the max cpu or it was the acpi modules I enabled.
Either way I’ll report where we ended up and which kernel change fixed the issue. I have also seen other recent CPU stalls like this that was fixed by setting acpi=off so we may need to move what ever fixed the issue into the main kernel build because new hardware/cpus may require it.
The issue ended up being a configuration problem with the dhcp server. Once that was straightened out the target system pxe booted like expected.
@robbit ok I just assumed since most people install ubuntu for some reason you had that. Let me translate it for centos (what I use)
yum update -y
yum install git -y
git clone https://github.com/FOGProject/fogproject.git /root/fogproject
cd /root/fogproject/bin
./installfog.sh
So its not staring WinSetup/OOBE at all? Only loops at reboot?
So the image you captured was it from a bios based VM or a uefi based VM?
The target computer you are deploying to, is it bios (legacy) or uefi based?
You can only deploy bios captured images to a bios based computer and the same thing goes for uefi.
FWIW, I develop my reference images on a VM and deploy them to physical computers. Our current base image is based on 1903 and it works fine when captured from a VM and deployed to a physical computer.
@slipke Well if you wanted to do it in the auto reg it will be a bit harder than manual registration, but here is the curl call in the fog.auto.reg program. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.auto.reg#L73
Before that curl call you will need to collect the serial number of the machine. The trick is the serial number is saved in the smbios in different locations for different manufacturers.
If you look at this post it shows you how to get the serial number for the two chassis types I had to interact with: https://forums.fogproject.org/topic/6304/fog-2-0-request-advanced-host-naming/2 It also shows how to create a complex computer name based on several factors on the fly. So you will need to compute/collect the serial number and pass it along with the other arguments to the php file mentioned in the curl call. And then in the php code read that variable and place it in the hostname variable instead of the mac address.
If you wanted to do this using the manual registration fog.man.reg where it asks for the user to input the host name into $host just use the dmidecode value to copy the serialno value into the host variable. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg#L161