Failed Imaging post migration to 20.04
-
Morning All,
Headscratcher - I just finished migrating to a new 20.04 (from 16.04) server and migrated ONE image from the old store over after bringing in the database for testing purposes.
During the image now, we get:
Current disk size doesn’t match that of the backup, Adjusting sizes to match but problems are possible
Secondary partition table overlaps the last partition by X blocks
“Partition 5 is too big for the disk”And it aborts…
Of course, I fire up the old server, everything works perfectly. The almighty google is failing me and my Linux skills are about a C+ — any thoughts or advise?
-
@zzeuss1969 What version of FOG was the old server and which do you use on the new server?
Is this deploying the exact same image to the exact same machine or a different physical host?
Image settings should be exactly the same as you moved over the whole database, right?
-
Upgraded to 1.5.9.28 (dev-branch) a few weeks ago on the old, same version on the new as well. exported the DB, Imported on new box and then WinScP’d the images to the /images folder.
Both VM’s are on the same phyiscal host.
-
@zzeuss1969 I may rephrase one of my quesitons: The machine you deploy to is exactly the same physical one?
-
Correct, they’re the same make/model Dell laptop
-
@zzeuss1969 said in Failed Imaging post migration to 20.04:
same make/model Dell laptop
But not the exact same device? Possibly a different disk in it?
Please schedule a debug deploy task in your new FOG Server. Boot up the Dell Laptop, Hit enter twice to get to the Shell, run
blockdev --getsize64 /dev/sda
and note down the disk’s size.Now run
cat /images/IMAGENAME/d1.partitions
on your FOG server and post the output here in the forums as well. -
@Sebastian-Roth Thank you – but I think we figured it out. A Junior Tech captured the original image in legacy BIOS, but we have moved on to UEFI. Once I recaptured in UEFI mode, everything is working and imaging is fine.
Thank you for your responses and guidance. It’s appreciated.
-
@zzeuss1969 Thanks for the update. It’s interesting you get this error message when capturing in legacy BIOS mode and deploying to UEFI. While I know that you cannot boot a machine in UEFI mode that has a legacy BIOS image deployed to it I don’t think that you’d get this error when capturing/deploying. We do actually have users who capture UEFI installations in legacy BIOS mode because they do their master image in a VirtualBox environment which you still cannot PXE boot in UEFI mode and it works all fine deploying this image to an UEFI machine.
Anyhow, good you got it solved!