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.
@Sebastian-Roth For now, since I’m doing training laptops and they will always be in my work area when performing the imaging, I can use debug mode with lsblk/reboot for both capture and deploy to ensure the desired image is processed. Or I can just let it process both drives each time.
Related to the same systems mentioned in this post:
https://forums.fogproject.org/topic/12959/dell-7730-precision-laptop-deploy-gpt-error-message/93
in which we were able to get FOG to perform a Multiple Partition Image - All Disks (Not Resizable) capture and deploy with a 2 drive based nvme system working as expected. However when wanting to only capture one of the drives, the randomness of how the uefi assigns nvme0n1 and nvem1n1 to the physical drives doesn’t allow me to know which drive will be captured when specifying the Host Primary Disk as:
/dev/nvme0n1 (should be disk0 linux driv)
or
/dev/nvme1n1 (should be disk1 windows drive)
but since the assignment is random so is the chance of the correct drive being selected.
I am expecting that this will also affect any attempt to deploy the single drive image back to another one of the identically configured training laptops. So when only one drive is selected for imaging whatever mechanism was put in place to keep multiple drives identified is not working when only a single drive is selected.
I am rebooting running the task to deploy in debug so that I can lsblk to see the assignment of the nvme0n1 and nvme1n1 in relation to the disk size. I believe that I would have to deploy in the same way.
This should be interesting.
Fog 1.5.5 with the init.xz updated on April 15, 2019
@Sebastian-Roth I am now, as what I expected is the case.
@Sebastian-Roth I’m working on attempting to image just one of the disks by specifying the primary host disk field to see if the /dev/nvme0n1 and /dev/nvme1n2 map correctly to the physical disk for this process. I’m thinking there may be an issue, but I can open another thread for that.
@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.
@Sebastian-Roth
Well I am watching the systems more closely now started up some new ones, perhaps its just much slower than what I expected with 10 hooked up vs the 2 I was testing with for a few months.
Potential BIG problem with hopefully an easy fix. I finally have a big training laptop update so captured my main image from the laptop again, and then hooked up 10 laptops to the switch to deploy as I have been doing… For some reason, when the deploy is complete it RESTARTS deploying all over again. I haven’t updated anything as far as OS or fog, all I did was create a BRAND new image to deploy. I thought it was taking an awful long time for them to complete when I watched one hit the end of the deploy cycle announce clone complete display the uuids and then start over with the first drive again.
It appears to only repeat the deploy process one more time and then shut down as expected.
@Sebastian-Roth I was finally able to get everything set back up in the new office location. I downloaded and replaced the init.xz and the UUIDs appeared as expected when I performed a deploy from my original image.
I believe this may be finally solved. I can test more things if you need and somewhat faster now that I’m set back up again.
I can’t express my thanks enough! Kudos!!
@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 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 I decided to run these all again after installing FOG on our permanent server with the init_nvme.xz file. I did a new capture and deploy.
I ran deploy in debug mode and regular mode and only the Disk UUID being set to........ is still blank.
The partition type and partition uuid are being set for each partition. Not sure what would have caused that change, unless there was some quick update to the init_nvme.xz file from when I downloaded it Tuesday morning to the test server vs tuesday afternoon to the permanent server.