Upgrade 8.2.1 -> 8.3 failed (manually fixed)

cg

After upgrading my first server successfully, I upgraded another one recently (different environments, no pool), but it failed.

I remembered from the forum to check installer logs, so I copied the whole directory (in case it contains useful info) and switched to another console (ALT+F3?) to see where it failed.
I don't know if it's documented somewhere, but following that console is pretty informative, rather then just seeing a progress bar.
Older windows types didn't hide what the installer is doing. It's a bit sad XCP-ng "hides" that.

tl;dr: The problem seemed to be:
STANDARD ERROR:

cp: error reading '/tmp/primary-jqbXmQ/usr/lib64/python2.7/lib-dynload/_codecs_hk.so': Input/output error
cp: failed to extend '/tmp/backup-TbutMQ/usr/lib64/python2.7/lib-dynload/_codecs_hk.so': Input/output error

As it was during backup phase, nothing was broken and I could just retry... to end up with the same problem.
As it looks like some hongkong locales, I just removed the file and tried again: with success.
Backup ran through, install/upgrade went fine. Box is running since.

I didn't back the file up, but with "ls" it looked fine like everything else. Also nobody ever touched that file. I can't say why, but wanted to drop it here, for archival purposes. Maybe someone else stumbles over a close or similar problem.

As the logs and other terminal give quite some information about current actions, debugging was somehow fun and it was interesting to dig a bit into what the installer is actually doing. Big pro over Microsoft... which often is a big pain to debug.

If you want the whole installlog-dir: I still have it, but will delete the next days, if not.

Greetings

Christof

bleader

When you say retry, did you completely restart the installation process, or did you just go back to the installer screen and retry the step that does the backup?

If you retried the step, you should still have all the logs of the installer on the updated host in /var/log/installer/ in that case, I would suggest checking the dmesg-log, that sounds like a disk error to me.

Having removed the file would not impact the newly upgraded host in anyway, it just means you lack that file in the backup, so that could have an impact in case you were to restore, which I hope you won't need.

Other than that, I would encourage you to check your disk health as this could be a sign of hardware error.