Skip to contentSkip to conversation

remove dependency on /boot/config-* in grub.d/20_linux_xen

PATCH In review Konrad Rzeszutek Wilk 2 participants 10 messages Jul 15, 2013 – Nov 14, 2013

lore
Share & tools
lore

Konrad Rzeszutek Wilk

author
#0 lore raw

PATCH 1/1 remove dependency on /boot/config-* in grub.d/20_linux_xen

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 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.

This patch removes said check.

Signed-off-by Konrad Rzeszutek Wilk <[email protected]>

=== modified file 'util/grub.d/20_linux_xen.in'

grub.d/20_linux_xen.in +2 -14
@@ -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
#1 lore raw
Quoted 6 lines · Konrad Rzeszutek Wilk

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.

Quoted 6 lines

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?
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.

Quoted 37 lines

This patch removes said check.

Signed-off-by Konrad Rzeszutek Wilk <[email protected]>

=== modified file 'util/grub.d/20_linux_xen.in'

grub.d/20_linux_xen.in +2 -14
@@ -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
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel

author
#2 lore raw
Quoted 8 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 6 lines · Konrad Rzeszutek Wilk

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

Quoted 8 lines
Quoted 6 lines

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.

Quoted 1 line

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?

Quoted 46 lines
Quoted 35 lines

This patch removes said check.

Signed-off-by Konrad Rzeszutek Wilk <[email protected]>

=== modified file 'util/grub.d/20_linux_xen.in'

grub.d/20_linux_xen.in 2013-07-15 17:34:32 +0000 renamed from grub.d/20_linux_xen.in 2013-03-24 13:03:33 +0000 +0 -0
@@ -144,20 +144,8 @@
  }
 
  linux_list=`for i in /boot/vmlinu[xz]-* /vmlinu[xz]-*

/boot/kernel-*; do

grub.d/20_linux_xen.in 2013-07-15 17:34:32 +0000 renamed from grub.d/20_linux_xen.in 2013-03-24 13:03:33 +0000 +0 -6
-    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

grub.d/20_linux_xen.in 2013-07-15 17:34:32 +0000 renamed from grub.d/20_linux_xen.in 2013-03-24 13:03:33 +0000 +0 -6
-        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

grub.d/20_linux_xen.in 2013-07-15 17:34:32 +0000 renamed from grub.d/20_linux_xen.in 2013-03-24 13:03:33 +0000 +2 -2
-    fi
-    done`
+    if grub_file_is_not_garbage "$i"; then echo -n "$i "; fi
+        done`
  if [ "x${linux_list}" = "x" ] ; then
      exit 0
  fi
Quoted 5 lines

_______________________________________________
Grub-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel

_______________________________________________
Grub-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel

#3 lore raw
Quoted 20 lines · konrad wilk
Quoted 11 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 6 lines · Konrad Rzeszutek Wilk

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?

Quoted 3 lines

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.

Quoted 12 lines
Quoted 7 lines
Quoted 7 lines

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.

Quoted 5 lines

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?

Quoted 8 lines

Yes, there is an decent error message on the VGA console.

Quoted 4 lines

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.

Quoted 3 lines

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.

author
#4 lore raw
Quoted 21 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 20 lines · konrad wilk
Quoted 11 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 6 lines · Konrad Rzeszutek Wilk

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?

Quoted 5 lines
Quoted 3 lines

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.

Duh! It certainly is. Thought the bzImage is decompressed and there is some form of ELF data in there, otherwise Xen wouldn't be able to load the Linux kernel and parse the .Xen.note entries.

Quoted 20 lines
Quoted 12 lines
Quoted 7 lines
Quoted 7 lines

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.

Quoted 5 lines

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?

Quoted 8 lines

Yes, there is an decent error message on the VGA console.

Quoted 4 lines

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.

Quoted 7 lines

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.

Quoted 3 lines

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.

Of course. But that begs the other question - if they are making their own kernel and a small size distro - they would surely also eliminate any other packages they don't need? But then the package manager might pull it. How different is this if a package manager pulled in say 'memtest' and they have no interest in using it?

I am not sure how to go forward with this. The Linux upstream is going to eliminate those two CONFIG_XEN_* at some point. They are going to be more of a 'hardware backend' and 'frontend' type options. Linus thinks that parsing the /boot/config-* is a bug and no user-space should depend on it changing - and there is no 'you shall not break userspace' rule to this.

Thoughts?

#5 lore raw
Quoted 25 lines · Konrad Rzeszutek Wilk
Quoted 24 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 23 lines · konrad wilk
Quoted 11 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 6 lines · Konrad Rzeszutek Wilk

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

Quoted 7 lines
Quoted 2 lines

pv_ops kernel is not ELF. It's bzImage. This article doesn't apply to bzImage.

Duh! It certainly is. Thought the bzImage is decompressed and there is some form of ELF data in there, otherwise Xen wouldn't be able to load the Linux kernel and parse the .Xen.note entries.

xen has special code for handling bzimage. Without documentation it's not easy to know what is expected from bzimage and what is guaranteed.

Quoted 8 lines
Quoted 1 line

They may not want to boot xen but end up with entries for it.

Of course. But that begs the other question - if they are making their own kernel and a small size distro - they would surely also eliminate any other packages they don't need? But then the package manager might pull it. How different is this if a package manager pulled in say 'memtest' and they have no interest in using it?

memtest has no chances of being set as default. Think about headless and remote scenarios. Wrong default would require someone to physically go to the server which might be problematic.

Quoted 10 lines

I am not sure how to go forward with this. The Linux upstream is going to eliminate those two CONFIG_XEN_* at some point. They are going to be more of a 'hardware backend' and 'frontend' type options. Linus thinks that parsing the /boot/config-* is a bug and no user-space should depend on it changing - and there is no 'you shall not break userspace' rule to this.

Thoughts?

As I said, we need docs as to what we can rely on in bzimage xen image. Not just what is there right now but what is required and guaranteed to be kept.

author
#7 lore raw
Quoted 10 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 6 lines · Konrad Rzeszutek Wilk

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).

Please try my grub_file branch:
http://git.savannah.gnu.org/cgit/grub.git/log/?h=phcoder/grub_file
It should do what you want.

Will do this week! Thank you!

Quoted 1 line
author
#8 lore raw
In reply to Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 11 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 6 lines · Konrad Rzeszutek Wilk

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).

Please try my grub_file branch:
http://git.savannah.gnu.org/cgit/grub.git/log/?h=phcoder/grub_file
It should do what you want.

Oddly I get this after I installed it.

/sbin/grub-probe: error: failed to get canonical path of `'.

