This can be disregarded – and marked as solved - the underlying VM infrastrcture was having an issue - we didn’t catch it as we of course thought it was due to the upgrade.

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

Correct, they’re the same make/model Dell laptop

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.

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?

Disregard - some how the SSH service was offline.

I ran the 1.5.9.28 update just now – no errors or anything, but now i’m unable to WinSCP via SSH(SFTP) with the access denied message. I cleared my cache’s in WinSCP just in case.

Did I miss something ?

Thank you,

This can be disregarded – and marked as solved - the underlying VM infrastrcture was having an issue - we didn’t catch it as we of course thought it was due to the upgrade.

Morning all,

So I updated my Ubuntu Kernel to 18.04 – didn’t have any issues it appears - but did re-install the latest dev-branch. Images deployment which usually took 10-12 minutes now take over an hour. No changes on the VM/Network, etc.

Any thoughts?