Re: pvgrub2 is merged

Re: pvgrub2 is merged

[Samuel Thibault]

Vladimir 'φ-coder/phcoder' Serbinenko, le Sat 09 Nov 2013 21:52:20 +0100, a écrit :
> pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.

\o/

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Andrey Borzenkov]

[-- Attachment #1.1: Type: text/plain, Size: 794 bytes --]

В Sat, 09 Nov 2013 21:52:20 +0100
Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:

> Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.
> http://git.savannah.gnu.org/cgit/grub.git
> 
> Documentation on its usage is missing for now but in short:
> ARCH=x86_64
> ./autogen.sh
> ./configure --target=$ARCH --with-platform=xen
> make
> mkdir -p boot/grub/
> cat > boot/grub/grub.cfg <<EOF
> search -s root -f /boot/grub/grub.cfg
> configfile /boot/grub/grub.cfg
> EOF
> ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o grub.xen -O $ARCH-xen -d grub-core/ boot/grub/grub.cfg
> 

Do I understand it correctly that to use grub.xen it is enough to add

kernel = "/path/to/grub.xen"

to guest configuration?


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Ian Campbell]

On Sat, 2013-11-09 at 21:52 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.

This is super cool, thanks!

> http://git.savannah.gnu.org/cgit/grub.git
> 
> Documentation on its usage is missing for now but in short:
> ARCH=x86_64
> ./autogen.sh
> ./configure --target=$ARCH --with-platform=xen

Does this enable Xen statically for the resulting binaries or is it a
dynamic/boot time selection between Xen and native?

Also, does this require any code from Xen (libxc, minios etc) at build
time or is it completely standalone?

(I'm asking because I'm thinking "how to enable this in distro
packaging"...)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 880 bytes --]

On 10.11.2013 05:47, Andrey Borzenkov wrote:
> В Sat, 09 Nov 2013 21:52:20 +0100
> Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:
> 
>> Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.
>> http://git.savannah.gnu.org/cgit/grub.git
>>
>> Documentation on its usage is missing for now but in short:
>> ARCH=x86_64
>> ./autogen.sh
>> ./configure --target=$ARCH --with-platform=xen
>> make
>> mkdir -p boot/grub/
>> cat > boot/grub/grub.cfg <<EOF
>> search -s root -f /boot/grub/grub.cfg
>> configfile /boot/grub/grub.cfg
>> EOF
>> ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o grub.xen -O $ARCH-xen -d grub-core/ boot/grub/grub.cfg
>>
> 
> Do I understand it correctly that to use grub.xen it is enough to add
> 
> kernel = "/path/to/grub.xen"
> 
> to guest configuration?
> 
Yes


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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[M A Young]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1620 bytes --]



On Sun, 10 Nov 2013, Andrey Borzenkov wrote:

> В Sat, 09 Nov 2013 21:52:20 +0100
> Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:
>
>> Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.
>> http://git.savannah.gnu.org/cgit/grub.git
>>
>> Documentation on its usage is missing for now but in short:
>> ARCH=x86_64
>> ./autogen.sh
>> ./configure --target=$ARCH --with-platform=xen
>> make
>> mkdir -p boot/grub/
>> cat > boot/grub/grub.cfg <<EOF
>> search -s root -f /boot/grub/grub.cfg
>> configfile /boot/grub/grub.cfg
>> EOF
>> ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o grub.xen -O $ARCH-xen -d grub-core/ boot/grub/grub.cfg
>>
>
> Do I understand it correctly that to use grub.xen it is enough to add
>
> kernel = "/path/to/grub.xen"
>
> to guest configuration?

I have found the following problems in doing this;

The instructions are missing a step. You I found I had to do
export pkgdatadir=.
before running ./grub-mkstandalone as otherwise it looks for some files in 
the installed version of grub2 rather than the build location.

Your script
search -s root -f /boot/grub/grub.cfg
configfile /boot/grub/grub.cfg
only checks one location, and the grub.cfg file can be in other places 
such as /grub/grub.cfg if there is a separate boot partition, or 
/boot/grub2/grub.cfg for Fedora. For testing it can be set correctly by 
hand but more locations would need to be searched for general use.

It doesn't seem to understand sub-partitions. I can get it to work if 
the boot files are in /dev/xvda but not in /dev/xvda1 .

 	Michael Young

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 1831 bytes --]

On 13.11.2013 20:06, M A Young wrote:
> 
> 
> On Sun, 10 Nov 2013, Andrey Borzenkov wrote:
> 
>> В Sat, 09 Nov 2013 21:52:20 +0100
>> Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:
>>
>>> Hello, all. pvgrub2 has just became part of upstream grub as ports
>>> i386-xen and x86_64-xen.
>>> http://git.savannah.gnu.org/cgit/grub.git
>>>
>>> Documentation on its usage is missing for now but in short:
>>> ARCH=x86_64
>>> ./autogen.sh
>>> ./configure --target=$ARCH --with-platform=xen
>>> make
>>> mkdir -p boot/grub/
>>> cat > boot/grub/grub.cfg <<EOF
>>> search -s root -f /boot/grub/grub.cfg
>>> configfile /boot/grub/grub.cfg
>>> EOF
>>> ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o grub.xen -O
>>> $ARCH-xen -d grub-core/ boot/grub/grub.cfg
>>>
>>
>> Do I understand it correctly that to use grub.xen it is enough to add
>>
>> kernel = "/path/to/grub.xen"
>>
>> to guest configuration?
> 
> I have found the following problems in doing this;
> 
> The instructions are missing a step. You I found I had to do
> export pkgdatadir=.
> before running ./grub-mkstandalone as otherwise it looks for some files
> in the installed version of grub2 rather than the build location.
> 
> Your script
> search -s root -f /boot/grub/grub.cfg
> configfile /boot/grub/grub.cfg
> only checks one location, and the grub.cfg file can be in other places
> such as /grub/grub.cfg if there is a separate boot partition, or
> /boot/grub2/grub.cfg for Fedora. For testing it can be set correctly by
> hand but more locations would need to be searched for general use.
> 
ok
> It doesn't seem to understand sub-partitions. I can get it to work if
> the boot files are in /dev/xvda but not in /dev/xvda1 .
> 
insmod part_msdos
insmod part_gpt
>     Michael Young



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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[M A Young]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 581 bytes --]

On Wed, 13 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> On 13.11.2013 20:06, M A Young wrote:
>> It doesn't seem to understand sub-partitions. I can get it to work if
>> the boot files are in /dev/xvda but not in /dev/xvda1 .
>>
> insmod part_msdos
> insmod part_gpt

Right, if I add those to the embedded grub.cfg file I get to the standard 
grub menu and the boot starts. However the boot doesn't get very far - it 
loads the kernel and the initrd file and starts the kernel but the kernel 
doesn't see the virtual disks so it doesn't get very far.

 	Michael Young

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[M A Young]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1084 bytes --]



On Thu, 14 Nov 2013, M A Young wrote:

> On Wed, 13 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
>> On 13.11.2013 20:06, M A Young wrote:
>>> It doesn't seem to understand sub-partitions. I can get it to work if
>>> the boot files are in /dev/xvda but not in /dev/xvda1 .
>>> 
>> insmod part_msdos
>> insmod part_gpt
>
> Right, if I add those to the embedded grub.cfg file I get to the standard 
> grub menu and the boot starts. However the boot doesn't get very far - it 
> loads the kernel and the initrd file and starts the kernel but the kernel 
> doesn't see the virtual disks so it doesn't get very far.

Using xenstore-ls from the dom0 on the guest when the boot stops the 
local/domain/2/device/vbd/51712 section looks like
       backend = "/local/domain/0/backend/vbd/2/51712"
       backend-id = "0"
       state = "6\000"
       virtual-device = "51712"
       device-type = "disk"
       ring-ref = "\000"
       event-channel = "\000"
       protocol = "x86_64-abi\000"

As nothing else has null character endings I suspend that is wrong.

 	Michael Young

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 1892 bytes --]

On 14.11.2013 18:03, M A Young wrote:
> 
> 
> On Thu, 14 Nov 2013, M A Young wrote:
> 
>> On Wed, 13 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>
>>> On 13.11.2013 20:06, M A Young wrote:
>>>> It doesn't seem to understand sub-partitions. I can get it to work if
>>>> the boot files are in /dev/xvda but not in /dev/xvda1 .
>>>>
>>> insmod part_msdos
>>> insmod part_gpt
>>
>> Right, if I add those to the embedded grub.cfg file I get to the
>> standard grub menu and the boot starts. However the boot doesn't get
>> very far - it loads the kernel and the initrd file and starts the
>> kernel but the kernel doesn't see the virtual disks so it doesn't get
>> very far.
> 
> Using xenstore-ls from the dom0 on the guest when the boot stops the
> local/domain/2/device/vbd/51712 section looks like
>       backend = "/local/domain/0/backend/vbd/2/51712"
>       backend-id = "0"
>       state = "6\000"
>       virtual-device = "51712"
>       device-type = "disk"
>       ring-ref = "\000"
>       event-channel = "\000"
>       protocol = "x86_64-abi\000"
> 
> As nothing else has null character endings I suspend that is wrong.
> 
Good catch. Could you test following:
diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
index 3bfd99f..ab74543 100644
--- a/grub-core/kern/xen/init.c
+++ b/grub-core/kern/xen/init.c
@@ -256,11 +256,10 @@ grub_xenstore_write_file (const char *dir, const void *buf, grub_size_t len)
 
   grub_memset (&msg, 0, sizeof (msg));
   msg.type = XS_WRITE;
-  msg.len = dirlen + len + 1;
+  msg.len = dirlen + len;
   grub_xen_store_send (&msg, sizeof (msg));
   grub_xen_store_send (dir, dirlen);
   grub_xen_store_send (buf, len);
-  grub_xen_store_send ("", 1);
   grub_xen_store_recv (&msg, sizeof (msg));
   resp = grub_malloc (msg.len + 1);
   if (!resp)

>     Michael Young



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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[M A Young]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2417 bytes --]

On Thu, 14 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> On 14.11.2013 18:03, M A Young wrote:
>>
>>
>> On Thu, 14 Nov 2013, M A Young wrote:
>>
>>> On Wed, 13 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>
>>>> On 13.11.2013 20:06, M A Young wrote:
>>>>> It doesn't seem to understand sub-partitions. I can get it to work if
>>>>> the boot files are in /dev/xvda but not in /dev/xvda1 .
>>>>>
>>>> insmod part_msdos
>>>> insmod part_gpt
>>>
>>> Right, if I add those to the embedded grub.cfg file I get to the
>>> standard grub menu and the boot starts. However the boot doesn't get
>>> very far - it loads the kernel and the initrd file and starts the
>>> kernel but the kernel doesn't see the virtual disks so it doesn't get
>>> very far.
>>
>> Using xenstore-ls from the dom0 on the guest when the boot stops the
>> local/domain/2/device/vbd/51712 section looks like
>>       backend = "/local/domain/0/backend/vbd/2/51712"
>>       backend-id = "0"
>>       state = "6\000"
>>       virtual-device = "51712"
>>       device-type = "disk"
>>       ring-ref = "\000"
>>       event-channel = "\000"
>>       protocol = "x86_64-abi\000"
>>
>> As nothing else has null character endings I suspend that is wrong.
>>
> Good catch. Could you test following:
> diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
> index 3bfd99f..ab74543 100644
> --- a/grub-core/kern/xen/init.c
> +++ b/grub-core/kern/xen/init.c
> @@ -256,11 +256,10 @@ grub_xenstore_write_file (const char *dir, const void *buf, grub_size_t len)
>
>   grub_memset (&msg, 0, sizeof (msg));
>   msg.type = XS_WRITE;
> -  msg.len = dirlen + len + 1;
> +  msg.len = dirlen + len;
>   grub_xen_store_send (&msg, sizeof (msg));
>   grub_xen_store_send (dir, dirlen);
>   grub_xen_store_send (buf, len);
> -  grub_xen_store_send ("", 1);
>   grub_xen_store_recv (&msg, sizeof (msg));
>   resp = grub_malloc (msg.len + 1);
>   if (!resp)

The section is tidied up, ie.
       backend = "/local/domain/0/backend/vbd/4/51712"
       backend-id = "0"
       state = "6"
       virtual-device = "51712"
       device-type = "disk"
       ring-ref = ""
       event-channel = ""
       protocol = "x86_64-abi"

but unfortunately it doesn't help as the boot process sticks at the same 
point. I notice this section is in state 6 which apparently is "closed". 
I wonder if the kernel expecting something else.

 	Michael Young

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 3118 bytes --]

On 14.11.2013 19:48, M A Young wrote:
> On Thu, 14 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> 
>> On 14.11.2013 18:03, M A Young wrote:
>>>
>>>
>>> On Thu, 14 Nov 2013, M A Young wrote:
>>>
>>>> On Wed, 13 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>>
>>>>> On 13.11.2013 20:06, M A Young wrote:
>>>>>> It doesn't seem to understand sub-partitions. I can get it to work if
>>>>>> the boot files are in /dev/xvda but not in /dev/xvda1 .
>>>>>>
>>>>> insmod part_msdos
>>>>> insmod part_gpt
>>>>
>>>> Right, if I add those to the embedded grub.cfg file I get to the
>>>> standard grub menu and the boot starts. However the boot doesn't get
>>>> very far - it loads the kernel and the initrd file and starts the
>>>> kernel but the kernel doesn't see the virtual disks so it doesn't get
>>>> very far.
>>>
>>> Using xenstore-ls from the dom0 on the guest when the boot stops the
>>> local/domain/2/device/vbd/51712 section looks like
>>>       backend = "/local/domain/0/backend/vbd/2/51712"
>>>       backend-id = "0"
>>>       state = "6\000"
>>>       virtual-device = "51712"
>>>       device-type = "disk"
>>>       ring-ref = "\000"
>>>       event-channel = "\000"
>>>       protocol = "x86_64-abi\000"
>>>
>>> As nothing else has null character endings I suspend that is wrong.
>>>
>> Good catch. Could you test following:
>> diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
>> index 3bfd99f..ab74543 100644
>> --- a/grub-core/kern/xen/init.c
>> +++ b/grub-core/kern/xen/init.c
>> @@ -256,11 +256,10 @@ grub_xenstore_write_file (const char *dir, const
>> void *buf, grub_size_t len)
>>
>>   grub_memset (&msg, 0, sizeof (msg));
>>   msg.type = XS_WRITE;
>> -  msg.len = dirlen + len + 1;
>> +  msg.len = dirlen + len;
>>   grub_xen_store_send (&msg, sizeof (msg));
>>   grub_xen_store_send (dir, dirlen);
>>   grub_xen_store_send (buf, len);
>> -  grub_xen_store_send ("", 1);
>>   grub_xen_store_recv (&msg, sizeof (msg));
>>   resp = grub_malloc (msg.len + 1);
>>   if (!resp)
> 
> The section is tidied up, ie.
>       backend = "/local/domain/0/backend/vbd/4/51712"
>       backend-id = "0"
>       state = "6"
>       virtual-device = "51712"
>       device-type = "disk"
>       ring-ref = ""
>       event-channel = ""
>       protocol = "x86_64-abi"
> 
> but unfortunately it doesn't help as the boot process sticks at the same
> point. I notice this section is in state 6 which apparently is "closed".
> I wonder if the kernel expecting something else.
Possible. I'd try this (on top of previous patch):
diff --git a/grub-core/disk/xen/xendisk.c b/grub-core/disk/xen/xendisk.c
index c449848..829da3d 100644
--- a/grub-core/disk/xen/xendisk.c
+++ b/grub-core/disk/xen/xendisk.c
@@ -449,5 +449,8 @@ grub_xendisk_fini (void)
       grub_xen_free_shared_page (virtdisks[i].shared_page);
 
       grub_xen_event_channel_op (EVTCHNOP_close, &close_op);
+
+      /* Prepare for handoff.  */
+      grub_xenstore_write_file (fdir, "0", 1);
     }
 }

> 
>     Michael Young



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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 3364 bytes --]

On 14.11.2013 19:57, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 14.11.2013 19:48, M A Young wrote:
>> On Thu, 14 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>
>>> On 14.11.2013 18:03, M A Young wrote:
>>>>
>>>>
>>>> On Thu, 14 Nov 2013, M A Young wrote:
>>>>
>>>>> On Wed, 13 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>>>
>>>>>> On 13.11.2013 20:06, M A Young wrote:
>>>>>>> It doesn't seem to understand sub-partitions. I can get it to work if
>>>>>>> the boot files are in /dev/xvda but not in /dev/xvda1 .
>>>>>>>
>>>>>> insmod part_msdos
>>>>>> insmod part_gpt
>>>>>
>>>>> Right, if I add those to the embedded grub.cfg file I get to the
>>>>> standard grub menu and the boot starts. However the boot doesn't get
>>>>> very far - it loads the kernel and the initrd file and starts the
>>>>> kernel but the kernel doesn't see the virtual disks so it doesn't get
>>>>> very far.
>>>>
>>>> Using xenstore-ls from the dom0 on the guest when the boot stops the
>>>> local/domain/2/device/vbd/51712 section looks like
>>>>       backend = "/local/domain/0/backend/vbd/2/51712"
>>>>       backend-id = "0"
>>>>       state = "6\000"
>>>>       virtual-device = "51712"
>>>>       device-type = "disk"
>>>>       ring-ref = "\000"
>>>>       event-channel = "\000"
>>>>       protocol = "x86_64-abi\000"
>>>>
>>>> As nothing else has null character endings I suspend that is wrong.
>>>>
>>> Good catch. Could you test following:
>>> diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
>>> index 3bfd99f..ab74543 100644
>>> --- a/grub-core/kern/xen/init.c
>>> +++ b/grub-core/kern/xen/init.c
>>> @@ -256,11 +256,10 @@ grub_xenstore_write_file (const char *dir, const
>>> void *buf, grub_size_t len)
>>>
>>>   grub_memset (&msg, 0, sizeof (msg));
>>>   msg.type = XS_WRITE;
>>> -  msg.len = dirlen + len + 1;
>>> +  msg.len = dirlen + len;
>>>   grub_xen_store_send (&msg, sizeof (msg));
>>>   grub_xen_store_send (dir, dirlen);
>>>   grub_xen_store_send (buf, len);
>>> -  grub_xen_store_send ("", 1);
>>>   grub_xen_store_recv (&msg, sizeof (msg));
>>>   resp = grub_malloc (msg.len + 1);
>>>   if (!resp)
>>
>> The section is tidied up, ie.
>>       backend = "/local/domain/0/backend/vbd/4/51712"
>>       backend-id = "0"
>>       state = "6"
>>       virtual-device = "51712"
>>       device-type = "disk"
>>       ring-ref = ""
>>       event-channel = ""
>>       protocol = "x86_64-abi"
>>
>> but unfortunately it doesn't help as the boot process sticks at the same
>> point. I notice this section is in state 6 which apparently is "closed".
>> I wonder if the kernel expecting something else.
> Possible. I'd try this (on top of previous patch):

Sorry, too tired. I meant:
diff --git a/grub-core/disk/xen/xendisk.c b/grub-core/disk/xen/xendisk.c
index c449848..9b71d3a 100644
--- a/grub-core/disk/xen/xendisk.c
+++ b/grub-core/disk/xen/xendisk.c
@@ -449,5 +449,10 @@ grub_xendisk_fini (void)
       grub_xen_free_shared_page (virtdisks[i].shared_page);

       grub_xen_event_channel_op (EVTCHNOP_close, &close_op);
+
+      /* Prepare for handoff.  */
+      grub_snprintf (fdir, sizeof (fdir), "%s/state",
+                    virtdisks[i].frontend_dir);
+      grub_xenstore_write_file (fdir, "0", 1);
     }
 }



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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[M A Young]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3721 bytes --]

On Thu, 14 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> On 14.11.2013 19:57, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 14.11.2013 19:48, M A Young wrote:
>>> On Thu, 14 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>
>>>> On 14.11.2013 18:03, M A Young wrote:
>>>>>
>>>>>
>>>>> On Thu, 14 Nov 2013, M A Young wrote:
>>>>>
>>>>>> On Wed, 13 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>>>>
>>>>>>> On 13.11.2013 20:06, M A Young wrote:
>>>>>>>> It doesn't seem to understand sub-partitions. I can get it to work if
>>>>>>>> the boot files are in /dev/xvda but not in /dev/xvda1 .
>>>>>>>>
>>>>>>> insmod part_msdos
>>>>>>> insmod part_gpt
>>>>>>
>>>>>> Right, if I add those to the embedded grub.cfg file I get to the
>>>>>> standard grub menu and the boot starts. However the boot doesn't get
>>>>>> very far - it loads the kernel and the initrd file and starts the
>>>>>> kernel but the kernel doesn't see the virtual disks so it doesn't get
>>>>>> very far.
>>>>>
>>>>> Using xenstore-ls from the dom0 on the guest when the boot stops the
>>>>> local/domain/2/device/vbd/51712 section looks like
>>>>>       backend = "/local/domain/0/backend/vbd/2/51712"
>>>>>       backend-id = "0"
>>>>>       state = "6\000"
>>>>>       virtual-device = "51712"
>>>>>       device-type = "disk"
>>>>>       ring-ref = "\000"
>>>>>       event-channel = "\000"
>>>>>       protocol = "x86_64-abi\000"
>>>>>
>>>>> As nothing else has null character endings I suspend that is wrong.
>>>>>
>>>> Good catch. Could you test following:
>>>> diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
>>>> index 3bfd99f..ab74543 100644
>>>> --- a/grub-core/kern/xen/init.c
>>>> +++ b/grub-core/kern/xen/init.c
>>>> @@ -256,11 +256,10 @@ grub_xenstore_write_file (const char *dir, const
>>>> void *buf, grub_size_t len)
>>>>
>>>>   grub_memset (&msg, 0, sizeof (msg));
>>>>   msg.type = XS_WRITE;
>>>> -  msg.len = dirlen + len + 1;
>>>> +  msg.len = dirlen + len;
>>>>   grub_xen_store_send (&msg, sizeof (msg));
>>>>   grub_xen_store_send (dir, dirlen);
>>>>   grub_xen_store_send (buf, len);
>>>> -  grub_xen_store_send ("", 1);
>>>>   grub_xen_store_recv (&msg, sizeof (msg));
>>>>   resp = grub_malloc (msg.len + 1);
>>>>   if (!resp)
>>>
>>> The section is tidied up, ie.
>>>       backend = "/local/domain/0/backend/vbd/4/51712"
>>>       backend-id = "0"
>>>       state = "6"
>>>       virtual-device = "51712"
>>>       device-type = "disk"
>>>       ring-ref = ""
>>>       event-channel = ""
>>>       protocol = "x86_64-abi"
>>>
>>> but unfortunately it doesn't help as the boot process sticks at the same
>>> point. I notice this section is in state 6 which apparently is "closed".
>>> I wonder if the kernel expecting something else.
>> Possible. I'd try this (on top of previous patch):
>
> Sorry, too tired. I meant:
> diff --git a/grub-core/disk/xen/xendisk.c b/grub-core/disk/xen/xendisk.c
> index c449848..9b71d3a 100644
> --- a/grub-core/disk/xen/xendisk.c
> +++ b/grub-core/disk/xen/xendisk.c
> @@ -449,5 +449,10 @@ grub_xendisk_fini (void)
>       grub_xen_free_shared_page (virtdisks[i].shared_page);
>
>       grub_xen_event_channel_op (EVTCHNOP_close, &close_op);
> +
> +      /* Prepare for handoff.  */
> +      grub_snprintf (fdir, sizeof (fdir), "%s/state",
> +                    virtdisks[i].frontend_dir);
> +      grub_xenstore_write_file (fdir, "0", 1);
>     }
> }

That doesn't work. However, according to the documentation state 0 is 
unknown, and the vif interface (while grub is running) is in state 1 
(initializing) so I thought I would try it, and if you replace "0" with 
"1" in the above patch then the kernel does boot.

 	Michael Young

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 4203 bytes --]

On 14.11.2013 22:11, M A Young wrote:
> On Thu, 14 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> 
>> On 14.11.2013 19:57, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>> On 14.11.2013 19:48, M A Young wrote:
>>>> On Thu, 14 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>>
>>>>> On 14.11.2013 18:03, M A Young wrote:
>>>>>>
>>>>>>
>>>>>> On Thu, 14 Nov 2013, M A Young wrote:
>>>>>>
>>>>>>> On Wed, 13 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>>>>>
>>>>>>>> On 13.11.2013 20:06, M A Young wrote:
>>>>>>>>> It doesn't seem to understand sub-partitions. I can get it to
>>>>>>>>> work if
>>>>>>>>> the boot files are in /dev/xvda but not in /dev/xvda1 .
>>>>>>>>>
>>>>>>>> insmod part_msdos
>>>>>>>> insmod part_gpt
>>>>>>>
>>>>>>> Right, if I add those to the embedded grub.cfg file I get to the
>>>>>>> standard grub menu and the boot starts. However the boot doesn't get
>>>>>>> very far - it loads the kernel and the initrd file and starts the
>>>>>>> kernel but the kernel doesn't see the virtual disks so it doesn't
>>>>>>> get
>>>>>>> very far.
>>>>>>
>>>>>> Using xenstore-ls from the dom0 on the guest when the boot stops the
>>>>>> local/domain/2/device/vbd/51712 section looks like
>>>>>>       backend = "/local/domain/0/backend/vbd/2/51712"
>>>>>>       backend-id = "0"
>>>>>>       state = "6\000"
>>>>>>       virtual-device = "51712"
>>>>>>       device-type = "disk"
>>>>>>       ring-ref = "\000"
>>>>>>       event-channel = "\000"
>>>>>>       protocol = "x86_64-abi\000"
>>>>>>
>>>>>> As nothing else has null character endings I suspend that is wrong.
>>>>>>
>>>>> Good catch. Could you test following:
>>>>> diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
>>>>> index 3bfd99f..ab74543 100644
>>>>> --- a/grub-core/kern/xen/init.c
>>>>> +++ b/grub-core/kern/xen/init.c
>>>>> @@ -256,11 +256,10 @@ grub_xenstore_write_file (const char *dir, const
>>>>> void *buf, grub_size_t len)
>>>>>
>>>>>   grub_memset (&msg, 0, sizeof (msg));
>>>>>   msg.type = XS_WRITE;
>>>>> -  msg.len = dirlen + len + 1;
>>>>> +  msg.len = dirlen + len;
>>>>>   grub_xen_store_send (&msg, sizeof (msg));
>>>>>   grub_xen_store_send (dir, dirlen);
>>>>>   grub_xen_store_send (buf, len);
>>>>> -  grub_xen_store_send ("", 1);
>>>>>   grub_xen_store_recv (&msg, sizeof (msg));
>>>>>   resp = grub_malloc (msg.len + 1);
>>>>>   if (!resp)
>>>>
>>>> The section is tidied up, ie.
>>>>       backend = "/local/domain/0/backend/vbd/4/51712"
>>>>       backend-id = "0"
>>>>       state = "6"
>>>>       virtual-device = "51712"
>>>>       device-type = "disk"
>>>>       ring-ref = ""
>>>>       event-channel = ""
>>>>       protocol = "x86_64-abi"
>>>>
>>>> but unfortunately it doesn't help as the boot process sticks at the
>>>> same
>>>> point. I notice this section is in state 6 which apparently is
>>>> "closed".
>>>> I wonder if the kernel expecting something else.
>>> Possible. I'd try this (on top of previous patch):
>>
>> Sorry, too tired. I meant:
>> diff --git a/grub-core/disk/xen/xendisk.c b/grub-core/disk/xen/xendisk.c
>> index c449848..9b71d3a 100644
>> --- a/grub-core/disk/xen/xendisk.c
>> +++ b/grub-core/disk/xen/xendisk.c
>> @@ -449,5 +449,10 @@ grub_xendisk_fini (void)
>>       grub_xen_free_shared_page (virtdisks[i].shared_page);
>>
>>       grub_xen_event_channel_op (EVTCHNOP_close, &close_op);
>> +
>> +      /* Prepare for handoff.  */
>> +      grub_snprintf (fdir, sizeof (fdir), "%s/state",
>> +                    virtdisks[i].frontend_dir);
>> +      grub_xenstore_write_file (fdir, "0", 1);
>>     }
>> }
> 
> That doesn't work. However, according to the documentation state 0 is
> unknown, and the vif interface (while grub is running) is in state 1
> (initializing) so I thought I would try it, and if you replace "0" with
> "1" in the above patch then the kernel does boot.
> 
Thanks.
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=c7995256e410c5272e2be2f94faf62d3c9d57b61
and
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=e1aa5b662088cea329fc968af7c819784b6da068
>     Michael Young



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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Fabio Fantoni]

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

Il 14/11/2013 22:43, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
> On 14.11.2013 22:11, M A Young wrote:
>> On Thu, 14 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>
>>> On 14.11.2013 19:57, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>> On 14.11.2013 19:48, M A Young wrote:
>>>>> On Thu, 14 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>>>
>>>>>> On 14.11.2013 18:03, M A Young wrote:
>>>>>>>
>>>>>>> On Thu, 14 Nov 2013, M A Young wrote:
>>>>>>>
>>>>>>>> On Wed, 13 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>>>>>>
>>>>>>>>> On 13.11.2013 20:06, M A Young wrote:
>>>>>>>>>> It doesn't seem to understand sub-partitions. I can get it to
>>>>>>>>>> work if
>>>>>>>>>> the boot files are in /dev/xvda but not in /dev/xvda1 .
>>>>>>>>>>
>>>>>>>>> insmod part_msdos
>>>>>>>>> insmod part_gpt
>>>>>>>> Right, if I add those to the embedded grub.cfg file I get to the
>>>>>>>> standard grub menu and the boot starts. However the boot doesn't get
>>>>>>>> very far - it loads the kernel and the initrd file and starts the
>>>>>>>> kernel but the kernel doesn't see the virtual disks so it doesn't
>>>>>>>> get
>>>>>>>> very far.
>>>>>>> Using xenstore-ls from the dom0 on the guest when the boot stops the
>>>>>>> local/domain/2/device/vbd/51712 section looks like
>>>>>>>        backend = "/local/domain/0/backend/vbd/2/51712"
>>>>>>>        backend-id = "0"
>>>>>>>        state = "6\000"
>>>>>>>        virtual-device = "51712"
>>>>>>>        device-type = "disk"
>>>>>>>        ring-ref = "\000"
>>>>>>>        event-channel = "\000"
>>>>>>>        protocol = "x86_64-abi\000"
>>>>>>>
>>>>>>> As nothing else has null character endings I suspend that is wrong.
>>>>>>>
>>>>>> Good catch. Could you test following:
>>>>>> diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
>>>>>> index 3bfd99f..ab74543 100644
>>>>>> --- a/grub-core/kern/xen/init.c
>>>>>> +++ b/grub-core/kern/xen/init.c
>>>>>> @@ -256,11 +256,10 @@ grub_xenstore_write_file (const char *dir, const
>>>>>> void *buf, grub_size_t len)
>>>>>>
>>>>>>    grub_memset (&msg, 0, sizeof (msg));
>>>>>>    msg.type = XS_WRITE;
>>>>>> -  msg.len = dirlen + len + 1;
>>>>>> +  msg.len = dirlen + len;
>>>>>>    grub_xen_store_send (&msg, sizeof (msg));
>>>>>>    grub_xen_store_send (dir, dirlen);
>>>>>>    grub_xen_store_send (buf, len);
>>>>>> -  grub_xen_store_send ("", 1);
>>>>>>    grub_xen_store_recv (&msg, sizeof (msg));
>>>>>>    resp = grub_malloc (msg.len + 1);
>>>>>>    if (!resp)
>>>>> The section is tidied up, ie.
>>>>>        backend = "/local/domain/0/backend/vbd/4/51712"
>>>>>        backend-id = "0"
>>>>>        state = "6"
>>>>>        virtual-device = "51712"
>>>>>        device-type = "disk"
>>>>>        ring-ref = ""
>>>>>        event-channel = ""
>>>>>        protocol = "x86_64-abi"
>>>>>
>>>>> but unfortunately it doesn't help as the boot process sticks at the
>>>>> same
>>>>> point. I notice this section is in state 6 which apparently is
>>>>> "closed".
>>>>> I wonder if the kernel expecting something else.
>>>> Possible. I'd try this (on top of previous patch):
>>> Sorry, too tired. I meant:
>>> diff --git a/grub-core/disk/xen/xendisk.c b/grub-core/disk/xen/xendisk.c
>>> index c449848..9b71d3a 100644
>>> --- a/grub-core/disk/xen/xendisk.c
>>> +++ b/grub-core/disk/xen/xendisk.c
>>> @@ -449,5 +449,10 @@ grub_xendisk_fini (void)
>>>        grub_xen_free_shared_page (virtdisks[i].shared_page);
>>>
>>>        grub_xen_event_channel_op (EVTCHNOP_close, &close_op);
>>> +
>>> +      /* Prepare for handoff.  */
>>> +      grub_snprintf (fdir, sizeof (fdir), "%s/state",
>>> +                    virtdisks[i].frontend_dir);
>>> +      grub_xenstore_write_file (fdir, "0", 1);
>>>      }
>>> }
>> That doesn't work. However, according to the documentation state 0 is
>> unknown, and the vif interface (while grub is running) is in state 1
>> (initializing) so I thought I would try it, and if you replace "0" with
>> "1" in the above patch then the kernel does boot.
>>
> Thanks.
> http://git.savannah.gnu.org/cgit/grub.git/commit/?id=c7995256e410c5272e2be2f94faf62d3c9d57b61
> and
> http://git.savannah.gnu.org/cgit/grub.git/commit/?id=e1aa5b662088cea329fc968af7c819784b6da068
>>      Michael Young

