Posts made by jmason

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

@Sebastian-Roth So I ran a deploy today not in debug mode and noticed that the UUID lines that were missing in debug mode actually showed what appeared to be UUIDs as the deployment concluded.

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

If the laptops have more than one hard drive and they are newer dells, it could be related if not the same issue regarding nvme drive initialization order as you will find in my post started a few weeks ago:

https://forums.fogproject.org/topic/12959/dell-7730-precision-laptop-deploy-gpt-error-message.

It is an interesting read.

@Sebastian-Roth Running it again in deploy debug so I can make sure with lsblk that it initialized the drives in a different order and not have to hope it’s different.

It came up with windows as nvme0n1 this time and nvme1n1 as linux…

The only odd thing was after writing the windows disk…all of the UUID/partition related set lines were just . . . . . . . . . . . . . . . . . . . . . without any values

Resetting UUIDs for /dev/nvme0n1
Disk UUID being set to ........................................
Partition type being set to ..................................
Partition uuid being set to...................................
etc...
...
...
Resetting swap systems

but it appears to have moved on to nvme1n1 and is writing the linux image correctly.

Next steps?

@Sebastian-Roth No problem…it is running now

Partclone window to recap for the linux disk

/dev/nvme0n1p1 raw 134.2 MB
/dev/nvme0n1p2 FAT16 209.7 MB
/dev/nvme0n1p3 XFS 1.1GB
/dev/nvme0n1p4 raw 510.7 GB

windows disk

/dev/nvme1n1p1 FAT32 681.6 MB
/dev/nvme1n1p2 raw 134.2 MB
/dev/nvme1n1p3 NTFS 1.0 TB
/dev/nvme1n1p4 NTFS 1.0 GB

@Sebastian-Roth said in Dell 7730 precision laptop deploy GPT error message:

blockdev --getsize64 /dev/nvme0n1

512110190592

blockdev --getsize64 /dev/nvme1n1

1024209543168

cat /images/mydiskimage/*.size

512110190592
1024209543168

@Sebastian-Roth Okay after attempting it the third time I’m sure that I have everything assigned appropriately. Still running in deploy-debug the message is confirmed.

After the Preparing Partition layout message I get the An error has been detected! box.

No drive number passed (restore PartitionTablesAndBootLoaders)  
   Args Passed: /dev/nvme0n1  /images/mydiskimage 50 all

Kernel variables and settings:
bzImage loglevel=4 initrd=init_nvme.xz root=dev/ram0 rw amdisk_size=127000 web=http://192.168.0.1/fog/
consoleblank=0 rootfstype=ext4 shutdown=1 mac=macaddressoflaptop ftp=192.168.0.1 storage=192.168.0.1:/images/ 
storageip=192.168.0.1 osid=50 irqpoll hostname=mylaptop chkdsk=0 img=mydiskimage imgType=mpa imgPartitionType=all 
imgid=11 imgFormat=0 PIGZ_COMP=-6 hostearly=1 isdebug=yes type=down shutdown=1

@Sebastian-Roth So with the newly captured image also created with the init_nvme.xz as Host Init, I brought the host for deploy up in debug mode .
I ensured that the init disk order nvme0n1 and nvme1n1 matched the same order for when I made the image (Just like I did last week when deploying to my 19 laptops).

…well running again now with the proper init settings and host image.