And I kind of fixed it by removing the 'set -e' at the start of the file.

After that, and with me removing the /boot/config-3.12.0 file it generates an proper entry in grub.cfg for the Xen payload! Yeey!

The other thing I saw was that the 'root' option for Linux ended up being 'root=' instead of the 'root=UUID=blabla'.

See here:

if [ x"$grub_platform" != xxen \( x"$grub_cpu" = xi386 -o x"$grub_cpu" = xx86_64 -o x"$grub_platform" = x \) ]; then

menuentry 'Fedora GNU/Linux, with Xen hypervisor' --class fedora --class gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-simple-' {
	insmod part_msdos 
	insmod ext2
	set root='hd0,msdos1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  760e0266-1a60-4621-b332-0788cf687e33
	else
	  search --no-floppy --fs-uuid --set=root 760e0266-1a60-4621-b332-0788cf687e33
	fi
	echo	'Loading Xen xen ...'
        if [ "$grub_platform" = "pc" -o "$grub_platform" = "" ]; then
            xen_rm_opts=
        else
            xen_rm_opts="no-real-mode edd=off"
        fi
	multiboot	/xen.gz placeholder guest_loglvl=all com1=115200,8n1 console=com1,vga loglvl=all iommu=no-amd-iommu-perdev-intremap,verbose,debug,no-intremap  ${xen_rm_opts}
	echo	'Loading Linux 3.12.0 ...'
	module	/vmlinuz-3.12.0 placeholder root= ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0  loglevel=8 radeon.modeset=0 xen-pciback.hide=(05:00.*) console=hvc0 
	echo	'Loading initial ramdisk ...'
	module	/initramfs-3.12.0.img
}

_______________________________________________
Grub-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel

#9 lore raw
Quoted 20 lines · Konrad Rzeszutek Wilk
Quoted 11 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 6 lines · Konrad Rzeszutek Wilk

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).

Please try my grub_file branch:
http://git.savannah.gnu.org/cgit/grub.git/log/?h=phcoder/grub_file
It should do what you want.

Oddly I get this after I installed it.

/sbin/grub-probe: error: failed to get canonical path of `'.

And I kind of fixed it by removing the 'set -e' at the start of the file.

Quoted 7 lines

After that, and with me removing the /boot/config-3.12.0 file it generates an proper entry in grub.cfg for the Xen payload! Yeey!

The other thing I saw was that the 'root' option for Linux ended up being 'root=' instead of the 'root=UUID=blabla'.

I've applied a small fix. It should fix both problems you report. Could you retest?

Quoted 16 lines

See here:

if [ x"$grub_platform" != xxen \( x"$grub_cpu" = xi386 -o x"$grub_cpu" = xx86_64 -o x"$grub_platform" = x \) ]; then

menuentry 'Fedora GNU/Linux, with Xen hypervisor' --class fedora --class gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-simple-' {
	insmod part_msdos 
	insmod ext2
	set root='hd0,msdos1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  760e0266-1a60-4621-b332-0788cf687e33
	else
	  search --no-floppy --fs-uuid --set=root 760e0266-1a60-4621-b332-0788cf687e33
	fi
	echo	'Loading Xen xen ...'
        if [ "$grub_platform" = "pc" -o "$grub_platform" = "" ]; then
            xen_rm_opts=
        else
Quoted 9 lines
            xen_rm_opts="no-real-mode edd=off"
        fi
	multiboot	/xen.gz placeholder guest_loglvl=all com1=115200,8n1 console=com1,vga loglvl=all iommu=no-amd-iommu-perdev-intremap,verbose,debug,no-intremap  ${xen_rm_opts}
	echo	'Loading Linux 3.12.0 ...'
	module	/vmlinuz-3.12.0 placeholder root= ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0  loglevel=8 radeon.modeset=0 xen-pciback.hide=(05:00.*) console=hvc0 
	echo	'Loading initial ramdisk ...'
	module	/initramfs-3.12.0.img
}

_______________________________________________
Grub-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel