Bug#983357: Netinst crashes xen domU when loading kernel

[Chuck Zmudzinski]

On 5/25/2021 2:38 PM, Phillip Susi wrote:
> Michael Biebl writes:
>
>> So this is a change in behaviour in the kernel?
> Yes, this commit fixed the kernel to report the error instead of
> silently failing:
>
> commit df44b479654f62b478c18ee4d8bc4e9f897a9844
> Author: Peter Rajnoha <prajnoha at redhat.com>
> Date:   Wed Dec 5 12:27:44 2018 +0100
>
>      kobject: return error code if writing /sys/.../uevent fails
>      
>      Propagate error code back to userspace if writing the /sys/.../uevent
>      file fails. Before, the write operation always returned with success,
>      even if we failed to recognize the input string or if we failed to
>      generate the uevent itself.
>      
>      With the error codes properly propagated back to userspace, we are
>      able to react in userspace accordingly by not assuming and awaiting
>      a uevent that is not delivered.
>      
>      Signed-off-by: Peter Rajnoha <prajnoha at redhat.com>
>      Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
>
>> What happens if you boot the installed system? Does udevadm trigger fail
>> there as well?
> Yes, it does; that is how I was able to track down the problem.
>
>> I feel a bit uneasy changing the udev start script this late in the
>> release cycle (especially when it appears like covering up an issue
>> someplace else).
>>
>> I'll let Marco make the judgement on this though, as he has the most
>> experience with those udev udeb start scripts as the original author.
> So far I have been removing the -e from the shbang line in the
> start-udev script and remastering the iso so I can get it to boot.  It
> would probably be a better idea to just add a || true to the udevadm
> trigger call.  I feel fairly certain that no matter what the cause of
> the coldplug failure, the user is going to be better off ignoring it and
> trying to proceed than a kernel panic.
>

Hello,

This bug was noticed on the debian-user list recently and I have
been testing various workarounds and instead of removing -e from
the shbang line I came up with prepending the udevadm trigger call
in the start-udev script with

dmesg | grep DMI: | grep 'Xen HVM domU' ||

This causes the offending udevadm trigger call to never be invoked
when running in a Xen HVM DomU. On all other systems, the call
should be invoked like normal. With this hack, I was able to create
a modified ISO and run the bullseye installer from it in a Xen HVM
DomU and complete an install without the crash and reboot.

I also can confirm that I always see the coldplug failure on the installed
system in a Xen HVM DomU, but in that case the failure does not
cause a crash and the system boots normally after reporting the failure.

I also do not see the problem in a Xen PV DomU, which I think is
what the /install.amd/xen folder on the installation media is for.

Chuck Zmudzinski