@Sebastian-Roth said in Issues after changing server IP: Hint: I think the great changeIP script does not handle dnsmasq config changes as this is not a standard setup. Correct, it doesn’t.

Fog did configure dhcp and it worked. we still modified it according our need. please resolve this.

After testing with the FOG client on my reference/golden image I found my issue which may help. I would task my client PC to be added to AD when the Auto Delayed service starts. Well, when a computer is being restored with the Windows 10 image it will start the services. Since it is starting the services it is trying to join the domain while the system is being sysprepped. This caused Windows to come up with an error to install or boot and various other errors. After the service was stopped in the reference/golden image then restoring had no issues. I manually have to enable the service and start it as well. The big issue turned into a okay fix.

I agree. I asked for the something similar here: https://forums.fogproject.org/topic/12096/allow-client-to-pull-inventory-information-without-pxe-booting

@george1421 My MySQL knowledge is pretty shallow. For this situation I’ve got enough data, but I’ll read up and maybe change things then.

@george1421 @Sebastian-Roth Thanks both for your help, I managed to get rid of the second IP address and the server is now multi-casting to 2 laptops.

@plegrand said in Multicast very slow: Then there is 2 sessions running (test and test2) and all the target computers have about 1.15GB/min rate Just so I’m clear on this. When you were able to get 4 computers imaging your transfer rate was 1.15GB/min? That’s still 19MB/sec. You are still above the 100Mb/s theoretical limit. All the computers have 2 partitions and strangely the first partition is slower than the second : about 700MB/min rate I can explain this. The number is based on an incorrect calculation. The issue is that first partition is pretty small, like 500MB. It transfers so fast that the speed numbers get skewed. The second partition is typically the contents of the C: drive. You can see this if you look at the disk manager in Windows. Look at the size of the first partition. I might need to explain how image multicasting works. There is one computer (FOG Server) that is sending the image out. As each multicast client boots up it checks in with the multicast sender through a discovery process. The muticast sender (FOG Server) configures the multicast sender service to wait for X number of clients to check in before going, or after the first client checks in wait for XX seconds before going even if not all have checked in. Once the multicast stream starts, no other late clients can check in (they are blocked). So in the image stream the FOG server sends out the first block of data then stops. It waits for every multicast receiver (target computers) to respond with “OK!”. The FOG server will not send the next block until it hears “OK!” from every client. If something happens and one client didn’t get the block correctly it will send “Retrans” back to the FOG server and the fog server will resend that block back to the client computer (while the others sit and wait until everyone replies with “OK!”. This is why we say multicasting can only go as fast as the slowest computer in the multicast stream. Consider you have 4, 8-core desktops all with SSD drives and one with a Penitum-4 and a slow HDD. If you imaged them all in one stream the 8 core systems would image at the rate the Penitum-4 system can write data to its slow HDD. If you have a system with a failing hard drive if the block transferred to it’s checksum doesn’t match the checksum of the block on the disk it will send a “Retrans” command back to the FOG server while the other clients wait. The point is when everything works it works well, when you have one bad actor everyone suffers.

@Guillaume-IT As well take a look at the Storage Node definition while you are in the web UI and make sure to correct the interface information there.

@mpatel For CentOS use the following: dodhcp='Y' bldhcp='1' dhcpd='dhcpd' packages='bc curl dhcp ...' Then re-run the installer and see it do the work.

@jsch Do you use the FOG DHCP server. I suppose you don’t. Please try changing the PXE filename from ipxe.efi to undionly.kpxe and see if that works for you.

@ArtLong As Joe posted long time ago: To clarify; this is not an issue with the client, but rather a bug with mono dealing with Apple’s SIP (system integrity protection). I don’t have access to a Mac to test so we probably need other people to confirm this is still an issue. There is nothing much we can do about I suppose.

@aborn said in Updating database Failed Error returned: <!DOCTYPE HTML PUBLIC .... 503 Service unavailable ....: The ftp connection with the fog user and the fog password that I did choose for the Linux user, the web GUI user and the storage default in the web GUI was rechecked and worked in every case. That definitely sounds like you have been playing with the fog Linux user account. This is not to be fiddled with. It’s the FOG service account and it will break things if you change the password!! This account/password is different to the one you use to login to the web UI!! https://wiki.fogproject.org/wiki/index.php?title=Password_Central#Local_.22fog.22_user It’s interesting you see the “503 Service unavailable” error. Please check the apache and php-fpm logs and post here. See my signature on where to find the logs. The other server was recently updated from fog 1.2.0 to 1.5.4 . Please tell us which FOG version you run on this particular server you have the error with.

@virtualdxs Definitely will make it into the official build as soon as I find a bit more time to properly fix this.

@mpatel Disabled SELinux and Firewall???

it did finish. but took long time. Thank you guys. please resolve this.

@Sebastian-Roth Great !!! Thank you again.

Hey george1421, Thanks for the response. To clear things up a bit. We do have multicast working across vlans, the issue is more the reliability. On one vlan only certain models (Dell e5430s, Dell 3380s) will multicast with others (Dell 3340s, Dell 3350s, Dell 3390 2in1) get to the gparted screen and just sit like they are waiting additional computers to join. Then on both of the vlans if you need to cancel the multicast tasks and try to kick if off again, it seems to be hit or miss if the host get past the gparted screen and start imaging. Seems I need to wait a certain amount of time before trying to kick off the job again. I haven’t nailed down that minimum wait time…seems to be 15 min or less. If I do it too soon it just sits at the gparted screen. So that is why I decided to look at the Storage Node approach. I then came across the wiki article about Storage management. https://wiki.fogproject.org/wiki/index.php?title=Managing_FOG#Storage_Manangement In the Storage Management section it talks about Storage Groups and multicasting via the Storage Group’s Group Master Node. I was unclear if I could make sure hosts on a vlan hit the Group Master Node on that vlan. Maybe I was adding wishful thinking. Thanks Randy

@FeatherlessBiped This has been an ongoing topic. See my post here: https://forums.fogproject.org/post/117517 FOG was initially build to be bound to one interface and this is still the case in various places in the code and logic (PXE boot, multicast, unicast, capture). So it’s a heavy task to do all the changes and the FOG dev team currently does not seem to have the resources to do so. Don’t get me wrong. This can definitely be done and we will surely encourage and help people who want to implement multi-homing for FOG!

I guess what do you mean nothing happens? Do you see it transfer vmlinuz ? Is vmlinuz in /tftpboot/os/lubuntu directory? If the menu is executing correctly it should transfer both vmlinuz and initrd.lz. It might not boot, but it should transfer the files. If the menu is not executing at all, did you remember to fill out the description field in the ipxe menu config for that ipxe entry?

@Sebastian-Roth Okay, I will give it a try. Thanks for the response.