|
From: | konrad wilk |
Subject: | Re: [PATCH] remove dependency on /boot/config-* in grub.d/20_linux_xen |
Date: | Fri, 26 Jul 2013 14:50:31 -0400 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 |
On 7/25/2013 5:24 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
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?On 15.07.2013 20:00, Konrad Rzeszutek Wilk wrote: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.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 .Xen ELF header is documented here:http://wiki.xenproject.org/wiki/X86_Paravirtualised_Memory_Management#Start_Of_Day
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?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.
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
[Prev in Thread] | Current Thread | [Next in Thread] |