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

    XCP-ng 8.0.0 Release Candidate

    Scheduled Pinned Locked Moved News
    66 Posts 23 Posters 32.5k Views 4 Watching
    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.
    • dicode-nlD Offline
      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
      • bnrstnrB Offline
        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
        • stormiS Offline
          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 Offline
            bvitnik @stormi
            last edited by

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

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

              @bvitnik no other change

              1 Reply Last reply Reply Quote 0
              • B Offline
                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 Offline
                  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 ?

                  stormiS 1 Reply Last reply Reply Quote 0
                  • stormiS Offline
                    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 Offline
                      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

                      stormiS 1 Reply Last reply Reply Quote 0
                      • stormiS Offline
                        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 Offline
                          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 Offline
                            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
                            • stormiS Offline
                              stormi Vates 🪐 XCP-ng Team
                              last edited by

                              Thanks. We could include it in an experimental kernel package indeed. No microsoft signature of our kernel so we're free to change it if we trust the change. You should also create this very detailed bug report on https://github.com/xcp-ng/xcp/issues so that we can track its status there and also on https://bugs.xenserver.org to let XenServer develpers know and maybe get their feedback about what they think of the fix.

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

                                We should also check if that patch brought regressions and subsequent commits fixed that afterwards.

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

                                  Did an grep for ipmi: and ipmi_si: over kernel 4.19 Changeslogs:

                                  ChangeLog-4.19.31:    ipmi_si: fix use-after-free of resource->name
                                  ChangeLog-4.19.31:    Fixes: 93c303d2045b ("ipmi_si: Clean up shutdown a bit")
                                  ChangeLog-4.19.33:    ipmi_si: Fix crash when using hard-coded device
                                  ChangeLog-4.19.37:    ipmi: fix sleep-in-atomic in free_user at cleanup SRCU user->release_barrier
                                  ChangeLog-4.19.37:    Fixes: 77f8269606bf ("ipmi: fix use-after-free of user->release_barrier.rda")
                                  ChangeLog-4.19.44:    ipmi: ipmi_si_hardcode.c: init si_type array to fix a crash
                                  ChangeLog-4.19.45:    ipmi:ssif: compare block number correctly for multi-part return messages
                                  ChangeLog-4.19.45:    Fixes: 7d6380cd40f79 ("ipmi:ssif: Fix handling of multi-part return messages").
                                  

                                  The patch i mentioned earlier was applied in 4.19.33 afterwards the patch from 4.19.44 looks like an following fix for an related issue.

                                  https://lkml.org/lkml/2019/5/7/250

                                  Yesterday I also tried to copy the whole drivers/char/ipmi folder from 4.19.57 to 4.19.19. The kernel successfully compiled and the ipmi modues also worked. Was just an quick test and needs to be compared to the above list of patches.

                                  1 Reply Last reply Reply Quote 0
                                  • R Offline
                                    r1 XCP-ng Team
                                    last edited by

                                    Hi @achim71 @stormi

                                    Patching only for 1 issue would leave other issues - just waiting to be found.

                                    Linux kernel gets weekly updates for fixes to stable and longterm. New features get added in new versions. I think at XCP we can follow longterm branch of 4.19 and keep pushing updates of kernels on regular basis.

                                    I have at tracked till 4.19.48 at link and at 2 instances I found that using the next patch on top of existing patches needs certain modifications. ( e.g. 37-pre and 47-pre )

                                    Following Linux longterm in XCP also means going back to CH updates will not be possible. But I assume, CH will anyways take updates from Linux longterm.

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

                                      @r1 I think we will provide the latest 4.19.x kernel as an alternate kernel for those who need it and keep the Citrix one by default.

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

                                        @stormi and @r1 Having the latest 4.19 kernel available would be great. It will also not require much effort from my side. 😉

                                        Update: @r1 build an rpm for your kernel with the citrix ddk 8.0.0 (and an suitable zfs-kmod package). Installed both on the G7 Microserver and ipmi_si works fine again. So thank you for providing the sources on github!

                                        1 Reply Last reply Reply Quote 0
                                        • R Offline
                                          r1 XCP-ng Team
                                          last edited by r1

                                          @achim71 I suppose you meant "built"..

                                          XCP-NG has its own variant of DDK at https://github.com/xcp-ng/xcp-ng-build-env

                                          Edit: replied on wrong topic.

                                          1 Reply Last reply Reply Quote 0
                                          • D Offline
                                            dave.opc
                                            last edited by dave.opc

                                            Is there any possibility to make installer nonGUI?
                                            On my Ryzen 2400G can't load, it boots up, and after choosing installer the screen is just blank. Tried the same image on VM it starts the installer, but with some graphics.

                                            Addon: ok, i changed 8192M to 2048M in grub.cfg and was able to install the system. Everything is working fine. Now, i got a question: i did yum update and system told me that there is a new kernel with newer xcp-ng:

                                            kernel x86_64 4.19.19-5.0.9.xcpng8.0 xcp-ng-base 30 M
                                            xcp-ng-release x86_64 8.0.0-12 xcp-ng-base 15 k
                                            xcp-ng-release-config x86_64 8.0.0-12 xcp-ng-base 350 k
                                            xenserver-firstboot noarch 1.0.11-1.1.xcpng8.0 xcp-ng-base 20 k

                                            After installing and rebooting, it still shows that kernel is 4.19.0 - any idea how to fix? (not sure if xcp-ng itself updated to 8.0.0-12, in xsconsole it shows as 8.0.0)

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post