1.4.4 to 1.5.8 migration - UEFI Deploy Issues



  • Hi, I recently migrated the images and DB to a new Ubuntu server. However when deploying the same UEFI images to the same hardware I encounter the error in the screenshot below. If I switch back to the old server with 1.4.4 I don’t have any issues with an identical image deployment!

    Capture.JPG

    Thanks,
    Mike



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


  • Developer

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



  • @Sebastian-Roth

    I have successfully recaptured the image as suggested and deployed the new image. However C: 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?



  • Ok, thanks for your help @Sebastian-Roth


  • Developer

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



  • @Sebastian-Roth
    118 GB - 73.9 GB used


  • Developer

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



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


  • Developer

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



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


  • Developer

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



  • 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.”.

    Capture.JPG


  • Developer

    @MikeS Please schedule another deploy to this host but enable the checkbox for debug in the web UI (just before you click create task). Let it boot up, hit enter twice to get to the shell and start the task with the command fog. Step through by hitting enter several times again till you see the error message and get back to the shell. Now run sgdisk -gl /images/LTSC2019_GTV_TTK_UEFI/d1.mbr /dev/sda manually to get the full error output in screen. Take a picture and post here.


Log in to reply
 

303
Online

7.0k
Users

14.2k
Topics

134.2k
Posts