1.4.4 to 1.5.8 migration - UEFI Deploy Issues

[MikeS]

Thanks @Sebastian-Roth. Initially I encountered the error below, so I reset the permissions on the images folder and now the command seems to stall “Creating new GPT entries.”.

[Sebastian Roth]

@MikeS See there is a typo in the path name!! Therefore it didn’t find the d1.mbr file. You know on Linux shells you can use the TAB key to expand path names. Give it a try. Nevertheless it seems like we have the error message already. It’s interesting this image deployed with FOG 1.4.4 without issue.

What size is the source disk and what size of disk do you want to deploy to?

Can you please post the contents of the following text files you find in /images/LTSC2019_GTV_TTK_UEFI/ on your FOG server: d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions

Also if you can, please upload d1.mbr (binary file) from that same directory to a file share and post a link here.

[MikeS]

@Sebastian-Roth Thanks, I assumed “GTV” is a typo on your part, I can’t see it anywhere on the screenshots or in any files or folders? And once I reset the permissions on the images folder and the command output now seems to stall “Creating new GPT entries.”.

Please find d1.mbr in this share…
https://1drv.ms/u/s!Ak2irxfbNras2mq4vVu2EgGRiB7r?e=0jrxQP

[Sebastian Roth]

@MikeS said in 1.4.4 to 1.5.8 migration - UEFI Deploy Issues:

I assumed “GTV” is a typo on your part

Yeah, GTV was wrong. But looking at the picture in your initial post I see ...GTC_TTK_UEFI - TTK was missing when you tried the command manually. Never mind…

Thanks for uploading the d1.mbr file. I tested deploying with that to a 512 GB disk and it worked fine without an issue. Then I tried deploying to 100 GB and 120 GB disks. Both tests surely failed because the partition layout needs at least 127 GB (rough calculation from the partition information in d1.mbr). So I am wondering what size disk you are trying to deploy this? If I had to guess from the figures in the picture I’d say your destination disk is roughly 119,3 GB.

I am not sure why your FOG 1.4.4 would deploy this image to a destination disk being actually too small for this image. Possibly older sgdisk versions didn’t check as well? But I am fairly sure we’ve seen those errors ever since FOG 1.2.0 and maybe even before that. No idea.

[MikeS]

@Sebastian-Roth

Ah ok, sorry about the misunderstanding!

Yes, your disk size calculations are correct.

So the only solution is capture a new image with a smaller disk size?

I upgraded the 1.4.4 server from older FOG versions, so maybe that is why.

Thanks,
Mike

[Sebastian Roth]

@MikeS Now that I think about it again I really wonder what happens when you deploy this image using FOG 1.4.4 to a disk of less than 120 GB?! While I can imagine sgdisk to be less strict and deploy the partition layout you’d still expect issues with the Windows partition (sda4) being too small for the data!

If you deploy using FOG 1.4.4 and start up Windows after that. What size is in Windows and how much data is on it?

So the only solution is capture a new image with a smaller disk size?

No. Well re-capture is probably the quickest way to solve this but it doesn’t have to be a smaller size disk you capture from. It only needs to have less data in sda4 (C:) so FOG is able to shrink it down further to fit it on a smaller destination disk. That’s all.

I upgraded the 1.4.4 server from older FOG versions, so maybe that is why.

Don’t think that’s the case.

[MikeS]

@Sebastian-Roth
118 GB - 73.9 GB used

[Sebastian Roth]

@MikeS FOG should be able to shrink that partition down to roughly 80 GB. In this case I would suggest you deploy this image to a machine using 1.4.4 and re-capture it using latest FOG (1.5.8 or even better if you upgrade to 1.5.9-RC1 first). I’d hope this should give you a proper image being deployable to disks smaller than 120 GB.

[MikeS]

Ok, thanks for your help @Sebastian-Roth

[MikeS]

@Sebastian-Roth

I have successfully recaptured the image as suggested and deployed the new image. However has been resized to the size of the image and therefore there is no additional capacity! Obviously I can extend the volume to use the full capacity of the disk, but ideally we would not have this additional step.

Any ideas?

[Sebastian Roth]

@MikeS We’ve had an issue that sounds similar in the inits a few days ago. But I fixed that and published the new inits (3rd of May). Did you update to 1.5.9-RC1 as suggested? When did you update?

Please run sha256sum /var/www/html/fog/service/ipxe/init.xz and post output here just to make sure which init you have. It should be 59c2c4dff91591033c681fe6e8c7ca376af25d64f593becebf3fca8301bb13fd.

[MikeS]

@Sebastian-Roth Yes, the update resolved the disk partition issue thanks.