Thanks for all that have worked for xen support on upstream grub2.

I did a test following informations on one of post before:
git clone git://git.sv.gnu.org/grub.git # commit 
61e1b9a49d48035bde52784abb54c3212b647fc8
./autogen.sh
./configure --target=x86_64 --with-platform=xen
mkdir -p boot/grub/
cat > boot/grub/grub.cfg <<EOF
search -s root -f /boot/grub/grub.cfg
configfile /boot/grub/grub.cfg
EOF
./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O 
x86_64-xen -d grub-core/ boot/grub/grub.cfg

Latest command give me this warning:
./grub-mkstandalone: warning: cannot open directory 
`/usr/local/share/locale': File o directory non esistente.

I tried to use it on Sid domU adding this line on domU's xl cfg:
kernel = "/mnt/vm/pvgrub2/grub/pvgrub2.xen"
But vnc show black screen and xl console white screen with only this 
line on start before refresh:
Welcome to GRUB!

I also tried to add this line:
extra = "(hd0,msdos1)/grub/grub.cfg"
but the result on vnc  and xl console is the same.

I did something wrong?
Output of xl -vvv create on attachment.
If you need more tests and/or details tell me and I'll post them.
Thanks for any reply and sorry for my bad english.

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


[-- Attachment #2: xl-create-vvv.txt --]
[-- Type: text/plain, Size: 11631 bytes --]

xl -vvv create /etc/xen/sid.cfg
Parsing config from /etc/xen/sid.cfg
libxl: debug: libxl_create.c:1341:do_domain_create: ao 0x126e260: create: how=(nil) callback=(nil) poller=0x126e070
libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=unknown
libxl: debug: libxl_device.c:197:disk_try_backend: Disk vdev=xvda, backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:286:libxl__device_disk_set_backend: Disk vdev=xvda, using backend qdisk
libxl: debug: libxl_create.c:785:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:327:libxl__bootloader_run: no bootloader configured, using user supplied kernel
libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x126e608: deregister unregistered
libxl: debug: libxl_numa.c:475:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=8, nr_vcpus=10, free_memkb=10066
libxl: detail: libxl_dom.c:195:numa_place_domain: NUMA placement candidate with 1 nodes, 8 cpus and 10066 KB free selected
domainbuilder: detail: xc_dom_allocate: cmdline="(hd0,msdos1)/grub/grub.cfg", features="(null)"
libxl: debug: libxl_dom.c:353:libxl__build_pv: pv kernel mapped 0 path /mnt/vm/pvgrub2/grub/pvgrub2.xen
domainbuilder: detail: xc_dom_kernel_file: filename="/mnt/vm/pvgrub2/grub/pvgrub2.xen"
domainbuilder: detail: xc_dom_malloc_filemap    : 2088 kB
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.4, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... 
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 
domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... 
domainbuilder: detail: loader probe OK
xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x41d148
xc: detail: elf_parse_binary: phdr: paddr=0x41d148 memsz=0x1fb500
xc: detail: elf_parse_binary: memory: 0x0 -> 0x618648
xc: detail: elf_xen_parse_note: GUEST_OS = "GRUB"
xc: detail: elf_xen_parse_note: LOADER = "generic"
xc: detail: elf_xen_parse_note: XEN_VERSION = "xen-3.0"
xc: detail: elf_xen_parse_note: ENTRY = 0x0
xc: detail: elf_xen_parse_note: VIRT_BASE = 0x0
xc: detail: elf_xen_addr_calc_check: ELF_PADDR_OFFSET unset, using 0x0
xc: detail: elf_xen_addr_calc_check: addresses:
xc: detail:     virt_base        = 0x0
xc: detail:     elf_paddr_offset = 0x0
xc: detail:     virt_offset      = 0x0
xc: detail:     virt_kstart      = 0x0
xc: detail:     virt_kend        = 0x618648
xc: detail:     virt_entry       = 0x0
xc: detail:     p2m_base         = 0xffffffffffffffff
domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> 0x618648
domainbuilder: detail: xc_dom_mem_init: mem 1024 MB, pages 0x40000 pages, 4k each
domainbuilder: detail: xc_dom_mem_init: 0x40000 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64
domainbuilder: detail: xc_dom_malloc            : 2048 kB
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0x0 -> 0x619000  (pfn 0x0 + 0x619 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x0+0x619 at 0x7ff4b9a5f000
xc: detail: elf_load_binary: phdr 0 at 0x7ff4b9a5f000 -> 0x7ff4b9a6cd07
xc: detail: elf_load_binary: phdr 2 at 0x7ff4b9e7c148 -> 0x7ff4ba077648
domainbuilder: detail: xc_dom_alloc_segment:   phys2mach    : 0x619000 -> 0x819000  (pfn 0x619 + 0x200 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x619+0x200 at 0x7ff4b985f000
domainbuilder: detail: xc_dom_alloc_page   :   start info   : 0x819000 (pfn 0x819)
domainbuilder: detail: xc_dom_alloc_page   :   xenstore     : 0x81a000 (pfn 0x81a)
domainbuilder: detail: xc_dom_alloc_page   :   console      : 0x81b000 (pfn 0x81b)
domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x0000000000000000 -> 0x000000003fffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s)
domainbuilder: detail: xc_dom_alloc_segment:   page tables  : 0x81c000 -> 0x825000  (pfn 0x81c + 0x9 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x81c+0x9 at 0x7ff4b9856000
domainbuilder: detail: xc_dom_alloc_page   :   boot stack   : 0x825000 (pfn 0x825)
domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0x826000
domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0xc00000
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: arch_setup_bootearly: doing nothing
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 <= matches
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64
domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x40000
domainbuilder: detail: clear_page: pfn 0x81b, mfn 0x326d4c
domainbuilder: detail: clear_page: pfn 0x81a, mfn 0x326d4d
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x819+0x1 at 0x7ff4bc775000
domainbuilder: detail: start_info_x86_64: called
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail:    allocated
domainbuilder: detail:       malloc             : 2099 kB
domainbuilder: detail:       anon mmap          : 0 bytes
domainbuilder: detail:    mapped
domainbuilder: detail:       file mmap          : 2088 kB
domainbuilder: detail:       domU mmap          : 8332 kB
domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xbed44
domainbuilder: detail: shared_info_x86_64: called
domainbuilder: detail: vcpu_x86_64: called
domainbuilder: detail: vcpu_x86_64: cr3: pfn 0x81c mfn 0x326d4b
domainbuilder: detail: launch_vm: called, ctxt=0x7ff4b9854004
domainbuilder: detail: xc_dom_release: called
libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=qdisk
libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x1279260: deregister unregistered
libxl: debug: libxl_dm.c:1327:libxl__spawn_local_dm: Spawning device-model /usr/lib/xen/bin/qemu-system-i386 with arguments:
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   /usr/lib/xen/bin/qemu-system-i386
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -xen-domid
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   4
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -chardev
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-4,server,nowait
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -mon
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   chardev=libxl-cmd,mode=control
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -nodefaults
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -xen-attach
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -name
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   sid
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -vnc
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   0.0.0.0:0,to=99
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -k
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   it
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -machine
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   xenpv
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -m
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   1025
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x126e840 wpath=/local/domain/0/device-model/4/state token=3/0: register slotnum=3
libxl: debug: libxl_create.c:1355:do_domain_create: ao 0x126e260: inprogress: poller=0x126e070, flags=i
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x126e840 wpath=/local/domain/0/device-model/4/state token=3/0: event epath=/local/domain/0/device-model/4/state
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x126e840 wpath=/local/domain/0/device-model/4/state token=3/0: event epath=/local/domain/0/device-model/4/state
libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch w=0x126e840 wpath=/local/domain/0/device-model/4/state token=3/0: deregister slotnum=3
libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x126e840: deregister unregistered
libxl: debug: libxl_qmp.c:703:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-4
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: qmp
libxl: debug: libxl_qmp.c:551:qmp_send_prepare: next qmp command: '{
    "execute": "qmp_capabilities",
    "id": 1
}
'
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: return
libxl: debug: libxl_qmp.c:551:qmp_send_prepare: next qmp command: '{
    "execute": "query-chardev",
    "id": 2
}
'
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: return
libxl: debug: libxl_qmp.c:551:qmp_send_prepare: next qmp command: '{
    "execute": "query-vnc",
    "id": 3
}
'
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: return
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x12716b8 wpath=/local/domain/0/backend/vif/4/0/state token=3/1: register slotnum=3
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x12716b8 wpath=/local/domain/0/backend/vif/4/0/state token=3/1: event epath=/local/domain/0/backend/vif/4/0/state
libxl: debug: libxl_event.c:646:devstate_watch_callback: backend /local/domain/0/backend/vif/4/0/state wanted state 2 still waiting state 1
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x12716b8 wpath=/local/domain/0/backend/vif/4/0/state token=3/1: event epath=/local/domain/0/backend/vif/4/0/state
libxl: debug: libxl_event.c:642:devstate_watch_callback: backend /local/domain/0/backend/vif/4/0/state wanted state 2 ok
libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch w=0x12716b8 wpath=/local/domain/0/backend/vif/4/0/state token=3/1: deregister slotnum=3
libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x12716b8: deregister unregistered
libxl: debug: libxl_device.c:1022:device_hotplug: calling hotplug script: /etc/xen/scripts/vif-bridge online
libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x1271740: deregister unregistered
libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x1271740: deregister unregistered
libxl: debug: libxl_event.c:1742:libxl__ao_progress_report: ao 0x126e260: progress report: ignored
libxl: debug: libxl_event.c:1572:libxl__ao_complete: ao 0x126e260: complete, rc=0
libxl: debug: libxl_event.c:1544:libxl__ao__destroy: ao 0x126e260: destroy
xc: debug: hypercall buffer: total allocations:237 total releases:237
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
xc: debug: hypercall buffer: cache current size:4
xc: debug: hypercall buffer: cache hits:226 misses:4 toobig:7

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 9231 bytes --]

Il 25/11/2013 17:01, Vladimir 'phcoder' Serbinenko ha scritto:
>
> quick response from my phone. No vfb support because on my computer 
> vfb fails so no vnc. arguments are ignored. send your dom config to 
> reproduce
>

Thanks for reply.
Dom0 is similar to this:
http://lists.xen.org/archives/html/xen-devel/2013-10/msg01111.html
but xen git branch changed to hvm-improve.t7 and qemu 1.6.1 from staging 
of upstream qemu's xen git

On attachment domU xl config file, is a debian Sid pv domU.

Sorry if I sended it double, I saw you dropped the cc, so I added 
xen-devel to cc.

> On Nov 25, 2013 4:56 PM, "Fabio Fantoni" <fabio.fantoni@m2r.biz 
> <mailto:fabio.fantoni@m2r.biz>> wrote:
>
>     Il 14/11/2013 22:43, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>
>         On 14.11.2013 22:11, M A Young wrote:
>
>             On Thu, 14 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko
>             wrote:
>
>                 On 14.11.2013 19:57, Vladimir 'φ-coder/phcoder'
>                 Serbinenko wrote:
>
>                     On 14.11.2013 19:48, M A Young wrote:
>
>                         On Thu, 14 Nov 2013, Vladimir
>                         'φ-coder/phcoder' Serbinenko wrote:
>
>                             On 14.11.2013 18:03, M A Young wrote:
>
>
>                                 On Thu, 14 Nov 2013, M A Young wrote:
>
>                                     On Wed, 13 Nov 2013, Vladimir
>                                     'φ-coder/phcoder' Serbinenko wrote:
>
>                                         On 13.11.2013 20:06, M A Young
>                                         wrote:
>
>                                             It doesn't seem to
>                                             understand sub-partitions.
>                                             I can get it to
>                                             work if
>                                             the boot files are in
>                                             /dev/xvda but not in
>                                             /dev/xvda1 .
>
>                                         insmod part_msdos
>                                         insmod part_gpt
>
>                                     Right, if I add those to the
>                                     embedded grub.cfg file I get to the
>                                     standard grub menu and the boot
>                                     starts. However the boot doesn't get
>                                     very far - it loads the kernel and
>                                     the initrd file and starts the
>                                     kernel but the kernel doesn't see
>                                     the virtual disks so it doesn't
>                                     get
>                                     very far.
>
>                                 Using xenstore-ls from the dom0 on the
>                                 guest when the boot stops the
>                                 local/domain/2/device/vbd/51712
>                                 section looks like
>                                        backend =
>                                 "/local/domain/0/backend/vbd/2/51712"
>                                        backend-id = "0"
>                                        state = "6\000"
>                                        virtual-device = "51712"
>                                        device-type = "disk"
>                                        ring-ref = "\000"
>                                        event-channel = "\000"
>                                        protocol = "x86_64-abi\000"
>
>                                 As nothing else has null character
>                                 endings I suspend that is wrong.
>
>                             Good catch. Could you test following:
>                             diff --git a/grub-core/kern/xen/init.c
>                             b/grub-core/kern/xen/init.c
>                             index 3bfd99f..ab74543 100644
>                             --- a/grub-core/kern/xen/init.c
>                             +++ b/grub-core/kern/xen/init.c
>                             @@ -256,11 +256,10 @@
>                             grub_xenstore_write_file (const char *dir,
>                             const
>                             void *buf, grub_size_t len)
>
>                                grub_memset (&msg, 0, sizeof (msg));
>                                msg.type = XS_WRITE;
>                             -  msg.len = dirlen + len + 1;
>                             +  msg.len = dirlen + len;
>                                grub_xen_store_send (&msg, sizeof (msg));
>                                grub_xen_store_send (dir, dirlen);
>                                grub_xen_store_send (buf, len);
>                             -  grub_xen_store_send ("", 1);
>                                grub_xen_store_recv (&msg, sizeof (msg));
>                                resp = grub_malloc (msg.len + 1);
>                                if (!resp)
>
>                         The section is tidied up, ie.
>                                backend =
>                         "/local/domain/0/backend/vbd/4/51712"
>                                backend-id = "0"
>                                state = "6"
>                                virtual-device = "51712"
>                                device-type = "disk"
>                                ring-ref = ""
>                                event-channel = ""
>                                protocol = "x86_64-abi"
>
>                         but unfortunately it doesn't help as the boot
>                         process sticks at the
>                         same
>                         point. I notice this section is in state 6
>                         which apparently is
>                         "closed".
>                         I wonder if the kernel expecting something else.
>
>                     Possible. I'd try this (on top of previous patch):
>
>                 Sorry, too tired. I meant:
>                 diff --git a/grub-core/disk/xen/xendisk.c
>                 b/grub-core/disk/xen/xendisk.c
>                 index c449848..9b71d3a 100644
>                 --- a/grub-core/disk/xen/xendisk.c
>                 +++ b/grub-core/disk/xen/xendisk.c
>                 @@ -449,5 +449,10 @@ grub_xendisk_fini (void)
>                        grub_xen_free_shared_page
>                 (virtdisks[i].shared_page);
>
>                        grub_xen_event_channel_op (EVTCHNOP_close,
>                 &close_op);
>                 +
>                 +      /* Prepare for handoff.  */
>                 +      grub_snprintf (fdir, sizeof (fdir), "%s/state",
>                 +                    virtdisks[i].frontend_dir);
>                 +      grub_xenstore_write_file (fdir, "0", 1);
>                      }
>                 }
>
>             That doesn't work. However, according to the documentation
>             state 0 is
>             unknown, and the vif interface (while grub is running) is
>             in state 1
>             (initializing) so I thought I would try it, and if you
>             replace "0" with
>             "1" in the above patch then the kernel does boot.
>
>         Thanks.
>         http://git.savannah.gnu.org/cgit/grub.git/commit/?id=c7995256e410c5272e2be2f94faf62d3c9d57b61
>         and
>         http://git.savannah.gnu.org/cgit/grub.git/commit/?id=e1aa5b662088cea329fc968af7c819784b6da068
>
>                  Michael Young
>
>
>     Thanks for all that have worked for xen support on upstream grub2.
>
>     I did a test following informations on one of post before:
>     git clone git://git.sv.gnu.org/grub.git
>     <http://git.sv.gnu.org/grub.git> # commit
>     61e1b9a49d48035bde52784abb54c3212b647fc8
>     ./autogen.sh
>     ./configure --target=x86_64 --with-platform=xen
>     mkdir -p boot/grub/
>     cat > boot/grub/grub.cfg <<EOF
>     search -s root -f /boot/grub/grub.cfg
>     configfile /boot/grub/grub.cfg
>     EOF
>     ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen
>     -O x86_64-xen -d grub-core/ boot/grub/grub.cfg
>
>     Latest command give me this warning:
>     ./grub-mkstandalone: warning: cannot open directory
>     `/usr/local/share/locale': File o directory non esistente.
>
>     I tried to use it on Sid domU adding this line on domU's xl cfg:
>     kernel = "/mnt/vm/pvgrub2/grub/pvgrub2.xen"
>     But vnc show black screen and xl console white screen with only
>     this line on start before refresh:
>     Welcome to GRUB!
>
>     I also tried to add this line:
>     extra = "(hd0,msdos1)/grub/grub.cfg"
>     but the result on vnc  and xl console is the same.
>
>     I did something wrong?
>     Output of xl -vvv create on attachment.
>     If you need more tests and/or details tell me and I'll post them.
>     Thanks for any reply and sorry for my bad english.
>
>         _______________________________________________
>         Xen-devel mailing list
>         Xen-devel@lists.xen.org <mailto:Xen-devel@lists.xen.org>
>         http://lists.xen.org/xen-devel
>
>


