XCP-ng 8.0.0 Release Candidate
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!
I unpacked the install.img, modified the script, repacked install.img and placed it on our web server.
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
dicode-nl last edited by
So far update from XS7.2 to XCP-ng 8.0.0RC1 went fine on Intel E5430.
bnrstnr last edited by bnrstnr
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.
@stormi So is
install.imgthe only thing changed in ISO or is there some changes to rpm packages?
@bvitnik no other change
Just to confirm. After copying new
install.imgto my PXE environment, unattended installation went smoothly with my answer file.
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 ?
@achim71 I don't think so. See https://github.com/xcp-ng/host-installer/tree/master/doc
@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.
@achim71 Could you add those details in https://github.com/xcp-ng/xcp/wiki/Hardware-Compatibility-List-(HCL) ?
@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.
Tracked down the necessary patch to make ipmi work again.
*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-18.104.22.168.xcpng8.0.x86_64.rpm"?
I assume it has to be signed by microsoft to make it work with secure uefi.
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.
We should also check if that patch brought regressions and subsequent commits fixed that afterwards.
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.
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.
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.
@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.
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!