Re: [Libguestfs] supermin init segfaults when kernel has large modules
On Fri, 27 May 2016 11:10:33 +0100
"Richard W.M. Jones" <rjones(a)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