Unable to restore 4k cluster size NVME

[Sebastian Roth]

@Fog_Newb Back then I used qcow VM disk Image format I think. Not sure though. I will see if I can find some old scripts or documentation.

[Fog_Newb]

@Sebastian-Roth

Thanks. Do you know where I can add the -C option to skip the disk size check?

[Sebastian Roth]

@Fog_Newb Notice the size difference? 555 divided by 70 equals roughly 8, same as 4096 / 512. There is no point in adding the -C option because the partition layout is not made to be pushed out to a 4k block size disk.

Can you please post your d1.partitions file you find in /images/BIGPIG/ or /images/Test/ on your FOG server? Possibly we can convert the numbers manually and try deploying like that.

I found scripts that I used some time ago to get 4k virtual disks. Turns out this was not on creation time of the VM disk but when starting the VM itself. I used QEMU with parameters -global ide-drive.physical_block_size=4096 and -drive file=disk.qcow2,if=ide,index=0,media=disk,io=native,physical_block_size=4096. Though I have not played with this in a long time and can’t remember exactly but I think it worked.

[Fog_Newb]

d1.partitions.txt @Sebastian-Roth said in Unable to restore 4k cluster size NVME:

I have since delete the BIGPIG image. Here is the one from TEST. This image was captured from the 4k block NVME

d1.partitions.txt

[Sebastian Roth]

@Fog_Newb said in Unable to restore 4k cluster size NVME:

This image was captured from the 4k block NVME

Yeah right, I see. Converting this to 512 byte block size is as easy as multiplying every sector count number by 8 - result:

label: gpt
label-id: 479D53EA-F9B2-4E50-97A5-3C89ACD97D43
device: /dev/nvme0n1
unit: sectors
first-lba: 48
last-lba: 500118144

/dev/nvme0n1p1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=7ED58F36-04DC-4D18-9CD2-C7D832B9F61E, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/nvme0n1p2 : start=     1085440, size=      614400, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=A6A8E7DC-0655-4E99-A1FB-5F42A76303A7, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p3 : start=     1699840, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=2BBCB147-BA4C-4545-806A-57770D209F01, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p4 : start=     1732608, size=   498384896, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=BECEA3AA-9442-42BF-B497-A3E0FF5D7D94, name="Basic data partition"

Should fit on a 512 byte sector size disk with 250 GB roughly (a little bit less would even do).

[Fog_Newb]

@Sebastian-Roth said in Unable to restore 4k cluster size NVME:
Cool! I changed d1.partitions to what you posted and it was able to deploy the image onto a VM with a 512 sector drive.

[Sebastian Roth]

@Fog_Newb Good to hear! You can do it the other way round as well. Capture from a 512 sector size disk, divide all the numbers by 8 and deploy to a 4k disk.

It shoudn’t be too hard to implement that for FOG 1.6 I reckon.

[Fog_Newb]

@Sebastian-Roth

This is very cool. The image finished deploying and it can boots up Windows but it would not load the desktop it goes to repair. But this could be because there is a huge difference in hardware?

Perhaps a feature could be added to convert back and forth from 4k to 512 in the web interface. The one thing I was curious about is why a 250GB drive would be needed since the image is around 60GB

[Sebastian Roth]

@Fog_Newb said in Unable to restore 4k cluster size NVME:

The one thing I was curious about is why a 250GB drive would be needed since the image is around 60GB

Well I did expect this to be a non-resizable image. If you have a resizable you’d need to also convert d1.minimum.partitions file. I’d think that should work just as well.

[Fog_Newb]

@Sebastian-Roth

Oh. Got it. That makes sense.

[Fog_Newb]

This post is deleted!