Here are two images showing the correlation. I only had to attempt deploy twice this time to get the difference to appear.
well I just ran it a third time and got another difference, but it appears it might be just like the first image displayed with only the output in a different order.
.
@Sebastian-Roth Grabbing the ISOs now, debian and ubuntu just updated their release.
https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-9.8.0-amd64-xfce.iso
http://releases.ubuntu.com/18.04.2/ubuntu-18.04.2-desktop-amd64.iso
@Sebastian-Roth Well if you move forward with this just let me know when you want some testing.
@Sebastian-Roth @Tom-Elliott One thing I realized today is that when the deploy fails it reboots and that gives the system a chance to initialize the way the master image expects.
Initially I assumed the key to this working for my setup was in making sure that the smaller drive was the first drive in the master image captured, so that it didn’t attempt to deploy the smaller image onto the larger drive and then fail when attempting to image the larger image onto the smaller drive. I’m not sure that is actually necessary.
So I hooked up 10 of my laptops to the switch today and deployed the group, about half failed the first startup, but on the next reboot all of them initialized the drives as the master image expected.
This might not work well for a system with more than 2 nvme drives being imaged, so I’ll still help test anything you guys come up with and need testing. But I’m fairly satisfied with even the failure and reboot and hoping it will init correctly on the next boot.
@Sebastian-Roth the *.size files were generated properly but the Disk UUID, Partition type, and Partition UUID lines still show just the being set to.................................. after writing an image to a drive. It still appears to be writing the images.
@Sebastian-Roth Was looking in the images directory here is the contents of the d1.original.uuids file
/dev/nvme0n1 c0c5d1ae-844a-476e-81c6-7df5e3996ef1
1:d8b3acfb-02fa-4da3-9eee-b42d59256a4f
/dev/nvme0n1p2 2:2607-0C5E 2:ee3b91d5-4673-4e49-9011-7d3e10182cbe
/dev/nvme0n1p3 3:bc88509e-b6ed-49c0-9106-dc7976a67b2a 3:9e96fd40-79f2-4d79-b2e7-574ddd2b5ce6
/dev/nvme0n1p4 4:HtWBPV-9Aom-jBpz-4pyv-qy3A-lf2o-x58axC 4:fea80442-d73a-494d-be20-1aeee1f51158
vs d2.original.uuids files
/dev/nvme1n1 5c273d41-1202-4874-8a69-9af1285c6d77
/dev/nvme1n1p1 1:DEFC-1910 1:2b0507fe-9371-463b-832d-63c3aa24795e
2:9667e751-1aee-4f09-b9cc-8e1c16b3010b
/dev/nvme1n1p3 3:382631A826316850 3:3adca3cc-702f-4084-9f16-3b8f241cf81e
/dev/nvme1n1p4 4:2C0C9D570C9D1D40 4:e12d4c98-026a-406c-8043-0498c66be933
Not sure if this is helpful in any way but it looked slightly odd missing /dev/nvme0n1p1 and /dev/nvme1n1p2, but may just be some debug info file you are using. Anyway thanks for all your work on this and I’ll keep checking in.
@Sebastian-Roth We are in the middle of an office move, I will test and respond as soon as I have everything set back up. Hopefully before the end of the week.
@Sebastian-Roth It only did the process once, I just semi panicked due to it being slower than when I was only running 1 at a time vs 10, and the pesky nvme drives starting and ending with different drives in the multi nvme drive system.
Weird that some of the laptops finish in the expected time about 45min was the avg, but I have some sitting at over 2hours on just one partition…and a few the elapsed time is frozen now.
After turning off and restarting a few of the laptops the others that appeared frozen started going again.