GIT 5676 Multicast results in bad images on machines.

[Tom Elliott]

We natsort the files to prevent this type of problem. Can I see output from the log file directly?

[mrdally204]

@Tom-Elliott You can find my log files at the link below. I just ran another multicast this morning and ended up with the same results.

https://dl.orangedox.com/YBrRpPXIzPFUWJd9W5

[Tom Elliott]

Can you please update?

I hope to have a solution for you now. The files from multicast command generation were working properly, but the partition’s listed to be used were not being sorted in the same fashion. I’ve added a sort command to this in hopes that you should be good, but I need a test with a user who has the high number of partitions you currently have to ensure thigns are good.

[mrdally204]

@Tom-Elliott I can certainly update. I am new to this and plan on using GIT. Is there anything special I need to do to update? Last commit looks to be from yesterday which tell me your code is not there quite yet.

Edit: nevermind, I was looking at the wrong location Updating in a few

[mrdally204]

@Tom-Elliott The 2 machines restored using multicast without issue using GIT Trunk 5698. I did notice the partitions restored in order, putting the 10th partition last. Is this how a normal deploy functions currently? I could have sworn the deploy option would send the partitions sda1, sda10, sda2…

Either way I really appreciate the fast turn around with the issue I was experiencing. Expect more questions and bug reports as we continue to use this great imaging solution. We are a qa team working for a software company using it to image our test machines.

[Wayne Workman]

@mrdally204 said:

I did notice the partitions restored in order, putting the 10th partition last. Is this how a normal deploy functions currently? I could have sworn the deploy option would send the partitions sda1, sda10, sda2…

That’s what Tom fixed, and that’s why your issue is fixed.

[mrdally204]

@Wayne-Workman I’m almost positive that when I used the deploy option, BEFORE he fixed the order issue, it would restore SDA1, SDA10, SDA2… and the machines would boot up correctly and function fine. The only time that I saw the issue was when the Multicast was used, again restoring them out of order. That was the puzzling part, why would they both restore out of order but it was only an issue with the Multicast restore process and not the deploy. Either way it looks like it’s running swell now

[Wayne Workman]

@mrdally204 The two different types of tasks (multicast and unicast) probably use different code bases.

Or, Tom might have just re-written all of the base code for that to make it cleaner and it was just an oversight.

Glad it’s fixed though.

[Tom Elliott]

@mrdally204 the order doesn’t matter on unicast imaging (non multicast) because unicast pulls the partition from the partition label it’s iterating on. In multicast the order is performed by the order the udp-sender commands are sent in. So unicast would always work but multicast would give the exact issue you had. Either way I’m glad to have the partitions iterating properly anyway. It helps people truly know how far in the process they are. Imagine if you had 19 partitions. It would have ordered them imaging in 1,10,11,12,13,14,15,16,17,18,19,2,3,4,5,6,7,8,9 which would’ve been not so fun to troubleshoot where and issue occurred.

[Tom Elliott]

@Tom-Elliott to further iterate and give some more specific information.

Unicast worked because while the order was not “proper” it pulled the partition number from the iterated item. Example /dev/sda1 would look for file d1p1.img. /dev/sda10 would actually look for and use d1p10.img.

In multicast this iteration happens but the data is sent by the server.

It did not scan for a particular file.

So in your case the commands were sent in expected order.

udp-sender would send in order
d1p1.img, d1p2, d1p10

It sent the commands in that specific order. The partition receiving the file was not matching the file it was receiving. /dev/sda1 would get d1p1.img properly but /dev/sda10 was getting d1p2.img. Hopefully that helps make sense of the problem.