On Fri, 27 May 2016 11:10:33 +0100 "Richard W.M. Jones" <rjones(a)redhat.com&gt; 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