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

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

[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 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 <konrad.wilk@oracle.com>

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

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

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.
> 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.
> This patch removes said check.
>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> === 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
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

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 <konrad.wilk@oracle.com>
>>
>> === 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
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

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.

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

[Konrad Rzeszutek Wilk]

On Fri, Jul 26, 2013 at 09:02:40PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> 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.

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.

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

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?

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 29.07.2013 16:52, Konrad Rzeszutek Wilk wrote:
> On Fri, Jul 26, 2013 at 09:02:40PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> 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.
>
> 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.
>> 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.
>
> 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.

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

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

[Konrad Rzeszutek Wilk]

On Sun, Nov 10, 2013 at 09:40:29PM +0100, 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).
> > 
> 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!
> 

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

[Konrad Rzeszutek Wilk]

On Sun, Nov 10, 2013 at 09:40:29PM +0100, 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).
> > 
> 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
}

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2460 bytes --]

On 13.11.2013 14:56, Konrad Rzeszutek Wilk wrote:
> On Sun, Nov 10, 2013 at 09:40:29PM +0100, 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).
>>>
>> 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'.
> 
I've applied a small fix. It should fix both problems you report. Could
you retest?
> 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
> }
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]