So more findings
Did a test of a different image that is based on /dev/sda
instead of /dev/nvmeXnX
That image deployed with the modified kernel just fine (minus booting to the OS, but that was a windows server image, which I didn’t expect to work on a surface go).
But wait there’s more!
As I started playing around in a debug session I found that the UFS disk wants to have a sector size of 4096. This is the dump after manually creating the partitions to match the d1.minimum.partitions of the image
sfdisk --dump /dev/sda
label: gpt
label-id: 745A6813-735A-4940-840D-28D0E805850A
device: /dev/sda
unit: sectors
first-lba: 6
last-lba: 31246330
sector-size: 4096
/dev/sda1 : start= 256, size= 25600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CFB2D745-2975-480D-BD56-EA18B65E03C5, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start= 25856, size= 4096, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=57426B89-9DEE-4BDF-9CBF-E9452D985FD5, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start= 29952, size= 7340032, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=857B1626-9DC1-44FD-8120-2AB922BBBD85, name="Basic data partition"
/dev/sda4 : start= 7369984, size= 140032, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE086091-5C6A-4D63-89E2-579581B9BD63, attrs="RequiredPartition GUID:63"
Whereas the header of d1.minimum.partitions in my normal base image is 512, though it seems like it might actually be 2048 based on math of partitionSectors/sector-size = size in MB (but I might be wrong about that formula, it’s been a minute since I’ve had to deal with sectors).
This is the contents of my d1.minimum.partitions from the image I want to deploy
label: gpt
label-id: 745A6813-735A-4940-840D-28D0E805850A
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 83886046
sector-size: 512
/dev/nvme0n1p1 : start= 2048, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CFB2D745-2975-480D-BD56-EA18B65E03C5, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p2 : start= 206848, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=57426B89-9DEE-4BDF-9CBF-E9452D985FD5, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start= 239616, size= 57417925, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=857B1626-9DC1-44FD-8120-2AB922BBBD85, name="Basic data partition"
/dev/nvme0n1p4 : start= 82761728, size= 1120256, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE086091-5C6A-4D63-89E2-579581B9BD63, attrs="RequiredPartition GUID:63"
I tried what @Sebastian-Roth mentions in another post here https://forums.fogproject.org/topic/15608/imaging-from-large-drive-to-small-drive/4?=1700488459744 and what @Tom-Elliott mentions here https://forums.fogproject.org/topic/13004/error-trying-to-restore-gpt-partition-tables-on-multiple-dell-machines/13?=1700488480736
When I try to restore from the original file I get an error saying the last-lba
is invalid/too high for the disk.
What’s weird, is I can use that syntax to restore the server based image, and that min parts file also has a higher lba, but it makes a little sense as the final sector is below the drive’s “31246330” last lba.
cat ../SVR-Base-Stable/d1.minimum.partitions
label: gpt
label-id: 0B6865A1-3053-4F45-9371-B73F033C7395
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 188743646
sector-size: 512
/dev/sda1 : start= 2048, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=3DF3DEBB-C856-4CC2-9263-EAF0AABF2DDF, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start= 206848, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=C9738054-91F0-4B3A-AFFA-A9C9ABCC9663, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start= 239616, size= 27175378, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=42364778-3F9E-4421-88C1-698974428C14, name="Basic data partition", attrs="GUID:63"
/dev/sda4 : start= 27415040, size= 1269760, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=CA25B771-91EC-40A3-B200-1360371A0AD8, attrs="RequiredPartition GUID:63"
So I made a backup of my original image mbr and patition files and edited the d1.minimum.partitions to look like this
label: gpt
label-id: 745A6813-735A-4940-840D-28D0E805850A
device: /dev/nvme0n1
unit: sectors
first-lba: 6
last-lba: 31246330
sector-size: 4096
/dev/nvme0n1p1 : start= 256, size= 25600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CFB2D745-2975-480D-BD56-EA18B65E03C5, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p2 : start= 25856, size= 4096, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=57426B89-9DEE-4BDF-9CBF-E9452D985FD5, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start= 29952, size= 7340032, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=857B1626-9DC1-44FD-8120-2AB922BBBD85, name="Basic data partition"
/dev/nvme0n1p4 : start= 7369984, size= 140032, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE086091-5C6A-4D63-89E2-579581B9BD63, attrs="RequiredPartition GUID:63"
Making it match the dump after making the partitions by MB and GB size manually.
After editing it this command worked without error
sfdisk /dev/sda < /images/Base-Stable/d1.minimum.partitions
So I made a new version of the d1.mbr
sgdisk -b /mnt/d1.mbr /dev/sda
And popped that on the server to test deploying with that. ON this test, I’m not editing the d1.partitions or d1.shrunken.partitions which may make it so it doesn’t expand properly, but we’ll see how it goes…
It got past the previous errors and is now imaging! woo hoo!
How to fix this permanently though, that’s a different question.