XCP-ng 8.3 betas and RCs feedback 🚀
-
@andyhhp I will pass that on thanks! I believe you're right in the long run this is something we are better off redeploying on their new appliance.
-
-
@stormi Update of my XCP-ng 8.3 test server through XO from source (88 patches) went really well and after a reboot (not sure if that was needed), my VMs started normaly . I will report back if something comes up. Looking forward to the RC
-
Applied recent 87 updates to 3-node home-lab pool running XCP-ng 8.3 using XO from source on the latest commit. The update worked perfectly and a mix of existing Linux and Windows VMs are running normally after the update.
-
11 hosts and thirty something VMs (windows, linux, bsd mix) and update went fine.
-
Updated 2 hosts with the current packages for 8.3. No issues during the package install and things have been running well so far. Keep up the amazing work XCP-NG/XO teams.
-
Good Morning,
I updated 2 1-node instances, one running on a Lenovo M920q and one running on a N5105 fanless devices. The Lenovo update run perfect but the N5105 device ended up in a boot loop. Both were on 8.3beta with the latest patches before.
Turned out the initrd image wasn't build but
/boot/initrd-4.19.0+1.img.cmd
was there. Running the command in the/boot/initrd-4.19.0+1.img.cmd
(new-kernel-pkg --install --mkinitrd "$@" 4.19.0+1
) created it and the reboot was successful. -
@patient0 Any chance you had rebooted before the initrd had a chance to build?
-
@stormi I was very thin on providing information, Sorry about that.
Using docker container XO I applied the patches and did something else for maybe 20 or 30 minutes. Then there were no more pending patches but also no mention of a necessary reboot. Usually I get two warning triangles, one for no-support for XO and the other that a reboot is necessary to apply the patches.
I was a bit suprised that the 88 patches didn't require a reboot but I wanted to do one anyway.
After putting the host in maintenance mode I pressed 'Smart Reboot' and let it do it's magic (the magic reboot loop that time).
Maybe I did not wait long enough. To be honest I don't really now what I would check to see if the patches are finished with applying. Usually when no there are no patches pending I do reboot. Seems I was just lucky with the Lenovo not having the problem.
-
@stormi I found that the interface-rename script broke with this update due to changes in python, specifically the line where the script concats two dict.keys(): the keys() method signature changed to return dict_keys, which doesn't have the add (or w/e it's named) method, so "a.keys()+b.keys()" fails now. I had to hand-edit the script to get it working, the fix is trivial: concat lists of keys rather than the keys directly.
-
-
@r0ssar00 hi, that issue would arise if you ran this script with python3, but it's interpreter is set as
/usr/bin/python
- How did you call this script, did you manually call it with python3? It should be ran by just running the command on the CLI eginterface-rename
-
@stormi
Updated ryzen 1700 late last week, and Threadripper 5975 and Epyc 7313p servers. No issues so far.
Installing fresh on epyc 9224 this week -
@ph7 said in XCP-ng 8.3 beta :
@stormi
I can not see anything underNetwork throughput
in XO-liteedit:
When I hover I can see the numbers but no graphI updated to latest version
Same again, no graphs -
@ph7 You seem to be the only one with this issue remaining. Maybe try a reinstall?
-
Hi there,
i was wondering for the install Image via ipxe, will there be something? I have it, that currently it only works with Legacy Bios and not the UEFI one.
-
@Houbsi The best we can do with ipxe is chaining to grub, because ipxe doesn't support multiboot2 in EFI mode.
-
I updated a test pool with 2 Intel NUC11TNHi5 hosts last week.
The updates went smooth. No issues after reboot.Can't wait till 8.3 goes live!
-
@fohdeesha I just did a reinstall of the interface-rename package to make sure I hadn't changed the shebang in the past, the reinstalled copy declares python3
-
I've notice the same python3 glitch.
You could manually amend /etc/sysconfig/network-scripts/interface-rename-data/static-rules.conf if that's an option for you.