@kratkale We are aware of this issue but still need more information to be able to solve this. Can you please schedule a debug capture on your master client (not the one you tried to deploy to here but your master client). When you get to the shell run blkid -po udev /dev/sda | grep "PART_TABLE_UUID" and sfdisk -d /dev/sda | grep "label-id" and post outputs here.

@scosta I can reproduce the error but only if I use a disk sized 60 GB or smaller. As soon as I use a disk around 120 GB (as you mentioned) I don’t have any issue deploying using the partition layout you posted.

Please re-run the debug deploy test on your VM and when it fails and you get to the shell please run fdisk -l /dev/sda, take a picture and post here.

It’s still possible I am missing something here. If so it’s probably something I can’t get from the partition layout text files. Then I may ask you to upload d1.mbr so I can test with that.

@kratkale Ok thanks for the update. So I will mark this solved again. Will push the systemd fixes to dev-branch soon.

@Tom-Elliott Ok, I suppose we just leave it like that as it has been the first time (I know of) this has happened and we were able to figure it out in less than a week. Good enough I reckon.

@fry_p From my point of view this is not indented behavior! While running the maintenance commands might help in this case I still think we should try to figure out why this happens. Thanks heaps for the details! Very likely we need to replicate the issue on a fresh install anyway to figure out what’s going on. So up to now there is no need for you to provide any more data. The story is clear enough I think. Possibly we’ll get back to you soon anyway if we can’t replicate things as expected.

Not sure though when we’ll get to it. No promise this will be found and fixed in the next days.

@kratkale said in FOG 1.5.6 Multicast problem?!:

Erasing current MBR/GPT Tables takes a looooooooooooooooong time

You have the older init files (1.5.4) still in place I am fairly sure. Hope you still have a copy of the 1.5.6 inits. If not, download here.

So to sum things up, systemd might bring up network interfaces too late and we need to wait for that! I will push a fix for that soon.

@kratkale Then schedule another multicast task and see if it’s working. I guess we are on the right way with this.

Earlier on you said:

This aproach is cousing a boot loop " Unable to locate image store …"

Where did you see this message?

@Tom-Elliott Would it be possible to prevent from this issue when returning and empty string instead of nothing when the key in globalSettings does not exist?! Not sure if that would break things in other places. You know fogmanagercontroller.class and all that way better than I do.

@fry_p May I first ask why you regularly run the database maintenance commands? Do you see issues if you don’t?

@kratkale Let’s try to take a new approach to this. Please edit /lib/systemd/system/FOGMulticastManager.service, goto line 18 that looks like this:

After=syslog.target network.target mysql.service

Change it to look like this:

After=syslog.target network-online.target mysql.service

Then reboot your FOG server and check /var/log/fog/fogmulticast.log again.

As well you might run systemd-analyze plot > systemd-deps.svg and upload that SVG graphics file to a file share and post a link here. On my Debian test VM it looks like this:

The FOG* services start late on that test system (latest Debian in virtualbox VM) anyway and that is without the above mentioned change. Would be interesting to see if that looks different on your hardware server. Possibly the network interface card on your hardware just takes a little longer…

@kratkale Ahhhh, just remembered that we had a similar issue, see here https://github.com/FOGProject/fogproject/issues/268

We ought to find a better solution to this…

@kratkale I tested on Debian as well, strange. Will take a look at the code when I get home in half an hour.

@kratkale Seems like it does not find the right network interface. Please double check the FOG config settings in the web UI for the multicast network interface setting.

As well, which Linux OS do you use?

@scosta I think we have all the information to try replicating the issue. Will do that over the weekend. If you are able to grab one more thing that might make it easier for us. Not sure if you got access over the weekend but if you easily can, get a copy of the binary d1.mbr, upload to your file share and post a link here.

@astrugatch said in FOG 1.5.6 Officially Released:

Add hostname for SSL certificate generation.
For this feature does it just read the host file on the machine or can I set this with a flag during install? I don’t currently have the FQDN in my host file, I just access it via our DNS server.

The installer grabs the name from the system and then asks if you are happy with that or want to manually change it.

@kratkale The old inits won’t help you I am fairly sure. But if you want to give it a try you can download those here: 1.5.5 and 1.5.4

Please take a look at the multicast log and post the full contents here. You find that log in /var/log/fog/fogmulticast.log

@kratkale Before releasing 1.5.6 I have tested multicasting (with two clients) and it worked perfectly fine. Have you restarted the FOG server after installing 1.5.6?

@scosta Can you please try the following: Schedule another deploy task but tick the checkbox for debug this time. Boot up the client, hit ENTER twice and when you get to the shell run the command fog to start the task. Then step through it till you hit the error. You should get back to the shell after that. Run the following command, take a picture of the output and post here:

sgdisk -gl /images/W10_SEMSIS_MULTI_1.01/d1.mbr /dev/sda

@scosta There is one particular aspect of resizable images in FOG that you need to know about. So far we have not got to the point where we distinguish between partitions that need to be fixed in size and position (e.g. MBR boot partitions tat break booting if moved) and on the other hand partitions that should be fixed in size but don’t need to stay at the same location (e.g. SWAP partition).

The math of resizing is complex enough anyway and we have not had the time to go ahead and come up with a solution to that. For that reason FOG might try to resize your partitions 1, 3 and 4 but will not move those forward to make room and fit those on a smaller size disk.

While I have not had a closer look to the figures you posted I can imagine this being the problem here.

@austinjt01 As Tom mentioned this is an issue within the newly updated inits. Moving this topic to bug reports. I am working on this and will update the inits soon!