[-- Attachment #1.2: Type: text/html, Size: 13100 bytes --]

[-- Attachment #2: sid.cfg --]
[-- Type: text/plain, Size: 445 bytes --]

name='sid'
memory=1024
vcpus=2
disk=['/mnt/vm/disks/sid.disk1.xm,raw,xvda,rw']
vif=['bridge=xenbr0']
vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
#bootloader='pygrub'
# pvgrub2 upstream
kernel = "/mnt/vm/pvgrub2/grub/pvgrub2.xen"
extra = "(hd0,msdos1)/grub/grub.cfg"
# Only for installation
#kernel = "/boot/domu/sid/vmlinuz"
#ramdisk = "/boot/domu/sid/initrd.gz"
#extra = "debian-installer/exit/always_halt=true -- quiet console=tty0"

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[M A Young]

On Mon, 25 Nov 2013, Fabio Fantoni wrote:

> I did a test following informations on one of post before:
> git clone git://git.sv.gnu.org/grub.git # commit 
> 61e1b9a49d48035bde52784abb54c3212b647fc8
> ./autogen.sh
> ./configure --target=x86_64 --with-platform=xen
> mkdir -p boot/grub/
> cat > boot/grub/grub.cfg <<EOF
> search -s root -f /boot/grub/grub.cfg
> configfile /boot/grub/grub.cfg
> EOF
You may want to adapt this script to your circumstances. I ended up with
cat > boot/grub/grub.cfg <<EOF
insmod part_msdos
insmod part_gpt
search -s root -f /grub2/grub.cfg
configfile /grub2/grub.cfg
EOF
for a Fedora domU.

> ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O 
> x86_64-xen -d grub-core/ boot/grub/grub.cfg
I also suggest export pkgdatadir=. before this so it looks in the grub 
source rather than the installed version.

Of course this may not help your current problem, though I can boot a domU 
guest with grub configured as above via the hvc0 interface with vnc 
enabled.

 	Michael Young

Re: pvgrub2 is merged

[Fabio Fantoni]

Il 25/11/2013 20:35, M A Young ha scritto:
> On Mon, 25 Nov 2013, Fabio Fantoni wrote:
>
>> I did a test following informations on one of post before:
>> git clone git://git.sv.gnu.org/grub.git # commit 
>> 61e1b9a49d48035bde52784abb54c3212b647fc8
>> ./autogen.sh
>> ./configure --target=x86_64 --with-platform=xen
>> mkdir -p boot/grub/
>> cat > boot/grub/grub.cfg <<EOF
>> search -s root -f /boot/grub/grub.cfg
>> configfile /boot/grub/grub.cfg
>> EOF
> You may want to adapt this script to your circumstances. I ended up with
> cat > boot/grub/grub.cfg <<EOF
> insmod part_msdos
> insmod part_gpt
> search -s root -f /grub2/grub.cfg
> configfile /grub2/grub.cfg
> EOF
> for a Fedora domU.
>
>> ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O 
>> x86_64-xen -d grub-core/ boot/grub/grub.cfg
> I also suggest export pkgdatadir=. before this so it looks in the grub 
> source rather than the installed version.

Thanks for reply.
Seems not working:
export pkgdatadir=. && ./grub-mkstandalone --grub-mkimage=./grub-mkimage 
-o pvgrub2.xen -O x86_64-xen -d grub-core/ boot/grub/grub.cfg
./grub-mkstandalone: warning: cannot open directory 
`/usr/local/share/locale': File o directory non esistente.

I also added the partition mods but Sid domU still unable to boot :(

I have also another question:
Is possible specify multiple path where search the grub.cfg for support 
all mainly distributions and add a custom cfg path support taking it 
from arguments?

Thanks for any reply and sorry for my bad english.

>
> Of course this may not help your current problem, though I can boot a 
> domU guest with grub configured as above via the hvc0 interface with 
> vnc enabled.
>
>     Michael Young

Re: pvgrub2 is merged

[Andrey Borzenkov]

В Tue, 26 Nov 2013 18:58:47 +0100
Fabio Fantoni <fabio.fantoni@m2r.biz> пишет:

> 
> I have also another question:
> Is possible specify multiple path where search the grub.cfg for support 
> all mainly distributions and add a custom cfg path support taking it 
> from arguments?
> 

You can do something like

if search --set root --file /boot/grub2/grub.cfg ; then
  configfile /boot/grub2/grub.cfg
elif search --set root --file /boot/grub/grub.cfg ; then
  configfile /boot/grub/grub.cfg
elif ...
  ...
fi

If xen provides way to pass arguments to kernel, it sure could be
implemented as arguments to grub. Actually someone asked for a way to
pass arguments to grub on EFI, so this could share implementation.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Andrew Cooper]

On 26/11/13 18:12, Andrey Borzenkov wrote:
> В Tue, 26 Nov 2013 18:58:47 +0100
> Fabio Fantoni <fabio.fantoni@m2r.biz> пишет:
>
>> I have also another question:
>> Is possible specify multiple path where search the grub.cfg for support 
>> all mainly distributions and add a custom cfg path support taking it 
>> from arguments?
>>
> You can do something like
>
> if search --set root --file /boot/grub2/grub.cfg ; then
>   configfile /boot/grub2/grub.cfg
> elif search --set root --file /boot/grub/grub.cfg ; then
>   configfile /boot/grub/grub.cfg
> elif ...
>   ...
> fi
>
> If xen provides way to pass arguments to kernel, it sure could be
> implemented as arguments to grub. Actually someone asked for a way to
> pass arguments to grub on EFI, so this could share implementation.

The way PV guests get a command line from the toolstack is via the
start_info.cmd_line, which is up to 1024 bytes.

This will be available to anything which gets its hand on the start info
page.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Fabio Fantoni]

Il 26/11/2013 19:12, Andrey Borzenkov ha scritto:
> В Tue, 26 Nov 2013 18:58:47 +0100
> Fabio Fantoni <fabio.fantoni@m2r.biz> пишет:
>
>> I have also another question:
>> Is possible specify multiple path where search the grub.cfg for support
>> all mainly distributions and add a custom cfg path support taking it
>> from arguments?
>>
> You can do something like
>
> if search --set root --file /boot/grub2/grub.cfg ; then
>    configfile /boot/grub2/grub.cfg
> elif search --set root --file /boot/grub/grub.cfg ; then
>    configfile /boot/grub/grub.cfg
> elif ...
>    ...
> fi

I tried with this:
cat > boot/grub/grub.cfg <<EOF
insmod lvm
insmod ext2
insmod part_msdos
insmod part_gpt
if search --set root --file /boot/grub2/grub.cfg ; then
   configfile /boot/grub2/grub.cfg
elif search --set root --file /boot/grub/grub.cfg ; then
   configfile /boot/grub/grub.cfg
fi
EOF

But it's not working and it prints this line indefinitely in loop:
error: no such device: /boot/grub2/grub.cfg.

I also tried with only these lines instead of conditions:
search -s root -f /boot/grub/grub.cfg
configfile /boot/grub/grub.cfg

But all I get is the line "Welcome to GRUB!" followed by a white screen 
on xl console.

I don't know what else to try :(

Thanks for any reply.

>
> If xen provides way to pass arguments to kernel, it sure could be
> implemented as arguments to grub. Actually someone asked for a way to
> pass arguments to grub on EFI, so this could share implementation.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 1911 bytes --]

On 27.11.2013 12:32, Fabio Fantoni wrote:
> Il 26/11/2013 19:12, Andrey Borzenkov ha scritto:
>> В Tue, 26 Nov 2013 18:58:47 +0100
>> Fabio Fantoni <fabio.fantoni@m2r.biz> пишет:
>>
>>> I have also another question:
>>> Is possible specify multiple path where search the grub.cfg for support
>>> all mainly distributions and add a custom cfg path support taking it
>>> from arguments?
>>>
>> You can do something like
>>
>> if search --set root --file /boot/grub2/grub.cfg ; then
>>    configfile /boot/grub2/grub.cfg
>> elif search --set root --file /boot/grub/grub.cfg ; then
>>    configfile /boot/grub/grub.cfg
>> elif ...
>>    ...
>> fi
> 
> I tried with this:
> cat > boot/grub/grub.cfg <<EOF
> insmod lvm
> insmod ext2
> insmod part_msdos
> insmod part_gpt
> if search --set root --file /boot/grub2/grub.cfg ; then
>   configfile /boot/grub2/grub.cfg
> elif search --set root --file /boot/grub/grub.cfg ; then
>   configfile /boot/grub/grub.cfg
> fi
> EOF
> 
> But it's not working and it prints this line indefinitely in loop:
> error: no such device: /boot/grub2/grub.cfg.
> 
That pretty much explains what happened: you don't have any
/boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB found
its own memdisk and fell into recursion. I'm not sure what should be the
proper way to solve this recursion.
> I also tried with only these lines instead of conditions:
> search -s root -f /boot/grub/grub.cfg
> configfile /boot/grub/grub.cfg
> 
> But all I get is the line "Welcome to GRUB!" followed by a white screen
> on xl console.
> 
> I don't know what else to try :(
> 
> Thanks for any reply.
> 
>>
>> If xen provides way to pass arguments to kernel, it sure could be
>> implemented as arguments to grub. Actually someone asked for a way to
>> pass arguments to grub on EFI, so this could share implementation.
> 
> 



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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Fabio Fantoni]

Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
> On 27.11.2013 12:32, Fabio Fantoni wrote:
>> Il 26/11/2013 19:12, Andrey Borzenkov ha scritto:
>>> В Tue, 26 Nov 2013 18:58:47 +0100
>>> Fabio Fantoni <fabio.fantoni@m2r.biz> пишет:
>>>
>>>> I have also another question:
>>>> Is possible specify multiple path where search the grub.cfg for support
>>>> all mainly distributions and add a custom cfg path support taking it
>>>> from arguments?
>>>>
>>> You can do something like
>>>
>>> if search --set root --file /boot/grub2/grub.cfg ; then
>>>     configfile /boot/grub2/grub.cfg
>>> elif search --set root --file /boot/grub/grub.cfg ; then
>>>     configfile /boot/grub/grub.cfg
>>> elif ...
>>>     ...
>>> fi
>> I tried with this:
>> cat > boot/grub/grub.cfg <<EOF
>> insmod lvm
>> insmod ext2
>> insmod part_msdos
>> insmod part_gpt
>> if search --set root --file /boot/grub2/grub.cfg ; then
>>    configfile /boot/grub2/grub.cfg
>> elif search --set root --file /boot/grub/grub.cfg ; then
>>    configfile /boot/grub/grub.cfg
>> fi
>> EOF
>>
>> But it's not working and it prints this line indefinitely in loop:
>> error: no such device: /boot/grub2/grub.cfg.
>>
> That pretty much explains what happened: you don't have any
> /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB found
> its own memdisk and fell into recursion. I'm not sure what should be the
> proper way to solve this recursion.

Ok, now I understand with this:
cat > boot/grub/grub.cfg <<EOF
insmod lvm
insmod ext2
insmod part_msdos
insmod part_gpt
search -s root -f /boot/grub/grub.cfg
configfile /boot/grub/grub.cfg
EOF

that has the debian grub.cfg path equal to memdisk's grub, and then it 
loads the memdisk ones indefinitely.

Anyone know how to exclude memdisk from the search please?

With this:
cat > boot/grub/grub.cfg <<EOF
insmod lvm
insmod ext2
insmod part_msdos
insmod part_gpt
root='(xen/xvda,msdos1)'
configfile /boot/grub/grub.cfg
EOF

it loads correctly the Sid grub.cfg but grub fails to load with any 
entry I select, that domU stop.

xl -vvv create -c /etc/xen/sid.cfg
...
Caricamento Linux 3.11-1-amd64...
error: not xen image.
Caricamento ramdisk iniziale...
xc: debug: hypercall buffer: total allocations:237 total releases:237
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
xc: debug: hypercall buffer: cache current size:4
xc: debug: hypercall buffer: cache hits:226 misses:4 toobig:7

Maybe that grub is waiting for a dom0 configuration type (with also 
xen.gz) but find only kernel and ramdisk? (which is right for a domU)

If you need more tests/informations tell me and I'll post them.

Thanks for any reply.

>> I also tried with only these lines instead of conditions:
>> search -s root -f /boot/grub/grub.cfg
>> configfile /boot/grub/grub.cfg
>>
>> But all I get is the line "Welcome to GRUB!" followed by a white screen
>> on xl console.
>>
>> I don't know what else to try :(
>>
>> Thanks for any reply.
>>
>>> If xen provides way to pass arguments to kernel, it sure could be
>>> implemented as arguments to grub. Actually someone asked for a way to
>>> pass arguments to grub on EFI, so this could share implementation.
>>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 3623 bytes --]

On 27.11.2013 16:59, Fabio Fantoni wrote:
> Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>> On 27.11.2013 12:32, Fabio Fantoni wrote:
>>> Il 26/11/2013 19:12, Andrey Borzenkov ha scritto:
>>>> В Tue, 26 Nov 2013 18:58:47 +0100
>>>> Fabio Fantoni <fabio.fantoni@m2r.biz> пишет:
>>>>
>>>>> I have also another question:
>>>>> Is possible specify multiple path where search the grub.cfg for
>>>>> support
>>>>> all mainly distributions and add a custom cfg path support taking it
>>>>> from arguments?
>>>>>
>>>> You can do something like
>>>>
>>>> if search --set root --file /boot/grub2/grub.cfg ; then
>>>>     configfile /boot/grub2/grub.cfg
>>>> elif search --set root --file /boot/grub/grub.cfg ; then
>>>>     configfile /boot/grub/grub.cfg
>>>> elif ...
>>>>     ...
>>>> fi
>>> I tried with this:
>>> cat > boot/grub/grub.cfg <<EOF
>>> insmod lvm
>>> insmod ext2
>>> insmod part_msdos
>>> insmod part_gpt
>>> if search --set root --file /boot/grub2/grub.cfg ; then
>>>    configfile /boot/grub2/grub.cfg
>>> elif search --set root --file /boot/grub/grub.cfg ; then
>>>    configfile /boot/grub/grub.cfg
>>> fi
>>> EOF
>>>
>>> But it's not working and it prints this line indefinitely in loop:
>>> error: no such device: /boot/grub2/grub.cfg.
>>>
>> That pretty much explains what happened: you don't have any
>> /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB found
>> its own memdisk and fell into recursion. I'm not sure what should be the
>> proper way to solve this recursion.
> 
> Ok, now I understand with this:
> cat > boot/grub/grub.cfg <<EOF
> insmod lvm
> insmod ext2
> insmod part_msdos
> insmod part_gpt
> search -s root -f /boot/grub/grub.cfg
> configfile /boot/grub/grub.cfg
> EOF
> 
> that has the debian grub.cfg path equal to memdisk's grub, and then it
> loads the memdisk ones indefinitely.
> 
> Anyone know how to exclude memdisk from the search please?
> 
> With this:
> cat > boot/grub/grub.cfg <<EOF
> insmod lvm
> insmod ext2
> insmod part_msdos
> insmod part_gpt
> root='(xen/xvda,msdos1)'
> configfile /boot/grub/grub.cfg
> EOF
> 
> it loads correctly the Sid grub.cfg but grub fails to load with any
> entry I select, that domU stop.
> 
> xl -vvv create -c /etc/xen/sid.cfg
> ...
> Caricamento Linux 3.11-1-amd64...
> error: not xen image.
> Caricamento ramdisk iniziale...
> xc: debug: hypercall buffer: total allocations:237 total releases:237
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
> xc: debug: hypercall buffer: cache current size:4
> xc: debug: hypercall buffer: cache hits:226 misses:4 toobig:7
> 
> Maybe that grub is waiting for a dom0 configuration type (with also
> xen.gz) but find only kernel and ramdisk? (which is right for a domU)
> 
No, this message indicates problem parsing domU image. Can you give the
link to exact image you use?
> If you need more tests/informations tell me and I'll post them.
> 
> Thanks for any reply.
> 
>>> I also tried with only these lines instead of conditions:
>>> search -s root -f /boot/grub/grub.cfg
>>> configfile /boot/grub/grub.cfg
>>>
>>> But all I get is the line "Welcome to GRUB!" followed by a white screen
>>> on xl console.
>>>
>>> I don't know what else to try :(
>>>
>>> Thanks for any reply.
>>>
>>>> If xen provides way to pass arguments to kernel, it sure could be
>>>> implemented as arguments to grub. Actually someone asked for a way to
>>>> pass arguments to grub on EFI, so this could share implementation.
>>>
>>
> 
> 



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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[M A Young]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 989 bytes --]

On Wed, 27 Nov 2013, Fabio Fantoni wrote:

> Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>> That pretty much explains what happened: you don't have any
>> /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB found
>> its own memdisk and fell into recursion. I'm not sure what should be the
>> proper way to solve this recursion.
>
> Ok, now I understand with this:
> cat > boot/grub/grub.cfg <<EOF
> insmod lvm
> insmod ext2
> insmod part_msdos
> insmod part_gpt
> search -s root -f /boot/grub/grub.cfg
> configfile /boot/grub/grub.cfg
> EOF
>
> that has the debian grub.cfg path equal to memdisk's grub, and then it loads 
> the memdisk ones indefinitely.
>
> Anyone know how to exclude memdisk from the search please?

Probably the simplest way is to rename the grub.cfg file on the memdisk so 
that search doesn't find it, eg. to grub-memdisk.cfg or grub-internal.cfg 
and then adjust the ./grub-mkstandalone line appropriately.

 	Michael Young

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Fabio Fantoni]

Il 27/11/2013 17:03, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
> On 27.11.2013 16:59, Fabio Fantoni wrote:
>> Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>>> On 27.11.2013 12:32, Fabio Fantoni wrote:
>>>> Il 26/11/2013 19:12, Andrey Borzenkov ha scritto:
>>>>> В Tue, 26 Nov 2013 18:58:47 +0100
>>>>> Fabio Fantoni <fabio.fantoni@m2r.biz> пишет:
>>>>>
>>>>>> I have also another question:
>>>>>> Is possible specify multiple path where search the grub.cfg for
>>>>>> support
>>>>>> all mainly distributions and add a custom cfg path support taking it
>>>>>> from arguments?
>>>>>>
>>>>> You can do something like
>>>>>
>>>>> if search --set root --file /boot/grub2/grub.cfg ; then
>>>>>      configfile /boot/grub2/grub.cfg
>>>>> elif search --set root --file /boot/grub/grub.cfg ; then
>>>>>      configfile /boot/grub/grub.cfg
>>>>> elif ...
>>>>>      ...
>>>>> fi
>>>> I tried with this:
>>>> cat > boot/grub/grub.cfg <<EOF
>>>> insmod lvm
>>>> insmod ext2
>>>> insmod part_msdos
>>>> insmod part_gpt
>>>> if search --set root --file /boot/grub2/grub.cfg ; then
>>>>     configfile /boot/grub2/grub.cfg
>>>> elif search --set root --file /boot/grub/grub.cfg ; then
>>>>     configfile /boot/grub/grub.cfg
>>>> fi
>>>> EOF
>>>>
>>>> But it's not working and it prints this line indefinitely in loop:
>>>> error: no such device: /boot/grub2/grub.cfg.
>>>>
>>> That pretty much explains what happened: you don't have any
>>> /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB found
>>> its own memdisk and fell into recursion. I'm not sure what should be the
>>> proper way to solve this recursion.
>> Ok, now I understand with this:
>> cat > boot/grub/grub.cfg <<EOF
>> insmod lvm
>> insmod ext2
>> insmod part_msdos
>> insmod part_gpt
>> search -s root -f /boot/grub/grub.cfg
>> configfile /boot/grub/grub.cfg
>> EOF
>>
>> that has the debian grub.cfg path equal to memdisk's grub, and then it
>> loads the memdisk ones indefinitely.
>>
>> Anyone know how to exclude memdisk from the search please?

Is it possible to specify a different default grub.cfg path (different 
from all other distributions) changing this command:
./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O 
x86_64-xen -d grub-core/ boot/grub/grub.cfg
Is it hardcoded as /boot/grub/grub.cfg for grub memdisk or can be set?

>>
>> With this:
>> cat > boot/grub/grub.cfg <<EOF
>> insmod lvm
>> insmod ext2
>> insmod part_msdos
>> insmod part_gpt
>> root='(xen/xvda,msdos1)'
>> configfile /boot/grub/grub.cfg
>> EOF
>>
>> it loads correctly the Sid grub.cfg but grub fails to load with any
>> entry I select, that domU stop.
>>
>> xl -vvv create -c /etc/xen/sid.cfg
>> ...
>> Caricamento Linux 3.11-1-amd64...
>> error: not xen image.
>> Caricamento ramdisk iniziale...
>> xc: debug: hypercall buffer: total allocations:237 total releases:237
>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
>> xc: debug: hypercall buffer: cache current size:4
>> xc: debug: hypercall buffer: cache hits:226 misses:4 toobig:7
>>
>> Maybe that grub is waiting for a dom0 configuration type (with also
>> xen.gz) but find only kernel and ramdisk? (which is right for a domU)
>>
> No, this message indicates problem parsing domU image. Can you give the
> link to exact image you use?

The standard kernel image installed by debian installer, the package is 
this:
http://packages.debian.org/sid/linux-image-3.11-2-amd64
On domU a previous version is installed but it was working and xen 
dom0/domU modules are included in this kernel image.

>> If you need more tests/informations tell me and I'll post them.
>>
>> Thanks for any reply.
>>
>>>> I also tried with only these lines instead of conditions:
>>>> search -s root -f /boot/grub/grub.cfg
>>>> configfile /boot/grub/grub.cfg
>>>>
>>>> But all I get is the line "Welcome to GRUB!" followed by a white screen
>>>> on xl console.
>>>>
>>>> I don't know what else to try :(
>>>>
>>>> Thanks for any reply.
>>>>
>>>>> If xen provides way to pass arguments to kernel, it sure could be
>>>>> implemented as arguments to grub. Actually someone asked for a way to
>>>>> pass arguments to grub on EFI, so this could share implementation.
>>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Andrey Borzenkov]

В Wed, 27 Nov 2013 17:24:53 +0100
Fabio Fantoni <fabio.fantoni@m2r.biz> пишет:

> Il 27/11/2013 17:03, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
> > On 27.11.2013 16:59, Fabio Fantoni wrote:
> >> Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:

> >>> That pretty much explains what happened: you don't have any
> >>> /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB found
> >>> its own memdisk and fell into recursion. I'm not sure what should be the
> >>> proper way to solve this recursion.

Yes, it was a bit naive on my side. Recursion in principle can be
stopped by using global variable, but search is limited to the first
match only anyway, so I guess it is not worth it.

> >>
> >> Anyone know how to exclude memdisk from the search please?
>

Please look in grub2 sources at docs/osdetect.cfg. It implements
advanced run-time detection of possible bootable files from
various operating systems. It boils down to loop across all devices,
and of course you can either limit device names (like looking for hd*
only) or explicitly exclude known ones (like memdisk).

> Is it possible to specify a different default grub.cfg path (different 
> from all other distributions) changing this command:
> ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O 
> x86_64-xen -d grub-core/ boot/grub/grub.cfg
> Is it hardcoded as /boot/grub/grub.cfg for grub memdisk or can be set?
>

Not really. Currently the situation is

- grub-mkstandalone hardcodes $prefix as (memdisk)/boot/grub
- after launch grub unconditionally starts "normal" module if at all
  possible
- normal module always tries to load and execute $prefix/grub.cfg if no
  explicit configuration file name is given as argument

But I think that using osdetect.cfg or something based on this idea
won't require changing defaults at all.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Fabio Fantoni]

Il 27/11/2013 18:35, Andrey Borzenkov ha scritto:
> В Wed, 27 Nov 2013 17:24:53 +0100
> Fabio Fantoni <fabio.fantoni@m2r.biz> пишет:
>
>> Il 27/11/2013 17:03, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>>> On 27.11.2013 16:59, Fabio Fantoni wrote:
>>>> Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>>>>> That pretty much explains what happened: you don't have any
>>>>> /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB found
>>>>> its own memdisk and fell into recursion. I'm not sure what should be the
>>>>> proper way to solve this recursion.
> Yes, it was a bit naive on my side. Recursion in principle can be
> stopped by using global variable, but search is limited to the first
> match only anyway, so I guess it is not worth it.
>
>>>> Anyone know how to exclude memdisk from the search please?
> Please look in grub2 sources at docs/osdetect.cfg. It implements
> advanced run-time detection of possible bootable files from
> various operating systems. It boils down to loop across all devices,
> and of course you can either limit device names (like looking for hd*
> only) or explicitly exclude known ones (like memdisk).
>
>> Is it possible to specify a different default grub.cfg path (different
>> from all other distributions) changing this command:
>> ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O
>> x86_64-xen -d grub-core/ boot/grub/grub.cfg
>> Is it hardcoded as /boot/grub/grub.cfg for grub memdisk or can be set?
>>
> Not really. Currently the situation is
>
> - grub-mkstandalone hardcodes $prefix as (memdisk)/boot/grub
> - after launch grub unconditionally starts "normal" module if at all
>    possible
> - normal module always tries to load and execute $prefix/grub.cfg if no
>    explicit configuration file name is given as argument
>
> But I think that using osdetect.cfg or something based on this idea
> won't require changing defaults at all.

Thanks for your reply.

I did this script that is working about finding and include the grub.cfg 
of pv domUs with many cases:

cat > boot/grub/grub.cfg <<EOF
insmod lvm
insmod ext2
insmod part_msdos
insmod part_gpt
insmod btrfs

insmod regexp
for dev in (*); do
     # $device: parenthesis removed from $dev
     regexp -s device '\((.*)\)' $dev
     set root=$device
     for file in /boot/vmlinuz-* /boot/linux-*; do
         if test -f $file; then
             set saved_root=$root
         fi
     done
done
set root=$saved_root

if test -f /boot/grub2/grub.cfg ; then
     configfile /boot/grub2/grub.cfg
elif test -f /boot/grub/grub.cfg ; then
     configfile /boot/grub/grub.cfg
fi
EOF

@xen developer: Are there other modules to insert for other partitions 
or file systems, other grub cfg path for other distributions or other 
kernel type to search that support xen pv domUs?
I think is good do and post complete pvgrub2 cfg that support all pv domUs.

@xen and grub developer: I'm still unable to boot any entry of Sid pv 
domU using official kernel:
xl -vvv create -c /etc/xen/sid.cfg
...
Caricamento Linux 3.11-1-amd64...
Caricamento ramdisk iniziale...
xc: debug: hypercall buffer: total allocations:247 total releases:247
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
xc: debug: hypercall buffer: cache current size:4
xc: debug: hypercall buffer: cache hits:236 misses:4 toobig:7

Any ideas?

If you need more tests/informations tell me and I'll post them.

Thanks for any reply.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 3846 bytes --]

On 28.11.2013 14:07, Fabio Fantoni wrote:
> Il 27/11/2013 18:35, Andrey Borzenkov ha scritto:
>> В Wed, 27 Nov 2013 17:24:53 +0100
>> Fabio Fantoni <fabio.fantoni@m2r.biz> пишет:
>>
>>> Il 27/11/2013 17:03, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>>>> On 27.11.2013 16:59, Fabio Fantoni wrote:
>>>>> Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>>>>>> That pretty much explains what happened: you don't have any
>>>>>> /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB
>>>>>> found
>>>>>> its own memdisk and fell into recursion. I'm not sure what should
>>>>>> be the
>>>>>> proper way to solve this recursion.
>> Yes, it was a bit naive on my side. Recursion in principle can be
>> stopped by using global variable, but search is limited to the first
>> match only anyway, so I guess it is not worth it.
>>
>>>>> Anyone know how to exclude memdisk from the search please?
>> Please look in grub2 sources at docs/osdetect.cfg. It implements
>> advanced run-time detection of possible bootable files from
>> various operating systems. It boils down to loop across all devices,
>> and of course you can either limit device names (like looking for hd*
>> only) or explicitly exclude known ones (like memdisk).
>>
>>> Is it possible to specify a different default grub.cfg path (different
>>> from all other distributions) changing this command:
>>> ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O
>>> x86_64-xen -d grub-core/ boot/grub/grub.cfg
>>> Is it hardcoded as /boot/grub/grub.cfg for grub memdisk or can be set?
>>>
>> Not really. Currently the situation is
>>
>> - grub-mkstandalone hardcodes $prefix as (memdisk)/boot/grub
>> - after launch grub unconditionally starts "normal" module if at all
>>    possible
>> - normal module always tries to load and execute $prefix/grub.cfg if no
>>    explicit configuration file name is given as argument
>>
>> But I think that using osdetect.cfg or something based on this idea
>> won't require changing defaults at all.
> 
> Thanks for your reply.
> 
> I did this script that is working about finding and include the grub.cfg
> of pv domUs with many cases:
> 
> cat > boot/grub/grub.cfg <<EOF
> insmod lvm
> insmod ext2
> insmod part_msdos
> insmod part_gpt
> insmod btrfs
> 
> insmod regexp
> for dev in (*); do
>     # $device: parenthesis removed from $dev
>     regexp -s device '\((.*)\)' $dev
>     set root=$device
>     for file in /boot/vmlinuz-* /boot/linux-*; do
>         if test -f $file; then
>             set saved_root=$root
>         fi
>     done
> done
> set root=$saved_root
> 
> if test -f /boot/grub2/grub.cfg ; then
>     configfile /boot/grub2/grub.cfg
> elif test -f /boot/grub/grub.cfg ; then
>     configfile /boot/grub/grub.cfg
> fi
> EOF
> 
> @xen developer: Are there other modules to insert for other partitions
> or file systems, other grub cfg path for other distributions or other
> kernel type to search that support xen pv domUs?
> I think is good do and post complete pvgrub2 cfg that support all pv domUs.
> 
> @xen and grub developer: I'm still unable to boot any entry of Sid pv
> domU using official kernel:
> xl -vvv create -c /etc/xen/sid.cfg
> ...
> Caricamento Linux 3.11-1-amd64...
> Caricamento ramdisk iniziale...
> xc: debug: hypercall buffer: total allocations:247 total releases:247
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
> xc: debug: hypercall buffer: cache current size:4
> xc: debug: hypercall buffer: cache hits:236 misses:4 toobig:7
> 
> Any ideas?
> 
Ah I forgot: you need to "insmod xzio" since debian ones are compressed.
> If you need more tests/informations tell me and I'll post them.
> 
> Thanks for any reply.
> 



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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Fabio Fantoni]

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

Il 28/11/2013 15:05, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
> On 28.11.2013 14:07, Fabio Fantoni wrote:
>> Il 27/11/2013 18:35, Andrey Borzenkov ha scritto:
>>> В Wed, 27 Nov 2013 17:24:53 +0100
>>> Fabio Fantoni <fabio.fantoni@m2r.biz> пишет:
>>>
>>>> Il 27/11/2013 17:03, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>>>>> On 27.11.2013 16:59, Fabio Fantoni wrote:
>>>>>> Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>>>>>>> That pretty much explains what happened: you don't have any
>>>>>>> /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB
>>>>>>> found
>>>>>>> its own memdisk and fell into recursion. I'm not sure what should
>>>>>>> be the
>>>>>>> proper way to solve this recursion.
>>> Yes, it was a bit naive on my side. Recursion in principle can be
>>> stopped by using global variable, but search is limited to the first
>>> match only anyway, so I guess it is not worth it.
>>>
>>>>>> Anyone know how to exclude memdisk from the search please?
>>> Please look in grub2 sources at docs/osdetect.cfg. It implements
>>> advanced run-time detection of possible bootable files from
>>> various operating systems. It boils down to loop across all devices,
>>> and of course you can either limit device names (like looking for hd*
>>> only) or explicitly exclude known ones (like memdisk).
>>>
>>>> Is it possible to specify a different default grub.cfg path (different
>>>> from all other distributions) changing this command:
>>>> ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O
>>>> x86_64-xen -d grub-core/ boot/grub/grub.cfg
>>>> Is it hardcoded as /boot/grub/grub.cfg for grub memdisk or can be set?
>>>>
>>> Not really. Currently the situation is
>>>
>>> - grub-mkstandalone hardcodes $prefix as (memdisk)/boot/grub
>>> - after launch grub unconditionally starts "normal" module if at all
>>>     possible
>>> - normal module always tries to load and execute $prefix/grub.cfg if no
>>>     explicit configuration file name is given as argument
>>>
>>> But I think that using osdetect.cfg or something based on this idea
>>> won't require changing defaults at all.
>> Thanks for your reply.
>>
>> I did this script that is working about finding and include the grub.cfg
>> of pv domUs with many cases:
>>
>> cat > boot/grub/grub.cfg <<EOF
>> insmod lvm
>> insmod ext2
>> insmod part_msdos
>> insmod part_gpt
>> insmod btrfs
>>
>> insmod regexp
>> for dev in (*); do
>>      # $device: parenthesis removed from $dev
>>      regexp -s device '\((.*)\)' $dev
>>      set root=$device
>>      for file in /boot/vmlinuz-* /boot/linux-*; do
>>          if test -f $file; then
>>              set saved_root=$root
>>          fi
>>      done
>> done
>> set root=$saved_root
>>
>> if test -f /boot/grub2/grub.cfg ; then
>>      configfile /boot/grub2/grub.cfg
>> elif test -f /boot/grub/grub.cfg ; then
>>      configfile /boot/grub/grub.cfg
>> fi
>> EOF
>>
>> @xen developer: Are there other modules to insert for other partitions
>> or file systems, other grub cfg path for other distributions or other
>> kernel type to search that support xen pv domUs?
>> I think is good do and post complete pvgrub2 cfg that support all pv domUs.
>>
>> @xen and grub developer: I'm still unable to boot any entry of Sid pv
>> domU using official kernel:
>> xl -vvv create -c /etc/xen/sid.cfg
>> ...
>> Caricamento Linux 3.11-1-amd64...
>> Caricamento ramdisk iniziale...
>> xc: debug: hypercall buffer: total allocations:247 total releases:247
>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
>> xc: debug: hypercall buffer: cache current size:4
>> xc: debug: hypercall buffer: cache hits:236 misses:4 toobig:7
>>
>> Any ideas?
>>
> Ah I forgot: you need to "insmod xzio" since debian ones are compressed.
>> If you need more tests/informations tell me and I'll post them.
>>
>> Thanks for any reply.
>>
>

Thanks for reply, in the meantime I rebuilt updated grub2 from git 
(commit    b67422d33de8eee83700db534a45b2ac5e5ed67a)  and there is a 
regression from build of some days ago (I don't remember the exact 
commit, probably was of 24 or 25 november).
Fails on script I posted on previous mail showing some errors:
> kern/dl.c:619: module name: test
> kern/dl.c:620: init function: 0x3f5abdd4
> error: two arguments expected.
> commands/wildcard.c:164: Regexp is ^vmlinuz-.*$
> commands/wildcard.c:164: Regexp is ^linux-.*$
> error: two arguments expected.
> commands/wildcard.c:164: Regexp is ^vmlinuz-.*$
> commands/wildcard.c:164: Regexp is ^linux-.*$
> error: two arguments expected.
> commands/wildcard.c:164: Regexp is ^vmlinuz-.*$
> commands/wildcard.c:164: Regexp is ^linux-.*$

Full log with debug on attachment.


[-- Attachment #2: pvgrub2.log --]
[-- Type: text/plain, Size: 106744 bytes --]

xl -vvv create -c /etc/xen/sid.cfg
Parsing config from /etc/xen/sid.cfg
libxl: debug: libxl_create.c:1341:do_domain_create: ao 0x9011a0: create: how=(nil) callback=(nil) poller=0x901070
libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=unknown
libxl: debug: libxl_device.c:197:disk_try_backend: Disk vdev=xvda, backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:286:libxl__device_disk_set_backend: Disk vdev=xvda, using backend qdisk
libxl: debug: libxl_create.c:785:initiate_domain_create: running bootloader                         
libxl: debug: libxl_bootloader.c:327:libxl__bootloader_run: no bootloader configured, using user supplied kernel
libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x901548: deregister unregistered         
libxl: debug: libxl_numa.c:475:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=8, nr_vcpus=12, free_memkb=7999
libxl: detail: libxl_dom.c:195:numa_place_domain: NUMA placement candidate with 1 nodes, 8 cpus and 7999 KB free selected                             
domainbuilder: detail: xc_dom_allocate: cmdline="", features="(null)"                                                    
libxl: debug: libxl_dom.c:353:libxl__build_pv: pv kernel mapped 0 path /mnt/vm/pvgrub2/grub/pvgrub2.xen
domainbuilder: detail: xc_dom_kernel_file: filename="/mnt/vm/pvgrub2/grub/pvgrub2.xen"                 
domainbuilder: detail: xc_dom_malloc_filemap    : 3989 kB                             
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.4, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 
domainbuilder: detail: xc_dom_parse_image: called                                                                                       
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... 
domainbuilder: detail: loader probe failed                                    
domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 
domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage
domainbuilder: detail: loader probe failed                                 
domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... 
domainbuilder: detail: loader probe OK                                                                                                                                            
xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x41d148                                                                                                                      
xc: detail: elf_parse_binary: phdr: paddr=0x41d148 memsz=0x3d6900                                                                                                                 
xc: detail: elf_parse_binary: memory: 0x0 -> 0x7f3a48                                                                                                                             
xc: detail: elf_xen_parse_note: GUEST_OS = "GRUB"                                                                                                                                 
xc: detail: elf_xen_parse_note: LOADER = "generic"                                                                                                                                
xc: detail: elf_xen_parse_note: XEN_VERSION = "xen-3.0"                                                                                                                           
xc: detail: elf_xen_parse_note: ENTRY = 0x0                                                                                                                                       
xc: detail: elf_xen_parse_note: VIRT_BASE = 0x0                                                                                                                                   
xc: detail: elf_xen_addr_calc_check: ELF_PADDR_OFFSET unset, using 0x0                                                                                                            
xc: detail: elf_xen_addr_calc_check: addresses:                                                                                                                                   
xc: detail:     virt_base        = 0x0                                                                                                                                            
xc: detail:     elf_paddr_offset = 0x0                                                                                                                                            
xc: detail:     virt_offset      = 0x0                                                                                                                                            
xc: detail:     virt_kstart      = 0x0                                                                                                                                            
xc: detail:     virt_kend        = 0x7f3a48                                                                                                                                       
xc: detail:     virt_entry       = 0x0                                                                                                                                            
xc: detail:     p2m_base         = 0xffffffffffffffff                                                                                                                             
domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> 0x7f3a48                                                                                                   
domainbuilder: detail: xc_dom_mem_init: mem 1024 MB, pages 0x40000 pages, 4k each                                                                                                 
domainbuilder: detail: xc_dom_mem_init: 0x40000 pages                                                                                                                             
domainbuilder: detail: xc_dom_boot_mem_init: called                                                                                                                               
domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64                                                                                                          
domainbuilder: detail: xc_dom_malloc            : 2048 kB                                                                                                                         
domainbuilder: detail: xc_dom_build_image: called                                                                                                                                 
domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0x0 -> 0x7f4000  (pfn 0x0 + 0x7f4 pages)                                                                            
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x0+0x7f4 at 0x7f490e40e000                                                                                  
xc: detail: elf_load_binary: phdr 0 at 0x7f490e40e000 -> 0x7f490e41bc57                                                                                                           
xc: detail: elf_load_binary: phdr 2 at 0x7f490e82b148 -> 0x7f490ec01a48                                                                                                           
domainbuilder: detail: xc_dom_alloc_segment:   phys2mach    : 0x7f4000 -> 0x9f4000  (pfn 0x7f4 + 0x200 pages)                                                                     
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x7f4+0x200 at 0x7f490e20e000                                                                                
domainbuilder: detail: xc_dom_alloc_page   :   start info   : 0x9f4000 (pfn 0x9f4)                                                                                                
domainbuilder: detail: xc_dom_alloc_page   :   xenstore     : 0x9f5000 (pfn 0x9f5)                                                                                                
domainbuilder: detail: xc_dom_alloc_page   :   console      : 0x9f6000 (pfn 0x9f6)                                                                                                
domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s)                                                                
domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s)                                                                
domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x0000000000000000 -> 0x000000003fffffff, 1 table(s)                                                                
domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s)                                                                
domainbuilder: detail: xc_dom_alloc_segment:   page tables  : 0x9f7000 -> 0xa00000  (pfn 0x9f7 + 0x9 pages)                                                                       
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x9f7+0x9 at 0x7f49114c3000                                                                                  
domainbuilder: detail: xc_dom_alloc_page   :   boot stack   : 0xa00000 (pfn 0xa00)                                                                                                
domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0xa01000                                                                                                            
domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0xc00000                                                                                                            
domainbuilder: detail: xc_dom_boot_image: called                                                                                                                                  
domainbuilder: detail: arch_setup_bootearly: doing nothing                                                                                                                        
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 <= matches                                                                                       
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p                                                                                                 
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32                                                                                                  
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p                                                                                                 
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64                                                                                                  
domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x40000                                                                                                          
domainbuilder: detail: clear_page: pfn 0x9f6, mfn 0x23cb77                                                                                                                        
domainbuilder: detail: clear_page: pfn 0x9f5, mfn 0x23cb78                                                                                                                        
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x9f4+0x1 at 0x7f49114c0000                                                                                  
domainbuilder: detail: start_info_x86_64: called                                                                                                                                  
domainbuilder: detail: domain builder memory footprint                                                                                                                            
domainbuilder: detail:    allocated                                                                                                                                               
domainbuilder: detail:       malloc             : 2110 kB                                                                                                                         
domainbuilder: detail:       anon mmap          : 0 bytes                                                                                                                         
domainbuilder: detail:    mapped                                                                                                                                                  
domainbuilder: detail:       file mmap          : 3989 kB                                                                                                                         
domainbuilder: detail:       domU mmap          : 10232 kB                                                                                                                        
domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xbeb7b                                                                                                     
domainbuilder: detail: shared_info_x86_64: called                                                                                                                                 
domainbuilder: detail: vcpu_x86_64: called                                                                                                                                        
domainbuilder: detail: vcpu_x86_64: cr3: pfn 0x9f7 mfn 0x23cb76                                                                                                                   
domainbuilder: detail: launch_vm: called, ctxt=0x7f49114c1004                                                                                                                     
domainbuilder: detail: xc_dom_release: called                                                                                                                                     
libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=qdisk                                                                                
libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x902a80: deregister unregistered                                                                           
libxl: debug: libxl_dm.c:1327:libxl__spawn_local_dm: Spawning device-model /usr/lib/xen/bin/qemu-system-i386 with arguments:                                                      
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   /usr/lib/xen/bin/qemu-system-i386                                                                                          
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -xen-domid                                                                                                                 
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   15                                                                                                                         
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -chardev                                                                                                                   
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-15,server,nowait                                                           
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -mon                                                                                                                       
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   chardev=libxl-cmd,mode=control                                                                                             
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -nodefaults                                                                                                                
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -xen-attach                                                                                                                
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -name                                                                                                                      
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   sid                                                                                                                        
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -vnc                                                                                                                       
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   0.0.0.0:0,to=99                                                                                                            
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -k                                                                                                                         
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   it                                                                                                                         
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -machine                                                                                                                   
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   xenpv                                                                                                                      
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -m                                                                                                                         
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   1025                                                                                                                       
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x901780 wpath=/local/domain/0/device-model/15/state token=3/0: register slotnum=3                            
libxl: debug: libxl_create.c:1355:do_domain_create: ao 0x9011a0: inprogress: poller=0x901070, flags=i                                                                             
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x901780 wpath=/local/domain/0/device-model/15/state token=3/0: event epath=/local/domain/0/device-model/15/state       
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x901780 wpath=/local/domain/0/device-model/15/state token=3/0: event epath=/local/domain/0/device-model/15/state       
libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch w=0x901780 wpath=/local/domain/0/device-model/15/state token=3/0: deregister slotnum=3                        
libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x901780: deregister unregistered                                                                           
libxl: debug: libxl_qmp.c:703:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-15                                                                                       
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: qmp                                                                                                              
libxl: debug: libxl_qmp.c:551:qmp_send_prepare: next qmp command: '{                                                                                                              
    "execute": "qmp_capabilities",                                                                                                                                                
    "id": 1                                                                                                                                                                       
}                                                                                                                                                                                 
'                                                                                                                                                                                 
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: return                                                                                                           
libxl: debug: libxl_qmp.c:551:qmp_send_prepare: next qmp command: '{                                                                                                              
    "execute": "query-chardev",                                                                                                                                                   
    "id": 2                                                                                                                                                                       
}                                                                                                                                                                                 
'                                                                                                                                                                                 
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: return                                                                                                           
libxl: debug: libxl_qmp.c:551:qmp_send_prepare: next qmp command: '{                                                                                                              
    "execute": "query-vnc",                                                                                                                                                       
    "id": 3                                                                                                                                                                       
}                                                                                                                                                                                 
'                                                                                                                                                                                 
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: return                                                                                                           
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x906308 wpath=/local/domain/0/backend/vif/15/0/state token=3/1: register slotnum=3                           
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x906308 wpath=/local/domain/0/backend/vif/15/0/state token=3/1: event epath=/local/domain/0/backend/vif/15/0/state     
libxl: debug: libxl_event.c:646:devstate_watch_callback: backend /local/domain/0/backend/vif/15/0/state wanted state 2 still waiting state 1                                      
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x906308 wpath=/local/domain/0/backend/vif/15/0/state token=3/1: event epath=/local/domain/0/backend/vif/15/0/state     
libxl: debug: libxl_event.c:642:devstate_watch_callback: backend /local/domain/0/backend/vif/15/0/state wanted state 2 ok                                                         
libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch w=0x906308 wpath=/local/domain/0/backend/vif/15/0/state token=3/1: deregister slotnum=3                       
libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x906308: deregister unregistered                                                                           
libxl: debug: libxl_device.c:1022:device_hotplug: calling hotplug script: /etc/xen/scripts/vif-bridge online                                                                      
libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x906390: deregister unregistered                                                                           
libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x906390: deregister unregistered                                                                           
libxl: debug: libxl_event.c:1752:libxl__ao_progress_report: ao 0x9011a0: progress report: callback queued aop=0x907260                                                            
libxl: debug: libxl_event.c:1572:libxl__ao_complete: ao 0x9011a0: complete, rc=0                                                                                                  
libxl: debug: libxl_event.c:1159:egc_run_callbacks: ao 0x9011a0: progress report: callback aop=0x907260                                                                           
libxl: debug: libxl_event.c:1544:libxl__ao__destroy: ao 0x9011a0: destroy                                                                                                         
Welcome to GRUB!                                                                                                                                                                  

script/script.c:65: free 0x3f5ebd20                                                                                                                                               
script/script.c:65: free 0x3f5ebd60                                                                                                                                               
script/script.c:65: free 0x3f5ebda0                                                                                                                                               
script/script.c:65: free 0x3f5eb9c0                                                                                                                                               
script/script.c:65: free 0x3f5eba20                                                                                                                                               
script/script.c:65: free 0x3f5eba60                                                                                                                                               
script/script.c:65: free 0x3f5ebac0                                                                                                                                               
script/script.c:65: free 0x3f5ebb20                                                                                                                                               
script/script.c:65: free 0x3f5ebc00                                                                                                                                               
script/lexer.c:321: token 259 text [                                                                                                                                              
]                                                                                                                                                                                 
script/script.c:50: malloc 0x3f5c95c0                                                                                                                                             
script/script.c:50: malloc 0x3f5c9580                                                                                                                                             
script/lexer.c:321: token 0 text []                                                                                                                                               
script/script.c:50: malloc 0x3f5c96e0                                                                                                                                             
script/script.c:50: malloc 0x3f5c96a0                                                                                                                                             
script/script.c:65: free 0x3f5c96a0                                                                                                                                               
script/script.c:65: free 0x3f5c96e0                                                                                                                                               
script/script.c:65: free 0x3f5c9580                                                                                                                                               
script/script.c:65: free 0x3f5c95c0                                                                                                                                               
script/lexer.c:321: token 288 text [insmod]                                                                                                                                       
script/script.c:50: malloc 0x3f5c95c0                                                                                                                                             
script/script.c:50: malloc 0x3f5c9580                                                                                                                                             
script/script.c:163: arglist                                                                                                                                                      
script/script.c:50: malloc 0x3f5c9520                                                                                                                                             
script/lexer.c:321: token 288 text [lvm]                                                                                                                                          
script/script.c:50: malloc 0x3f5c94c0                                                                                                                                             
script/script.c:50: malloc 0x3f5c9480                                                                                                                                             
script/script.c:163: arglist                                                                                                                                                      
script/script.c:50: malloc 0x3f5c9420                                                                                                                                             
script/lexer.c:321: token 259 text [                                                                                                                                              
]                                                                                                                                                                                 
script/script.c:50: malloc 0x3f5c93c0                                                                                                                                             
script/script.c:50: malloc 0x3f5c9380                                                                                                                                             
script/script.c:198: cmdline                                                                                                                                                      
script/script.c:50: malloc 0x3f5c9320                                                                                                                                             
script/lexer.c:321: token 0 text []                                                                                                                                               
script/script.c:50: malloc 0x3f5c96e0                                                                                                                                             
script/script.c:50: malloc 0x3f5c96a0                                                                                                                                             
script/script.c:294: append command                                                                                                                                               
script/script.c:50: malloc 0x3f5c92e0                                                                                                                                             
kern/disk.c:196: Opening `memdisk'...                                                                                                                                             
kern/fs.c:56: Detecting tarfs...                                                                                                                                                  
kern/disk.c:295: Closing `memdisk'.                                                                                                                                               
kern/dl.c:572: module at 0x3f5c6bc0, size 0x26e8                                                                                                                                  
kern/dl.c:596: relocating to 0x3f5cb5e0                                                                                                                                           
kern/disk.c:196: Opening `memdisk'...                                                                                                                                             
kern/fs.c:56: Detecting tarfs...                                                                                                                                                  
kern/disk.c:295: Closing `memdisk'.                                                                                                                                               
kern/dl.c:572: module at 0x3f5c3620, size 0x3580                                                                                                                                  
kern/dl.c:596: relocating to 0x3f5cb400                                                                                                                                           
kern/dl.c:560: flushing 0x31eb bytes at 0x3f5c0400                                                                                                                                
kern/dl.c:619: module name: diskfilter                                                                                                                                            
kern/dl.c:620: init function: 0x3f5c1a2c                                                                                                                                          
kern/dl.c:560: flushing 0x2374 bytes at 0x3f5c4820                                                                                                                                
kern/dl.c:619: module name: lvm                                                                                                                                                   
kern/dl.c:620: init function: 0x3f5c59e0                                                                                                                                          
script/script.c:65: free 0x3f5c92e0                                                                                                                                               
script/script.c:65: free 0x3f5c96a0                                                                                                                                               
script/script.c:65: free 0x3f5c96e0                                                                                                                                               
script/script.c:65: free 0x3f5c9320                                                                                                                                               
script/script.c:65: free 0x3f5c9380                                                                                                                                               
script/script.c:65: free 0x3f5c93c0                                                                                                                                               
script/script.c:65: free 0x3f5c9420                                                                                                                                               
script/script.c:65: free 0x3f5c9480                                                                                                                                               
script/script.c:65: free 0x3f5c94c0                                                                                                                                               
script/script.c:65: free 0x3f5c9520                                                                                                                                               
script/script.c:65: free 0x3f5c9580                                                                                                                                               
script/script.c:65: free 0x3f5c95c0                                                                                                                                               
script/lexer.c:321: token 288 text [insmod]                                                                                                                                       
script/script.c:50: malloc 0x3f5bda40                                                                                                                                             
script/script.c:50: malloc 0x3f5bda00                                                                                                                                             
script/script.c:163: arglist                                                                                                                                                      
script/script.c:50: malloc 0x3f5bd9a0                                                                                                                                             
script/lexer.c:321: token 288 text [ext2]                                                                                                                                         
script/script.c:50: malloc 0x3f5bd940                                                                                                                                             
script/script.c:50: malloc 0x3f5bd900                                                                                                                                             
script/script.c:163: arglist                                                                                                                                                      
script/script.c:50: malloc 0x3f5bd8a0                                                                                                                                             
script/lexer.c:321: token 259 text [                                                                                                                                              
]                                                                                                                                                                                 
script/script.c:50: malloc 0x3f5bd840                                                                                                                                             
script/script.c:50: malloc 0x3f5bd800                                                                                                                                             
script/script.c:198: cmdline                                                                                                                                                      
script/script.c:50: malloc 0x3f5bd7a0                                                                                                                                             
script/lexer.c:321: token 0 text []                                                                                                                                               
script/script.c:50: malloc 0x3f5bdb60                                                                                                                                             
script/script.c:50: malloc 0x3f5bdb20                                                                                                                                             
script/script.c:294: append command                                                                                                                                               
script/script.c:50: malloc 0x3f5bd760                                                                                                                                             
kern/disk.c:196: Opening `memdisk'...                                                                                                                                             
kern/fs.c:56: Detecting tarfs...                                                                                                                                                  
kern/disk.c:295: Closing `memdisk'.                                                                                                                                               
kern/dl.c:572: module at 0x3f5bb520, size 0x2220                                                                                                                                  
kern/dl.c:596: relocating to 0x3f5bfa60                                                                                                                                           
kern/disk.c:196: Opening `memdisk'...                                                                                                                                             
kern/fs.c:56: Detecting tarfs...                                                                                                                                                  
kern/disk.c:295: Closing `memdisk'.                                                                                                                                               
kern/dl.c:572: module at 0x3f5be660, size 0xea8                                                                                                                                   
kern/dl.c:596: relocating to 0x3f5bf880                                                                                                                                           
kern/dl.c:560: flushing 0xbad bytes at 0x3f5ba940                                                                                                                                 
kern/dl.c:619: module name: fshelp                                                                                                                                                
kern/dl.c:620: init function: 0x0                                                                                                                                                 
kern/dl.c:560: flushing 0x1eb0 bytes at 0x3f5b87e0                                                                                                                                
kern/dl.c:619: module name: ext2                                                                                                                                                  
kern/dl.c:620: init function: 0x3f5b95f5                                                                                                                                          
script/script.c:65: free 0x3f5bd760                                                                                                                                               
script/script.c:65: free 0x3f5bdb20                                                                                                                                               
script/script.c:65: free 0x3f5bdb60                                                                                                                                               
script/script.c:65: free 0x3f5bd7a0                                                                                                                                               
script/script.c:65: free 0x3f5bd800                                                                                                                                               
script/script.c:65: free 0x3f5bd840                                                                                                                                               
script/script.c:65: free 0x3f5bd8a0                                                                                                                                               
script/script.c:65: free 0x3f5bd900                                                                                                                                               
script/script.c:65: free 0x3f5bd940                                                                                                                                               
script/script.c:65: free 0x3f5bd9a0                                                                                                                                               
script/script.c:65: free 0x3f5bda00                                                                                                                                               
script/script.c:65: free 0x3f5bda40                                                                                                                                               
script/lexer.c:321: token 288 text [insmod]                                                                                                                                       
script/script.c:50: malloc 0x3f5b62c0                                                                                                                                             
script/script.c:50: malloc 0x3f5b6280                                                                                                                                             
script/script.c:163: arglist                                                                                                                                                      
script/script.c:50: malloc 0x3f5b6220                                                                                                                                             
script/lexer.c:321: token 288 text [part_msdos]                                                                                                                                   
script/script.c:50: malloc 0x3f5b61c0                                                                                                                                             
script/script.c:50: malloc 0x3f5b6180                                                                                                                                             
script/script.c:163: arglist                                                                                                                                                      
script/script.c:50: malloc 0x3f5b6120                                                                                                                                             
script/lexer.c:321: token 259 text [                                                                                                                                              
]                                                                                                                                                                                 
script/script.c:50: malloc 0x3f5b60c0                                                                                                                                             
script/script.c:50: malloc 0x3f5b6080                                                                                                                                             
script/script.c:198: cmdline                                                                                                                                                      
script/script.c:50: malloc 0x3f5b6020                                                                                                                                             
script/lexer.c:321: token 0 text []                                                                                                                                               
script/script.c:50: malloc 0x3f5b63e0                                                                                                                                             
script/script.c:50: malloc 0x3f5b63a0                                                                                                                                             
script/script.c:294: append command                                                                                                                                               
script/script.c:50: malloc 0x3f5b5fe0                                                                                                                                             
kern/disk.c:196: Opening `memdisk'...                                                                                                                                             
kern/fs.c:56: Detecting ext2...                                                                                                                                                   
kern/fs.c:78: ext2 detection failed.                                                                                                                                              
kern/fs.c:56: Detecting tarfs...                                                                                                                                                  
kern/disk.c:295: Closing `memdisk'.                                                                                                                                               
kern/dl.c:572: module at 0x3f5b7380, size 0xbe0                                                                                                                                   
kern/dl.c:596: relocating to 0x3f5b82e0                                                                                                                                           
kern/dl.c:560: flushing 0x8a1 bytes at 0x3f5b6aa0                                                                                                                                 
kern/dl.c:619: module name: part_msdos                                                                                                                                            
kern/dl.c:620: init function: 0x3f5b6d7e                                                                                                                                          
script/script.c:65: free 0x3f5b5fe0                                                                                                                                               
script/script.c:65: free 0x3f5b63a0                                                                                                                                               
script/script.c:65: free 0x3f5b63e0                                                                                                                                               
script/script.c:65: free 0x3f5b6020                                                                                                                                               
script/script.c:65: free 0x3f5b6080                                                                                                                                               
script/script.c:65: free 0x3f5b60c0                                                                                                                                               
script/script.c:65: free 0x3f5b6120                                                                                                                                               
script/script.c:65: free 0x3f5b6180                                                                                                                                               
script/script.c:65: free 0x3f5b61c0                                                                                                                                               
script/script.c:65: free 0x3f5b6220                                                                                                                                               
script/script.c:65: free 0x3f5b6280                                                                                                                                               
script/script.c:65: free 0x3f5b62c0                                                                                                                                               
script/lexer.c:321: token 288 text [insmod]                                                                                                                                       
script/script.c:50: malloc 0x3f5b44e0                                                                                                                                             
script/script.c:50: malloc 0x3f5b44a0                                                                                                                                             
script/script.c:163: arglist                                                                                                                                                      
script/script.c:50: malloc 0x3f5b4440                                                                                                                                             
script/lexer.c:321: token 288 text [part_gpt]                                                                                                                                     
script/script.c:50: malloc 0x3f5b43e0                                                                                                                                             
script/script.c:50: malloc 0x3f5b43a0                                                                                                                                             
script/script.c:163: arglist                                                                                                                                                      
script/script.c:50: malloc 0x3f5b4340                                                                                                                                             
script/lexer.c:321: token 259 text [                                                                                                                                              
]                                                                                                                                                                                 
script/script.c:50: malloc 0x3f5b42e0                                                                                                                                             
script/script.c:50: malloc 0x3f5b42a0                                                                                                                                             
script/script.c:198: cmdline                                                                                                                                                      
script/script.c:50: malloc 0x3f5b4240                                                                                                                                             
script/lexer.c:321: token 0 text []                                                                                                                                               
script/script.c:50: malloc 0x3f5b4600                                                                                                                                             
script/script.c:50: malloc 0x3f5b45c0                                                                                                                                             
script/script.c:294: append command                                                                                                                                               
script/script.c:50: malloc 0x3f5b4200                                                                                                                                             
kern/disk.c:196: Opening `memdisk'...                                                                                                                                             
kern/fs.c:56: Detecting ext2...                                                                                                                                                   
kern/fs.c:78: ext2 detection failed.                                                                                                                                              
kern/fs.c:56: Detecting tarfs...                                                                                                                                                  
kern/disk.c:295: Closing `memdisk'.                                                                                                                                               
kern/dl.c:572: module at 0x3f5b54e0, size 0xca0                                                                                                                                   
kern/dl.c:596: relocating to 0x3f5b6500                                                                                                                                           
kern/dl.c:560: flushing 0x91f bytes at 0x3f5b4ba0                                                                                                                                 
kern/dl.c:619: module name: part_gpt                                                                                                                                              
kern/dl.c:620: init function: 0x3f5b4e3c                                                                                                                                          
script/script.c:65: free 0x3f5b4200                                                                                                                                               
script/script.c:65: free 0x3f5b45c0                                                                                                                                               
script/script.c:65: free 0x3f5b4600                                                                                                                                               
script/script.c:65: free 0x3f5b4240                                                                                                                                               
script/script.c:65: free 0x3f5b42a0                                                                                                                                               
script/script.c:65: free 0x3f5b42e0                                                                                                                                               
script/script.c:65: free 0x3f5b4340                                                                                                                                               
script/script.c:65: free 0x3f5b43a0                                                                                                                                               
script/script.c:65: free 0x3f5b43e0                                                                                                                                               
script/script.c:65: free 0x3f5b4440                                                                                                                                               
script/script.c:65: free 0x3f5b44a0                                                                                                                                               
script/script.c:65: free 0x3f5b44e0                                                                                                                                               
script/lexer.c:321: token 288 text [insmod]                                                                                                                                       
script/script.c:50: malloc 0x3f5b25a0                                                                                                                                             
script/script.c:50: malloc 0x3f5b2560                                                                                                                                             
script/script.c:163: arglist                                                                                                                                                      
script/script.c:50: malloc 0x3f5b2500                                                                                                                                             
script/lexer.c:321: token 288 text [btrfs]                                                                                                                                        
script/script.c:50: malloc 0x3f5b24a0                                                                                                                                             
script/script.c:50: malloc 0x3f5b2460                                                                                                                                             
script/script.c:163: arglist                                                                                                                                                      
script/script.c:50: malloc 0x3f5b2400                                                                                                                                             
script/lexer.c:321: token 259 text [                                                                                                                                              
]                                                                                                                                                                                 
script/script.c:50: malloc 0x3f5b23a0                                                                                                                                             
script/script.c:50: malloc 0x3f5b2360                                                                                                                                             
script/script.c:198: cmdline                                                                                                                                                      
script/script.c:50: malloc 0x3f5b2300                                                                                                                                             
script/lexer.c:321: token 0 text []                                                                                                                                               
script/script.c:50: malloc 0x3f5b26c0                                                                                                                                             
script/script.c:50: malloc 0x3f5b2680                                                                                                                                             
script/script.c:294: append command                                                                                                                                               
script/script.c:50: malloc 0x3f5b22c0                                                                                                                                             
kern/disk.c:196: Opening `memdisk'...                                                                                                                                             
kern/fs.c:56: Detecting ext2...                                                                                                                                                   
kern/fs.c:78: ext2 detection failed.                                                                                                                                              
kern/fs.c:56: Detecting tarfs...                                                                                                                                                  
kern/disk.c:295: Closing `memdisk'.                                                                                                                                               
kern/dl.c:572: module at 0x3f5ad600, size 0x4c98                                                                                                                                  
kern/dl.c:596: relocating to 0x3f5b45c0                                                                                                                                           
kern/disk.c:196: Opening `memdisk'...                                                                                                                                             
kern/fs.c:56: Detecting ext2...                                                                                                                                                   
kern/fs.c:78: ext2 detection failed.                                                                                                                                              
kern/fs.c:56: Detecting tarfs...                                                                                                                                                  
kern/disk.c:295: Closing `memdisk'.                                                                                                                                               
kern/dl.c:572: module at 0x3f5aa5a0, size 0x3040                                                                                                                                  
kern/dl.c:596: relocating to 0x3f5b43e0                                                                                                                                           
kern/dl.c:560: flushing 0x2c72 bytes at 0x3f5a7900                                                                                                                                
kern/dl.c:619: module name: lzopio                                                                                                                                                
kern/dl.c:620: init function: 0x3f5a80fa                                                                                                                                          
kern/dl.c:560: flushing 0x4cdd bytes at 0x3f5a1f40                                                                                                                                
kern/dl.c:619: module name: btrfs                                                                                                                                                 
kern/dl.c:620: init function: 0x3f5a4567                                                                                                                                          
script/script.c:65: free 0x3f5b22c0                                                                                                                                               
script/script.c:65: free 0x3f5b2680                                                                                                                                               
script/script.c:65: free 0x3f5b26c0                                                                                                                                               
script/script.c:65: free 0x3f5b2300                                                                                                                                               
script/script.c:65: free 0x3f5b2360                                                                                                                                               
script/script.c:65: free 0x3f5b23a0                                                                                                                                               
script/script.c:65: free 0x3f5b2400                                                                                                                                               
script/script.c:65: free 0x3f5b2460                                                                                                                                               
script/script.c:65: free 0x3f5b24a0                                                                                                                                               
script/script.c:65: free 0x3f5b2500                                                                                                                                               
script/script.c:65: free 0x3f5b2560                                                                                                                                               
script/script.c:65: free 0x3f5b25a0                                                                                                                                               
script/lexer.c:321: token 259 text [                                                                                                                                              
]                                                                                                                                                                                 
script/script.c:50: malloc 0x3f5b1f80                                                                                                                                             
script/script.c:50: malloc 0x3f5b1f40                                                                                                                                             
script/lexer.c:321: token 0 text []                                                                                                                                               
script/script.c:50: malloc 0x3f5b20a0                                                                                                                                             
script/script.c:50: malloc 0x3f5b2060                                                                                                                                             
script/script.c:65: free 0x3f5b2060                                                                                                                                               
script/script.c:65: free 0x3f5b20a0                                                                                                                                               
script/script.c:65: free 0x3f5b1f40                                                                                                                                               
script/script.c:65: free 0x3f5b1f80                                                                                                                                               
script/lexer.c:321: token 288 text [insmod]                                                                                                                                       
script/script.c:50: malloc 0x3f5b1f80                                                                                                                                             
script/script.c:50: malloc 0x3f5b1f40                                                                                                                                             
script/script.c:163: arglist                                                                                                                                                      
script/script.c:50: malloc 0x3f5b1ee0                                                                                                                                             
script/lexer.c:321: token 288 text [regexp]                                                                                                                                       
script/script.c:50: malloc 0x3f5b1e80                                                                                                                                             
script/script.c:50: malloc 0x3f5b1e40                                                                                                                                             
script/script.c:163: arglist                                                                                                                                                      
script/script.c:50: malloc 0x3f5b1de0                                                                                                                                             
script/lexer.c:321: token 259 text [                                                                                                                                              
]                                                                                                                                                                                 
script/script.c:50: malloc 0x3f5b1d80                                                                                                                                             
script/script.c:50: malloc 0x3f5b1d40                                                                                                                                             
script/script.c:198: cmdline                                                                                                                                                      
script/script.c:50: malloc 0x3f5b1ce0                                                                                                                                             
script/lexer.c:321: token 0 text []                                                                                                                                               
script/script.c:50: malloc 0x3f5b20a0                                                                                                                                             
script/script.c:50: malloc 0x3f5b2060                                                                                                                                             
script/script.c:294: append command                                                                                                                                               
script/script.c:50: malloc 0x3f5b1ca0                                                                                                                                             
kern/disk.c:196: Opening `memdisk'...                                                                                                                                             
kern/fs.c:56: Detecting btrfs...                                                                                                                                                  
kern/fs.c:78: btrfs detection failed.                                                                                                                                             
kern/fs.c:56: Detecting ext2...                                                                                                                                                   
kern/fs.c:78: ext2 detection failed.                                                                                                                                              
kern/fs.c:56: Detecting tarfs...                                                                                                                                                  
kern/disk.c:295: Closing `memdisk'.                                                                                                                                               
kern/dl.c:572: module at 0x3f58ea80, size 0x13270                                                                                                                                 
kern/dl.c:596: relocating to 0x3f5b3fa0                                                                                                                                           
kern/dl.c:560: flushing 0x12dfb bytes at 0x3f573c40                                                                                                                               
kern/dl.c:619: module name: regexp                                                                                                                                                
kern/dl.c:620: init function: 0x3f573f0a                                                                                                                                          
script/script.c:65: free 0x3f5b1ca0                                                                                                                                               
script/script.c:65: free 0x3f5b2060                                                                                                                                               
script/script.c:65: free 0x3f5b20a0                                                                                                                                               
script/script.c:65: free 0x3f5b1ce0                                                                                                                                               
script/script.c:65: free 0x3f5b1d40                                                                                                                                               
script/script.c:65: free 0x3f5b1d80                                                                                                                                               
script/script.c:65: free 0x3f5b1de0                                                                                                                                               
script/script.c:65: free 0x3f5b1e40                                                                                                                                               
script/script.c:65: free 0x3f5b1e80                                                                                                                                               
script/script.c:65: free 0x3f5b1ee0                                                                                                                                               
script/script.c:65: free 0x3f5b1f40                                                                                                                                               
script/script.c:65: free 0x3f5b1f80                                                                                                                                               
script/lexer.c:321: token 280 text [for]                                                                                                                                          
script/script.c:50: malloc 0x3f5b1000                                                                                                                                             
script/script.c:50: malloc 0x3f5b0fc0                                                                                                                                             
script/lexer.c:321: token 288 text [dev]                                                                                                                                          
script/script.c:50: malloc 0x3f5b0f60                                                                                                                                             
script/script.c:50: malloc 0x3f5b0f20                                                                                                                                             
script/lexer.c:321: token 282 text [in]                                                                                                                                           
script/script.c:50: malloc 0x3f5b0ec0                                                                                                                                             
script/script.c:50: malloc 0x3f5b0e80                                                                                                                                             
script/lexer.c:321: token 289 text [(*)]                                                                                                                                          
script/script.c:50: malloc 0x3f5b0ca0                                                                                                                                             
script/script.c:50: malloc 0x3f5b0c60                                                                                                                                             
script/script.c:163: arglist                                                                                                                                                      
script/script.c:50: malloc 0x3f5b0c00                                                                                                                                             
script/lexer.c:321: token 265 text [;]                                                                                                                                            
script/script.c:50: malloc 0x3f5b0ba0                                                                                                                                             
script/script.c:50: malloc 0x3f5b0b60
script/lexer.c:321: token 274 text [do]
script/script.c:50: malloc 0x3f5b0b00
script/script.c:50: malloc 0x3f5b0ac0
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f5b0a60
script/script.c:50: malloc 0x3f5b0a20
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f5b09c0
script/script.c:50: malloc 0x3f5b0980
script/lexer.c:321: token 288 text [regexp]
script/script.c:50: malloc 0x3f5b0920
script/script.c:50: malloc 0x3f5b08e0
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5b0880
script/lexer.c:321: token 289 text [-s]
script/script.c:50: malloc 0x3f5b0820
script/script.c:50: malloc 0x3f5b07e0
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5b0780
script/lexer.c:321: token 288 text [device]
script/script.c:50: malloc 0x3f5b0720
script/script.c:50: malloc 0x3f5b06e0
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5b0680
script/lexer.c:321: token 289 text []
script/script.c:50: malloc 0x3f5b0580
script/script.c:50: malloc 0x3f5b0540
script/lexer.c:321: token 289 text [\((.*)\)]
script/script.c:50: malloc 0x3f5b04e0
script/script.c:50: malloc 0x3f5b04a0
script/lexer.c:321: token 289 text []
script/script.c:50: malloc 0x3f5b0620
script/script.c:50: malloc 0x3f5b0460
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5b0400
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f5b03a0
script/script.c:50: malloc 0x3f5b0360
script/script.c:198: cmdline
script/script.c:50: malloc 0x3f5b0300
script/script.c:294: append command
script/script.c:50: malloc 0x3f5b02c0
script/lexer.c:321: token 288 text [set]
script/script.c:50: malloc 0x3f5b0260
script/script.c:50: malloc 0x3f5b0220
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5b01c0
script/lexer.c:321: token 289 text [root=]
script/script.c:50: malloc 0x3f5b0160
script/script.c:50: malloc 0x3f5b0120
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5b00c0
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f5b0060
script/script.c:50: malloc 0x3f5b0020
script/script.c:198: cmdline
script/script.c:50: malloc 0x3f5affc0
script/script.c:294: append command
script/lexer.c:321: token 280 text [for]
script/script.c:50: malloc 0x3f5aff60
script/script.c:50: malloc 0x3f5aff20
script/lexer.c:321: token 288 text [file]
script/script.c:50: malloc 0x3f5afec0
script/script.c:50: malloc 0x3f5afe80
script/lexer.c:321: token 282 text [in]
script/script.c:50: malloc 0x3f5afe20
script/script.c:50: malloc 0x3f5afde0
script/lexer.c:321: token 289 text [/boot/vmlinuz-*]
script/script.c:50: malloc 0x3f5afd80
script/script.c:50: malloc 0x3f5afd40
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5afce0
script/lexer.c:321: token 289 text [/boot/linux-*]
script/script.c:50: malloc 0x3f5afc80
script/script.c:50: malloc 0x3f5afc40
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5afbe0
script/lexer.c:321: token 265 text [;]
script/script.c:50: malloc 0x3f5afb80
script/script.c:50: malloc 0x3f5afb40
script/lexer.c:321: token 274 text [do]
script/script.c:50: malloc 0x3f5afae0
script/script.c:50: malloc 0x3f5afaa0
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f5afa40
script/script.c:50: malloc 0x3f5afa00
script/lexer.c:321: token 281 text [if]
script/script.c:50: malloc 0x3f5af9a0
script/script.c:50: malloc 0x3f5af960
script/lexer.c:321: token 288 text [test]
script/script.c:50: malloc 0x3f5af900
script/script.c:50: malloc 0x3f5af8c0
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5af860
script/lexer.c:321: token 289 text [-f]
script/script.c:50: malloc 0x3f5af800
script/script.c:50: malloc 0x3f5af7c0
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5af760
script/lexer.c:321: token 265 text [;]
script/script.c:50: malloc 0x3f5af700
script/script.c:50: malloc 0x3f5af6c0
script/script.c:198: cmdline
script/script.c:50: malloc 0x3f5af660
script/script.c:294: append command
script/script.c:50: malloc 0x3f5af620
script/lexer.c:321: token 284 text [then]
script/script.c:50: malloc 0x3f5af5c0
script/script.c:50: malloc 0x3f5af580
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f5af520
script/script.c:50: malloc 0x3f5af4e0
script/lexer.c:321: token 288 text [set]
script/script.c:50: malloc 0x3f5af480
script/script.c:50: malloc 0x3f5af440
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5af3e0
script/lexer.c:321: token 289 text [saved_root=]
script/script.c:50: malloc 0x3f5af380
script/script.c:50: malloc 0x3f5af340
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5af2e0
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f5af280
script/script.c:50: malloc 0x3f5af240
script/script.c:198: cmdline
script/script.c:50: malloc 0x3f5af1e0
script/script.c:294: append command
script/script.c:50: malloc 0x3f5af1a0
script/lexer.c:321: token 279 text [fi]
script/script.c:50: malloc 0x3f5af140
script/script.c:50: malloc 0x3f5af100
script/script.c:223: cmdif
script/script.c:50: malloc 0x3f5af0a0
script/script.c:294: append command
script/script.c:50: malloc 0x3f5af060
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f5af000
script/script.c:50: malloc 0x3f5aefc0
script/lexer.c:321: token 275 text [done]
script/script.c:50: malloc 0x3f5aef60
script/script.c:50: malloc 0x3f5aef20
script/script.c:247: cmdfor
script/script.c:50: malloc 0x3f5aeec0
script/script.c:294: append command
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f5aee60
script/script.c:50: malloc 0x3f5aee20
script/lexer.c:321: token 275 text [done]
script/script.c:50: malloc 0x3f5aedc0
script/script.c:50: malloc 0x3f5aed80
script/script.c:247: cmdfor
script/script.c:50: malloc 0x3f5aed20
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f5aecc0
script/script.c:50: malloc 0x3f5aec80
script/lexer.c:321: token 0 text []
script/script.c:50: malloc 0x3f5a1760
script/script.c:50: malloc 0x3f5a1720
script/script.c:294: append command
script/script.c:50: malloc 0x3f5a16e0
commands/wildcard.c:164: Regexp is ^\(.*\)$
commands/wildcard.c:238: matching: (memdisk)
kern/disk.c:196: Opening `memdisk'...
kern/disk.c:295: Closing `memdisk'.
commands/wildcard.c:238: matching: (xen/xvda)
kern/disk.c:196: Opening `xen/xvda'...
kern/xen/init.c:236: msg type = 2, len = 8
kern/xen/init.c:236: msg type = 2, len = 3
partmap/msdos.c:188: partition 0: flag 0x80, type 0x83, start 0x800, len
0x11b1800
partmap/msdos.c:188: partition 1: flag 0x0, type 0x82, start 0x11b2000, len
0x1d5800
partmap/msdos.c:188: partition 2: flag 0x0, type 0x0, start 0x0, len 0x0
partmap/msdos.c:188: partition 3: flag 0x0, type 0x0, start 0x0, len 0x0
kern/disk.c:295: Closing `xen/xvda'.
commands/wildcard.c:238: matching: (xen/xvda,msdos2)
commands/wildcard.c:238: matching: (xen/xvda,msdos1)
kern/disk.c:196: Opening `memdisk'...
disk/diskfilter.c:135: Scanning for DISKFILTER devices on disk memdisk
kern/disk.c:295: Closing `memdisk'.
kern/disk.c:196: Opening `xen/xvda'...
kern/xen/init.c:236: msg type = 2, len = 8
kern/xen/init.c:236: msg type = 2, len = 3
disk/diskfilter.c:135: Scanning for DISKFILTER devices on disk xen/xvda
partmap/msdos.c:188: partition 0: flag 0x80, type 0x83, start 0x800, len
0x11b1800
disk/diskfilter.c:135: Scanning for DISKFILTER devices on disk xen/xvda
partmap/msdos.c:188: partition 1: flag 0x0, type 0x82, start 0x11b2000, len
0x1d5800
disk/diskfilter.c:135: Scanning for DISKFILTER devices on disk xen/xvda
partmap/msdos.c:188: partition 2: flag 0x0, type 0x0, start 0x0, len 0x0
partmap/msdos.c:188: partition 3: flag 0x0, type 0x0, start 0x0, len 0x0
kern/disk.c:295: Closing `xen/xvda'.
error: two arguments expected.
commands/wildcard.c:164: Regexp is ^vmlinuz-.*$
commands/wildcard.c:164: Regexp is ^linux-.*$
kern/disk.c:196: Opening `memdisk'...
kern/fs.c:56: Detecting btrfs...
kern/fs.c:78: btrfs detection failed.
kern/fs.c:56: Detecting ext2...
kern/fs.c:78: ext2 detection failed.
kern/fs.c:56: Detecting tarfs...
kern/disk.c:295: Closing `memdisk'.
kern/dl.c:572: module at 0x3f5acda0, size 0x1eb0
kern/dl.c:596: relocating to 0x3f5b29e0
kern/dl.c:560: flushing 0x1bc6 bytes at 0x3f5ab1a0
kern/dl.c:619: module name: test
kern/dl.c:620: init function: 0x3f5abdd4
error: two arguments expected.
commands/wildcard.c:164: Regexp is ^vmlinuz-.*$
commands/wildcard.c:164: Regexp is ^linux-.*$
error: two arguments expected.
commands/wildcard.c:164: Regexp is ^vmlinuz-.*$
commands/wildcard.c:164: Regexp is ^linux-.*$
error: two arguments expected.
commands/wildcard.c:164: Regexp is ^vmlinuz-.*$
commands/wildcard.c:164: Regexp is ^linux-.*$
script/script.c:65: free 0x3f5a16e0
script/script.c:65: free 0x3f5a1720
script/script.c:65: free 0x3f5a1760
script/script.c:65: free 0x3f5aec80
script/script.c:65: free 0x3f5aecc0
script/script.c:65: free 0x3f5aed20
script/script.c:65: free 0x3f5aed80
script/script.c:65: free 0x3f5aedc0
script/script.c:65: free 0x3f5aee20
script/script.c:65: free 0x3f5aee60
script/script.c:65: free 0x3f5aeec0
script/script.c:65: free 0x3f5aef20
script/script.c:65: free 0x3f5aef60
script/script.c:65: free 0x3f5aefc0
script/script.c:65: free 0x3f5af000
script/script.c:65: free 0x3f5af060
script/script.c:65: free 0x3f5af0a0
script/script.c:65: free 0x3f5af100
script/script.c:65: free 0x3f5af140
script/script.c:65: free 0x3f5af1a0
script/script.c:65: free 0x3f5af1e0
script/script.c:65: free 0x3f5af240
script/script.c:65: free 0x3f5af280
script/script.c:65: free 0x3f5af2e0
script/script.c:65: free 0x3f5af340
script/script.c:65: free 0x3f5af380
script/script.c:65: free 0x3f5af3e0
script/script.c:65: free 0x3f5af440
script/script.c:65: free 0x3f5af480
script/script.c:65: free 0x3f5af4e0
script/script.c:65: free 0x3f5af520
script/script.c:65: free 0x3f5af580
script/script.c:65: free 0x3f5af5c0
script/script.c:65: free 0x3f5af620
script/script.c:65: free 0x3f5af660
script/script.c:65: free 0x3f5af6c0
script/script.c:65: free 0x3f5af700
script/script.c:65: free 0x3f5af760
script/script.c:65: free 0x3f5af7c0
script/script.c:65: free 0x3f5af800
script/script.c:65: free 0x3f5af860
script/script.c:65: free 0x3f5af8c0
script/script.c:65: free 0x3f5af900
script/script.c:65: free 0x3f5af960
script/script.c:65: free 0x3f5af9a0
script/script.c:65: free 0x3f5afa00
script/script.c:65: free 0x3f5afa40
script/script.c:65: free 0x3f5afaa0
script/script.c:65: free 0x3f5afae0
script/script.c:65: free 0x3f5afb40
script/script.c:65: free 0x3f5afb80
script/script.c:65: free 0x3f5afbe0
script/script.c:65: free 0x3f5afc40
script/script.c:65: free 0x3f5afc80
script/script.c:65: free 0x3f5afce0
script/script.c:65: free 0x3f5afd40
script/script.c:65: free 0x3f5afd80
script/script.c:65: free 0x3f5afde0
script/script.c:65: free 0x3f5afe20
script/script.c:65: free 0x3f5afe80
script/script.c:65: free 0x3f5afec0
script/script.c:65: free 0x3f5aff20
script/script.c:65: free 0x3f5aff60
script/script.c:65: free 0x3f5affc0
script/script.c:65: free 0x3f5b0020
script/script.c:65: free 0x3f5b0060
script/script.c:65: free 0x3f5b00c0
script/script.c:65: free 0x3f5b0120
script/script.c:65: free 0x3f5b0160
script/script.c:65: free 0x3f5b01c0
script/script.c:65: free 0x3f5b0220
script/script.c:65: free 0x3f5b0260
script/script.c:65: free 0x3f5b02c0
script/script.c:65: free 0x3f5b0300
script/script.c:65: free 0x3f5b0360
script/script.c:65: free 0x3f5b03a0
script/script.c:65: free 0x3f5b0400
script/script.c:65: free 0x3f5b0460
script/script.c:65: free 0x3f5b0620
script/script.c:65: free 0x3f5b04a0
script/script.c:65: free 0x3f5b04e0
script/script.c:65: free 0x3f5b0540
script/script.c:65: free 0x3f5b0580
script/script.c:65: free 0x3f5b0680
script/script.c:65: free 0x3f5b06e0
script/script.c:65: free 0x3f5b0720
script/script.c:65: free 0x3f5b0780
script/script.c:65: free 0x3f5b07e0
script/script.c:65: free 0x3f5b0820
script/script.c:65: free 0x3f5b0880
script/script.c:65: free 0x3f5b08e0
script/script.c:65: free 0x3f5b0920
script/script.c:65: free 0x3f5b0980
script/script.c:65: free 0x3f5b09c0
script/script.c:65: free 0x3f5b0a20
script/script.c:65: free 0x3f5b0a60
script/script.c:65: free 0x3f5b0ac0
script/script.c:65: free 0x3f5b0b00
script/script.c:65: free 0x3f5b0b60
script/script.c:65: free 0x3f5b0ba0
script/script.c:65: free 0x3f5b0c00
script/script.c:65: free 0x3f5b0c60
script/script.c:65: free 0x3f5b0ca0
script/script.c:65: free 0x3f5b0e80
script/script.c:65: free 0x3f5b0ec0
script/script.c:65: free 0x3f5b0f20
script/script.c:65: free 0x3f5b0f60
script/script.c:65: free 0x3f5b0fc0
script/script.c:65: free 0x3f5b1000
script/lexer.c:321: token 288 text [set]
script/script.c:50: malloc 0x3f571860
script/script.c:50: malloc 0x3f571820
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5717c0
script/lexer.c:321: token 289 text [root=]
script/script.c:50: malloc 0x3f5715e0
script/script.c:50: malloc 0x3f5715a0
script/script.c:163: arglist
script/script.c:50: malloc 0x3f571540
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f5714e0
script/script.c:50: malloc 0x3f5714a0
script/script.c:198: cmdline
script/script.c:50: malloc 0x3f571440
script/lexer.c:321: token 0 text []
script/script.c:50: malloc 0x3f571980
script/script.c:50: malloc 0x3f571940
script/script.c:294: append command
script/script.c:50: malloc 0x3f571900
script/script.c:65: free 0x3f571900
script/script.c:65: free 0x3f571940
script/script.c:65: free 0x3f571980
script/script.c:65: free 0x3f571440
script/script.c:65: free 0x3f5714a0
script/script.c:65: free 0x3f5714e0
script/script.c:65: free 0x3f571540
script/script.c:65: free 0x3f5715a0
script/script.c:65: free 0x3f5715e0
script/script.c:65: free 0x3f5717c0
script/script.c:65: free 0x3f571820
script/script.c:65: free 0x3f571860
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f561820
script/script.c:50: malloc 0x3f5617e0
script/lexer.c:321: token 0 text []
script/script.c:50: malloc 0x3f561940
script/script.c:50: malloc 0x3f561900
script/script.c:65: free 0x3f561900
script/script.c:65: free 0x3f561940
script/script.c:65: free 0x3f5617e0
script/script.c:65: free 0x3f561820
script/lexer.c:321: token 281 text [if]
script/script.c:50: malloc 0x3f5617e0
script/script.c:50: malloc 0x3f5617a0
script/lexer.c:321: token 288 text [test]
script/script.c:50: malloc 0x3f561740
script/script.c:50: malloc 0x3f561700
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5616a0
script/lexer.c:321: token 289 text [-f]
script/script.c:50: malloc 0x3f5614c0
script/script.c:50: malloc 0x3f561480
script/script.c:163: arglist
script/script.c:50: malloc 0x3f561420
script/lexer.c:321: token 289 text [/boot/grub2/grub.cfg]
script/script.c:50: malloc 0x3f5613c0
script/script.c:50: malloc 0x3f561360
script/script.c:163: arglist
script/script.c:50: malloc 0x3f561300
script/lexer.c:321: token 265 text [;]
script/script.c:50: malloc 0x3f5612a0
script/script.c:50: malloc 0x3f561260
script/script.c:198: cmdline
script/script.c:50: malloc 0x3f561200
script/script.c:294: append command
script/script.c:50: malloc 0x3f5611c0
script/lexer.c:321: token 284 text [then]
script/script.c:50: malloc 0x3f561160
script/script.c:50: malloc 0x3f561120
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f5610c0
script/script.c:50: malloc 0x3f561080
script/lexer.c:321: token 288 text [configfile]
script/script.c:50: malloc 0x3f561020
script/script.c:50: malloc 0x3f560fe0
script/script.c:163: arglist
script/script.c:50: malloc 0x3f560f80
script/lexer.c:321: token 289 text [/boot/grub2/grub.cfg]
script/script.c:50: malloc 0x3f560f20
script/script.c:50: malloc 0x3f560ec0
script/script.c:163: arglist
script/script.c:50: malloc 0x3f560e60
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f560e00
script/script.c:50: malloc 0x3f560dc0
script/script.c:198: cmdline
script/script.c:50: malloc 0x3f560d60
script/script.c:294: append command
script/script.c:50: malloc 0x3f560d20
script/lexer.c:321: token 276 text [elif]
script/script.c:50: malloc 0x3f560cc0
script/script.c:50: malloc 0x3f560c80
script/lexer.c:321: token 288 text [test]
script/script.c:50: malloc 0x3f560c20
script/script.c:50: malloc 0x3f560be0
script/script.c:163: arglist
script/script.c:50: malloc 0x3f560b80
script/lexer.c:321: token 289 text [-f]
script/script.c:50: malloc 0x3f560b20
script/script.c:50: malloc 0x3f560ae0
script/script.c:163: arglist
script/script.c:50: malloc 0x3f560a80
script/lexer.c:321: token 289 text [/boot/grub/grub.cfg]
script/script.c:50: malloc 0x3f560a20
script/script.c:50: malloc 0x3f5609c0
script/script.c:163: arglist
script/script.c:50: malloc 0x3f560960
script/lexer.c:321: token 265 text [;]
script/script.c:50: malloc 0x3f560900
script/script.c:50: malloc 0x3f5608c0
script/script.c:198: cmdline
script/script.c:50: malloc 0x3f560860
script/script.c:294: append command
script/script.c:50: malloc 0x3f560820
script/lexer.c:321: token 284 text [then]
script/script.c:50: malloc 0x3f5607c0
script/script.c:50: malloc 0x3f560780
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f560720
script/script.c:50: malloc 0x3f5606e0
script/lexer.c:321: token 288 text [configfile]
script/script.c:50: malloc 0x3f560680
script/script.c:50: malloc 0x3f560640
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5605e0
script/lexer.c:321: token 289 text [/boot/grub/grub.cfg]
script/script.c:50: malloc 0x3f560580
script/script.c:50: malloc 0x3f560520
script/script.c:163: arglist
script/script.c:50: malloc 0x3f5604c0
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f560460
script/script.c:50: malloc 0x3f560420
script/script.c:198: cmdline
script/script.c:50: malloc 0x3f5603c0
script/script.c:294: append command
script/script.c:50: malloc 0x3f560380
script/lexer.c:321: token 279 text [fi]
script/script.c:50: malloc 0x3f560320
script/script.c:50: malloc 0x3f5602e0
script/script.c:223: cmdif
script/script.c:50: malloc 0x3f560280
script/script.c:223: cmdif
script/script.c:50: malloc 0x3f560220
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0x3f5601c0
script/script.c:50: malloc 0x3f560180
script/lexer.c:321: token 0 text []
script/script.c:50: malloc 0x3f553920
script/script.c:50: malloc 0x3f5538e0
script/script.c:294: append command
script/script.c:50: malloc 0x3f5538a0
commands/wildcard.c:505: no expansion needed
commands/wildcard.c:564: paths[0] = `/boot/grub2/grub.cfg'
commands/wildcard.c:505: no expansion needed
commands/wildcard.c:564: paths[0] = `/boot/grub/grub.cfg'
script/script.c:65: free 0x3f5538a0
script/script.c:65: free 0x3f5538e0
script/script.c:65: free 0x3f553920
script/script.c:65: free 0x3f560180
script/script.c:65: free 0x3f5601c0
script/script.c:65: free 0x3f560220
script/script.c:65: free 0x3f560280
script/script.c:65: free 0x3f5602e0
script/script.c:65: free 0x3f560320
script/script.c:65: free 0x3f560380
script/script.c:65: free 0x3f5603c0
script/script.c:65: free 0x3f560420
script/script.c:65: free 0x3f560460
script/script.c:65: free 0x3f5604c0
script/script.c:65: free 0x3f560520
script/script.c:65: free 0x3f560580
script/script.c:65: free 0x3f5605e0
script/script.c:65: free 0x3f560640
script/script.c:65: free 0x3f560680
script/script.c:65: free 0x3f5606e0
script/script.c:65: free 0x3f560720
script/script.c:65: free 0x3f560780
script/script.c:65: free 0x3f5607c0
script/script.c:65: free 0x3f560820
script/script.c:65: free 0x3f560860
script/script.c:65: free 0x3f5608c0
script/script.c:65: free 0x3f560900
script/script.c:65: free 0x3f560960
script/script.c:65: free 0x3f5609c0
script/script.c:65: free 0x3f560a20
script/script.c:65: free 0x3f560a80
script/script.c:65: free 0x3f560ae0
script/script.c:65: free 0x3f560b20
script/script.c:65: free 0x3f560b80
script/script.c:65: free 0x3f560be0
script/script.c:65: free 0x3f560c20
script/script.c:65: free 0x3f560c80
script/script.c:65: free 0x3f560cc0
script/script.c:65: free 0x3f560d20
script/script.c:65: free 0x3f560d60
script/script.c:65: free 0x3f560dc0
script/script.c:65: free 0x3f560e00
script/script.c:65: free 0x3f560e60
script/script.c:65: free 0x3f560ec0
script/script.c:65: free 0x3f560f20
script/script.c:65: free 0x3f560f80
script/script.c:65: free 0x3f560fe0
script/script.c:65: free 0x3f561020
script/script.c:65: free 0x3f561080
script/script.c:65: free 0x3f5610c0
script/script.c:65: free 0x3f561120
script/script.c:65: free 0x3f561160
script/script.c:65: free 0x3f5611c0
script/script.c:65: free 0x3f561200
script/script.c:65: free 0x3f561260
script/script.c:65: free 0x3f5612a0
script/script.c:65: free 0x3f561300
script/script.c:65: free 0x3f561360
script/script.c:65: free 0x3f5613c0
script/script.c:65: free 0x3f561420
script/script.c:65: free 0x3f561480
script/script.c:65: free 0x3f5614c0
script/script.c:65: free 0x3f5616a0
script/script.c:65: free 0x3f561700
script/script.c:65: free 0x3f561740
script/script.c:65: free 0x3f5617a0
script/script.c:65: free 0x3f5617e0
xc: debug: hypercall buffer: cache current size:4
xc: debug: hypercall buffer: cache hits:236 misses:4 toobig:7

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Fabio Fantoni]

Il 28/11/2013 15:17, Fabio Fantoni ha scritto:
> Il 28/11/2013 15:05, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>> On 28.11.2013 14:07, Fabio Fantoni wrote:
>>> Il 27/11/2013 18:35, Andrey Borzenkov ha scritto:
>>>> В Wed, 27 Nov 2013 17:24:53 +0100
>>>> Fabio Fantoni <fabio.fantoni@m2r.biz> пишет:
>>>>
>>>>> Il 27/11/2013 17:03, Vladimir 'φ-coder/phcoder' Serbinenko ha 
>>>>> scritto:
>>>>>> On 27.11.2013 16:59, Fabio Fantoni wrote:
>>>>>>> Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha 
>>>>>>> scritto:
>>>>>>>> That pretty much explains what happened: you don't have any
>>>>>>>> /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB
>>>>>>>> found
>>>>>>>> its own memdisk and fell into recursion. I'm not sure what should
>>>>>>>> be the
>>>>>>>> proper way to solve this recursion.
>>>> Yes, it was a bit naive on my side. Recursion in principle can be
>>>> stopped by using global variable, but search is limited to the first
>>>> match only anyway, so I guess it is not worth it.
>>>>
>>>>>>> Anyone know how to exclude memdisk from the search please?
>>>> Please look in grub2 sources at docs/osdetect.cfg. It implements
>>>> advanced run-time detection of possible bootable files from
>>>> various operating systems. It boils down to loop across all devices,
>>>> and of course you can either limit device names (like looking for hd*
>>>> only) or explicitly exclude known ones (like memdisk).
>>>>
>>>>> Is it possible to specify a different default grub.cfg path 
>>>>> (different
>>>>> from all other distributions) changing this command:
>>>>> ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O
>>>>> x86_64-xen -d grub-core/ boot/grub/grub.cfg
>>>>> Is it hardcoded as /boot/grub/grub.cfg for grub memdisk or can be 
>>>>> set?
>>>>>
>>>> Not really. Currently the situation is
>>>>
>>>> - grub-mkstandalone hardcodes $prefix as (memdisk)/boot/grub
>>>> - after launch grub unconditionally starts "normal" module if at all
>>>>     possible
>>>> - normal module always tries to load and execute $prefix/grub.cfg 
>>>> if no
>>>>     explicit configuration file name is given as argument
>>>>
>>>> But I think that using osdetect.cfg or something based on this idea
>>>> won't require changing defaults at all.
>>> Thanks for your reply.
>>>
>>> I did this script that is working about finding and include the 
>>> grub.cfg
>>> of pv domUs with many cases:
>>>
>>> cat > boot/grub/grub.cfg <<EOF
>>> insmod lvm
>>> insmod ext2
>>> insmod part_msdos
>>> insmod part_gpt
>>> insmod btrfs
>>>
>>> insmod regexp
>>> for dev in (*); do
>>>      # $device: parenthesis removed from $dev
>>>      regexp -s device '\((.*)\)' $dev
>>>      set root=$device
>>>      for file in /boot/vmlinuz-* /boot/linux-*; do
>>>          if test -f $file; then
>>>              set saved_root=$root
>>>          fi
>>>      done
>>> done
>>> set root=$saved_root
>>>
>>> if test -f /boot/grub2/grub.cfg ; then
>>>      configfile /boot/grub2/grub.cfg
>>> elif test -f /boot/grub/grub.cfg ; then
>>>      configfile /boot/grub/grub.cfg
>>> fi
>>> EOF
>>>
>>> @xen developer: Are there other modules to insert for other partitions
>>> or file systems, other grub cfg path for other distributions or other
>>> kernel type to search that support xen pv domUs?
>>> I think is good do and post complete pvgrub2 cfg that support all pv 
>>> domUs.
>>>
>>> @xen and grub developer: I'm still unable to boot any entry of Sid pv
>>> domU using official kernel:
>>> xl -vvv create -c /etc/xen/sid.cfg
>>> ...
>>> Caricamento Linux 3.11-1-amd64...
>>> Caricamento ramdisk iniziale...
>>> xc: debug: hypercall buffer: total allocations:247 total releases:247
>>> xc: debug: hypercall buffer: current allocations:0 maximum 
>>> allocations:4
>>> xc: debug: hypercall buffer: cache current size:4
>>> xc: debug: hypercall buffer: cache hits:236 misses:4 toobig:7
>>>
>>> Any ideas?
>>>
>> Ah I forgot: you need to "insmod xzio" since debian ones are compressed.
>>> If you need more tests/informations tell me and I'll post them.
>>>
>>> Thanks for any reply.
>>>
>>
>
> Thanks for reply, in the meantime I rebuilt updated grub2 from git 
> (commit    b67422d33de8eee83700db534a45b2ac5e5ed67a)  and there is a 
> regression from build of some days ago (I don't remember the exact 
> commit, probably was of 24 or 25 november).
> Fails on script I posted on previous mail showing some errors:
>> kern/dl.c:619: module name: test
>> kern/dl.c:620: init function: 0x3f5abdd4
>> error: two arguments expected.
>> commands/wildcard.c:164: Regexp is ^vmlinuz-.*$
>> commands/wildcard.c:164: Regexp is ^linux-.*$
>> error: two arguments expected.
>> commands/wildcard.c:164: Regexp is ^vmlinuz-.*$
>> commands/wildcard.c:164: Regexp is ^linux-.*$
>> error: two arguments expected.
>> commands/wildcard.c:164: Regexp is ^vmlinuz-.*$
>> commands/wildcard.c:164: Regexp is ^linux-.*$
>
> Full log with debug on attachment.
>

I updated git to commit 69ca97c820a623f85baf2db1627e19bef9c24e44 and the 
regression persist.

About Sid boot adding "insmod xzio" not solve the problem.
Can you give me details of your working cases?

Thanks for any reply and sorry for my bad english.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] pvgrub2 is merged

[Fabio Fantoni]

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

Il 29/11/2013 13:58, Fabio Fantoni ha scritto:
> Il 29/11/2013 12:41, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>> On 29.11.2013 12:28, Fabio Fantoni wrote:
>>> Il 28/11/2013 15:17, Fabio Fantoni ha scritto:
>>>> Il 28/11/2013 15:05, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>>>>> On 28.11.2013 14:07, Fabio Fantoni wrote:
>>>>>> Il 27/11/2013 18:35, Andrey Borzenkov ha scritto:
>>>>>>> В Wed, 27 Nov 2013 17:24:53 +0100
>>>>>>> Fabio Fantoni <fabio.fantoni@m2r.biz> пишет:
>>>>>>>
>>>>>>>> Il 27/11/2013 17:03, Vladimir 'φ-coder/phcoder' Serbinenko ha
>>>>>>>> scritto:
>>>>>>>>> On 27.11.2013 16:59, Fabio Fantoni wrote:
>>>>>>>>>> Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha
>>>>>>>>>> scritto:
>>>>>>>>>>> That pretty much explains what happened: you don't have any
>>>>>>>>>>> /boot/grub2/grub.cfg and when looking for 
>>>>>>>>>>> /boot/grub/grub.cfg GRUB
>>>>>>>>>>> found
>>>>>>>>>>> its own memdisk and fell into recursion. I'm not sure what 
>>>>>>>>>>> should
>>>>>>>>>>> be the
>>>>>>>>>>> proper way to solve this recursion.
>>>>>>> Yes, it was a bit naive on my side. Recursion in principle can be
>>>>>>> stopped by using global variable, but search is limited to the 
>>>>>>> first
>>>>>>> match only anyway, so I guess it is not worth it.
>>>>>>>
>>>>>>>>>> Anyone know how to exclude memdisk from the search please?
>>>>>>> Please look in grub2 sources at docs/osdetect.cfg. It implements
>>>>>>> advanced run-time detection of possible bootable files from
>>>>>>> various operating systems. It boils down to loop across all 
>>>>>>> devices,
>>>>>>> and of course you can either limit device names (like looking 
>>>>>>> for hd*
>>>>>>> only) or explicitly exclude known ones (like memdisk).
>>>>>>>
>>>>>>>> Is it possible to specify a different default grub.cfg path
>>>>>>>> (different
>>>>>>>> from all other distributions) changing this command:
>>>>>>>> ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o 
>>>>>>>> pvgrub2.xen -O
>>>>>>>> x86_64-xen -d grub-core/ boot/grub/grub.cfg
>>>>>>>> Is it hardcoded as /boot/grub/grub.cfg for grub memdisk or can be
>>>>>>>> set?
>>>>>>>>
>>>>>>> Not really. Currently the situation is
>>>>>>>
>>>>>>> - grub-mkstandalone hardcodes $prefix as (memdisk)/boot/grub
>>>>>>> - after launch grub unconditionally starts "normal" module if at 
>>>>>>> all
>>>>>>>      possible
>>>>>>> - normal module always tries to load and execute $prefix/grub.cfg
>>>>>>> if no
>>>>>>>      explicit configuration file name is given as argument
>>>>>>>
>>>>>>> But I think that using osdetect.cfg or something based on this idea
>>>>>>> won't require changing defaults at all.
>>>>>> Thanks for your reply.
>>>>>>
>>>>>> I did this script that is working about finding and include the
>>>>>> grub.cfg
>>>>>> of pv domUs with many cases:
>>>>>>
>>>>>> cat > boot/grub/grub.cfg <<EOF
>>>>>> insmod lvm
>>>>>> insmod ext2
>>>>>> insmod part_msdos
>>>>>> insmod part_gpt
>>>>>> insmod btrfs
>>>>>>
>>>>>> insmod regexp
>>>>>> for dev in (*); do
>>>>>>       # $device: parenthesis removed from $dev
>>>>>>       regexp -s device '\((.*)\)' $dev
>>>>>>       set root=$device
>>>>>>       for file in /boot/vmlinuz-* /boot/linux-*; do
>>>>>>           if test -f $file; then
>>>>>>               set saved_root=$root
>>>>>>           fi
>>>>>>       done
>>>>>> done
>>>>>> set root=$saved_root
>>>>>>
>>>>>> if test -f /boot/grub2/grub.cfg ; then
>>>>>>       configfile /boot/grub2/grub.cfg
>>>>>> elif test -f /boot/grub/grub.cfg ; then
>>>>>>       configfile /boot/grub/grub.cfg
>>>>>> fi
>>>>>> EOF
>>>>>>
>>>>>> @xen developer: Are there other modules to insert for other 
>>>>>> partitions
>>>>>> or file systems, other grub cfg path for other distributions or 
>>>>>> other
>>>>>> kernel type to search that support xen pv domUs?
>>>>>> I think is good do and post complete pvgrub2 cfg that support all pv
>>>>>> domUs.
>>>>>>
>>>>>> @xen and grub developer: I'm still unable to boot any entry of 
>>>>>> Sid pv
>>>>>> domU using official kernel:
>>>>>> xl -vvv create -c /etc/xen/sid.cfg
>>>>>> ...
>>>>>> Caricamento Linux 3.11-1-amd64...
>>>>>> Caricamento ramdisk iniziale...
>>>>>> xc: debug: hypercall buffer: total allocations:247 total 
>>>>>> releases:247
>>>>>> xc: debug: hypercall buffer: current allocations:0 maximum
>>>>>> allocations:4
>>>>>> xc: debug: hypercall buffer: cache current size:4
>>>>>> xc: debug: hypercall buffer: cache hits:236 misses:4 toobig:7
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>> Ah I forgot: you need to "insmod xzio" since debian ones are 
>>>>> compressed.
>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>>
>>>>>> Thanks for any reply.
>>>>>>
>>>> Thanks for reply, in the meantime I rebuilt updated grub2 from git
>>>> (commit    b67422d33de8eee83700db534a45b2ac5e5ed67a)  and there is a
>>>> regression from build of some days ago (I don't remember the exact
>>>> commit, probably was of 24 or 25 november).
>>>> Fails on script I posted on previous mail showing some errors:
>>>>> kern/dl.c:619: module name: test
>>>>> kern/dl.c:620: init function: 0x3f5abdd4
>>>>> error: two arguments expected.
>>>>> commands/wildcard.c:164: Regexp is ^vmlinuz-.*$
>>>>> commands/wildcard.c:164: Regexp is ^linux-.*$
>>>>> error: two arguments expected.
>>>>> commands/wildcard.c:164: Regexp is ^vmlinuz-.*$
>>>>> commands/wildcard.c:164: Regexp is ^linux-.*$
>>>>> error: two arguments expected.
>>>>> commands/wildcard.c:164: Regexp is ^vmlinuz-.*$
>>>>> commands/wildcard.c:164: Regexp is ^linux-.*$
>>>> Full log with debug on attachment.
>>>>
>>> I updated git to commit 69ca97c820a623f85baf2db1627e19bef9c24e44 and 
>>> the
>>> regression persist.
>>>
>>> About Sid boot adding "insmod xzio" not solve the problem.
>>> Can you give me details of your working cases?
>> Can you send me the exact kernel? My sid kernel work fine.
>

(Resent re-adding xen-devel and grub-devel)

I have updated Sid domU today before retry with pvgrub2.
Latest version of kernel and grub is installed, on attachment the 
grub.cfg of domU.
If domU's grub.cfg is ok, what is git commit and details of your pvgrub2 
build working?

My actual build is:
git clone git://git.sv.gnu.org/grub.git
./autogen.sh
./configure --target=x86_64 --with-platform=xen
make
mkdir -p boot/grub/
cat > boot/grub/grub.cfg <<EOF
insmod lvm
insmod ext2
insmod part_msdos
insmod part_gpt
insmod btrfs
insmod xzio

insmod regexp
for dev in (*); do
     # $device: parenthesis removed from $dev
     regexp -s device '\((.*)\)' $dev
     set root=$device
     for file in /boot/vmlinuz-* /boot/linux-*; do
         if test -f $file; then
             set saved_root=$root
         fi
     done
done
set root=$saved_root

if test -f /boot/grub2/grub.cfg ; then
     configfile /boot/grub2/grub.cfg
elif test -f /boot/grub/grub.cfg ; then
     configfile /boot/grub/grub.cfg
fi
EOF
./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O 
x86_64-xen -d grub-core/ boot/grub/grub.cfg

And I use Wheezy (debian 7) as dom0 with xen-unstable from git.

If you need more tests/informations tell me and I'll post them.

Thanks for any reply.


[-- Attachment #2: grub.cfg --]
[-- Type: text/plain, Size: 11227 bytes --]

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
set default="0"

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
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='hd0,msdos1'  3ab55964-09d1-4853-be38-661b5a476a14
else
  search --no-floppy --fs-uuid --set=root 3ab55964-09d1-4853-be38-661b5a476a14
fi
    font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=it_IT
  insmod gettext
fi
terminal_output gfxterm
set timeout=5
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
	set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-3ab55964-09d1-4853-be38-661b5a476a14' {
	load_video
	insmod gzio
	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='hd0,msdos1'  3ab55964-09d1-4853-be38-661b5a476a14
	else
	  search --no-floppy --fs-uuid --set=root 3ab55964-09d1-4853-be38-661b5a476a14
	fi
	echo	'Caricamento Linux 3.11-2-amd64...'
	linux	/boot/vmlinuz-3.11-2-amd64 root=UUID=3ab55964-09d1-4853-be38-661b5a476a14 ro console=tty0 quiet
	echo	'Caricamento ramdisk iniziale...'
	initrd	/boot/initrd.img-3.11-2-amd64
}
submenu 'Opzioni avanzate per Debian GNU/Linux' $menuentry_id_option 'gnulinux-advanced-3ab55964-09d1-4853-be38-661b5a476a14' {
	menuentry 'Debian GNU/Linux, con Linux 3.11-2-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.11-2-amd64-advanced-3ab55964-09d1-4853-be38-661b5a476a14' {
		load_video
		insmod gzio
		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='hd0,msdos1'  3ab55964-09d1-4853-be38-661b5a476a14
		else
		  search --no-floppy --fs-uuid --set=root 3ab55964-09d1-4853-be38-661b5a476a14
		fi
		echo	'Caricamento Linux 3.11-2-amd64...'
		linux	/boot/vmlinuz-3.11-2-amd64 root=UUID=3ab55964-09d1-4853-be38-661b5a476a14 ro console=tty0 quiet
		echo	'Caricamento ramdisk iniziale...'
		initrd	/boot/initrd.img-3.11-2-amd64
	}
	menuentry 'Debian GNU/Linux, con Linux 3.11-2-amd64 (modalità ripristino)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.11-2-amd64-recovery-3ab55964-09d1-4853-be38-661b5a476a14' {
		load_video
		insmod gzio
		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='hd0,msdos1'  3ab55964-09d1-4853-be38-661b5a476a14
		else
		  search --no-floppy --fs-uuid --set=root 3ab55964-09d1-4853-be38-661b5a476a14
		fi
		echo	'Caricamento Linux 3.11-2-amd64...'
		linux	/boot/vmlinuz-3.11-2-amd64 root=UUID=3ab55964-09d1-4853-be38-661b5a476a14 ro single console=tty0
		echo	'Caricamento ramdisk iniziale...'
		initrd	/boot/initrd.img-3.11-2-amd64
	}
	menuentry 'Debian GNU/Linux, con Linux 3.11-1-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.11-1-amd64-advanced-3ab55964-09d1-4853-be38-661b5a476a14' {
		load_video
		insmod gzio
		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='hd0,msdos1'  3ab55964-09d1-4853-be38-661b5a476a14
		else
		  search --no-floppy --fs-uuid --set=root 3ab55964-09d1-4853-be38-661b5a476a14
		fi
		echo	'Caricamento Linux 3.11-1-amd64...'
		linux	/boot/vmlinuz-3.11-1-amd64 root=UUID=3ab55964-09d1-4853-be38-661b5a476a14 ro console=tty0 quiet
		echo	'Caricamento ramdisk iniziale...'
		initrd	/boot/initrd.img-3.11-1-amd64
	}
	menuentry 'Debian GNU/Linux, con Linux 3.11-1-amd64 (modalità ripristino)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.11-1-amd64-recovery-3ab55964-09d1-4853-be38-661b5a476a14' {
		load_video
		insmod gzio
		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='hd0,msdos1'  3ab55964-09d1-4853-be38-661b5a476a14
		else
		  search --no-floppy --fs-uuid --set=root 3ab55964-09d1-4853-be38-661b5a476a14
		fi
		echo	'Caricamento Linux 3.11-1-amd64...'
		linux	/boot/vmlinuz-3.11-1-amd64 root=UUID=3ab55964-09d1-4853-be38-661b5a476a14 ro single console=tty0
		echo	'Caricamento ramdisk iniziale...'
		initrd	/boot/initrd.img-3.11-1-amd64
	}
	menuentry 'Debian GNU/Linux, con Linux 3.10-3-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.10-3-amd64-advanced-3ab55964-09d1-4853-be38-661b5a476a14' {
		load_video
		insmod gzio
		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='hd0,msdos1'  3ab55964-09d1-4853-be38-661b5a476a14
		else
		  search --no-floppy --fs-uuid --set=root 3ab55964-09d1-4853-be38-661b5a476a14
		fi
		echo	'Caricamento Linux 3.10-3-amd64...'
		linux	/boot/vmlinuz-3.10-3-amd64 root=UUID=3ab55964-09d1-4853-be38-661b5a476a14 ro console=tty0 quiet
		echo	'Caricamento ramdisk iniziale...'
		initrd	/boot/initrd.img-3.10-3-amd64
	}
	menuentry 'Debian GNU/Linux, con Linux 3.10-3-amd64 (modalità ripristino)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.10-3-amd64-recovery-3ab55964-09d1-4853-be38-661b5a476a14' {
		load_video
		insmod gzio
		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='hd0,msdos1'  3ab55964-09d1-4853-be38-661b5a476a14
		else
		  search --no-floppy --fs-uuid --set=root 3ab55964-09d1-4853-be38-661b5a476a14
		fi
		echo	'Caricamento Linux 3.10-3-amd64...'
		linux	/boot/vmlinuz-3.10-3-amd64 root=UUID=3ab55964-09d1-4853-be38-661b5a476a14 ro single console=tty0
		echo	'Caricamento ramdisk iniziale...'
		initrd	/boot/initrd.img-3.10-3-amd64
	}
	menuentry 'Debian GNU/Linux, con Linux 3.10-2-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.10-2-amd64-advanced-3ab55964-09d1-4853-be38-661b5a476a14' {
		load_video
		insmod gzio
		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='hd0,msdos1'  3ab55964-09d1-4853-be38-661b5a476a14
		else
		  search --no-floppy --fs-uuid --set=root 3ab55964-09d1-4853-be38-661b5a476a14
		fi
		echo	'Caricamento Linux 3.10-2-amd64...'
		linux	/boot/vmlinuz-3.10-2-amd64 root=UUID=3ab55964-09d1-4853-be38-661b5a476a14 ro console=tty0 quiet
		echo	'Caricamento ramdisk iniziale...'
		initrd	/boot/initrd.img-3.10-2-amd64
	}
	menuentry 'Debian GNU/Linux, con Linux 3.10-2-amd64 (modalità ripristino)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.10-2-amd64-recovery-3ab55964-09d1-4853-be38-661b5a476a14' {
		load_video
		insmod gzio
		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='hd0,msdos1'  3ab55964-09d1-4853-be38-661b5a476a14
		else
		  search --no-floppy --fs-uuid --set=root 3ab55964-09d1-4853-be38-661b5a476a14
		fi
		echo	'Caricamento Linux 3.10-2-amd64...'
		linux	/boot/vmlinuz-3.10-2-amd64 root=UUID=3ab55964-09d1-4853-be38-661b5a476a14 ro single console=tty0
		echo	'Caricamento ramdisk iniziale...'
		initrd	/boot/initrd.img-3.10-2-amd64
	}
	menuentry 'Debian GNU/Linux, con Linux 3.2.0-4-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.2.0-4-amd64-advanced-3ab55964-09d1-4853-be38-661b5a476a14' {
		load_video
		insmod gzio
		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='hd0,msdos1'  3ab55964-09d1-4853-be38-661b5a476a14
		else
		  search --no-floppy --fs-uuid --set=root 3ab55964-09d1-4853-be38-661b5a476a14
		fi
		echo	'Caricamento Linux 3.2.0-4-amd64...'
		linux	/boot/vmlinuz-3.2.0-4-amd64 root=UUID=3ab55964-09d1-4853-be38-661b5a476a14 ro console=tty0 quiet
		echo	'Caricamento ramdisk iniziale...'
		initrd	/boot/initrd.img-3.2.0-4-amd64
	}
	menuentry 'Debian GNU/Linux, con Linux 3.2.0-4-amd64 (modalità ripristino)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.2.0-4-amd64-recovery-3ab55964-09d1-4853-be38-661b5a476a14' {
		load_video
		insmod gzio
		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='hd0,msdos1'  3ab55964-09d1-4853-be38-661b5a476a14
		else
		  search --no-floppy --fs-uuid --set=root 3ab55964-09d1-4853-be38-661b5a476a14
		fi
		echo	'Caricamento Linux 3.2.0-4-amd64...'
		linux	/boot/vmlinuz-3.2.0-4-amd64 root=UUID=3ab55964-09d1-4853-be38-661b5a476a14 ro single console=tty0
		echo	'Caricamento ramdisk iniziale...'
		initrd	/boot/initrd.img-3.2.0-4-amd64
	}
}

### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###

### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/30_uefi-firmware ###
### END /etc/grub.d/30_uefi-firmware ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###

[-- Attachment #3: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 242 bytes --]

On 03.12.2013 11:31, Fabio Fantoni wrote:
> If you need more tests/informations tell me and I'll post them.
I've already asked you for exact kernel that I can download (and SHA512
to check it's the same one) and got only vague response


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

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] pvgrub2 is merged

[Fabio Fantoni]

Il 03/12/2013 11:33, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
> On 03.12.2013 11:31, Fabio Fantoni wrote:
>> If you need more tests/informations tell me and I'll post them.
> I've already asked you for exact kernel that I can download (and SHA512
> to check it's the same one) and got only vague response
>

Thanks for reply.
The actual kernel used is from this package:
http://packages.debian.org/sid/linux-image-3.11-2-amd64

I already checked kernel's files integrity with md5 (using the debian 
package's md5sums file and is correct).
Same domU with pygrub with manual and minimal grub.cfg configuration and 
it boots correctly, but with pvgrub2 and grub.cfg created automatically 
(see attachment of previous mail) it doesn't boot.

Thanks for any reply.

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] pvgrub2 is merged

[Fabio Fantoni]

Il 17/12/2013 14:32, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
> On 17.12.2013 14:11, Fabio Fantoni wrote:
>> Il 17/12/2013 12:03, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>>> On 17.12.2013 11:44, Fabio Fantoni wrote:
>>>> Il 09/12/2013 11:06, Fabio Fantoni ha scritto:
>>>>> Il 07/12/2013 11:06, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>>>>>> On 06.12.2013 16:22, Fabio Fantoni wrote:
>>>>>>> Il 06/12/2013 15:55, Vladimir 'φ-coder/phcoder' Serbinenko ha
>>>>>>> scritto:
>>>>>>>> On 06.12.2013 15:44, Fabio Fantoni wrote:
>>>>>>>>> Il 06/12/2013 12:32, Vladimir 'φ-coder/phcoder' Serbinenko ha
>>>>>>>>> scritto:
>>>>>>>>>> On 06.12.2013 12:11, Fabio Fantoni wrote:
>>>>>>>>>>> Il 03/12/2013 17:16, Fabio Fantoni ha scritto:
>>>>>>>>>>>> Il 03/12/2013 16:33, Vladimir 'φ-coder/phcoder' Serbinenko ha
>>>>>>>>>>>> scritto:
>>>>>>>>>>>>> On 03.12.2013 15:00, Fabio Fantoni wrote:
>>>>>>>>>>>>>> Il 03/12/2013 12:29, Vladimir 'φ-coder/phcoder' Serbinenko ha
>>>>>>>>>>>>>> scritto:
>>>>>>>>>>>>>>> On 03.12.2013 12:22, Fabio Fantoni wrote:
>>>>>>>>>>>>>>>> Il 03/12/2013 11:33, Vladimir 'φ-coder/phcoder'
>>>>>>>>>>>>>>>> Serbinenko ha
>>>>>>>>>>>>>>>> scritto:
>>>>>>>>>>>>>>>>> On 03.12.2013 11:31, Fabio Fantoni wrote:
>>>>>>>>>>>>>>>>>> If you need more tests/informations tell me and I'll post
>>>>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>> I've already asked you for exact kernel that I can
>>>>>>>>>>>>>>>>> download (and
>>>>>>>>>>>>>>>>> SHA512
>>>>>>>>>>>>>>>>> to check it's the same one) and got only vague response
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for reply.
>>>>>>>>>>>>>>>> The actual kernel used is from this package:
>>>>>>>>>>>>>>>> http://packages.debian.org/sid/linux-image-3.11-2-amd64
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I already checked kernel's files integrity with md5
>>>>>>>>>>>>>>>> (using the
>>>>>>>>>>>>>>>> debian
>>>>>>>>>>>>>>>> package's md5sums file and is correct).
>>>>>>>>>>>>>>>> Same domU with pygrub with manual and minimal grub.cfg
>>>>>>>>>>>>>>>> configuration and
>>>>>>>>>>>>>>>> it boots correctly, but with pvgrub2 and grub.cfg created
>>>>>>>>>>>>>>>> automatically
>>>>>>>>>>>>>>>> (see attachment of previous mail) it doesn't boot.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> With HEAD:
>>>>>>>>>>>>>>> phcoder@debian:12:21:06:~/compile/bt/x86_64-xen$ ar x
>>>>>>>>>>>>>>> ~/downloads/linux-image-3.11-2-amd64_3.11.8-1_amd64.deb
>>>>>>>>>>>>>>> phcoder@debian:12:23:29:~/compile/bt/x86_64-xen$ tar --xz -xf
>>>>>>>>>>>>>>> data.tar.xz
>>>>>>>>>>>>>>> phcoder@debian:12:28:36:~/compile/bt/x86_64-xen$ sha512sum
>>>>>>>>>>>>>>> boot/vmlinuz-3.11-2-amd64
>>>>>>>>>>>>>>> 002bc39cfc0191614ec380a44993d20691e1dc8791a8c6f3a163777ef6fb733243d3da48760b2eedfc3ab9b8bd7b8fe2d473cdd3a91eb3d855eb4f3db9f7b6df
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         boot/vmlinuz-3.11-2-amd64
>>>>>>>>>>>>>>> phcoder@debian:12:23:38:~/compile/bt/x86_64-xen$
>>>>>>>>>>>>>>> ./grub-mkstandalone
>>>>>>>>>>>>>>> --grub-mkimage=./grub-mkimage -o grub.xen -O x86_64-xen -d
>>>>>>>>>>>>>>> grub-core/
>>>>>>>>>>>>>>> boot/vmlinuz-3.11-2-amd64
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                                     GNU GRUB version 2.00
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>           Minimal BASH-like line editing is supported. For the
>>>>>>>>>>>>>>> first
>>>>>>>>>>>>>>> word, TAB
>>>>>>>>>>>>>>>           lists possible command completions. Anywhere else
>>>>>>>>>>>>>>> TAB lists
>>>>>>>>>>>>>>> possible
>>>>>>>>>>>>>>>           device or file completions.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> grub> insmod xzio
>>>>>>>>>>>>>>> grub> linux /boot/vmlinuz-3.11-2-amd64
>>>>>>>>>>>>>>> grub> boot
>>>>>>>>>>>>>>> [    0.000000] Initializing cgroup subsys cpuset
>>>>>>>>>>>>>>> [    0.000000] Initializing cgroup subsys cpu
>>>>>>>>>>>>>>> [    0.000000] Initializing cgroup subsys cpuacct
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've uploaded my grub.xen to
>>>>>>>>>>>>>>> http://download-mirror.savannah.gnu.org/releases/grub/phcoder/grub.xen.xz
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for any reply.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for your reply.
>>>>>>>>>>>>>> I tried with your build and gave me:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Caricamento Linux 3.11-2-amd64...
>>>>>>>>>>>>>> errore: not xen image.
>>>>>>>>>>>>>> Caricamento ramdisk iniziale...
>>>>>>>>>>>>>> errore: ? necessario caricare il kernel prima.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I also rebuilt pvgrub2 from clean directory, full logs of
>>>>>>>>>>>>>> configure,
>>>>>>>>>>>>>> make and xl create on attachment.
>>>>>>>>>>>>>> Also in this case domU destroys on kernel and initrd loading.
>>>>>>>>>>>>>> I not understand what are my errors and/or forgetfulness.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> $ sha512sum /boot/vmlinuz-3.11-2-amd64
>>>>>>>>>>>> sha512sum /mnt/tmp/boot/vmlinuz-3.11-2-amd64
>>>>>>>>>>>> 002bc39cfc0191614ec380a44993d20691e1dc8791a8c6f3a163777ef6fb733243d3da48760b2eedfc3ab9b8bd7b8fe2d473cdd3a91eb3d855eb4f3db9f7b6df
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> /mnt/tmp/boot/vmlinuz-3.11-2-amd64
>>>>>>>>>>>>
>>>>>>>>>>>>> Did you try with kernel embed in GRUB?
>>>>>>>>>>>> I tried with ./grub-mkstandalone
>>>>>>>>>>>> --grub-mkimage=./grub-mkimage -o
>>>>>>>>>>>> pvgrub2.xen -O x86_64-xen -d grub-core/
>>>>>>>>>>>> /mnt/tmp/boot/vmlinuz-3.11-2-amd64
>>>>>>>>>>>> Probably I did something wrong or missed about this test.
>>>>>>>>>>>> On xl create it arrives to grub console, so I tried to set root
>>>>>>>>>>>> and
>>>>>>>>>>>> include the grub.cfg of domU but gave nothing, only new console
>>>>>>>>>>>> line.
>>>>>>>>>>>> Can you give me more details to do a complete and correct test?
>>>>>>>>>>>>
>>>>>>>>>>>>> Did you try root/linux/initrd/boot sequence manually?
>>>>>>>>>>>> I presume you mean to do insmod, set root and all other command
>>>>>>>>>>>> manually without using grub.cfg, could you confirm that or give
>>>>>>>>>>>> me an
>>>>>>>>>>>> exact howto?
>>>>>>>>>>>>
>>>>>>>>>>> I tried manually sequence instead of do it with grub.cfg (I
>>>>>>>>>>> hope to
>>>>>>>>>>> did
>>>>>>>>>>> it correctly):
>>>>>>>>>>>
>>>>>>>>>>> ...
>>>>>>>>>>> grub> insmod part_msdos
>>>>>>>>>>> grub> insmod xzio
>>>>>>>>>>> grub> insmod ext2
>>>>>>>>>>> grub> insmod gzio
>>>>>>>>>>> grub> set root=(xen/xvda,msdos1)
>>>>>>>>>>> grub> linux /boot/vmlinuz-3.11-2-amd64
>>>>>>>>>>> root=UUID=3ab55964-09d1-4853-be38-661b56a14 ro console=tty0 debug
>>>>>>>>>>> grub> initrd /boot/initrd.img-3.11-2-amd64
>>>>>>>>>>> grub> boot
>>>>>>>>>>> xc: debug: hypercall buffer: total allocations:237 total
>>>>>>>>>>> releases:237
>>>>>>>>>>> xc: debug: hypercall buffer: current allocations:0 maximum
>>>>>>>>>>> allocations:4
>>>>>>>>>>> xc: debug: hypercall buffer: cache current size:4
>>>>>>>>>>> xc: debug: hypercall buffer: cache hits:226 misses:4 toobig:7
>>>>>>>>>>>
>>>>>>>>>>> unfortunately the result is the same :(
>>>>>>>>>>>
>>>>>>>>>> Hm, that is different from previous. Previously you spoke about
>>>>>>>>>> "not a
>>>>>>>>>> xen image" message. I'd remove console=tty0 and also try without
>>>>>>>>>> initrd.
>>>>>>>>> Without console and initrd:
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>> grub> insmod part_msdos
>>>>>>>>> grub> insmod xzio
>>>>>>>>> grub> insmod ext2
>>>>>>>>> grub> insmod gzio
>>>>>>>>> grub> set root=(xen/xvda,msdos1)
>>>>>>>>> grub> linux /boot/vmlinuz-3.11-2-amd64
>>>>>>>>> root=UUID=3ab55964-09d1-4853-be38-661b5a476a14 ro debug
>>>>>>>>> grub> boot
>>>>>>>>> xc: debug: hypercall buffer: total allocations:247 total
>>>>>>>>> releases:247
>>>>>>>>> xc: debug: hypercall buffer: current allocations:0 maximum
>>>>>>>>> allocations:4
>>>>>>>>> xc: debug: hypercall buffer: cache current size:4
>>>>>>>>> xc: debug: hypercall buffer: cache hits:236 misses:4 toobig:7
>>>>>>>>>
>>>>>>>> Which xen version is it? I tried only with 4.3
>>>>>>>>
>>>>>>> I always use xen-unstable (4.4) for pvgrub2 tests.
>>>>>>> My actual build is on upstream commit
>>>>>>> 4b07b3cbf29f66da6090d52e75b5fdae592c6441
>>>>>>> Could you check with xen-unstable? (now on freeze and near to first
>>>>>>> 4.4 rc)
>>>>>>>
>>>>>> Can't tell I get far on this one. I installed xen from git but when I
>>>>>> attempt to execute any command with xl it just hangs.
>>>>> Did you try also -vvv?
>>>>> If it show any debug messages please post them and add also xen-devel
>>>>> to cc in that case.
>>>>> Can you also post details about your dom0?
>>>>>
>>>>>> Is there anything in your xl dmesg
>>>>>> Meanwhile I implemented vfb/vkbd in phcoder/vfb branch.
>>>>> I tried vfb branch:
>>>>> git log
>>>>> commit acc3ea93f59727bdac47b1fef4eef24380161847
>>>>> Author: Vladimir Serbinenko <phcoder@gmail.com>
>>>>> Date:   Sat Dec 7 12:46:59 2013 +0100
>>>>>
>>>>>       Fix compilation error
>>>>>
>>>>> I installed missed unifont package and compiled grub.
>>>>>
>>>>> xl -vvv create -c does not show any grub line and crashes.
>>>>> I attached xl -vvv create -c output and xl dmesg with calltrace inside.
>>>>>
>>>>> If you need more informations and/or tests tell me and I'll post them.
>>>>>
>>>>> Thanks for any reply.
>>>>>
>>>> I've seen 2 new commits about xen on master, than I tried to update and
>>>> rebuild pvgrub2.
>>>>
>>> With Xen 4.3 everything seems to work. However if I install Xen 4.4 from
>>> git. All I get:
>>> phcoder@debian:11:58:30:~/grub2$ sudo /usr/local/sbin/xl create -f
>>> grub.dom -vv
>>> Swipe your right index finger across the fingerprint reader
>>> xc: error: Could not obtain handle on privileged command interface (2 =
>>> No such file or directory): Internal error
>>> libxl: error: libxl.c:92:libxl_ctx_alloc: cannot open libxc handle: No
>>> such file or directory
>>> cannot init xl context
>>> phcoder@debian:11:58:36:~/grub2$ sudo mount -t xenfs xenfs /proc/xen/
>>> phcoder@debian:11:58:46:~/grub2$ sudo /usr/local/sbin/xl create -f
>>> grub.dom -vv
>>> option `v' not supported.
>>> option `v' not supported.
>>> Parsing config from grub.dom
>>> <just sits there>
>> -v must be before the subcommand, for example "xl -vvv create
>> /etc/xen/sid.cfg".
>> xenfs should be automatically mounted by xencommons init script, make
>> sure that it is running before executing xl commands, it is needed to
>> load necessary kernel modules (if they are not already loaded), xenfs,
>> xenstore and xenconsoled.
> Yes, gone through that already, see my other mail and recent commits.
> Your issue should be fixed.

Thanks.
Now there is another error, probably introduced by xenfb support:

xl -vvv create -c /etc/xen/sid.cfg
...
Welcome to GRUB!
error: file `/boot/grub/x86_64-xen/gfxterm.mod' not found.
error: file `/boot/grub/locale/it.gmo' not found.
[    0.000000] PAGETABLE BUG #02!
[    1.298688] i8042: No controller found
[    1.368244] /build/linux-4VBEpo/linux-3.11.8/drivers/rtc/hctosys.c: 
unable to open rtc device (rtc0)
xc: debug: hypercall buffer: total allocations:237 total releases:237
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
xc: debug: hypercall buffer: cache current size:4
xc: debug: hypercall buffer: cache hits:226 misses:4 toobig:7

xl dmesg
...
(d17) mapping kernel into physical memory
(d17) about to get started...
(XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp 
1000000000000000) for mfn 2171b8 (pfn 3fbe8)
(XEN) mm.c:2995:d17 Error while pinning mfn 2171b8
(XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp 
1000000000000000) for mfn 2171b8 (pfn 3fbe8)
(XEN) mm.c:906:d17 Attempt to create linear p.t. with write perms
(XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp 
1000000000000000) for mfn 2171ba (pfn 3fbe6)
(XEN) mm.c:2995:d17 Error while pinning mfn 2171ba
(XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp 
1000000000000000) for mfn 2171bb (pfn 3fbe5)
(XEN) mm.c:2995:d17 Error while pinning mfn 2171bb
(XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp 
2000000000000000) for mfn 2171b9 (pfn 3fbe7)
(XEN) mm.c:948:d17 Attempt to create linear p.t. with write perms
(XEN) mm.c:1379:d17 Failure in alloc_l3_table: entry 511
(XEN) mm.c:2099:d17 Error while validating mfn 23df00 (pfn 19a0) for 
type 3000000000000000: caf=8000000000000003 taf=3000000000000001
(XEN) mm.c:972:d17 Attempt to create linear p.t. with write perms
(XEN) mm.c:1438:d17 Failure in alloc_l4_table: entry 511
(XEN) mm.c:2099:d17 Error while validating mfn 2b5d85 (pfn 241b) for 
type 4000000000000000: caf=8000000000000003 taf=4000000000000001
(XEN) mm.c:2995:d17 Error while pinning mfn 2b5d85
(XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp 
2000000000000000) for mfn 2171b9 (pfn 3fbe7)
(XEN) mm.c:948:d17 Attempt to create linear p.t. with write perms
(XEN) mm.c:1379:d17 Failure in alloc_l3_table: entry 511
(XEN) mm.c:2099:d17 Error while validating mfn 23df00 (pfn 19a0) for 
type 3000000000000000: caf=8000000000000003 taf=3000000000000001
(XEN) mm.c:972:d17 Attempt to create linear p.t. with write perms
(XEN) mm.c:1438:d17 Failure in alloc_l4_table: entry 511
(XEN) mm.c:2099:d17 Error while validating mfn 2b5d85 (pfn 241b) for 
type 4000000000000000: caf=8000000000000003 taf=4000000000000001
(XEN) mm.c:3122:d17 Error while installing new mfn 2b5d85
(XEN) traps.c:291:d17 Guest switching to user mode with no user page tables
(XEN) traps.c:320:d17 Fatal error
(XEN) domain_crash called from traps.c:321
(XEN) Domain 17 (vcpu#1) crashed on cpu#3:
(XEN) ----[ Xen-4.4-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e033:[<ffffffff810012ed>]
(XEN) RFLAGS: 0000000000000286   EM: 1   CONTEXT: pv guest
(XEN) rax: 0000000000000017   rbx: 0000000000000000   rcx: ffffffff810012ed
(XEN) rdx: 0000000000000000   rsi: 0000000000000000   rdi: 0000000000000000
(XEN) rbp: 0000000000000000   rsp: ffff88003e1f9fb8   r8: 0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000286
(XEN) cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 00000002b5d86000   cr2: 00007fffb46b9e19
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=ffff88003e1f9fb8:
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    00007f0b1f431500 0000000000000033 0000000000000200 00007fffb46b9ca0
(XEN)    000000000000002b ffff88003e004958 ffff88003e004958 0000000000000080
(XEN)    ffff88003e1fa080 ffffffff00000006 d5dc82dde2520000 0000000200000001
(XEN)    0000000400000003 ffffffff00000005 0501e668a45aed37 d3a51001f8186504
(XEN)    3d41962be0a726d3 fbee8906bde13da3 9e907ea339feb0c4 270b40af55a0f4b8
(XEN)    264b0560a7e2c9dc 0a3145802804d2e1 faf4b4eca4180ba6 01957dd1d4131d2e
(XEN)    a18b79fe805a7821 bf0afc62c71eddcb 630fca5df80eb04b 845a16e1648fdd51
(XEN)    c588c03d2edcf807 9cf4717d19322687 510724530fcbf04b d8f1199bd10015fe
(XEN)    5272422fa11fb05c f2447667cb9fa47a 37c90f94df9206f9 43eca9d987b7240b
(XEN)    def99e5d7d577367 9b0d95f77cdf3672 4ef9836df37ccdf6 5a79437e62989ecf
(XEN)    3772f347b726713a 27fc0fe3f633e7e4 b975e7e927ca3183 a3eb9b3cea9ebb28
(XEN)    76b3d73a083d2d34 3e7c801b21bd2ad3 4874b5adac7be5fe 327fb4145bc5967e
(XEN)    ce5fd2670ed6fe93 6671781eb982fcaf 865c0f25bbc6796d da793d360234fc4d
(XEN)    fe53c86f9465bf2c cf6fc89cfcb9d3e9 a05d1a75741d9703 0670c66fb870cfae
(XEN)    fc725a3f8a7f7448 759e29fdd16ebe29 3bea153e12f5193a 8a2727cf5451fa53
(XEN)    740afaa283c9cbea e8059556115ea89f 08b76c91fd5bd13f 21d63b340cca2982
(XEN)    9ae74e68a733e980 ace9f7ded7134e44 6c7e4a6a743f4959 fbe3ca9cd6501e75
(XEN)    93b91393e99784e0 dd54b7bd06b739b9 2aefee3afab953f4 5a9c30b6dd98fadc
(XEN)    390f275e52fa88ef 18115b1dfc41622e 29960fc50c03101e 04a4d7f6a9fd0795

>> In that case it is good to use also -c after create to open the xl
>> console strightaway and see what pvgrub2 is doing, for example "xl -vvv
>> create -c /etc/xen/sid.cfg".
>>
>>>> git log
>>>> commit a82010503e3098930a56110826c4ffe6e1609726
>>>> Author: Vladimir Serbinenko <phcoder@gmail.com>
>>>> Date:   Tue Dec 17 01:18:09 2013 +0100
>>>>
>>>>           Update exclude.pot and mark few strings for translation.
>>>>
>>>>
>>>> My problem on kernel boot with Sid and Wheezy domUs persist.
>>>>
>>>> Thanks for any reply.
>>>>
>>
>


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 6168 bytes --]


> Thanks.
> Now there is another error, probably introduced by xenfb support:
> 
doesn't look like related to xenfb. Is it 64-bit or PAE guest?
> xl -vvv create -c /etc/xen/sid.cfg
> ...
> Welcome to GRUB!
> error: file `/boot/grub/x86_64-xen/gfxterm.mod' not found.
> error: file `/boot/grub/locale/it.gmo' not found.
> [    0.000000] PAGETABLE BUG #02!
> [    1.298688] i8042: No controller found
> [    1.368244] /build/linux-4VBEpo/linux-3.11.8/drivers/rtc/hctosys.c:
> unable to open rtc device (rtc0)
> xc: debug: hypercall buffer: total allocations:237 total releases:237
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
> xc: debug: hypercall buffer: cache current size:4
> xc: debug: hypercall buffer: cache hits:226 misses:4 toobig:7
> 
> xl dmesg
> ...
> (d17) mapping kernel into physical memory
> (d17) about to get started...
> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
> 1000000000000000) for mfn 2171b8 (pfn 3fbe8)
> (XEN) mm.c:2995:d17 Error while pinning mfn 2171b8
> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
> 1000000000000000) for mfn 2171b8 (pfn 3fbe8)
> (XEN) mm.c:906:d17 Attempt to create linear p.t. with write perms
> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
> 1000000000000000) for mfn 2171ba (pfn 3fbe6)
> (XEN) mm.c:2995:d17 Error while pinning mfn 2171ba
> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
> 1000000000000000) for mfn 2171bb (pfn 3fbe5)
> (XEN) mm.c:2995:d17 Error while pinning mfn 2171bb
> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
> 2000000000000000) for mfn 2171b9 (pfn 3fbe7)
> (XEN) mm.c:948:d17 Attempt to create linear p.t. with write perms
> (XEN) mm.c:1379:d17 Failure in alloc_l3_table: entry 511
> (XEN) mm.c:2099:d17 Error while validating mfn 23df00 (pfn 19a0) for
> type 3000000000000000: caf=8000000000000003 taf=3000000000000001
> (XEN) mm.c:972:d17 Attempt to create linear p.t. with write perms
> (XEN) mm.c:1438:d17 Failure in alloc_l4_table: entry 511
> (XEN) mm.c:2099:d17 Error while validating mfn 2b5d85 (pfn 241b) for
> type 4000000000000000: caf=8000000000000003 taf=4000000000000001
> (XEN) mm.c:2995:d17 Error while pinning mfn 2b5d85
> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
> 2000000000000000) for mfn 2171b9 (pfn 3fbe7)
> (XEN) mm.c:948:d17 Attempt to create linear p.t. with write perms
> (XEN) mm.c:1379:d17 Failure in alloc_l3_table: entry 511
> (XEN) mm.c:2099:d17 Error while validating mfn 23df00 (pfn 19a0) for
> type 3000000000000000: caf=8000000000000003 taf=3000000000000001
> (XEN) mm.c:972:d17 Attempt to create linear p.t. with write perms
> (XEN) mm.c:1438:d17 Failure in alloc_l4_table: entry 511
> (XEN) mm.c:2099:d17 Error while validating mfn 2b5d85 (pfn 241b) for
> type 4000000000000000: caf=8000000000000003 taf=4000000000000001
> (XEN) mm.c:3122:d17 Error while installing new mfn 2b5d85
> (XEN) traps.c:291:d17 Guest switching to user mode with no user page tables
> (XEN) traps.c:320:d17 Fatal error
> (XEN) domain_crash called from traps.c:321
> (XEN) Domain 17 (vcpu#1) crashed on cpu#3:
> (XEN) ----[ Xen-4.4-unstable  x86_64  debug=y  Not tainted ]----
> (XEN) CPU:    3
> (XEN) RIP:    e033:[<ffffffff810012ed>]
> (XEN) RFLAGS: 0000000000000286   EM: 1   CONTEXT: pv guest
> (XEN) rax: 0000000000000017   rbx: 0000000000000000   rcx: ffffffff810012ed
> (XEN) rdx: 0000000000000000   rsi: 0000000000000000   rdi: 0000000000000000
> (XEN) rbp: 0000000000000000   rsp: ffff88003e1f9fb8   r8: 0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000286
> (XEN) cr0: 000000008005003b   cr4: 00000000000026f0
> (XEN) cr3: 00000002b5d86000   cr2: 00007fffb46b9e19
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
> (XEN) Guest stack trace from rsp=ffff88003e1f9fb8:
> (XEN)    0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN)    00007f0b1f431500 0000000000000033 0000000000000200
> 00007fffb46b9ca0
> (XEN)    000000000000002b ffff88003e004958 ffff88003e004958
> 0000000000000080
> (XEN)    ffff88003e1fa080 ffffffff00000006 d5dc82dde2520000
> 0000000200000001
> (XEN)    0000000400000003 ffffffff00000005 0501e668a45aed37
> d3a51001f8186504
> (XEN)    3d41962be0a726d3 fbee8906bde13da3 9e907ea339feb0c4
> 270b40af55a0f4b8
> (XEN)    264b0560a7e2c9dc 0a3145802804d2e1 faf4b4eca4180ba6
> 01957dd1d4131d2e
> (XEN)    a18b79fe805a7821 bf0afc62c71eddcb 630fca5df80eb04b
> 845a16e1648fdd51
> (XEN)    c588c03d2edcf807 9cf4717d19322687 510724530fcbf04b
> d8f1199bd10015fe
> (XEN)    5272422fa11fb05c f2447667cb9fa47a 37c90f94df9206f9
> 43eca9d987b7240b
> (XEN)    def99e5d7d577367 9b0d95f77cdf3672 4ef9836df37ccdf6
> 5a79437e62989ecf
> (XEN)    3772f347b726713a 27fc0fe3f633e7e4 b975e7e927ca3183
> a3eb9b3cea9ebb28
> (XEN)    76b3d73a083d2d34 3e7c801b21bd2ad3 4874b5adac7be5fe
> 327fb4145bc5967e
> (XEN)    ce5fd2670ed6fe93 6671781eb982fcaf 865c0f25bbc6796d
> da793d360234fc4d
> (XEN)    fe53c86f9465bf2c cf6fc89cfcb9d3e9 a05d1a75741d9703
> 0670c66fb870cfae
> (XEN)    fc725a3f8a7f7448 759e29fdd16ebe29 3bea153e12f5193a
> 8a2727cf5451fa53
> (XEN)    740afaa283c9cbea e8059556115ea89f 08b76c91fd5bd13f
> 21d63b340cca2982
> (XEN)    9ae74e68a733e980 ace9f7ded7134e44 6c7e4a6a743f4959
> fbe3ca9cd6501e75
> (XEN)    93b91393e99784e0 dd54b7bd06b739b9 2aefee3afab953f4
> 5a9c30b6dd98fadc
> (XEN)    390f275e52fa88ef 18115b1dfc41622e 29960fc50c03101e
> 04a4d7f6a9fd0795
> 
>>> In that case it is good to use also -c after create to open the xl
>>> console strightaway and see what pvgrub2 is doing, for example "xl -vvv
>>> create -c /etc/xen/sid.cfg".
>>>
>>>>> git log
>>>>> commit a82010503e3098930a56110826c4ffe6e1609726
>>>>> Author: Vladimir Serbinenko <phcoder@gmail.com>
>>>>> Date:   Tue Dec 17 01:18:09 2013 +0100
>>>>>
>>>>>           Update exclude.pot and mark few strings for translation.
>>>>>
>>>>>
>>>>> My problem on kernel boot with Sid and Wheezy domUs persist.
>>>>>
>>>>> Thanks for any reply.
>>>>>
>>>
>>
> 
> 



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

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] pvgrub2 is merged

[Fabio Fantoni]

Il 17/12/2013 15:08, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>> Thanks.
>> Now there is another error, probably introduced by xenfb support:
>>
> doesn't look like related to xenfb. Is it 64-bit or PAE guest?

64 bit

>> xl -vvv create -c /etc/xen/sid.cfg
>> ...
>> Welcome to GRUB!
>> error: file `/boot/grub/x86_64-xen/gfxterm.mod' not found.
>> error: file `/boot/grub/locale/it.gmo' not found.
>> [    0.000000] PAGETABLE BUG #02!
>> [    1.298688] i8042: No controller found
>> [    1.368244] /build/linux-4VBEpo/linux-3.11.8/drivers/rtc/hctosys.c:
>> unable to open rtc device (rtc0)
>> xc: debug: hypercall buffer: total allocations:237 total releases:237
>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
>> xc: debug: hypercall buffer: cache current size:4
>> xc: debug: hypercall buffer: cache hits:226 misses:4 toobig:7
>>
>> xl dmesg
>> ...
>> (d17) mapping kernel into physical memory
>> (d17) about to get started...
>> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
>> 1000000000000000) for mfn 2171b8 (pfn 3fbe8)
>> (XEN) mm.c:2995:d17 Error while pinning mfn 2171b8
>> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
>> 1000000000000000) for mfn 2171b8 (pfn 3fbe8)
>> (XEN) mm.c:906:d17 Attempt to create linear p.t. with write perms
>> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
>> 1000000000000000) for mfn 2171ba (pfn 3fbe6)
>> (XEN) mm.c:2995:d17 Error while pinning mfn 2171ba
>> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
>> 1000000000000000) for mfn 2171bb (pfn 3fbe5)
>> (XEN) mm.c:2995:d17 Error while pinning mfn 2171bb
>> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
>> 2000000000000000) for mfn 2171b9 (pfn 3fbe7)
>> (XEN) mm.c:948:d17 Attempt to create linear p.t. with write perms
>> (XEN) mm.c:1379:d17 Failure in alloc_l3_table: entry 511
>> (XEN) mm.c:2099:d17 Error while validating mfn 23df00 (pfn 19a0) for
>> type 3000000000000000: caf=8000000000000003 taf=3000000000000001
>> (XEN) mm.c:972:d17 Attempt to create linear p.t. with write perms
>> (XEN) mm.c:1438:d17 Failure in alloc_l4_table: entry 511
>> (XEN) mm.c:2099:d17 Error while validating mfn 2b5d85 (pfn 241b) for
>> type 4000000000000000: caf=8000000000000003 taf=4000000000000001
>> (XEN) mm.c:2995:d17 Error while pinning mfn 2b5d85
>> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
>> 2000000000000000) for mfn 2171b9 (pfn 3fbe7)
>> (XEN) mm.c:948:d17 Attempt to create linear p.t. with write perms
>> (XEN) mm.c:1379:d17 Failure in alloc_l3_table: entry 511
>> (XEN) mm.c:2099:d17 Error while validating mfn 23df00 (pfn 19a0) for
>> type 3000000000000000: caf=8000000000000003 taf=3000000000000001
>> (XEN) mm.c:972:d17 Attempt to create linear p.t. with write perms
>> (XEN) mm.c:1438:d17 Failure in alloc_l4_table: entry 511
>> (XEN) mm.c:2099:d17 Error while validating mfn 2b5d85 (pfn 241b) for
>> type 4000000000000000: caf=8000000000000003 taf=4000000000000001
>> (XEN) mm.c:3122:d17 Error while installing new mfn 2b5d85
>> (XEN) traps.c:291:d17 Guest switching to user mode with no user page tables
>> (XEN) traps.c:320:d17 Fatal error
>> (XEN) domain_crash called from traps.c:321
>> (XEN) Domain 17 (vcpu#1) crashed on cpu#3:
>> (XEN) ----[ Xen-4.4-unstable  x86_64  debug=y  Not tainted ]----
>> (XEN) CPU:    3
>> (XEN) RIP:    e033:[<ffffffff810012ed>]
>> (XEN) RFLAGS: 0000000000000286   EM: 1   CONTEXT: pv guest
>> (XEN) rax: 0000000000000017   rbx: 0000000000000000   rcx: ffffffff810012ed
>> (XEN) rdx: 0000000000000000   rsi: 0000000000000000   rdi: 0000000000000000
>> (XEN) rbp: 0000000000000000   rsp: ffff88003e1f9fb8   r8: 0000000000000000
>> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000286
>> (XEN) cr0: 000000008005003b   cr4: 00000000000026f0
>> (XEN) cr3: 00000002b5d86000   cr2: 00007fffb46b9e19
>> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
>> (XEN) Guest stack trace from rsp=ffff88003e1f9fb8:
>> (XEN)    0000000000000000 0000000000000000 0000000000000000
>> 0000000000000000
>> (XEN)    00007f0b1f431500 0000000000000033 0000000000000200
>> 00007fffb46b9ca0
>> (XEN)    000000000000002b ffff88003e004958 ffff88003e004958
>> 0000000000000080
>> (XEN)    ffff88003e1fa080 ffffffff00000006 d5dc82dde2520000
>> 0000000200000001
>> (XEN)    0000000400000003 ffffffff00000005 0501e668a45aed37
>> d3a51001f8186504
>> (XEN)    3d41962be0a726d3 fbee8906bde13da3 9e907ea339feb0c4
>> 270b40af55a0f4b8
>> (XEN)    264b0560a7e2c9dc 0a3145802804d2e1 faf4b4eca4180ba6
>> 01957dd1d4131d2e
>> (XEN)    a18b79fe805a7821 bf0afc62c71eddcb 630fca5df80eb04b
>> 845a16e1648fdd51
>> (XEN)    c588c03d2edcf807 9cf4717d19322687 510724530fcbf04b
>> d8f1199bd10015fe
>> (XEN)    5272422fa11fb05c f2447667cb9fa47a 37c90f94df9206f9
>> 43eca9d987b7240b
>> (XEN)    def99e5d7d577367 9b0d95f77cdf3672 4ef9836df37ccdf6
>> 5a79437e62989ecf
>> (XEN)    3772f347b726713a 27fc0fe3f633e7e4 b975e7e927ca3183
>> a3eb9b3cea9ebb28
>> (XEN)    76b3d73a083d2d34 3e7c801b21bd2ad3 4874b5adac7be5fe
>> 327fb4145bc5967e
>> (XEN)    ce5fd2670ed6fe93 6671781eb982fcaf 865c0f25bbc6796d
>> da793d360234fc4d
>> (XEN)    fe53c86f9465bf2c cf6fc89cfcb9d3e9 a05d1a75741d9703
>> 0670c66fb870cfae
>> (XEN)    fc725a3f8a7f7448 759e29fdd16ebe29 3bea153e12f5193a
>> 8a2727cf5451fa53
>> (XEN)    740afaa283c9cbea e8059556115ea89f 08b76c91fd5bd13f
>> 21d63b340cca2982
>> (XEN)    9ae74e68a733e980 ace9f7ded7134e44 6c7e4a6a743f4959
>> fbe3ca9cd6501e75
>> (XEN)    93b91393e99784e0 dd54b7bd06b739b9 2aefee3afab953f4
>> 5a9c30b6dd98fadc
>> (XEN)    390f275e52fa88ef 18115b1dfc41622e 29960fc50c03101e
>> 04a4d7f6a9fd0795
>>
>>>> In that case it is good to use also -c after create to open the xl
>>>> console strightaway and see what pvgrub2 is doing, for example "xl -vvv
>>>> create -c /etc/xen/sid.cfg".
>>>>
>>>>>> git log
>>>>>> commit a82010503e3098930a56110826c4ffe6e1609726
>>>>>> Author: Vladimir Serbinenko <phcoder@gmail.com>
>>>>>> Date:   Tue Dec 17 01:18:09 2013 +0100
>>>>>>
>>>>>>            Update exclude.pot and mark few strings for translation.
>>>>>>
>>>>>>
>>>>>> My problem on kernel boot with Sid and Wheezy domUs persist.
>>>>>>
>>>>>> Thanks for any reply.
>>>>>>
>>
>


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] pvgrub2 is merged

[Fabio Fantoni]

Il 17/12/2013 15:10, Fabio Fantoni ha scritto:
> Il 17/12/2013 15:08, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>>> Thanks.
>>> Now there is another error, probably introduced by xenfb support:
>>>
>> doesn't look like related to xenfb. Is it 64-bit or PAE guest?
>
> 64 bit

I did "git reset --hard" to commit "Remove grub_bios_interrupt on 
coreboot." and then I applied only 
"grub-core/lib/x86_64/xen/relocator.S: Fix hypercall ABI violation." commit.
Now the Sid domU boot correctly, therefore the regression is caused by 
"xenfb" or "xen grants to v1" commit, should I find the exact commit 
that causes that problem or these informations are enough for you?

Thanks for any reply.


>
>>> xl -vvv create -c /etc/xen/sid.cfg
>>> ...
>>> Welcome to GRUB!
>>> error: file `/boot/grub/x86_64-xen/gfxterm.mod' not found.
>>> error: file `/boot/grub/locale/it.gmo' not found.
>>> [    0.000000] PAGETABLE BUG #02!
>>> [    1.298688] i8042: No controller found
>>> [    1.368244] /build/linux-4VBEpo/linux-3.11.8/drivers/rtc/hctosys.c:
>>> unable to open rtc device (rtc0)
>>> xc: debug: hypercall buffer: total allocations:237 total releases:237
>>> xc: debug: hypercall buffer: current allocations:0 maximum 
>>> allocations:4
>>> xc: debug: hypercall buffer: cache current size:4
>>> xc: debug: hypercall buffer: cache hits:226 misses:4 toobig:7
>>>
>>> xl dmesg
>>> ...
>>> (d17) mapping kernel into physical memory
>>> (d17) about to get started...
>>> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
>>> 1000000000000000) for mfn 2171b8 (pfn 3fbe8)
>>> (XEN) mm.c:2995:d17 Error while pinning mfn 2171b8
>>> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
>>> 1000000000000000) for mfn 2171b8 (pfn 3fbe8)
>>> (XEN) mm.c:906:d17 Attempt to create linear p.t. with write perms
>>> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
>>> 1000000000000000) for mfn 2171ba (pfn 3fbe6)
>>> (XEN) mm.c:2995:d17 Error while pinning mfn 2171ba
>>> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
>>> 1000000000000000) for mfn 2171bb (pfn 3fbe5)
>>> (XEN) mm.c:2995:d17 Error while pinning mfn 2171bb
>>> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
>>> 2000000000000000) for mfn 2171b9 (pfn 3fbe7)
>>> (XEN) mm.c:948:d17 Attempt to create linear p.t. with write perms
>>> (XEN) mm.c:1379:d17 Failure in alloc_l3_table: entry 511
>>> (XEN) mm.c:2099:d17 Error while validating mfn 23df00 (pfn 19a0) for
>>> type 3000000000000000: caf=8000000000000003 taf=3000000000000001
>>> (XEN) mm.c:972:d17 Attempt to create linear p.t. with write perms
>>> (XEN) mm.c:1438:d17 Failure in alloc_l4_table: entry 511
>>> (XEN) mm.c:2099:d17 Error while validating mfn 2b5d85 (pfn 241b) for
>>> type 4000000000000000: caf=8000000000000003 taf=4000000000000001
>>> (XEN) mm.c:2995:d17 Error while pinning mfn 2b5d85
>>> (XEN) mm.c:2352:d17 Bad type (saw 7400000000000001 != exp
>>> 2000000000000000) for mfn 2171b9 (pfn 3fbe7)
>>> (XEN) mm.c:948:d17 Attempt to create linear p.t. with write perms
>>> (XEN) mm.c:1379:d17 Failure in alloc_l3_table: entry 511
>>> (XEN) mm.c:2099:d17 Error while validating mfn 23df00 (pfn 19a0) for
>>> type 3000000000000000: caf=8000000000000003 taf=3000000000000001
>>> (XEN) mm.c:972:d17 Attempt to create linear p.t. with write perms
>>> (XEN) mm.c:1438:d17 Failure in alloc_l4_table: entry 511
>>> (XEN) mm.c:2099:d17 Error while validating mfn 2b5d85 (pfn 241b) for
>>> type 4000000000000000: caf=8000000000000003 taf=4000000000000001
>>> (XEN) mm.c:3122:d17 Error while installing new mfn 2b5d85
>>> (XEN) traps.c:291:d17 Guest switching to user mode with no user page 
>>> tables
>>> (XEN) traps.c:320:d17 Fatal error
>>> (XEN) domain_crash called from traps.c:321
>>> (XEN) Domain 17 (vcpu#1) crashed on cpu#3:
>>> (XEN) ----[ Xen-4.4-unstable  x86_64  debug=y  Not tainted ]----
>>> (XEN) CPU:    3
>>> (XEN) RIP:    e033:[<ffffffff810012ed>]
>>> (XEN) RFLAGS: 0000000000000286   EM: 1   CONTEXT: pv guest
>>> (XEN) rax: 0000000000000017   rbx: 0000000000000000   rcx: 
>>> ffffffff810012ed
>>> (XEN) rdx: 0000000000000000   rsi: 0000000000000000   rdi: 
>>> 0000000000000000
>>> (XEN) rbp: 0000000000000000   rsp: ffff88003e1f9fb8   r8: 
>>> 0000000000000000
>>> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 
>>> 0000000000000286
>>> (XEN) cr0: 000000008005003b   cr4: 00000000000026f0
>>> (XEN) cr3: 00000002b5d86000   cr2: 00007fffb46b9e19
>>> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b cs: e033
>>> (XEN) Guest stack trace from rsp=ffff88003e1f9fb8:
>>> (XEN)    0000000000000000 0000000000000000 0000000000000000
>>> 0000000000000000
>>> (XEN)    00007f0b1f431500 0000000000000033 0000000000000200
>>> 00007fffb46b9ca0
>>> (XEN)    000000000000002b ffff88003e004958 ffff88003e004958
>>> 0000000000000080
>>> (XEN)    ffff88003e1fa080 ffffffff00000006 d5dc82dde2520000
>>> 0000000200000001
>>> (XEN)    0000000400000003 ffffffff00000005 0501e668a45aed37
>>> d3a51001f8186504
>>> (XEN)    3d41962be0a726d3 fbee8906bde13da3 9e907ea339feb0c4
>>> 270b40af55a0f4b8
>>> (XEN)    264b0560a7e2c9dc 0a3145802804d2e1 faf4b4eca4180ba6
>>> 01957dd1d4131d2e
>>> (XEN)    a18b79fe805a7821 bf0afc62c71eddcb 630fca5df80eb04b
>>> 845a16e1648fdd51
>>> (XEN)    c588c03d2edcf807 9cf4717d19322687 510724530fcbf04b
>>> d8f1199bd10015fe
>>> (XEN)    5272422fa11fb05c f2447667cb9fa47a 37c90f94df9206f9
>>> 43eca9d987b7240b
>>> (XEN)    def99e5d7d577367 9b0d95f77cdf3672 4ef9836df37ccdf6
>>> 5a79437e62989ecf
>>> (XEN)    3772f347b726713a 27fc0fe3f633e7e4 b975e7e927ca3183
>>> a3eb9b3cea9ebb28
>>> (XEN)    76b3d73a083d2d34 3e7c801b21bd2ad3 4874b5adac7be5fe
>>> 327fb4145bc5967e
>>> (XEN)    ce5fd2670ed6fe93 6671781eb982fcaf 865c0f25bbc6796d
>>> da793d360234fc4d
>>> (XEN)    fe53c86f9465bf2c cf6fc89cfcb9d3e9 a05d1a75741d9703
>>> 0670c66fb870cfae
>>> (XEN)    fc725a3f8a7f7448 759e29fdd16ebe29 3bea153e12f5193a
>>> 8a2727cf5451fa53
>>> (XEN)    740afaa283c9cbea e8059556115ea89f 08b76c91fd5bd13f
>>> 21d63b340cca2982
>>> (XEN)    9ae74e68a733e980 ace9f7ded7134e44 6c7e4a6a743f4959
>>> fbe3ca9cd6501e75
>>> (XEN)    93b91393e99784e0 dd54b7bd06b739b9 2aefee3afab953f4
>>> 5a9c30b6dd98fadc
>>> (XEN)    390f275e52fa88ef 18115b1dfc41622e 29960fc50c03101e
>>> 04a4d7f6a9fd0795
>>>
>>>>> In that case it is good to use also -c after create to open the xl
>>>>> console strightaway and see what pvgrub2 is doing, for example "xl 
>>>>> -vvv
>>>>> create -c /etc/xen/sid.cfg".
>>>>>
>>>>>>> git log
>>>>>>> commit a82010503e3098930a56110826c4ffe6e1609726
>>>>>>> Author: Vladimir Serbinenko <phcoder@gmail.com>
>>>>>>> Date:   Tue Dec 17 01:18:09 2013 +0100
>>>>>>>
>>>>>>>            Update exclude.pot and mark few strings for translation.
>>>>>>>
>>>>>>>
>>>>>>> My problem on kernel boot with Sid and Wheezy domUs persist.
>>>>>>>
>>>>>>> Thanks for any reply.
>>>>>>>
>>>
>>
>


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 1648 bytes --]

On 17.12.2013 15:35, Fabio Fantoni wrote:
> Il 17/12/2013 15:10, Fabio Fantoni ha scritto:
>> Il 17/12/2013 15:08, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>>>> Thanks.
>>>> Now there is another error, probably introduced by xenfb support:
>>>>
>>> doesn't look like related to xenfb. Is it 64-bit or PAE guest?
>>
>> 64 bit
> 
> I did "git reset --hard" to commit "Remove grub_bios_interrupt on
> coreboot." and then I applied only
> "grub-core/lib/x86_64/xen/relocator.S: Fix hypercall ABI violation."
> commit.
> Now the Sid domU boot correctly, therefore the regression is caused by
> "xenfb" or "xen grants to v1" commit, should I find the exact commit
> that causes that problem or these informations are enough for you?

It's because of vfb. Apparently vfb framebuffer stays mapped as rw even
after vfb shutdown
phcoder@debian:15:52:40:~/grub2$ sudo xenstore-ls
/local/domain/54/device/vfb
0 = ""
 backend = "/local/domain/0/backend/vfb/54/0"
 backend-id = "0"
 state = "1"
phcoder@debian:15:52:51:~/grub2$ sudo xenstore-ls
/local/domain/0/backend/vfb/54/0
frontend = "/local/domain/54/device/vfb/0"
frontend-id = "54"
online = "1"
state = "2"
domain = "grub"
vnc = "1"
vnclisten = "127.0.0.1"
vncdisplay = "0"
vncunused = "1"
sdl = "0"
opengl = "0"
feature-resize = "1"
hotplug-status = "connected"

When I do "dry vfb": do everything except writing vfb state problem
disappears. So my question would be:
- how can I inspect how backend maps framebuffer pages?
- Why does it map as rw and not ro? It doesn't need to write to framebuffer?
- How do I force it to drop the mapping?



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

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] pvgrub2 is merged

[Stefano Stabellini]

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

On Wed, 18 Dec 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 17.12.2013 15:35, Fabio Fantoni wrote:
> > Il 17/12/2013 15:10, Fabio Fantoni ha scritto:
> >> Il 17/12/2013 15:08, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
> >>>> Thanks.
> >>>> Now there is another error, probably introduced by xenfb support:
> >>>>
> >>> doesn't look like related to xenfb. Is it 64-bit or PAE guest?
> >>
> >> 64 bit
> > 
> > I did "git reset --hard" to commit "Remove grub_bios_interrupt on
> > coreboot." and then I applied only
> > "grub-core/lib/x86_64/xen/relocator.S: Fix hypercall ABI violation."
> > commit.
> > Now the Sid domU boot correctly, therefore the regression is caused by
> > "xenfb" or "xen grants to v1" commit, should I find the exact commit
> > that causes that problem or these informations are enough for you?
> 
> It's because of vfb. Apparently vfb framebuffer stays mapped as rw even
> after vfb shutdown
> phcoder@debian:15:52:40:~/grub2$ sudo xenstore-ls
> /local/domain/54/device/vfb
> 0 = ""
>  backend = "/local/domain/0/backend/vfb/54/0"
>  backend-id = "0"
>  state = "1"
> phcoder@debian:15:52:51:~/grub2$ sudo xenstore-ls
> /local/domain/0/backend/vfb/54/0
> frontend = "/local/domain/54/device/vfb/0"
> frontend-id = "54"
> online = "1"
> state = "2"
> domain = "grub"
> vnc = "1"
> vnclisten = "127.0.0.1"
> vncdisplay = "0"
> vncunused = "1"
> sdl = "0"
> opengl = "0"
> feature-resize = "1"
> hotplug-status = "connected"
> 
> When I do "dry vfb": do everything except writing vfb state problem
> disappears. So my question would be:
> - how can I inspect how backend maps framebuffer pages?

There is only one xenfb backend: hw/display/xenfb.c in the QEMU source
tree.


> - Why does it map as rw and not ro? It doesn't need to write to framebuffer?

Actually it is mapping it RO, see hw/display/xenfb.c:xenfb_map_fb


> - How do I force it to drop the mapping?

Theoretically QEMU should drop the mapping at disconnect time:

hw/display/xenfb.c:fb_disconnect

    /*
     * FIXME: qemu can't un-init gfx display (yet?).
     *   Replacing the framebuffer with anonymous shared memory
     *   instead.  This releases the guest pages and keeps qemu happy.
     */
    fb->pixels = mmap(fb->pixels, fb->fbpages * XC_PAGE_SIZE,
                      PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANON,
                      -1, 0);

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 2756 bytes --]

On 18.12.2013 20:39, Stefano Stabellini wrote:
> On Wed, 18 Dec 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 17.12.2013 15:35, Fabio Fantoni wrote:
>>> Il 17/12/2013 15:10, Fabio Fantoni ha scritto:
>>>> Il 17/12/2013 15:08, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>>>>>> Thanks.
>>>>>> Now there is another error, probably introduced by xenfb support:
>>>>>>
>>>>> doesn't look like related to xenfb. Is it 64-bit or PAE guest?
>>>>
>>>> 64 bit
>>>
>>> I did "git reset --hard" to commit "Remove grub_bios_interrupt on
>>> coreboot." and then I applied only
>>> "grub-core/lib/x86_64/xen/relocator.S: Fix hypercall ABI violation."
>>> commit.
>>> Now the Sid domU boot correctly, therefore the regression is caused by
>>> "xenfb" or "xen grants to v1" commit, should I find the exact commit
>>> that causes that problem or these informations are enough for you?
>>
>> It's because of vfb. Apparently vfb framebuffer stays mapped as rw even
>> after vfb shutdown
>> phcoder@debian:15:52:40:~/grub2$ sudo xenstore-ls
>> /local/domain/54/device/vfb
>> 0 = ""
>>  backend = "/local/domain/0/backend/vfb/54/0"
>>  backend-id = "0"
>>  state = "1"
>> phcoder@debian:15:52:51:~/grub2$ sudo xenstore-ls
>> /local/domain/0/backend/vfb/54/0
>> frontend = "/local/domain/54/device/vfb/0"
>> frontend-id = "54"
>> online = "1"
>> state = "2"
>> domain = "grub"
>> vnc = "1"
>> vnclisten = "127.0.0.1"
>> vncdisplay = "0"
>> vncunused = "1"
>> sdl = "0"
>> opengl = "0"
>> feature-resize = "1"
>> hotplug-status = "connected"
>>
>> When I do "dry vfb": do everything except writing vfb state problem
>> disappears. So my question would be:
>> - how can I inspect how backend maps framebuffer pages?
> 
> There is only one xenfb backend: hw/display/xenfb.c in the QEMU source
> tree.
> 
> 
>> - Why does it map as rw and not ro? It doesn't need to write to framebuffer?
> 
> Actually it is mapping it RO, see hw/display/xenfb.c:xenfb_map_fb
> 
./tools/qemu-xen-dir-remote/hw/xenfb.c:
    xenfb->pixels = xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom,
					 PROT_READ | PROT_WRITE, fbmfns, xenfb->fbpages);

> 
>> - How do I force it to drop the mapping?
> 
> Theoretically QEMU should drop the mapping at disconnect time:
> 
> hw/display/xenfb.c:fb_disconnect
> 
>     /*
>      * FIXME: qemu can't un-init gfx display (yet?).
>      *   Replacing the framebuffer with anonymous shared memory
>      *   instead.  This releases the guest pages and keeps qemu happy.
>      */
>     fb->pixels = mmap(fb->pixels, fb->fbpages * XC_PAGE_SIZE,
>                       PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANON,
>                       -1, 0);
> 
Could this fail?


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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] pvgrub2 is merged

[Stefano Stabellini]

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

On Wed, 18 Dec 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 18.12.2013 20:39, Stefano Stabellini wrote:
> > On Wed, 18 Dec 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> >> On 17.12.2013 15:35, Fabio Fantoni wrote:
> >>> Il 17/12/2013 15:10, Fabio Fantoni ha scritto:
> >>>> Il 17/12/2013 15:08, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
> >>>>>> Thanks.
> >>>>>> Now there is another error, probably introduced by xenfb support:
> >>>>>>
> >>>>> doesn't look like related to xenfb. Is it 64-bit or PAE guest?
> >>>>
> >>>> 64 bit
> >>>
> >>> I did "git reset --hard" to commit "Remove grub_bios_interrupt on
> >>> coreboot." and then I applied only
> >>> "grub-core/lib/x86_64/xen/relocator.S: Fix hypercall ABI violation."
> >>> commit.
> >>> Now the Sid domU boot correctly, therefore the regression is caused by
> >>> "xenfb" or "xen grants to v1" commit, should I find the exact commit
> >>> that causes that problem or these informations are enough for you?
> >>
> >> It's because of vfb. Apparently vfb framebuffer stays mapped as rw even
> >> after vfb shutdown
> >> phcoder@debian:15:52:40:~/grub2$ sudo xenstore-ls
> >> /local/domain/54/device/vfb
> >> 0 = ""
> >>  backend = "/local/domain/0/backend/vfb/54/0"
> >>  backend-id = "0"
> >>  state = "1"
> >> phcoder@debian:15:52:51:~/grub2$ sudo xenstore-ls
> >> /local/domain/0/backend/vfb/54/0
> >> frontend = "/local/domain/54/device/vfb/0"
> >> frontend-id = "54"
> >> online = "1"
> >> state = "2"
> >> domain = "grub"
> >> vnc = "1"
> >> vnclisten = "127.0.0.1"
> >> vncdisplay = "0"
> >> vncunused = "1"
> >> sdl = "0"
> >> opengl = "0"
> >> feature-resize = "1"
> >> hotplug-status = "connected"
> >>
> >> When I do "dry vfb": do everything except writing vfb state problem
> >> disappears. So my question would be:
> >> - how can I inspect how backend maps framebuffer pages?
> > 
> > There is only one xenfb backend: hw/display/xenfb.c in the QEMU source
> > tree.
> > 
> > 
> >> - Why does it map as rw and not ro? It doesn't need to write to framebuffer?
> > 
> > Actually it is mapping it RO, see hw/display/xenfb.c:xenfb_map_fb
> > 
> ./tools/qemu-xen-dir-remote/hw/xenfb.c:
>     xenfb->pixels = xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom,
> 					 PROT_READ | PROT_WRITE, fbmfns, xenfb->fbpages);

You are right, my bad.
I did a quick test and it should be safe to modify it to PROT_READ only.


> >> - How do I force it to drop the mapping?
> > 
> > Theoretically QEMU should drop the mapping at disconnect time:
> > 
> > hw/display/xenfb.c:fb_disconnect
> > 
> >     /*
> >      * FIXME: qemu can't un-init gfx display (yet?).
> >      *   Replacing the framebuffer with anonymous shared memory
> >      *   instead.  This releases the guest pages and keeps qemu happy.
> >      */
> >     fb->pixels = mmap(fb->pixels, fb->fbpages * XC_PAGE_SIZE,
> >                       PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANON,
> >                       -1, 0);
> > 
> Could this fail?

Yes and we don't check for the return value (-1 in case of error). Well spotted!
Do you want to submit a patch to fix both issues or should I do it?

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 3320 bytes --]

On 19.12.2013 12:54, Stefano Stabellini wrote:
> On Wed, 18 Dec 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 18.12.2013 20:39, Stefano Stabellini wrote:
>>> On Wed, 18 Dec 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>> On 17.12.2013 15:35, Fabio Fantoni wrote:
>>>>> Il 17/12/2013 15:10, Fabio Fantoni ha scritto:
>>>>>> Il 17/12/2013 15:08, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>>>>>>>> Thanks.
>>>>>>>> Now there is another error, probably introduced by xenfb support:
>>>>>>>>
>>>>>>> doesn't look like related to xenfb. Is it 64-bit or PAE guest?
>>>>>>
>>>>>> 64 bit
>>>>>
>>>>> I did "git reset --hard" to commit "Remove grub_bios_interrupt on
>>>>> coreboot." and then I applied only
>>>>> "grub-core/lib/x86_64/xen/relocator.S: Fix hypercall ABI violation."
>>>>> commit.
>>>>> Now the Sid domU boot correctly, therefore the regression is caused by
>>>>> "xenfb" or "xen grants to v1" commit, should I find the exact commit
>>>>> that causes that problem or these informations are enough for you?
>>>>
>>>> It's because of vfb. Apparently vfb framebuffer stays mapped as rw even
>>>> after vfb shutdown
>>>> phcoder@debian:15:52:40:~/grub2$ sudo xenstore-ls
>>>> /local/domain/54/device/vfb
>>>> 0 = ""
>>>>  backend = "/local/domain/0/backend/vfb/54/0"
>>>>  backend-id = "0"
>>>>  state = "1"
>>>> phcoder@debian:15:52:51:~/grub2$ sudo xenstore-ls
>>>> /local/domain/0/backend/vfb/54/0
>>>> frontend = "/local/domain/54/device/vfb/0"
>>>> frontend-id = "54"
>>>> online = "1"
>>>> state = "2"
>>>> domain = "grub"
>>>> vnc = "1"
>>>> vnclisten = "127.0.0.1"
>>>> vncdisplay = "0"
>>>> vncunused = "1"
>>>> sdl = "0"
>>>> opengl = "0"
>>>> feature-resize = "1"
>>>> hotplug-status = "connected"
>>>>
>>>> When I do "dry vfb": do everything except writing vfb state problem
>>>> disappears. So my question would be:
>>>> - how can I inspect how backend maps framebuffer pages?
>>>
>>> There is only one xenfb backend: hw/display/xenfb.c in the QEMU source
>>> tree.
>>>
>>>
>>>> - Why does it map as rw and not ro? It doesn't need to write to framebuffer?
>>>
>>> Actually it is mapping it RO, see hw/display/xenfb.c:xenfb_map_fb
>>>
>> ./tools/qemu-xen-dir-remote/hw/xenfb.c:
>>     xenfb->pixels = xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom,
>> 					 PROT_READ | PROT_WRITE, fbmfns, xenfb->fbpages);
> 
> You are right, my bad.
> I did a quick test and it should be safe to modify it to PROT_READ only.
> 
> 
>>>> - How do I force it to drop the mapping?
>>>
>>> Theoretically QEMU should drop the mapping at disconnect time:
>>>
>>> hw/display/xenfb.c:fb_disconnect
>>>
>>>     /*
>>>      * FIXME: qemu can't un-init gfx display (yet?).
>>>      *   Replacing the framebuffer with anonymous shared memory
>>>      *   instead.  This releases the guest pages and keeps qemu happy.
>>>      */
>>>     fb->pixels = mmap(fb->pixels, fb->fbpages * XC_PAGE_SIZE,
>>>                       PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANON,
>>>                       -1, 0);
>>>
>> Could this fail?
> 
> Yes and we don't check for the return value (-1 in case of error). Well spotted!
> Do you want to submit a patch to fix both issues or should I do it?
> 
I'm fine with you doing it.


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

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] pvgrub2 is merged

[Stefano Stabellini]

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

On Fri, 20 Dec 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 19.12.2013 12:54, Stefano Stabellini wrote:
> > On Wed, 18 Dec 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> >> On 18.12.2013 20:39, Stefano Stabellini wrote:
> >>> On Wed, 18 Dec 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> >>>> On 17.12.2013 15:35, Fabio Fantoni wrote:
> >>>>> Il 17/12/2013 15:10, Fabio Fantoni ha scritto:
> >>>>>> Il 17/12/2013 15:08, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
> >>>>>>>> Thanks.
> >>>>>>>> Now there is another error, probably introduced by xenfb support:
> >>>>>>>>
> >>>>>>> doesn't look like related to xenfb. Is it 64-bit or PAE guest?
> >>>>>>
> >>>>>> 64 bit
> >>>>>
> >>>>> I did "git reset --hard" to commit "Remove grub_bios_interrupt on
> >>>>> coreboot." and then I applied only
> >>>>> "grub-core/lib/x86_64/xen/relocator.S: Fix hypercall ABI violation."
> >>>>> commit.
> >>>>> Now the Sid domU boot correctly, therefore the regression is caused by
> >>>>> "xenfb" or "xen grants to v1" commit, should I find the exact commit
> >>>>> that causes that problem or these informations are enough for you?
> >>>>
> >>>> It's because of vfb. Apparently vfb framebuffer stays mapped as rw even
> >>>> after vfb shutdown
> >>>> phcoder@debian:15:52:40:~/grub2$ sudo xenstore-ls
> >>>> /local/domain/54/device/vfb
> >>>> 0 = ""
> >>>>  backend = "/local/domain/0/backend/vfb/54/0"
> >>>>  backend-id = "0"
> >>>>  state = "1"
> >>>> phcoder@debian:15:52:51:~/grub2$ sudo xenstore-ls
> >>>> /local/domain/0/backend/vfb/54/0
> >>>> frontend = "/local/domain/54/device/vfb/0"
> >>>> frontend-id = "54"
> >>>> online = "1"
> >>>> state = "2"
> >>>> domain = "grub"
> >>>> vnc = "1"
> >>>> vnclisten = "127.0.0.1"
> >>>> vncdisplay = "0"
> >>>> vncunused = "1"
> >>>> sdl = "0"
> >>>> opengl = "0"
> >>>> feature-resize = "1"
> >>>> hotplug-status = "connected"
> >>>>
> >>>> When I do "dry vfb": do everything except writing vfb state problem
> >>>> disappears. So my question would be:
> >>>> - how can I inspect how backend maps framebuffer pages?
> >>>
> >>> There is only one xenfb backend: hw/display/xenfb.c in the QEMU source
> >>> tree.
> >>>
> >>>
> >>>> - Why does it map as rw and not ro? It doesn't need to write to framebuffer?
> >>>
> >>> Actually it is mapping it RO, see hw/display/xenfb.c:xenfb_map_fb
> >>>
> >> ./tools/qemu-xen-dir-remote/hw/xenfb.c:
> >>     xenfb->pixels = xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom,
> >> 					 PROT_READ | PROT_WRITE, fbmfns, xenfb->fbpages);
> > 
> > You are right, my bad.
> > I did a quick test and it should be safe to modify it to PROT_READ only.
> > 
> > 
> >>>> - How do I force it to drop the mapping?
> >>>
> >>> Theoretically QEMU should drop the mapping at disconnect time:
> >>>
> >>> hw/display/xenfb.c:fb_disconnect
> >>>
> >>>     /*
> >>>      * FIXME: qemu can't un-init gfx display (yet?).
> >>>      *   Replacing the framebuffer with anonymous shared memory
> >>>      *   instead.  This releases the guest pages and keeps qemu happy.
> >>>      */
> >>>     fb->pixels = mmap(fb->pixels, fb->fbpages * XC_PAGE_SIZE,
> >>>                       PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANON,
> >>>                       -1, 0);
> >>>
> >> Could this fail?
> > 
> > Yes and we don't check for the return value (-1 in case of error). Well spotted!
> > Do you want to submit a patch to fix both issues or should I do it?
> > 
> I'm fine with you doing it.

Done, see:

http://marc.info/?l=qemu-devel&m=138901099512700&w=2

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] pvgrub2 is merged

[Stefano Stabellini]

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

Hello Vladimir,
sorry to resurrect an old thread and to top-post, but I noticed that in
upstream grub the xenfb driver has been reverted. Is that because of
this bug?  If so, you should know that the bug has been fixed in QEMU.

Thanks,

Stefano

On Fri, 20 Dec 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 19.12.2013 12:54, Stefano Stabellini wrote:
> > On Wed, 18 Dec 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> >> On 18.12.2013 20:39, Stefano Stabellini wrote:
> >>> On Wed, 18 Dec 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> >>>> On 17.12.2013 15:35, Fabio Fantoni wrote:
> >>>>> Il 17/12/2013 15:10, Fabio Fantoni ha scritto:
> >>>>>> Il 17/12/2013 15:08, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
> >>>>>>>> Thanks.
> >>>>>>>> Now there is another error, probably introduced by xenfb support:
> >>>>>>>>
> >>>>>>> doesn't look like related to xenfb. Is it 64-bit or PAE guest?
> >>>>>>
> >>>>>> 64 bit
> >>>>>
> >>>>> I did "git reset --hard" to commit "Remove grub_bios_interrupt on
> >>>>> coreboot." and then I applied only
> >>>>> "grub-core/lib/x86_64/xen/relocator.S: Fix hypercall ABI violation."
> >>>>> commit.
> >>>>> Now the Sid domU boot correctly, therefore the regression is caused by
> >>>>> "xenfb" or "xen grants to v1" commit, should I find the exact commit
> >>>>> that causes that problem or these informations are enough for you?
> >>>>
> >>>> It's because of vfb. Apparently vfb framebuffer stays mapped as rw even
> >>>> after vfb shutdown
> >>>> phcoder@debian:15:52:40:~/grub2$ sudo xenstore-ls
> >>>> /local/domain/54/device/vfb
> >>>> 0 = ""
> >>>>  backend = "/local/domain/0/backend/vfb/54/0"
> >>>>  backend-id = "0"
> >>>>  state = "1"
> >>>> phcoder@debian:15:52:51:~/grub2$ sudo xenstore-ls
> >>>> /local/domain/0/backend/vfb/54/0
> >>>> frontend = "/local/domain/54/device/vfb/0"
> >>>> frontend-id = "54"
> >>>> online = "1"
> >>>> state = "2"
> >>>> domain = "grub"
> >>>> vnc = "1"
> >>>> vnclisten = "127.0.0.1"
> >>>> vncdisplay = "0"
> >>>> vncunused = "1"
> >>>> sdl = "0"
> >>>> opengl = "0"
> >>>> feature-resize = "1"
> >>>> hotplug-status = "connected"
> >>>>
> >>>> When I do "dry vfb": do everything except writing vfb state problem
> >>>> disappears. So my question would be:
> >>>> - how can I inspect how backend maps framebuffer pages?
> >>>
> >>> There is only one xenfb backend: hw/display/xenfb.c in the QEMU source
> >>> tree.
> >>>
> >>>
> >>>> - Why does it map as rw and not ro? It doesn't need to write to framebuffer?
> >>>
> >>> Actually it is mapping it RO, see hw/display/xenfb.c:xenfb_map_fb
> >>>
> >> ./tools/qemu-xen-dir-remote/hw/xenfb.c:
> >>     xenfb->pixels = xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom,
> >> 					 PROT_READ | PROT_WRITE, fbmfns, xenfb->fbpages);
> > 
> > You are right, my bad.
> > I did a quick test and it should be safe to modify it to PROT_READ only.
> > 
> > 
> >>>> - How do I force it to drop the mapping?
> >>>
> >>> Theoretically QEMU should drop the mapping at disconnect time:
> >>>
> >>> hw/display/xenfb.c:fb_disconnect
> >>>
> >>>     /*
> >>>      * FIXME: qemu can't un-init gfx display (yet?).
> >>>      *   Replacing the framebuffer with anonymous shared memory
> >>>      *   instead.  This releases the guest pages and keeps qemu happy.
> >>>      */
> >>>     fb->pixels = mmap(fb->pixels, fb->fbpages * XC_PAGE_SIZE,
> >>>                       PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANON,
> >>>                       -1, 0);
> >>>
> >> Could this fail?
> > 
> > Yes and we don't check for the return value (-1 in case of error). Well spotted!
> > Do you want to submit a patch to fix both issues or should I do it?
> > 
> I'm fine with you doing it.
> 
> 

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 248 bytes --]

On 29.11.2013 12:28, Fabio Fantoni wrote:
> I updated git to commit 69ca97c820a623f85baf2db1627e19bef9c24e44 and the
> regression persist.
I've just tested it here and it works perfectly. Are you sure you don't
have a typo in variable name?


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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Fabio Fantoni]

Il 05/12/2013 16:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
> On 29.11.2013 12:28, Fabio Fantoni wrote:
>> I updated git to commit 69ca97c820a623f85baf2db1627e19bef9c24e44 and the
>> regression persist.
> I've just tested it here and it works perfectly. Are you sure you don't
> have a typo in variable name?
>

The script for include the grub.cfg of domU works, was only my stupid 
error with cat, sorry.

Below the actual version of the script that works on many common cases.
Are there other modules to insert for other partitions
or file systems, other grub cfg path for other distributions or other
kernel type to search for that support xen pv domUs?
I think is good to make and post complete pvgrub2 cfg that support all 
pv domUs cases.

> cat > boot/grub/grub.cfg <<'EOF'
> insmod lvm
> insmod ext2
> insmod part_msdos
> insmod part_gpt
> insmod btrfs
> insmod xzio
>
> insmod regexp
> for dev in (*); do
>     # $device: parenthesis removed from $dev
>     regexp -s device '\((.*)\)' $dev
>     set root=$device
>     for file in /boot/vmlinuz-* /boot/linux-*; do
>         if test -f $file; then
>             set saved_root=$root
>         fi
>     done
> done
> set root=$saved_root
>
> if test -f /boot/grub2/grub.cfg ; then
>     configfile /boot/grub2/grub.cfg
> elif test -f /boot/grub/grub.cfg ; then
>     configfile /boot/grub/grub.cfg
> fi
> EOF


About the other problem of stop/crash on domU kernel/initrd without any 
errors (also with serial and debug enabled) the problem persist, I'll do 
further test tomorrow.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 1011 bytes --]

On 11.11.2013 11:10, Ian Campbell wrote:
> On Sat, 2013-11-09 at 21:52 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
>> Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.
> 
> This is super cool, thanks!
> 
You're welcome
>> http://git.savannah.gnu.org/cgit/grub.git
>>
>> Documentation on its usage is missing for now but in short:
>> ARCH=x86_64
>> ./autogen.sh
>> ./configure --target=$ARCH --with-platform=xen
> 
> Does this enable Xen statically for the resulting binaries or is it a
> dynamic/boot time selection between Xen and native?
> 
The result binaries are xen only. Dynamic selection makes very little
sense for bootloader.
> Also, does this require any code from Xen (libxc, minios etc) at build
> time or is it completely standalone?
> 
It needs xen headers (/ur/include/xen). On debian those are in libxen-devel
> (I'm asking because I'm thinking "how to enable this in distro
> packaging"...)
> 
> Ian.
> 
> 



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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Ian Campbell]

On Mon, 2013-11-11 at 12:54 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 11.11.2013 11:10, Ian Campbell wrote:
> > On Sat, 2013-11-09 at 21:52 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> > wrote:
> >> Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.
> > 
> > This is super cool, thanks!
> > 
> You're welcome
> >> http://git.savannah.gnu.org/cgit/grub.git
> >>
> >> Documentation on its usage is missing for now but in short:
> >> ARCH=x86_64
> >> ./autogen.sh
> >> ./configure --target=$ARCH --with-platform=xen
> > 
> > Does this enable Xen statically for the resulting binaries or is it a
> > dynamic/boot time selection between Xen and native?
> > 
> The result binaries are xen only. Dynamic selection makes very little
> sense for bootloader.

Right this is what I expected.

Can it coexist alright with a native grub? e.g. will grub-makestandalone
pick the right inputs based on -O $arch-xen instead of -O $arch?

> > Also, does this require any code from Xen (libxc, minios etc) at build
> > time or is it completely standalone?
> > 
> It needs xen headers (/ur/include/xen). On debian those are in libxen-devel

So no requirement for e.g. a Xen source tree. That should make things
much easier for the distros...

Thanks.
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 1644 bytes --]

On 11.11.2013 13:06, Ian Campbell wrote:
> On Mon, 2013-11-11 at 12:54 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
>> On 11.11.2013 11:10, Ian Campbell wrote:
>>> On Sat, 2013-11-09 at 21:52 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
>>> wrote:
>>>> Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.
>>>
>>> This is super cool, thanks!
>>>
>> You're welcome
>>>> http://git.savannah.gnu.org/cgit/grub.git
>>>>
>>>> Documentation on its usage is missing for now but in short:
>>>> ARCH=x86_64
>>>> ./autogen.sh
>>>> ./configure --target=$ARCH --with-platform=xen
>>>
>>> Does this enable Xen statically for the resulting binaries or is it a
>>> dynamic/boot time selection between Xen and native?
>>>
>> The result binaries are xen only. Dynamic selection makes very little
>> sense for bootloader.
> 
> Right this is what I expected.
> 
> Can it coexist alright with a native grub? e.g. will grub-makestandalone
> pick the right inputs based on -O $arch-xen instead of -O $arch?
> 
Coexistance of ports is no problem. All files between ports which share
the name also share the contents. Files which differ have different
names ( E.g.
/usr/lib/grub/{i386-pc,i386-efi,i386-xen,x86_64-xen,x86_64-efi}/*.mod)
>>> Also, does this require any code from Xen (libxc, minios etc) at build
>>> time or is it completely standalone?
>>>
>> It needs xen headers (/ur/include/xen). On debian those are in libxen-devel
> 
> So no requirement for e.g. a Xen source tree. That should make things
> much easier for the distros...
> 
> Thanks.
> Ian.
> 
> 



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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1404 bytes --]

On lun, 2013-11-11 at 10:10 +0000, Ian Campbell wrote:
> On Sat, 2013-11-09 at 21:52 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
> > Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.
> 
> This is super cool, thanks!
> 
Indeed!

Actually, it would be great to have an entry about this in the
Xen-Project blog: http://blog.xen.org/

Vladimir, would you be interested? If yes, would you be up to writing
the blog post? I'm thinking about something like:
 - what is this?
 - what is this good for?
 - how to enable/use it?
 - how [hard] was it to do it? (if you like)

And, of course, whatever else you think could be interesting to have
there.

If not Vladimir, anyone else? If not, I can try to collect the info from
this thread and put something together, but it'll take longer (since I'm
not at all into this).

Anyway, if anyone is interested, please, contact me. I'll provide all
the necessary information either privately or on the @xen-publicity
mailing list (so that we also will stop bothering people in
@xen-devel :-)).

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Ian Campbell]

On Sat, 2013-11-09 at 21:52 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.
> http://git.savannah.gnu.org/cgit/grub.git

I was just talking to some folks here and we thought this might make an
interesting topic for a talk at fosdem e.g. in the virt and iaas room.
http://lists.xen.org/archives/html/xen-devel/2013-10/msg01824.html
http://www.xenproject.org/about/events/viewevent/74-fosdem-2014-virtualization-and-iaas-devroom.html

I guess you have some interesting war stories from doing a pv port and
all the kexec/launching stuff?

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 951 bytes --]

On 13.11.2013 17:36, Ian Campbell wrote:
> On Sat, 2013-11-09 at 21:52 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
>> Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.
>> http://git.savannah.gnu.org/cgit/grub.git
> 
> I was just talking to some folks here and we thought this might make an
> interesting topic for a talk at fosdem e.g. in the virt and iaas room.
> http://lists.xen.org/archives/html/xen-devel/2013-10/msg01824.html
> http://www.xenproject.org/about/events/viewevent/74-fosdem-2014-virtualization-and-iaas-devroom.html
> 
> I guess you have some interesting war stories from doing a pv port and
> all the kexec/launching stuff?
> 
Yes, I can give a talk. Even though it's not clear to me what yet what
the contents will be. Does giving a talk gives right to stay at student
campus there? (it's the case for some conferences but not all)
> Ian.
> 
> 
> 
> 



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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Ian Campbell]

On Wed, 2013-11-13 at 19:25 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 13.11.2013 17:36, Ian Campbell wrote:
> > On Sat, 2013-11-09 at 21:52 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> > wrote:
> >> Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.
> >> http://git.savannah.gnu.org/cgit/grub.git
> > 
> > I was just talking to some folks here and we thought this might make an
> > interesting topic for a talk at fosdem e.g. in the virt and iaas room.
> > http://lists.xen.org/archives/html/xen-devel/2013-10/msg01824.html
> > http://www.xenproject.org/about/events/viewevent/74-fosdem-2014-virtualization-and-iaas-devroom.html
> > 
> > I guess you have some interesting war stories from doing a pv port and
> > all the kexec/launching stuff?
> > 
> Yes, I can give a talk. Even though it's not clear to me what yet what
> the contents will be.

AFAICT you did this port with only a pretty minimal amount of input from
Xen developers, xen-devel, etc which is pretty impressive. I thought you
might have some interesting insights into some of the murkier corners of
the Xen PV architecture, things that were easier/harder than expected,
perhaps some general thoughts or advice on doing a PV OS port etc.

>  Does giving a talk gives right to stay at student
> campus there? (it's the case for some conferences but not all)

I can't find the reference but I seem to remember seeing somewhere that
fosdem offer neither travel not accommodation subsidies.

Also, this is a devroom rather than main track. When I've given a
devroom talk in the past it was never suggested to me, but I also never
asked.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 1931 bytes --]

I can't confirm for 100% now, but I'll be 90-95% at FOSDEM and if I'll
be ther I'm ok to give a talk. Is this offer still on the table?
On 14.11.2013 09:37, Ian Campbell wrote:
> On Wed, 2013-11-13 at 19:25 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
>> On 13.11.2013 17:36, Ian Campbell wrote:
>>> On Sat, 2013-11-09 at 21:52 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
>>> wrote:
>>>> Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.
>>>> http://git.savannah.gnu.org/cgit/grub.git
>>>
>>> I was just talking to some folks here and we thought this might make an
>>> interesting topic for a talk at fosdem e.g. in the virt and iaas room.
>>> http://lists.xen.org/archives/html/xen-devel/2013-10/msg01824.html
>>> http://www.xenproject.org/about/events/viewevent/74-fosdem-2014-virtualization-and-iaas-devroom.html
>>>
>>> I guess you have some interesting war stories from doing a pv port and
>>> all the kexec/launching stuff?
>>>
>> Yes, I can give a talk. Even though it's not clear to me what yet what
>> the contents will be.
> 
> AFAICT you did this port with only a pretty minimal amount of input from
> Xen developers, xen-devel, etc which is pretty impressive. I thought you
> might have some interesting insights into some of the murkier corners of
> the Xen PV architecture, things that were easier/harder than expected,
> perhaps some general thoughts or advice on doing a PV OS port etc.
> 
>>  Does giving a talk gives right to stay at student
>> campus there? (it's the case for some conferences but not all)
> 
> I can't find the reference but I seem to remember seeing somewhere that
> fosdem offer neither travel not accommodation subsidies.
> 
> Also, this is a devroom rather than main track. When I've given a
> devroom talk in the past it was never suggested to me, but I also never
> asked.
> 
> Ian.
> 
> 



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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Ian Campbell]

On Wed, 2013-12-11 at 12:47 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> I can't confirm for 100% now, but I'll be 90-95% at FOSDEM and if I'll
> be ther I'm ok to give a talk. Is this offer still on the table?

I'm afraid the deadline for submissions has passed (IIRC it was 1
December, at least for the virt devroom).

Ian.

> On 14.11.2013 09:37, Ian Campbell wrote:
> > On Wed, 2013-11-13 at 19:25 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> > wrote:
> >> On 13.11.2013 17:36, Ian Campbell wrote:
> >>> On Sat, 2013-11-09 at 21:52 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> >>> wrote:
> >>>> Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.
> >>>> http://git.savannah.gnu.org/cgit/grub.git
> >>>
> >>> I was just talking to some folks here and we thought this might make an
> >>> interesting topic for a talk at fosdem e.g. in the virt and iaas room.
> >>> http://lists.xen.org/archives/html/xen-devel/2013-10/msg01824.html
> >>> http://www.xenproject.org/about/events/viewevent/74-fosdem-2014-virtualization-and-iaas-devroom.html
> >>>
> >>> I guess you have some interesting war stories from doing a pv port and
> >>> all the kexec/launching stuff?
> >>>
> >> Yes, I can give a talk. Even though it's not clear to me what yet what
> >> the contents will be.
> > 
> > AFAICT you did this port with only a pretty minimal amount of input from
> > Xen developers, xen-devel, etc which is pretty impressive. I thought you
> > might have some interesting insights into some of the murkier corners of
> > the Xen PV architecture, things that were easier/harder than expected,
> > perhaps some general thoughts or advice on doing a PV OS port etc.
> > 
> >>  Does giving a talk gives right to stay at student
> >> campus there? (it's the case for some conferences but not all)
> > 
> > I can't find the reference but I seem to remember seeing somewhere that
> > fosdem offer neither travel not accommodation subsidies.
> > 
> > Also, this is a devroom rather than main track. When I've given a
> > devroom talk in the past it was never suggested to me, but I also never
> > asked.
> > 
> > Ian.
> > 
> > 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 2300 bytes --]

On 11.12.2013 12:51, Ian Campbell wrote:
> On Wed, 2013-12-11 at 12:47 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
>> I can't confirm for 100% now, but I'll be 90-95% at FOSDEM and if I'll
>> be ther I'm ok to give a talk. Is this offer still on the table?
> 
> I'm afraid the deadline for submissions has passed (IIRC it was 1
> December, at least for the virt devroom).
> 
Ok, np
> Ian.
> 
>> On 14.11.2013 09:37, Ian Campbell wrote:
>>> On Wed, 2013-11-13 at 19:25 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
>>> wrote:
>>>> On 13.11.2013 17:36, Ian Campbell wrote:
>>>>> On Sat, 2013-11-09 at 21:52 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
>>>>> wrote:
>>>>>> Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.
>>>>>> http://git.savannah.gnu.org/cgit/grub.git
>>>>>
>>>>> I was just talking to some folks here and we thought this might make an
>>>>> interesting topic for a talk at fosdem e.g. in the virt and iaas room.
>>>>> http://lists.xen.org/archives/html/xen-devel/2013-10/msg01824.html
>>>>> http://www.xenproject.org/about/events/viewevent/74-fosdem-2014-virtualization-and-iaas-devroom.html
>>>>>
>>>>> I guess you have some interesting war stories from doing a pv port and
>>>>> all the kexec/launching stuff?
>>>>>
>>>> Yes, I can give a talk. Even though it's not clear to me what yet what
>>>> the contents will be.
>>>
>>> AFAICT you did this port with only a pretty minimal amount of input from
>>> Xen developers, xen-devel, etc which is pretty impressive. I thought you
>>> might have some interesting insights into some of the murkier corners of
>>> the Xen PV architecture, things that were easier/harder than expected,
>>> perhaps some general thoughts or advice on doing a PV OS port etc.
>>>
>>>>  Does giving a talk gives right to stay at student
>>>> campus there? (it's the case for some conferences but not all)
>>>
>>> I can't find the reference but I seem to remember seeing somewhere that
>>> fosdem offer neither travel not accommodation subsidies.
>>>
>>> Also, this is a devroom rather than main track. When I've given a
>>> devroom talk in the past it was never suggested to me, but I also never
>>> asked.
>>>
>>> Ian.
>>>
>>>
>>
>>
> 
> 
> 



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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1244 bytes --]

On mer, 2013-12-11 at 12:54 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 11.12.2013 12:51, Ian Campbell wrote:
> > On Wed, 2013-12-11 at 12:47 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> > wrote:
> >> I can't confirm for 100% now, but I'll be 90-95% at FOSDEM and if I'll
> >> be ther I'm ok to give a talk. Is this offer still on the table?
> > 
> > I'm afraid the deadline for submissions has passed (IIRC it was 1
> > December, at least for the virt devroom).
> > 
> Ok, np
>
So, what about writing a blog post about this, with, if you want,
specific instructions on ho to test this?

Both me and George asked this before... George specifically asked
whether we could have it in time for one of the Xen 4.4 test days, which
would really be ideal.

Still, there is no real deadline this time... Even if it's after 4.4
will be out, we really would like to have something on the project blog.

Up for it? :-)

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Leif Lindholm]

On Wed, Dec 11, 2013 at 12:54:35PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 11.12.2013 12:51, Ian Campbell wrote:
> >> I can't confirm for 100% now, but I'll be 90-95% at FOSDEM and if I'll
> >> be ther I'm ok to give a talk. Is this offer still on the table?
> > 
> > I'm afraid the deadline for submissions has passed (IIRC it was 1
> > December, at least for the virt devroom).
> 
> Ok, np

Just a thought - but the Distribution devroom call for participation is
still open (until 22 Dec). It might not be entirely off-topic there.

/
    Leif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Lars Kurth]

On 11/12/2013 11:51, Ian Campbell wrote:
> On Wed, 2013-12-11 at 12:47 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
>> I can't confirm for 100% now, but I'll be 90-95% at FOSDEM and if I'll
>> be ther I'm ok to give a talk. Is this offer still on the table?
> I'm afraid the deadline for submissions has passed (IIRC it was 1
> December, at least for the virt devroom).
There is a possibility to give an appropriate talk the day before FOSDEM 
at a CentOS DoJo which will be hosted at IBM in Brusseles. I will talk 
to the organizer later today as it is not yet clear what the format of 
the DoJo will be (just talks or a mixture of Hackathon and talks).

Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Andrey Borzenkov]

В Fri, 29 Nov 2013 13:24:22 +0000
Colin Watson <cjwatson@ubuntu.com> пишет:

> On Sat, Nov 09, 2013 at 09:52:20PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > Hello, all. pvgrub2 has just became part of upstream grub as ports
> > i386-xen and x86_64-xen.
> 
> Could anyone offer packaging advice for which ports should be built
> here?  Is it reasonable to assume that a 32-bit userspace only needs the
> 32-bit Xen port and a 64-bit userspace only needs the 64-bit Xen port,
> or is it possible that there could be cross-architecture combinations
> here?  Does the architecture of the GRUB port have to match the
> architecture of the Xen hypervisor?
> 

I guess this question is better asked on xen-devel. Assuming we have 64
bit dom0 and try to boot 32 bit domU. Is it possible to start with
loading 64 bit grub that loads 32 bit kernel and jumps to it? If yes
(and in other direction too) situation becomes relatively simple.

> For those familiar with Debian packaging, I'm trying to work out whether
> it's sufficient to just build grub-xen{,-bin,-dbg} packages which would
> be i386-xen on i386 and x86_64-xen on amd64, or whether I have to have
> two variants on each architecture the way I do for EFI.  All other
> things being equal I'd prefer to keep the package count as low as
> possible, but only if that won't break real-world use cases.
> 

For a long time I dream of possibility to mark grub platform packages
as noarch (speaking about RPM) - they *are* noarch from the OS PoV. I
was told that was impossible, but may be I should try once more.

This would mean one platform - one package that can be installed
everywhere.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Ian Campbell]

On Fri, 2013-11-29 at 21:44 +0400, Andrey Borzenkov wrote:
> В Fri, 29 Nov 2013 13:24:22 +0000
> Colin Watson <cjwatson@ubuntu.com> пишет:
> 
> > On Sat, Nov 09, 2013 at 09:52:20PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > > Hello, all. pvgrub2 has just became part of upstream grub as ports
> > > i386-xen and x86_64-xen.
> > 
> > Could anyone offer packaging advice for which ports should be built
> > here?  Is it reasonable to assume that a 32-bit userspace only needs the
> > 32-bit Xen port and a 64-bit userspace only needs the 64-bit Xen port,
> > or is it possible that there could be cross-architecture combinations
> > here?  Does the architecture of the GRUB port have to match the
> > architecture of the Xen hypervisor?
> > 
> 
> I guess this question is better asked on xen-devel. Assuming we have 64
> bit dom0 and try to boot 32 bit domU. Is it possible to start with
> loading 64 bit grub that loads 32 bit kernel and jumps to it? If yes
> (and in other direction too) situation becomes relatively simple.

AIUI it is not in general possible for a 32-bit PV guest to convert
itself to 64-bit or vice versa, which is essentially what would have to
happen to boot the other type of kernel. So once you have selected the
grub binary to use it cannot boot the other type of kernel. (Yes, this
is an annoying technical restriction...)

It is however possible to run 32-bit and 64-bit guests on a 32-bit dom0
with a 64-bit underlying hypervisor. It is also possible to run both
types of guest on a 64-bit kernel and 64-bit underlying hypervisor.

So, for packaging purposes it would be best to provide both 32- and
64-bit grub binaries for both 32- and 64-bit userspace.

> > For those familiar with Debian packaging, I'm trying to work out whether
> > it's sufficient to just build grub-xen{,-bin,-dbg} packages which would
> > be i386-xen on i386 and x86_64-xen on amd64, or whether I have to have
> > two variants on each architecture the way I do for EFI.  All other
> > things being equal I'd prefer to keep the package count as low as
> > possible, but only if that won't break real-world use cases.

Sorry!

> For a long time I dream of possibility to mark grub platform packages
> as noarch (speaking about RPM) - they *are* noarch from the OS PoV. I
> was told that was impossible, but may be I should try once more.

That does sound like a good idea.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Samuel Thibault]

Ian Campbell, le Mon 02 Dec 2013 09:48:07 +0000, a écrit :
> On Fri, 2013-11-29 at 21:44 +0400, Andrey Borzenkov wrote:
> > I guess this question is better asked on xen-devel. Assuming we have 64
> > bit dom0 and try to boot 32 bit domU. Is it possible to start with
> > loading 64 bit grub that loads 32 bit kernel and jumps to it? If yes
> > (and in other direction too) situation becomes relatively simple.
> 
> AIUI it is not in general possible for a 32-bit PV guest to convert
> itself to 64-bit or vice versa,

Indeed.  At the time of PV-grub1, we discussed about making it possible,
but that'd be quite complex and bug-prone, so we preferred not to
implement it.

Samuel

Re: pvgrub2 is merged

[Ian Campbell]

On Mon, 2013-12-02 at 11:37 +0100, Samuel Thibault wrote:
> Ian Campbell, le Mon 02 Dec 2013 09:48:07 +0000, a écrit :
> > On Fri, 2013-11-29 at 21:44 +0400, Andrey Borzenkov wrote:
> > > I guess this question is better asked on xen-devel. Assuming we have 64
> > > bit dom0 and try to boot 32 bit domU. Is it possible to start with
> > > loading 64 bit grub that loads 32 bit kernel and jumps to it? If yes
> > > (and in other direction too) situation becomes relatively simple.
> > 
> > AIUI it is not in general possible for a 32-bit PV guest to convert
> > itself to 64-bit or vice versa,
> 
> Indeed.  At the time of PV-grub1, we discussed about making it possible,
> but that'd be quite complex and bug-prone, so we preferred not to
> implement it.

I thought we'd concluded "impossible", but yeah ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Colin Watson]

On Mon, Dec 02, 2013 at 09:48:07AM +0000, Ian Campbell wrote:
> On Fri, 2013-11-29 at 21:44 +0400, Andrey Borzenkov wrote:
> > В Fri, 29 Nov 2013 13:24:22 +0000
> > Colin Watson <cjwatson@ubuntu.com> пишет:
> > > Could anyone offer packaging advice for which ports should be built
> > > here?  Is it reasonable to assume that a 32-bit userspace only needs the
> > > 32-bit Xen port and a 64-bit userspace only needs the 64-bit Xen port,
> > > or is it possible that there could be cross-architecture combinations
> > > here?  Does the architecture of the GRUB port have to match the
> > > architecture of the Xen hypervisor?
> > 
> > I guess this question is better asked on xen-devel. Assuming we have 64
> > bit dom0 and try to boot 32 bit domU. Is it possible to start with
> > loading 64 bit grub that loads 32 bit kernel and jumps to it? If yes
> > (and in other direction too) situation becomes relatively simple.
> 
> AIUI it is not in general possible for a 32-bit PV guest to convert
> itself to 64-bit or vice versa, which is essentially what would have to
> happen to boot the other type of kernel. So once you have selected the
> grub binary to use it cannot boot the other type of kernel. (Yes, this
> is an annoying technical restriction...)
> 
> It is however possible to run 32-bit and 64-bit guests on a 32-bit dom0
> with a 64-bit underlying hypervisor. It is also possible to run both
> types of guest on a 64-bit kernel and 64-bit underlying hypervisor.
> 
> So, for packaging purposes it would be best to provide both 32- and
> 64-bit grub binaries for both 32- and 64-bit userspace.

Thanks for the feedback.

I'm inclined, then, to just ship both in the same grub-xen binary
package (actually the pattern is grub-xen{,-bin,-dbg} but never mind
that for now).  It's a bit different from the usual case since you might
well want to actively use both on the same system, and I don't think we
would get much out of the two ports being in separate packages.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvgrub2 is merged

[Ian Campbell]

On Tue, 2013-12-03 at 17:27 +0000, Colin Watson wrote:
> On Mon, Dec 02, 2013 at 09:48:07AM +0000, Ian Campbell wrote:
> > On Fri, 2013-11-29 at 21:44 +0400, Andrey Borzenkov wrote:
> > > В Fri, 29 Nov 2013 13:24:22 +0000
> > > Colin Watson <cjwatson@ubuntu.com> пишет:
> > > > Could anyone offer packaging advice for which ports should be built
> > > > here?  Is it reasonable to assume that a 32-bit userspace only needs the
> > > > 32-bit Xen port and a 64-bit userspace only needs the 64-bit Xen port,
> > > > or is it possible that there could be cross-architecture combinations
> > > > here?  Does the architecture of the GRUB port have to match the
> > > > architecture of the Xen hypervisor?
> > > 
> > > I guess this question is better asked on xen-devel. Assuming we have 64
> > > bit dom0 and try to boot 32 bit domU. Is it possible to start with
> > > loading 64 bit grub that loads 32 bit kernel and jumps to it? If yes
> > > (and in other direction too) situation becomes relatively simple.
> > 
> > AIUI it is not in general possible for a 32-bit PV guest to convert
> > itself to 64-bit or vice versa, which is essentially what would have to
> > happen to boot the other type of kernel. So once you have selected the
> > grub binary to use it cannot boot the other type of kernel. (Yes, this
> > is an annoying technical restriction...)
> > 
> > It is however possible to run 32-bit and 64-bit guests on a 32-bit dom0
> > with a 64-bit underlying hypervisor. It is also possible to run both
> > types of guest on a 64-bit kernel and 64-bit underlying hypervisor.
> > 
> > So, for packaging purposes it would be best to provide both 32- and
> > 64-bit grub binaries for both 32- and 64-bit userspace.
> 
> Thanks for the feedback.
> 
> I'm inclined, then, to just ship both in the same grub-xen binary
> package (actually the pattern is grub-xen{,-bin,-dbg} but never mind
> that for now).  It's a bit different from the usual case since you might
> well want to actively use both on the same system, and I don't think we
> would get much out of the two ports being in separate packages.

Yes, that makes sense to me.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 520 bytes --]

Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.
http://git.savannah.gnu.org/cgit/grub.git

Documentation on its usage is missing for now but in short:
ARCH=x86_64
./autogen.sh
./configure --target=$ARCH --with-platform=xen
make
mkdir -p boot/grub/
cat > boot/grub/grub.cfg <<EOF
search -s root -f /boot/grub/grub.cfg
configfile /boot/grub/grub.cfg
EOF
./grub-mkstandalone --grub-mkimage=./grub-mkimage -o grub.xen -O $ARCH-xen -d grub-core/ boot/grub/grub.cfg


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

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel