[Libguestfs] supermin init segfaults when kernel has large modules
Luiz Capitulino
lcapitulino at redhat.com
Fri May 27 12:52:16 UTC 2016
On Fri, 27 May 2016 11:10:33 +0100
"Richard W.M. Jones" <rjones at redhat.com> wrote:
> Continuing the discussion from:
> https://bugzilla.redhat.com/show_bug.cgi?id=1339691#c17
>
> [Luiz: There's no need to subscribe to the mailing list, once I've
> moderated your first message the others will go through.]
>
> > IMO, supermin should use the kernel the host is running as a hint and
> > try that one first. This shouldn't be hard to do.
> >
> > This BZ should be enough evidence that picking up the highest numbered
> > kernel is not a good design decision. My kernel was a test kernel with
> > custom patches, I was just lucky it didn't blow at boot.
>
> What we really want is to pick a kernel that will definitely boot on
> qemu. It's not clear this is always going to be either the highest
> numbered kernel (for reasons you outline) nor the running kernel
> (because the host kernel may not include virtio drivers - a problem on
> Ubuntu sometimes because it has special virt kernels).
>
> This is a tough problem, but we could do better than we are doing now.
Yeah, it's tougher than I thought. What I want is to give users the
best possible experience with libguestfs. I don't want to add problems
to working code.
Here's one idea in a horrible pseudo-language I have just invented:
kernel_is_good()
{
if (required drivers in /lib/modules)
return true;
/* kernel configured without modules? */
if (required drivers in config file)
return true;
return false;
}
for each kernel in running-kernel highest-numbered next-highest-numbered
if (kernel_is_good $kernel)
return $kernel;
This starts from the most likely to work: the running kernel with
drivers in /lib/modules. If this is not good enough, it keeps
searching.
If everything fails, we have two options:
1. Print an error message explaining how to use the env
variables to use a kernel of your choosing
2. Fall back to the highest-numbered kernel and cross fingers,
although it's very likely it will fail
More information about the Libguestfs
mailing list