Don’t know if you got it right by now, but here it goes how I solved it.
I write another thread in BUGS, about this.
It has to do with the way the script fog.download counts partitions.
If you really need multicast with multiple partitions:

• unzip init.xz (the same goes for init32.xz) with xz -d init.xz
• mount the init file in a loop device with: mount -o loop init sometempdir/
• go to sometempdir/bin with cd
• edit fog.download, and search for the part that does the multicast write, for your “method” (mps or mpa)
• look for the part that does a loop on each partition, and fix it in a way that it checks for the existence of the file
  (something like if [ ! -f $imgpart ] ; then echo “Partition file missing …jumping”; sleep 1; else writeMulticastImage; fi )
  (look in the “not multicast” lines or the previous multicast method, for just linux type)
• save your file, and back to the init file dir.
• zip it with xz -C crc32 init

Put the task again to try it.

Try it again …you should briefly the message “Partition file …” and get the correct ones to the partclone/partimage program stream

Other related bug is in the MulticastTask.class.php. If you have 10 or more partitions, you need natsort() instead of sort().

Maybe you need a (not so much experienced) linux shell programmer to help.

P.S. Be sure to have also installed the php-process extensions to PHP, as the killing of multicast tasks uses posix_ functions in it. (That is for a CentOS / Redhat server; on Ubuntu server I have not tested or searched for them)

Checked out svn, and the new code in fog.download is more structured and does the job as I expected, and more !

And the natsort() is ok in MulticastTask.class.php

So need to send diff files, I guess.

The code for next milestone gets care of the swap-UUID, at least, for one swap partition, that is the common sense thing to do, but …linux installers do not always care about that.

And the selective partition download …I used some empty-image and linking files trick before. Now I guess it would be possible from the web interface.

Thank you all.
P.S. Is there an expected release date for 1.3.0 ?

Hi,
I noticed part of the Multicast task failing to work, was due to FOGMulticastManager just stating it is running and somehow it is not. A restart gets things back to ‘normal’ but leaving many child processes still running.

Tracking the cause, removed the @ at @posix_kill and found that …the php package is not installed ! (on the httpd/error_log )

As I work on CentOS, the partial solution was to install php-process, which includes the php posix_ functions.
I did not found any similar package for Ubuntu/Debian.

Still, the manager now kills the main process created to attend a multicast task, but leaves the first childs created waiting to stream (cat … d1p1.img | udp-sender …)

I googled a bit, as I am not an skilled php programmer, and found on the php doc’s that neither posix_kill, nor proc_terminate kills the childs of the processes created from the php script.

So the fix would be to look for the processes childs (the childs of “sh -c …” ) looking for the PID as PPID, and kill them in a loop, and then kill the PID.

I should not that using posix_kill adds a dependency on php-process, that should be resolved at install time, or …decline the use of posix_xxx functions in favor of proc_ alike. But …then how to kill the childs as they have no proc_reference ?

I will try a fix using poxix_kill to get rid of the childs, as a workaround.

OS: CentOS 6.5
FOG: 1.2.0

Hi,

Reviewed again fog.download on the client side, and …I think something happened there on the reworking of the script.

When receiving multicast (mc case) on the mps and mpa options, there is no ‘file checking’ on the $imgpath, as in the previous 0.xx versions. It tries to receive all the partitions returned by fogpartinfo, which is …wrong in most cases, as there will not be some “parts” coming from the udp-sender on the server, as the swap partition (and I think there is absolutely no need to get/put the extended EBR, if you are using sfdisk) (that is another point, anyway)

So I took the lines from the nearby case ( I think the ‘n’ one, with os=50, Linux), deleting the swap UUID recreation line which will require checking if there was that file in the upload (thus, fog.upload also needs checking)

Tested, and …now multicast works ok for a 16 partition image without the swap partition file, and also deleting/renaming the extended partition file on the server.

The result is as expected in previous 0.xx versions, where the client just ‘jumps’ the absent files in the server, and waits for the correct stream, in order, due to the natsort previous fix.

Maybe it would be helpful for you if I send a diff file with the fog.download fixes, but I am at home now (today is a Holiday, here in Peru, and don’t have access to that private network at the testing lab)

I will like to discuss about the UUID swap file cloning: one method preserves it; the others, just do a mkswap recreating it.
What is the ‘correct’ way ? I think it depends on the Linux distro: RedHat and derivatives (CentOS, Oracle) need the UUID swap partition, Debian/Ubuntu and derivatives do not.
So the conservative would be to respect RedHat ?
I would propose reformat the swap partition and then clone the UUID, as a more complete way.

Hi, thank you for your quick response.

No, we are not using GPT; still MBR-BIOS style booting.

We had a Windows installation on our labs, with 3 to 4 partitions (one primary, the rest logical), one spare primary partition, and then a linux-swap (logical) and some different flavours and different configured linux distros, that almost always went up from 10 to 15.

One difference I note in the 1.x series, besides using sfdisk, which I myself modified in 0.22 and beyond with the addtition of one dX.tbl file, is that now the extended partition somehow gets cloned and has a file dXpY.img which not always work and writes over the sfdisk work. Is there any reason to put this extended partition as a file to clone?

The natsort() is “quick-fix” that worked for years, but as I said, the fog client uses another function. This should be consistent.

I really love Fog over the other, free or not free, alternatives, and appreciate so much your work and reworking in this release.

Today I will debug some other Multicast problems in my network. I suspect of one old kernel ‘update’ .

One bug I have found since FOG 0.22 is the sorting of the partitions. When you come to have d1p10, it is put between d1p1.img and d1p2.img, due to bad sorting.

Changing sort(), to natsort() in the MulticastTask.class.php, fixes it for Multicast
It was in /opt/fog/service/lib before, now it is in /var/www/html/fog/lib/

I am still testing it, but it looks good in the server side: the task created is in the right order.

The point is, why the client sort is right ? It uses asort, as far as I have seen in the fog.download ( /usr/share/fog/lib …) code.