Strange interaction from grub2 and XEN

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange interaction from grub2 and XEN

Marco Nenciarini

I'm testing how xen and grub2 can work together.

I'm using xen 3.4.2 and grub2 1.97+20091115-1 from debian sid.

After many failed attempts I've discovered that on my system the first
argument that grub2 should pass to the linux kernel is lost.

This is my working grub2 configuration:

menuentry "Xen 3.4.0 / Debian GNU/Linux, Linux 2.6.31-1-xen-amd64" {
     insmod xfs
     set root=(hd0,2)
     multiboot /boot/xen-3.4-amd64.gz
     module /boot/vmlinuz-2.6.31-1-xen-amd64 dummy=dummy
root=UUID=e9ed5af4-0503-4314-9d28-415a0eb7b0a0 ro quiet
     module /boot/initrd.img-2.6.31-1-xen-amd64
}

Looking in /proc/cmdline, there isn't any dummy=dummy argument

mnencia@manwe:/tmp$ cat /proc/cmdline
root=UUID=e9ed5af4-0503-4314-9d28-415a0eb7b0a0 ro quiet

Before the addition of dummy=dummy in front of line, the missing
argument was the root=*, so my initrd had no idea of which root it have
to mount.

BTW, the problem happens with both oldschool kernels and pvops ones.

I've googled around a bit, but I haven't found anything about this issue.

Kind regards,
Marco

--
---------------------------------------------------------------------
|    Marco Nenciarini    | Debian/GNU Linux Developer - Plug Member |
| [hidden email] | http://www.prato.linux.it/~mnencia       |
---------------------------------------------------------------------
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4


_______________________________________________
Xen-users mailing list
[hidden email]
http://lists.xensource.com/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange interaction from grub2 and XEN

dbaxps
I switched etc/default/grub :
   GRUB_DISABLE_LINUX_UUID=true
and ran:-
# update-grub
Compiled pvops kernel with built in command line:-
   root=/dev/sda(x) ro console=tty0
Details here :-

http://bderzhavets.wordpress.com/2009/08/31/loading-xen-via-grub2-on-top-ubuntu-karmic-server-alpha-4/

It works for final 9.10 as well.
Boris.

--- On Sun, 11/22/09, Marco Nenciarini <[hidden email]> wrote:

From: Marco Nenciarini <[hidden email]>
Subject: [Xen-users] Strange interaction from grub2 and XEN
To: [hidden email]
Date: Sunday, November 22, 2009, 5:27 AM


I'm testing how xen and grub2 can work together.

I'm using xen 3.4.2 and grub2 1.97+20091115-1 from debian sid.

After many failed attempts I've discovered that on my system the first argument that grub2 should pass to the linux kernel is lost.

This is my working grub2 configuration:

menuentry "Xen 3.4.0 / Debian GNU/Linux, Linux 2.6.31-1-xen-amd64" {
    insmod xfs
    set root=(hd0,2)
    multiboot /boot/xen-3.4-amd64.gz
    module /boot/vmlinuz-2.6.31-1-xen-amd64 dummy=dummy root=UUID=e9ed5af4-0503-4314-9d28-415a0eb7b0a0 ro quiet
    module /boot/initrd.img-2.6.31-1-xen-amd64
}

Looking in /proc/cmdline, there isn't any dummy=dummy argument

mnencia@manwe:/tmp$ cat /proc/cmdline
root=UUID=e9ed5af4-0503-4314-9d28-415a0eb7b0a0 ro quiet

Before the addition of dummy=dummy in front of line, the missing argument was the root=*, so my initrd had no idea of which root it have to mount.

BTW, the problem happens with both oldschool kernels and pvops ones.

I've googled around a bit, but I haven't found anything about this issue.

Kind regards,
Marco

-- ---------------------------------------------------------------------
|    Marco Nenciarini    | Debian/GNU Linux Developer - Plug Member |
| mnencia@... | http://www.prato.linux.it/~mnencia       |
---------------------------------------------------------------------
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4


_______________________________________________
Xen-users mailing list
Xen-users@...
http://lists.xensource.com/xen-users


_______________________________________________
Xen-users mailing list
[hidden email]
http://lists.xensource.com/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange interaction from grub2 and XEN

Marco Nenciarini
Boris Derzhavets ha scritto:
> I switched etc/default/grub :
> |   GRUB_DISABLE_LINUX_UUID=true
> and ran:-
> # update-grub
> Compiled pvops kernel with built in command line:-
>    root=/dev/sda(x) ro console=tty0

This is a workaround, like my dummy argument.

I'm looking for a real solution, as find where is the problem and a
proper correction, or a rationale that explain what I'm doing wrong.

Kind regards,
Marco

--
---------------------------------------------------------------------
|    Marco Nenciarini    | Debian/GNU Linux Developer - Plug Member |
| [hidden email] | http://www.prato.linux.it/~mnencia       |
---------------------------------------------------------------------
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4


_______________________________________________
Xen-users mailing list
[hidden email]
http://lists.xensource.com/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange interaction from grub2 and XEN

Marco Nenciarini
In reply to this post by Marco Nenciarini
Marco Nenciarini ha scritto:

