Libguestfs - May 2016 - Re: supermin init segfaults when kernel has large modules

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.

For example we could check the kernels to ensure they have virtio and
the other devices we need enabled (eg. using /boot/config-*) and
discard any kernels from the list which do not.

We might also consider excluding kernels based on a blacklist of
version numbers, since kernels are sometimes released which simply
don't boot on qemu.

The current code has been picking the highest numbered non-Xen kernel
for the last 7 years, and while it generally works fine it does
occasionally cause trouble like this.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

On Fri, 27 May 2016 11:10:33 +0100
"Richard W.M. Jones" <rjones@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

On Fri, May 27, 2016 at 08:52:16AM -0400, Luiz Capitulino
wrote:
> On Fri, 27 May 2016 11:10:33 +0100
> "Richard W.M. Jones" <rjones@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
Yup, something like this would be a marked improvement on
what we're doing now.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/