Re: [PATCH] remove dependency on /boot/config-* in grub.d/20_linux_xen

[konrad wilk]

On 7/25/2013 5:24 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 15.07.2013 20:00, Konrad Rzeszutek Wilk wrote:
> > Hey,
> >
> > There is a discussion on the linux-kernel mailing list in which the
> > Linus states that "if you depend on any config file, you're broken
> > by definition" (https://lkml.org/lkml/2013/7/15/368).
> The world is broken by definition sometimes you just can't avoid being 
> broken unless a good facility for your needs is supplied. In this case 
> it would be a documentation on how to detect dom0 pv_ops. We could 
> ship a detector as a GRUB tool if appropriate documentation is provided.
One suggestion was to use readelf to see if the binary has an .Xen ELF 
note in it. But then
that creates a dependency of grub tools on 'libelf' and that is probably 
unwise for just one
case. I guess one could write a grub-detection code without depending on 
libelf to do this too?

The .Xen ELF header is documented 
here:http://wiki.xenproject.org/wiki/X86_Paravirtualised_Memory_Management#Start_Of_Day

> > The 20_linux_xen does that however it should not do it. In all fairness
> > this check is a bit of old as pretty much any upstream kernel
> > is being built by default from distros to boot with Xen. If it does
> > not, Xen will print a message telling the user that Linux does not
> > have the required components.
> It depends on kernel config. Not everybody uses one-size-fits-all 
> major distro kernels (no offense for distros but sometimes you need or 
> prefer customized kernels).
> What happens if one tries to load a kernel without pv_ops on top of 
> xen? Does he at least get a decent error message or just black screen?
Yes, there is an decent error message on the VGA console.
> Some distros increase xen_linux priority above those of standard linux 
> and it may happen that xen is inadvertently installed but no pv_ops 
> kernel is available. With proposed change such setup becomes 
> needlessly unbootable.
Correct. That is the unfortunate part. But I am not sure how different 
that is from somebody configuring the kernel and forgetting to compile 
in a SATA controller.
If a person does build their customized kernel they should surely know 
what they would like or not?

> > This patch removes said check.
> >
> > Signed-off-by: Konrad Rzeszutek Wilk <address@hidden>
> >
> > === modified file 'util/grub.d/20_linux_xen.in'
> > --- util/grub.d/20_linux_xen.in    2013-03-24 13:03:33 +0000
> > +++ util/grub.d/20_linux_xen.in    2013-07-15 17:34:32 +0000
> > @@ -144,20 +144,8 @@
> >   }
> >
> >   linux_list=`for i in /boot/vmlinu[xz]-* /vmlinu[xz]-* 
> > /boot/kernel-*; do
> > -    if grub_file_is_not_garbage "$i"; then
> > -        basename=$(basename $i)
> > -    version=$(echo $basename | sed -e "s,^[^0-9]*-,,g")
> > -    dirname=$(dirname $i)
> > -    config=
> > -    for j in "${dirname}/config-${version}" 
> > "${dirname}/config-${alt_version}" 
> > "/etc/kernels/kernel-config-${version}" ; do
> > -        if test -e "${j}" ; then
> > -        config="${j}"
> > -        break
> > -        fi
> > -    done
> > -        if (grep -qx "CONFIG_XEN_DOM0=y" "${config}" 2> /dev/null || 
> > grep -qx "CONFIG_XEN_PRIVILEGED_GUEST=y" "${config}" 2> /dev/null); 
> > then echo -n "$i " ; fi
> > -    fi
> > -    done`
> > +    if grub_file_is_not_garbage "$i"; then echo -n "$i "; fi
> > +        done`
> >   if [ "x${linux_list}" = "x" ] ; then
> >       exit 0
> >   fi
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel