XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    XCP-ng 8.3 betas and RCs feedback 🚀

    Scheduled Pinned Locked Moved News
    792 Posts 89 Posters 1.2m Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      john.c @stormi
      last edited by john.c

      @stormi Is it possible to pull the bad edk2 package or at least for problematic systems send a package update which excludes in yum the bad update package of edk2?

      Any way I have suggested to the developers of dnf to implement some kind of compatibility hold system, or possibility of a bad packages list file for repository meta-data. This info would be used by default (though overridable) when using dnf install and dnf update, so bad packages are automatically excluded from installation and/or system updates.

      In principal it would operate in a similar fashion to how dandelions hold onto bad seeds, to keep them from spreading. So a bad packages list would be used by rpm repositories and dnf to keep from spreading the bad packages to more systems, thus improving system stability, reliability and/or preventing regressions.

      If you wish to give update or assistance on implementing this request upstream you can find the issue here (https://github.com/rpm-software-management/dnf/issues/2029). Also may be worth considering and/or working on transitioning to dnf for XCP-ng as well as updating the appropriate parts of the software stack in the hypervisor, and Xen Orchestra.

      MrGrymReaper created this issue in rpm-software-management/dnf

      closed Feature Request - Compatibility safe guard holds or bad package meta data list as file. #2029

      1 Reply Last reply Reply Quote 1
      • A Andrew referenced this topic on
      • stormiS
        stormi Vates 🪐 XCP-ng Team
        last edited by

        We already retain a lot of packages until they pass our internal tests successfully, but at some point we need to get feedback from users, and that's what happened here, revealing at the same time that we need to add pfSense to the OSes we test internally. Better find issues now than after the final release, and retaining packages would limit the amount of testing they receive. There's a known workaround for people who are really stuck, so I didn't pull the package back.

        1 Reply Last reply Reply Quote 0
        • stormiS
          stormi Vates 🪐 XCP-ng Team
          last edited by stormi

          There is a new build of edk2 available for testing. We don't know yet if it fixes all the issues users met, so we need your feedback.

          Install with:

          yum update edk2 --enablerepo=xcp-ng-testing,xcp-ng-ci

          If you need to rollback:

          yum downgrade edk2-20180522git4b8552d-1.5.1.xcpng8.3

          I'm especially interested in @archw's feedback, since their issue was not just with pfSense but with any UEFI VM instead. But I'm also interested in feedback from UEFI pfSense users.

          A A 2 Replies Last reply Reply Quote 2
          • A
            Andrew Top contributor @stormi
            last edited by

            @stormi New update version edk2-20220801-1.7.3.xcpng8.3.x86_64 fixed my FreeBSD UEFI boot problem (stuck on boot countdown). XCP reboot NOT required after install. Windows 10 and Ubuntu boot correctly also (but did before too). I did not test secure boot or bitlocker.

            1 Reply Last reply Reply Quote 3
            • olivierlambertO
              olivierlambert Vates 🪐 Co-Founder CEO
              last edited by

              Great news 🙂

              1 Reply Last reply Reply Quote 0
              • M
                matt-plan8
                last edited by

                Hey gents,

                Has anyone else noticed that if you have a Win 11 guest (pro or enterprise) with the vtpm, that's Entra (Azure) joined, that when migrating to a diff host it breaks the Azure AD membership?

                I'll try to dig up some more specifics and run a more thorough test, but I've run into it twice now on a VM I've been running on my test lab with 8.3 beta. Relatively simple solution, leave Azure domain, rejoin, but I suspect that that the token gets saved in vtpm and is either lost or invalidated by migrating hosts.

                1 Reply Last reply Reply Quote 0
                • olivierlambertO
                  olivierlambert Vates 🪐 Co-Founder CEO
                  last edited by

                  That's a good question 🤔 Are you migrating in the same pool or to a different pool?

                  M 1 Reply Last reply Reply Quote 0
                  • M
                    matt-plan8 @olivierlambert
                    last edited by

                    @olivierlambert

                    Same pool, I have 3 minisforum pc's I've been messing around with to learn XCP-NG, they aren't in a cluster because I got lazy after installation, but are connected via truenas iscsi as central iscsi storage.

                    Loving the system overall, I could never go back to hyper-v...

                    I was patching manually by moving machines and then using the gui single host patch button. I had an issue with rolling patches, and didn't really want to bug you guys over it, it's likely user error. Setup is installed from sources.

                    stormiS 1 Reply Last reply Reply Quote 0
                    • stormiS
                      stormi Vates 🪐 XCP-ng Team @matt-plan8
                      last edited by stormi

                      @matt-plan8 I don't understand. Pool and cluster are the same thing. Pool for XCP-ng is what VMWare calls cluster.

                      M 1 Reply Last reply Reply Quote 0
                      • M
                        matt-plan8 @stormi
                        last edited by

                        @stormi sorry I consider HA a cluster, pool I consider just a group of machines in the same management domain.

                        They are in a single pool, they aren't HA

                        1 Reply Last reply Reply Quote 1
                        • A
                          archw @stormi
                          last edited by

                          @stormi said in XCP-ng 8.3 beta 🚀:

                          yum downgrade edk2-20180522git4b8552d-1.5.1.xcpng8.3

                          It didn't work. It just sits there with the attached screen.

                          Capture-no-boot-uefi.PNG

                          stormiS 1 Reply Last reply Reply Quote 0
                          • stormiS
                            stormi Vates 🪐 XCP-ng Team @archw
                            last edited by

                            @archw You're quoting the downgrade command. May I assume you tried yum update edk2 --enablerepo=xcp-ng-testing,xcp-ng-ci instead and got version edk2-20220801-1.7.3.xcpng8.3.x86_64?

                            A 1 Reply Last reply Reply Quote 0
                            • A
                              archw @stormi
                              last edited by

                              @stormi
                              Sorry...I cliked reply to teh wrong post.

                              Yes, I ran "yum update edk2 --enablerepo=xcp-ng-testing,xcp-ng-cii" and let it install. I then rebooted the VM (several of them) and tried to start them and none worked. I then ran "yum downgrade edk2-20180522git4b8552d-1.5.1.xcpng8.3" and the VM's fired right up.

                              1 Reply Last reply Reply Quote 1
                              • stormiS
                                stormi Vates 🪐 XCP-ng Team
                                last edited by

                                I just published new updates for XCP-ng 8.3:

                                • edk2-20220801-1.7.3.xcpng8.3, which some of you already tested. It fixes UEFI pfSense booting.
                                • e2fsprogs-1.47.0-1.1.xcpng8.3 (and subpackages): brought to the same level as latest XCP-ng 8.2.1. If you installed using the latest test installation ISO, you already have it.
                                • r8125-module-9.012.04-1.xcpng8.3 which updates the r8125 driver.
                                gskgerG W 2 Replies Last reply Reply Quote 3
                                • gskgerG
                                  gskger Top contributor @stormi
                                  last edited by

                                  @stormi While I can not test the changes, the update went well. However, the restart took a few minutes longer than expected (or I was impatient again).

                                  1 Reply Last reply Reply Quote 0
                                  • W
                                    wilsonqanda @stormi
                                    last edited by

                                    @stormi Nice thanks so I can run the complete update on XOA and not worry about having to remove that single edk2 anymore that wasn't working. 🙂 Will do that later

                                    1 Reply Last reply Reply Quote 0
                                    • stormiS
                                      stormi Vates 🪐 XCP-ng Team
                                      last edited by

                                      So, @ThierryEscande found the issue which made all UEFI VMs crash on @archw's server and patched it.

                                      This was the last issue before we could publish XCP-ng 8.3 Beta 2, so this is good news.

                                      Now, we need you all to test the patched RPM and check your UEFI VMs still work well with it: start, function normally...

                                      To install it:

                                      yum update edk2-20220801-1.7.3.1.xcpng8.3 --enablerepo=xcp-ng-ci

                                      No need to reboot, but UEFI VMs need to be restarted afterwards (when doable. If you have a specfic VM that you can't reboot yet, it's OK to leave it alone).

                                      In case things do not work as expected, you can come back to the previous build with :

                                      yum downgrade edk2
                                      A B 2 Replies Last reply Reply Quote 3
                                      • A
                                        Andrew Top contributor @stormi
                                        last edited by

                                        @stormi The new version still works for me (linux/freebsd).

                                        1 Reply Last reply Reply Quote 2
                                        • B
                                          bufanda @stormi
                                          last edited by

                                          @stormi Tested the new edk package at looks good to me. was able to reboot linux and freebsd VMs without a hitch with UEFI boot mode.

                                          1 Reply Last reply Reply Quote 4
                                          • stormiS
                                            stormi Vates 🪐 XCP-ng Team
                                            last edited by

                                            Thanks to both of you. I moved the fixed edk2 package to repo xcp-ng-base, so all testers will get it next time they update.

                                            A 1 Reply Last reply Reply Quote 2
                                            • First post
                                              Last post