>
> I'm testing how xen and grub2 can work together.
>
> I'm using xen 3.4.2 and grub2 1.97+20091115-1 from debian sid.
>
> After many failed attempts I've discovered that on my system the first
> argument that grub2 should pass to the linux kernel is lost.
>
> This is my working grub2 configuration:
>
> menuentry "Xen 3.4.0 / Debian GNU/Linux, Linux 2.6.31-1-xen-amd64" {
>     insmod xfs
>     set root=(hd0,2)
>     multiboot /boot/xen-3.4-amd64.gz
>     module /boot/vmlinuz-2.6.31-1-xen-amd64 dummy=dummy
> root=UUID=e9ed5af4-0503-4314-9d28-415a0eb7b0a0 ro quiet
>     module /boot/initrd.img-2.6.31-1-xen-amd64
> }
>
> Looking in /proc/cmdline, there isn't any dummy=dummy argument
>
> mnencia@manwe:/tmp$ cat /proc/cmdline
> root=UUID=e9ed5af4-0503-4314-9d28-415a0eb7b0a0 ro quiet
>
> Before the addition of dummy=dummy in front of line, the missing
> argument was the root=*, so my initrd had no idea of which root it have
> to mount.
>
> BTW, the problem happens with both oldschool kernels and pvops ones.
>
> I've googled around a bit, but I haven't found anything about this issue.

I've just found something on this issue in a debian bug report

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555985#10

Here I quote the interesting part (Felix Zielcke talking of grub):

        With newest releases you have to double the filename both in multiboot
        and module line or add a dummy parameter but the filename would
reassemble GRUB Legacy's behaviour.
        I.e. with 1.97 change it to
            multiboot /xen-3.4-amd64.gz /xen-3.4-amd64.gz dom0_mem=512M
            module /vmlinuz-2.6.31.5-xen-00513-g47dfde5
/vmlinuz-2.6.31.5-xen-00513-g47dfde5 nomodeset

So is a known issue/feature. Maybe some record of this are needed in xen
wiki.

Kind Regards,
Marco

P.S: I'm still curious on why grub2 behaves in this manner.

--
---------------------------------------------------------------------
|    Marco Nenciarini    | Debian/GNU Linux Developer - Plug Member |
| [hidden email] | http://www.prato.linux.it/~mnencia       |
---------------------------------------------------------------------
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4


_______________________________________________
Xen-users mailing list
[hidden email]
http://lists.xensource.com/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange interaction from grub2 and XEN

Marco Nenciarini
In reply to this post by Marco Nenciarini
Marco Nenciarini ha scritto:

> Boris Derzhavets ha scritto:
>> I switched etc/default/grub :
>> |   GRUB_DISABLE_LINUX_UUID=true
>> and ran:-
>> # update-grub
>> Compiled pvops kernel with built in command line:-
>>    root=/dev/sda(x) ro console=tty0
>
> This is a workaround, like my dummy argument.
>
> I'm looking for a real solution, as find where is the problem and a
> proper correction, or a rationale that explain what I'm doing wrong.
>
> Kind regards,
> Marco
>

I finally found the the root cause of this issue on grub-devel mailing list.

http://lists.gnu.org/archive/html/grub-devel/2009-08/msg00001.html

Now I wonder if there is any chance to make the xen hypervisor aware of
this behavior change in grub2.

Kind regards,
Marco

--
---------------------------------------------------------------------
|    Marco Nenciarini    | Debian/GNU Linux Developer - Plug Member |
| [hidden email] | http://www.prato.linux.it/~mnencia       |
---------------------------------------------------------------------
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4


_______________________________________________
Xen-users mailing list
[hidden email]
http://lists.xensource.com/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] Re: Strange interaction from grub2 and XEN

Keir Fraser-3
On 23/11/2009 16:20, "Marco Nenciarini" <[hidden email]> wrote:

>> I'm looking for a real solution, as find where is the problem and a
>> proper correction, or a rationale that explain what I'm doing wrong.
>
> I finally found the the root cause of this issue on grub-devel mailing list.
>
> http://lists.gnu.org/archive/html/grub-devel/2009-08/msg00001.html
>
> Now I wonder if there is any chance to make the xen hypervisor aware of
> this behavior change in grub2.

So they've stopped passing the kernel name as a first element of the command
line, but haven't allocated a new flag or anything to indicate that new
behaviour? What are we supposed to do to detect it and act on it?

 -- Keir



_______________________________________________
Xen-users mailing list
[hidden email]
http://lists.xensource.com/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] Re: Strange interaction from grub2 and XEN

Keir Fraser-3
On 24/11/2009 17:11, "Keir Fraser" <[hidden email]> wrote:

>> Now I wonder if there is any chance to make the xen hypervisor aware of
>> this behavior change in grub2.
>
> So they've stopped passing the kernel name as a first element of the command
> line, but haven't allocated a new flag or anything to indicate that new
> behaviour? What are we supposed to do to detect it and act on it?

Looks like you're supposed to provide your own dummy first arg, like a '.'
or something, if booting something that assumes first arg is the kernel
name. Seems pretty stupid and unnecessary to change the behaviour I must
say. GRUB sucks.

 -- Keir



_______________________________________________
Xen-users mailing list
[hidden email]
http://lists.xensource.com/xen-users