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

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

On 26.07.2013 20:50, konrad wilk wrote:
>
> 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
>
pv_ops kernel is not ELF. It's bzImage. This article doesn't apply to 
bzImage.
>
>>> 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.
Xen may be installed inadvertently by package manager as pulled by some 
dpendency. So you may trigger it without touching kernel or ever 
intending to run xen.
> If a person does build their customized kernel they should surely know
> what they would like or not?
>
They may not want to boot xen but end up with entries for it.