@sebastian-roth Good morning,
Yesterday I tried changing the command to nvme0n1, however that did not make a difference. Today I am going to try rolling the Kernel back a version and see if that makes a difference. It is weird that it is transmitting data, just extremely slowly. The 7090 Ultras are transferring at 70-200MB per minute and our other devices transfer anywhere from 4-10GB per minute.

@wuenschz Update: I have launched the task in debug mode and entered nvme set-feature -f 0x0c -v=0 /dev/nvme0. I am now able to get past the “Restoring partition Tables (GPT)” portion of the cloning, however it still gets hung up at the partclone screen. I did look at the partition information and it said that “Disk /dev/nvme0n1: 256GB” Do I have to change the command to reflect nvme0n1 instead of the /dev/nvme0?

Also, I saw that it says “Write caching not supported” but does support the drive and sees the drive.

I have also tried adding the nvme_core.default_ps_max_latency_us=0 kernal arguments to to the host in FOG and that did not fix anything.

@sebastian-roth Hello again, I just wanted to update you on this issue. I have launched the task in debug mode and entered nvme set-feature -f 0x0c -v=0 /dev/nvme0. I am now able to get past the “Restoring partition Tables (GPT)” portion of the cloning, however it still gets hung up at the partclone screen. I did look at the partition information and it said that “Disk /dev/nvme0n1: 256GB” Do I have to change the command to reflect nvme0n1 instead of the /dev/nvme0?

Also, I saw that it says “Write caching not supported” but does support the drive and sees the drive.

I have also tried adding the nvme_core.default_ps_max_latency_us=0 kernal arguments to to the host in FOG and that did not fix anything.

Hello,
Currently we are in the process of refreshing some of our classroom labs and plan to deploy the new OptiPlex 7090 Ultras from Dell. We set one up in the office to test with and found that it takes about seven(7) hours to push a 16.22GB image. We tested the network port we were using for imaging by setting up a Dell laptop and imaging it and it went fine, took about ten(10) minutes. We have also tried the 7090 Ultra on a different network port and got the same results. I did let the 7090 image over night and when I came in in the morning there was a http(s) error screen up, however clicking enter fixed that and I was able to log into the PC without issue.

It is initially getting stuck on the step “Restoring Partition Tables (GPT)…” After about half an hour, it will then start the cloning process, however as I stated this can take anywhere from seven(7) to thirty-four(34) hours.

Our FOG server is running version 1.5.9 and our Kernal versions are both 5.10.34. It is also installed on a CentOS server.

The processor is an 11th Gen Intel i7 4-core 4.8GHz
16GB DDR4 RAM
256GB M.2
Intel Ethernet Connection (13) I219-LM

Any help or guidance would be greatly appreciated! I am new to managing a FOG server and know next to nothing about CentOS.
Thank you again!

@sebastian-roth Good morning Sebastian, I have been reading through the topic but have not tried anything beyond updating my FOG server’s Kernel to 5.10.34. I did see in the topic where it was suggested to add that parameter, however I believe it was stated that it was added in the 1.5.8 build of FOG. Should I still try adding it? We are using CentOS as well. If I do need to add that line, could you please clarify how I do that? I apologize but I’m not very good with Linux. Thank you for your help!

@itsupport Hello, I was curious if a solution was ever discovered for fixing the slow imaging when working with Dell 7090 Ultras? We have recently purchased this model to refresh our labs, however we can’t get the image to push to the PCs. We are running FOG 1.5.9 and I just updated the Kernel to 5.10.34 TomElliot 64.

bzImage Version: 5.10.34
bzImage32 Version: 5.10.34

It seems to hang up for a while on “Restoring Partition Tables (GPT_)”

Any help would be greatly appreciated! Thank you!