Bug#500336: patch for grub detection

[Raphael Hertzog]

tag 500336 + patch
thanks

On Thu, 30 Oct 2008, Ian Campbell wrote:
> > What's the reasoning behind this loop ? All the suitable kernels are already selected
> > by the first loot that matches CONFIG_XEN + CONFIG_XEN_PRIVILEGED_GUEST.
> > 
> > Can't we simply drop this loop and be done with it ? What do I miss ?
> 
> Current paravirt ops kernels cannot be booted as a dom0 but future ones
> will be. Currently there is no way to tell them apart, there may or may
> not be a variable similar to CONFIG_XEN_PRIVILEGED_GUEST for those
> kernels when dom0 support goes upstream. However we have no way of
> knowing what will happen here.

Why are we trying to guess the future here ? We want something working for
lenny now and we'll fix that for squeeze when it has been merged upstream.

> (I may have been mistakenly thought we were discussing that a "native
> style" entry was being created for the -xen-686 kernel (in addition to
> one which specified a hypervisor).)

That is also the case (since we don't drop anything out of
sortedKernel) but it's not what this bug is reporting. Furthermore entries
for the hypervisor tend to be first and thus any bad first entry is worse
than any bad entry that appears later in the list.

> > All the kernels are still listed individually but that category of kernel is no
> > more combined with the hypervisor if it's available.
> > 
> > We at least reduce the number of bad combinations without dropping any good
> > combination if I trust the table given in
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500336#25
> 
> But this table *does* drop a good combination, which is a CONFIG_XEN +
> no CONFIG_PARAVIRT when used inside a domU.

The table shows the CONFIG combinations in all official Debian kernels
that we care about, it doesn't drop anything. Thomas's patch drop those
combinations from sortedKernel however.

I propose to not use Thomas patch but to remove the code that tries to
deal with future kernel that do not exist yet and to be done with that
bug.

Please find the patch attached. It works here at least.

(Note: it looks like that grub-pc's update-grub doesn't deal at all with Xen
yet…)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
-------------- next part --------------
Index: update-grub
===================================================================
--- update-grub	(révision 1100)
+++ update-grub	(copie de travail)
@@ -784,32 +784,6 @@
     fi
 done
 
-# Second new style CONFIG_PARAVIRT kernels with xen support. There is
-# no distinction between xen0 and xenU in these kernels.
-for ver in `grep -l CONFIG_PARAVIRT=y /boot/config* | sed -e s%/boot/config-%%`; do
-  if ! grep -q CONFIG_XEN=y /boot/config-$ver ; then
-      continue
-  fi
-  # ver is a kernel version
-  kern="/boot/vmlinuz-$ver"
-  if [ -r $kern ] ; then
-       newerKernels=""
-       for i in $xen0Kernels ; do
-                res=$(CompareVersions "$kern" "$i")
-                if [ "$kern" != "" ] && [ "$res" -gt 0 ] ; then
-                        newerKernels="$newerKernels $kern $i"
-                        kern=""
-                else
-                        newerKernels="$newerKernels $i"
-                fi
-        done
-        if [ "$kern" != "" ] ; then
-                newerKernels="$newerKernels $kern"
-        fi
-        xen0Kernels="$newerKernels"
-    fi
-done
-
 sortedKernels=""
 for kern in $(/bin/ls -1vr /boot | grep -v "dpkg-*" | grep "^vmlinuz-") ; do
         kern="/boot/$kern"