Multicast partition order
-
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.
-
Added natsort to the MulticastTask as suggested. Thank you Felipe. I am guessing you have GPT partition tables then?
-
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’ .
-
The extended partition data get’s copied because that’s considered it’s own partition on the primary scope. The sfdisk calls just allow the reworking and sizing of the partition data. I’ve not seen any issues with having it. That’s not to say they couldn’t exist, but I just haven’t all possibilities to test with.
The natsort vs. shells asort methods may be doing the same things as one another. Numbers are typically difficult to sort out because it wants all like numbers first (e.g. 1,10-19,100,101,110-119,1110)
The nat sort just reads it in the way humans usually sort (1,2,3,4,5,etc…) I think this is the same as the asort you’re seeing.
-
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. -
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 ? -
There is no expected release date for 1.3.0, though I am hoping soon. We’ve been working on multiple things as you’re no doubt finding right now. Torrent-casting, Menu customizations, Partition selection for imaging, FOG Service, etc… are hopefully soon to come to fruition. The swap-UUID methodology works well now, but I don’t know for the case of multiple swap partitions.
Please post the diff’s. Preferably base them on the trunk pull form as it it makes it easier to find, edit and fix based on what’s already been changed. I’m always open for suggestions and help as I imagine the majority of the dev team as well. We are all human and don’t know everything.
