GIT 5676 Multicast results in bad images on machines.

[mrdally204]

@Wayne-Workman Sure.

The multicast does not begin till both machines are ready to receive. The machines progress at the same rate, switching to restoring a new partition until finished. Each machine renames the computer at the end of the restore process and reboots. (appears to fail for Windows 10 32/64 upon further inspection)

The computers show the normal pre OS boot screens and then the multiboot Windows selection screen is shown. Selecting Windows 10 for instance, which is second on the list but default choice, actually loads up Windows 7 which appears first on the list. Windows 7 attempts to load the desktop but hangs. Task manager shows a bunch of instances of winmail.exe. I was concerned it was a virus somehow stuck in there

Restoring both machines at the same time with the deploy option completes successfully and is bootable.

[Wayne Workman]

@mrdally204 oh I see now why you were bringing up the order in which the partitions are restored. The disordered restore is most likely swapping the 2nd option on the menu somehow.

So now we need to ask the @Developers if there is any particular reason why the partitions are restored in the order that they are.

For resizing reasons, it’s obvious that a certain restore order is needed in order to expand partitions into empty contiguous drive space. But for non-Resizable image types, I think it’d be best to restore the partitions back in the original order.

[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.