XCP-ng

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups

    XCP-ng 8.0.0 Release Candidate

    News
    23
    66
    14509
    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.
    • A
      averell last edited by

      Just performed the upgrade from beta to RC. Went very smooth with yum upgrade.
      All works well, no changes were made to the altered configurations, changes I made to NFS, exports, firewall, containers and passing thru of USB controllers still intact. Very smooth upgrade.
      New version of XOA also now handles userid and password correctly.

      Good job!

      1 Reply Last reply Reply Quote 0
      • R
        renx999 last edited by

        Is it going to be possible to upgrade from RC to release also through yum when it's final? like from beta to RC?

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

          @renx999 said in XCP-ng 8.0.0 Release Candidate:

          Is it going to be possible to upgrade from RC to release also through yum when it's final? like from beta to RC?

          Yes. At worse, there may be an extra manual step but if that happens we'll document it.

          1 Reply Last reply Reply Quote 1
          • FWuerl
            FWuerl last edited by

            Upgrade in legacy mode on the testpool with older IBM x3650 M4 Servers from XCP-ng 7.6 to 8.0 RC runs perfect 🙂
            All networks, SRs and VMs up und running 🙂

            Also a fresh installed XCP-ng 8.0 RC in UEFI mode on a Lenovo ThinkSystem SR650 with latest BIOS updates an Mellanox X5 Network Adapters works perfekt out of the box.

            Nice work!!! 🙂

            1 Reply Last reply Reply Quote 2
            • S
              scpcom last edited by scpcom

              Remote Upgrade from 7.6 to 8.0 RC1 does not seem to work currently (tried on two different hosts)

              1. In dom0 shell:
              • get UUID of host
                xe host-list
              • Test
                xe host-call-plugin plugin=prepare_host_upgrade.py host-uuid=<uuid> fn=testUrl args:url=http://my.example.com/xs/releases/xcp-ng-8.0.0-rc1/
                (returns true)
              • Prepare
                xe host-call-plugin plugin=prepare_host_upgrade.py host-uuid=<uuid> fn=main args:url=http://my.example.com/xs/releases/xcp-ng-8.0.0-rc1/
                (returns true)
              • reboot
              1. Server boots , Blue background shows up

              2. Dialog
                Attempting to configure networking...

              3. Dialog
                Error occured
                local variable 'results' referenced before assignment

              xcp-ng-8.0-remote-upgrade-error.PNG

              A 1 Reply Last reply Reply Quote 0
              • R
                rj-dsl last edited by

                I would be very grateful if anyone would be able to test 8.0 on the following CPUs:

                E5520, E5540 and E5649

                I unfortunatly dont have access to a test environment and is not able to do it myself..

                So if anyone has any experiences with XCP 8.0 on these CPUs, I very interested in hearing your feedback 🙂

                bnrstnr 1 Reply Last reply Reply Quote 1
                • A
                  achim71 @scpcom last edited by achim71

                  @scpcom

                  Also hit that error there is an modification required in /opt/xensource/installer/answerfile.py

                  def processAnswerfile(self):
                          xelogging.log("Processing XML answerfile for %s." % self.operation)
                          if self.operation == 'installation':
                              install_type = getStrAttribute(self.top_node, ['mode'], default = 'fresh')
                              results['netinstall-gpg-check'] = getBoolAttribute(self.top_node, ['netinstall-gpg-check'], default = True)
                              if install_type == "fresh":
                                  results = self.parseFreshInstall()
                              elif install_type == "reinstall":
                                  results = self.parseReinstall()
                              elif install_type == "upgrade":
                                  results = self.parseUpgrade()
                              else:
                                  raise AnswerfileException, "Unknown mode, %s" % install_type
                  
                              results.update(self.parseCommon())
                          elif self.operation == 'restore':
                              results = self.parseRestore()
                          
                          return results
                  

                  Should be

                  def processAnswerfile(self):
                          xelogging.log("Processing XML answerfile for %s." % self.operation)
                          if self.operation == 'installation':
                              install_type = getStrAttribute(self.top_node, ['mode'], default = 'fresh')
                              results = {}
                              results['netinstall-gpg-check'] = getBoolAttribute(self.top_node, ['netinstall-gpg-check'], default = True)
                              if install_type == "fresh":
                                  results.update(self.parseFreshInstall())
                              elif install_type == "reinstall":
                                  results.update(self.parseReinstall())
                              elif install_type == "upgrade":
                                  results.update(self.parseUpgrade())
                              else:
                                  raise AnswerfileException, "Unknown mode, %s" % install_type
                  
                              results.update(self.parseCommon())
                          elif self.operation == 'restore':
                              results = self.parseRestore()
                          
                          return results
                  

                  In my case i started from the iso and passed an answerfile. Had to boot into manual mode switch to console #2 (ALT+F2) made the modification with vi, killed the process /opt/xensource/installer/init and launched it again using the answerfile and install options

                  /opt/xensource/installer/init --answerfile=[path to your answer file] --install
                  

                  In your case you may have to modify the file inside the install.img at your url location.
                  Hope that modification will make it into the final iso.

                  1 Reply Last reply Reply Quote 0
                  • S
                    scpcom last edited by scpcom

                    @achim71
                    Thank you for the hint. I first tried your changes but it did not work in Remote Upgrade mode (i did not use an extra answer file, I just used the same commands I posted above).
                    On second try I used these modifications and now it works!
                    https://github.com/xcp-ng/host-installer/commit/336b2b64fc0f8a6e113ca69dd3053b3124c34426#diff-6c480f72da7e1acb5eab3acf571a27e2
                    I unpacked the install.img, modified the script, repacked install.img and placed it on our web server.

                    @rj-dsl
                    My second test system is with X5670, but I also may have some other servers with E5520

                    EDIT: Remote Upgrade (with patch) worked on
                    Asrock FM2A88x Extreme4+ with AMD A8-6500
                    HP ML350 G6 with two Intel Xeon X5670

                    0 bdonnahue committed to xcp-ng/host-installer
                    [Bug fix] - Variable referenced before assignment (#11)
                    
                    * [Bug fix] - Variable referenced before assignment
                    
                    The installation will fail while using an answefile_generator script. The results variable is referenced before assignment.
                    1 Reply Last reply Reply Quote 0
                    • dicode-nl
                      dicode-nl last edited by

                      So far update from XS7.2 to XCP-ng 8.0.0RC1 went fine on Intel E5430.

                      1 Reply Last reply Reply Quote 1
                      • bnrstnr
                        bnrstnr @rj-dsl last edited by bnrstnr

                        @rj-dsl

                        @bnrstnr said in XCP-ng 8.0.0 Beta now available!:

                        HP DL360 v7 with (2) Intel E5649 working good so far. Just finished installation and yum updates and everything came right up, as expected.

                        No issues in the 2 weeks since upgrading to beta and all updates between.

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

                          I made new ISOs meant to fix the unattended installation (either remote upgrade method or installation with answer file). That's the only change so I've not made it an official RC2, just some tests ISOs for the community to confirm that the bug is fixed, so that we are sure that it will not be in the final ISOs.

                          https://updates.xcp-ng.org/tmp/RC1custom1/

                          B 1 Reply Last reply Reply Quote 0
                          • B
                            bvitnik @stormi last edited by

                            @stormi So is install.img the only thing changed in ISO or is there some changes to rpm packages?

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

                              @bvitnik no other change

                              1 Reply Last reply Reply Quote 0
                              • B
                                bvitnik last edited by

                                Just to confirm. After copying new install.img to my PXE environment, unattended installation went smoothly with my answer file.

                                1 Reply Last reply Reply Quote 2
                                • A
                                  achim71 last edited by

                                  Tried the new ISO here as well and so far it is working with the answerfile now.
                                  Is there an sytnax extension to configure an md root mirror in the answerfile in version 8 ?

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

                                    @achim71 I don't think so. See https://github.com/xcp-ng/host-installer/tree/master/doc

                                    1 Reply Last reply Reply Quote 0
                                    • A
                                      achim71 last edited by

                                      @stormi Thanks for the link
                                      Meanwhile i tried version 8 on an older HP G7 Microserver. The addon ipmi card does no longer work here. It requires passing module parameters to the ipmi_si module (https://gist.github.com/joshenders/9065698) and worked till now.
                                      With the options type=kcs ports=0xca2 there is an kernel segfault now on module load.
                                      Seems to be an issue with newer kernels.
                                      https://bugzilla.redhat.com/show_bug.cgi?id=1551285
                                      https://bugs.archlinux.org/task/57429

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

                                        @achim71 Could you add those details in https://github.com/xcp-ng/xcp/wiki/Hardware-Compatibility-List-(HCL) ?

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

                                          @stormi I try to find the commit causing the error or the one fixing it. Newer kernels (testes 5.1.3) are working. If it's not too difficult i'll try to backport the modification to 4.19.

                                          1 Reply Last reply Reply Quote 0
                                          • A
                                            achim71 last edited by

                                            Tracked down the necessary patch to make ipmi work again.

                                            https://lkml.org/lkml/2019/2/21/926

                                            *When excuting a command like:
                                            modprobe ipmi_si ports=0xffc0e3 type=bt
                                            The system would get an oops.

                                            The trouble here is that ipmi_si_hardcode_find_bmc() is called before ipmi_si_platform_init(), but initialization of the hard-coded device creates an IPMI platform device, which won't be initialized yet.

                                            The real trouble is that hard-coded devices aren't created with any device, and the fixup is done later. So do it right, create the hard-coded devices as normal platform devices.

                                            This required adding some new resource types to the IPMI platform code for passing information required by the hard-coded device
                                            and adding some code to remove the hard-coded platform devices on module removal.

                                            To enforce the "hard-coded devices passed by the user take priority over firmware devices" rule, some special code was added to check and see if a hard-coded device already exists.*

                                            The patch was backported to 4.19.37. Used the backported version from here. https://github.com/raspberrypi/linux/commit/6bba17f6bce39e46fdf8c0fe190bdc3f57ef8f8f

                                            Once applied to the 4.19.19 sources

                                            modprobe type=kcs ports=0xca2
                                            ipmitool sensor
                                            

                                            works. I tried it with an debian usb system with pristen 4.19.19 sources.
                                            Is it woth the effort to prepare the patch for the xcp-ng kernel "kernel-4.19.19-5.0.8.1.xcpng8.0.x86_64.rpm"?
                                            I assume it has to be signed by microsoft to make it work with secure uefi.

                                            0 cminyard committed to raspberrypi/linux
                                            ipmi_si: Fix crash when using hard-coded device
                                            
                                            Backport from 41b766d661bf94a364960862cfc248a78313dbd3
                                            
                                            When excuting a command like:
                                              modprobe ipmi_si ports=0xffc0e3 type=bt
                                            The system would get an oops.
                                            
                                            The trouble here is that ipmi_si_hardcode_find_bmc() is called before
                                            ipmi_si_platform_init(), but initialization of the hard-coded device
                                            creates an IPMI platform device, which won't be initialized yet.
                                            
                                            The real trouble is that hard-coded devices aren't created with
                                            any device, and the fixup is done later.  So do it right, create the
                                            hard-coded devices as normal platform devices.
                                            
                                            This required adding some new resource types to the IPMI platform
                                            code for passing information required by the hard-coded device
                                            and adding some code to remove the hard-coded platform devices
                                            on module removal.
                                            
                                            To enforce the "hard-coded devices passed by the user take priority
                                            over firmware devices" rule, some special code was added to check
                                            and see if a hard-coded device already exists.
                                            
                                            The backport required some minor fixups and adding the device
                                            id table that had been added in another change and was used
                                            in this one.
                                            
                                            Reported-by: Yang Yingliang <yangyingliang@huawei.com>
                                            Cc: stable@vger.kernel.org # v4.15+
                                            Signed-off-by: Corey Minyard <cminyard@mvista.com>
                                            Tested-by: Yang Yingliang <yangyingliang@huawei.com>
                                            Signed-off-by: Sasha Levin <sashal@kernel.org>
                                            Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
                                            1 Reply Last reply Reply Quote 1
                                            • First post
                                              Last post