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>

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!

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.

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>

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.

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

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 ?

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.