XCP-ng 8.3 betas and RCs feedback 🚀
-
@stormi Follow up on the steps I took to possibly help others that may have similar scenarios.
- Migrated all VM's off of my Master (Node1) and rebooted, upgraded to 8.3 from ISO still on BIOS mode.
- Once Node1 was back online, I went ahead and upgraded Node2, and Node3 one at a time. I would just move my current VM's around to the host I wasn't upgrading. Finally had all 3 hosts on 8.3.
- Started the UEFI transition. I started with Node1 which was the master, but I changed the master to be on Node3. I went ahead and migrated all the VM's off the Node1, shutdown, pull the HDD (So I would have a backup) and put a new HDD in. Changed my boot mode to UEFI and did a fresh install. I removed Node1 from the cluster in XO. Once back online, I went ahead and just added Node1 back into my cluster and let XO do its magic of bringing everything back online.
Only issue I ran into was a
POOL_JOINING_HOST_TLS_VERIFICATION_MISMATCH
when I attempted to add the Node1 to the cluster. I followed the steps listed here: https://xcp-ng.org/forum/post/63470Running
xe pool-enable-tls-verification
andxe host-emergency-reenable-tls-verification
on Node3 which was still the master and was then able to get the new server added to the pool.- Moved the master back to Node1 and started the process over again on Node2 and 3.
-
@eb-xcp is it something that also happens with the previous alpha/beta ISOs ?
-
@yann, No seems Beta 2 works as it should. Though I'm hesitant to go that route since RC1 is available. Is update from Beta 2 to RC1 save / reliable to do via internal updates without ISO?
-
-
I've tried to do a "clean" beta 2 install, same issue (efi shell).
I've changed bios to legacy boot and was able to run a RC1 installer (nice bootup graphic and all), but it warns you that such method will not be supported:So I ended up using said installer to recover 8.2 install from backup and I'm back up and running at 8.2 (via EFI). Not sure what part of my config could cause issues with 8.3.
-
@stormi The CentOS Base yum repo need to be changed to the baseurl vault as the mirrorlist no longer works...
-
@Andrew said in XCP-ng 8.3 betas and RCs feedback :
@stormi The CentOS Base yum repo need to be changed to the baseurl vault as the mirrorlist no longer works...
Oh yeah, i wanted to give that info to.
Is there any plan/information on a distro upgrade / distro rebase?
There is from plesk a centos2alma 8 script on the internet, if there is some ressource needed.
-
We are aware of that, we discussed the best approach recently.
-
Is XOSTOR supported on 8.3 rc1?
-
No yet, we prioritize 8.2 so far. But it will come, don't worry It's mostly packaging work and some subtle difference, but it's not that big. Just a matter of what to do first
-
@olivierlambert
Thanks for the info. No hurry. Better to do it right than fast. -
-
Ok, update on the update issues:
I could not migrate VMs from the older backup server which was upgraded to 8.3 RC1 back to 8.2 install, so I'm forced with having to continue troubleshooting it.
Today I tried to start a CD install from efi shell and I finally got an error / output as to why install fails silently:"This build of Xen requires NX support"
I guess I had it disabled in the BIOS, just wish the install would have output the error with a wait prompt or something, rather than a silent failure.
Edit: Confirmed; after enabling execution disable option within bios, installer booted without issues and the install is currently ongoing.
-
Ah thanks, great feedback
-
@olivierlambert Thank you. Install went smoothly and I'm in the process of transferring all of the VMs from the backup server back onto my main workhorse.
I just wish I remembered an old troubleshooting tip:
When something odd is going on, reset the bios to defaults (or something along those lines).I did figure out a way to run the installer from efi shell; never done that before. Wish I thought of it sooner as well (no telling how many times I've rebooted this system trying to troubleshoot things.
-
@eb-xcp said in XCP-ng 8.3 betas and RCs feedback :
Edit: Confirmed; after enabling execution disable option within bios, installer booted without issues and the install is currently ongoing.
That is a bug. Xen is supposed to be able to detect this case and re-activate NX on it's own.
For the EFI path in your screenshot, that one doesn't have logic to re-activate. IIRC, we weren't sure whether it was needed, because surely an EFI system wasn't still using Pentium4 compatibility. Clearly some wrong reasoning, and it's fairly easy to adjust.
However, fixing that path wont fix the normal MB2 path, which does have logic to reactivate and should have been able to cope fine.
What system do you have?
-
@andyhhp thanks, seems issue was most visible within RC1 install. 8.2 worked well with NX disabled (I guess by activating it on it's own), beta 2 would install, but not boot (have not tried beta 1), and RC1 would fail seemingly silently.
The efi path is not to activate the NX setting, it was just me getting to the cd directory with the bootx64.efi launcher for the installer. Running it this way, rather than allowing BIOS to boot into CD directly is what allowed me to see the output of the installer prior to exit: "This build of Xen requires NX support". Normally the next boot option would take over and this text would not be seen.
My setup is Supermicro X10SRM-TF motherboard with E5-2699 V4 processor, latest bios, UEFI boot.
I don't even remember when I disabled NX support, perhaps couple of years ago when playing around with increasing single core performance. -
@eb-xcp said in XCP-ng 8.3 betas and RCs feedback :
beta 2 would install, but not boot
Did you use the network to install the packages? I would expect that when getting them from the ISO you should have the same behavior on first boot than when booting the ISO (but obviously, once the packages get upgrade later, that would bring the problem too)
-
@yann Never got that far, 8.3 beta 2 would not boot after the install.
Difference with RC1 is that the beta 2 installer itself did not check, or could re-enable NX support, but the actual boot of beta 2 would fail similar to RC1 installer (likely due to NX support being disabled).
So I could install, but not boot, the beta 2 onto the system. My previous posts don't provide much detail, but here is how it went: https://xcp-ng.org/forum/post/80208 -
Forgot to mention that I did try installing RC1 via legacy bios onto the system (installer would work in that case), but I could not get the system to recognize boot disk (NVME) after the install (installer itself saw and could use said disk).
Ended up discovering issue with EFI installer prior to fixing the legacy path as I've not spent much time on that since legacy bios would not be supported down the road.