* pvgrub2 is merged @ 2013-11-09 20:52 Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-09 21:01 ` Samuel Thibault ` (8 more replies) 0 siblings, 9 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-09 20:52 UTC (permalink / raw) To: The development of GRUB 2, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-09 20:52 pvgrub2 is merged Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-09 21:01 ` Samuel Thibault 2013-11-09 21:01 ` [Xen-devel] " Samuel Thibault ` (7 subsequent siblings) 8 siblings, 0 replies; 149+ messages in thread From: Samuel Thibault @ 2013-11-09 21:01 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-09 20:52 pvgrub2 is merged Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-09 21:01 ` Samuel Thibault @ 2013-11-09 21:01 ` Samuel Thibault 2013-11-10 4:47 ` Andrey Borzenkov ` (6 subsequent siblings) 8 siblings, 0 replies; 149+ messages in thread From: Samuel Thibault @ 2013-11-09 21:01 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-09 20:52 pvgrub2 is merged Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-09 21:01 ` Samuel Thibault 2013-11-09 21:01 ` [Xen-devel] " Samuel Thibault @ 2013-11-10 4:47 ` Andrey Borzenkov 2013-11-11 11:51 ` Vladimir 'φ-coder/phcoder' Serbinenko ` (2 more replies) 2013-11-10 4:47 ` Andrey Borzenkov ` (5 subsequent siblings) 8 siblings, 3 replies; 149+ messages in thread From: Andrey Borzenkov @ 2013-11-10 4:47 UTC (permalink / raw) To: The development of GNU GRUB; +Cc: phcoder, xen-devel [-- Attachment #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 #2: signature.asc --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-10 4:47 ` Andrey Borzenkov @ 2013-11-11 11:51 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-11 11:51 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-13 19:06 ` [Xen-devel] " M A Young 2 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-11 11:51 UTC (permalink / raw) To: Andrey Borzenkov; +Cc: The development of GNU GRUB, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-10 4:47 ` Andrey Borzenkov 2013-11-11 11:51 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-11 11:51 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-13 19:06 ` [Xen-devel] " M A Young 2 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-11 11:51 UTC (permalink / raw) To: Andrey Borzenkov; +Cc: The development of GNU GRUB, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-10 4:47 ` Andrey Borzenkov @ 2013-11-13 19:06 ` M A Young 2013-11-11 11:51 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-13 19:06 ` [Xen-devel] " M A Young 2 siblings, 0 replies; 149+ messages in thread From: M A Young @ 2013-11-13 19:06 UTC (permalink / raw) To: phcoder; +Cc: The development of GNU GRUB, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-11-13 19:06 ` M A Young 0 siblings, 0 replies; 149+ messages in thread From: M A Young @ 2013-11-13 19:06 UTC (permalink / raw) To: phcoder; +Cc: The development of GNU GRUB, xen-devel [-- Attachment #1: Type: TEXT/PLAIN, Size: 1667 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-13 19:06 ` [Xen-devel] " M A Young (?) @ 2013-11-13 20:14 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 12:27 ` M A Young 2013-11-14 12:27 ` M A Young -1 siblings, 2 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-13 20:14 UTC (permalink / raw) To: M A Young; +Cc: The development of GNU GRUB, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-13 20:14 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 12:27 ` M A Young 2013-11-14 17:03 ` M A Young 2013-11-14 17:03 ` [Xen-devel] " M A Young 2013-11-14 12:27 ` M A Young 1 sibling, 2 replies; 149+ messages in thread From: M A Young @ 2013-11-14 12:27 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GNU GRUB, xen-devel [-- Attachment #1: Type: TEXT/PLAIN, Size: 595 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-14 12:27 ` M A Young @ 2013-11-14 17:03 ` M A Young 2013-11-14 17:03 ` [Xen-devel] " M A Young 1 sibling, 0 replies; 149+ messages in thread From: M A Young @ 2013-11-14 17:03 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GNU GRUB, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-14 12:27 ` M A Young 2013-11-14 17:03 ` M A Young @ 2013-11-14 17:03 ` M A Young 2013-11-14 17:32 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 17:32 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 2 replies; 149+ messages in thread From: M A Young @ 2013-11-14 17:03 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GNU GRUB, xen-devel [-- Attachment #1: Type: TEXT/PLAIN, Size: 1115 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-14 17:03 ` [Xen-devel] " M A Young @ 2013-11-14 17:32 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 18:48 ` M A Young 2013-11-14 18:48 ` M A Young 2013-11-14 17:32 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 2 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 17:32 UTC (permalink / raw) To: M A Young; +Cc: The development of GNU GRUB, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply related [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-14 17:32 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 18:48 ` M A Young 2013-11-14 18:57 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 18:57 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 18:48 ` M A Young 1 sibling, 2 replies; 149+ messages in thread From: M A Young @ 2013-11-14 18:48 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GNU GRUB, xen-devel [-- Attachment #1: Type: TEXT/PLAIN, Size: 2485 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-14 18:48 ` M A Young @ 2013-11-14 18:57 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 18:57 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 18:57 UTC (permalink / raw) To: M A Young; +Cc: The development of GNU GRUB, xen-devel [-- 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 ^ permalink raw reply related [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-14 18:48 ` M A Young 2013-11-14 18:57 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 18:57 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 18:59 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 18:59 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 2 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 18:57 UTC (permalink / raw) To: M A Young; +Cc: The development of GNU GRUB, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply related [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-14 18:57 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 18:59 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 21:11 ` M A Young 2013-11-14 21:11 ` [Xen-devel] " M A Young 2013-11-14 18:59 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 2 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 18:59 UTC (permalink / raw) To: M A Young; +Cc: The development of GNU GRUB, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply related [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-14 18:59 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 21:11 ` M A Young 2013-11-14 21:11 ` [Xen-devel] " M A Young 1 sibling, 0 replies; 149+ messages in thread From: M A Young @ 2013-11-14 21:11 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GNU GRUB, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-14 18:59 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 21:11 ` M A Young @ 2013-11-14 21:11 ` M A Young 2013-11-14 21:43 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 21:43 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 2 replies; 149+ messages in thread From: M A Young @ 2013-11-14 21:11 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GNU GRUB, xen-devel [-- Attachment #1: Type: TEXT/PLAIN, Size: 3817 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-14 21:11 ` [Xen-devel] " M A Young @ 2013-11-14 21:43 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 21:43 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 21:43 UTC (permalink / raw) To: M A Young; +Cc: The development of GNU GRUB, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-14 21:11 ` [Xen-devel] " M A Young 2013-11-14 21:43 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 21:43 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-25 15:56 ` [Xen-devel] " Fabio Fantoni 1 sibling, 1 reply; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 21:43 UTC (permalink / raw) To: M A Young; +Cc: The development of GNU GRUB, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-14 21:43 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-25 15:56 ` Fabio Fantoni 0 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-25 15:56 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko, M A Young Cc: The development of GNU GRUB, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-11-25 15:56 ` Fabio Fantoni 0 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-25 15:56 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko, M A Young Cc: The development of GNU GRUB, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
[parent not found: <CAEaD8JOKf7J8ZRfRH_s03UQ9xw=qDziutHNoZs=NTKo3oN_vJg@mail.gmail.com>]
* Re: pvgrub2 is merged [not found] ` <CAEaD8JOKf7J8ZRfRH_s03UQ9xw=qDziutHNoZs=NTKo3oN_vJg@mail.gmail.com> @ 2013-11-25 16:26 ` Fabio Fantoni 0 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-25 16:26 UTC (permalink / raw) To: Vladimir 'phcoder' Serbinenko; +Cc: xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-25 15:56 ` [Xen-devel] " Fabio Fantoni (?) (?) @ 2013-11-25 19:35 ` M A Young -1 siblings, 0 replies; 149+ messages in thread From: M A Young @ 2013-11-25 19:35 UTC (permalink / raw) To: Fabio Fantoni Cc: Vladimir 'φ-coder/phcoder' Serbinenko, xen-devel, The development of GNU GRUB 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-25 15:56 ` [Xen-devel] " Fabio Fantoni ` (2 preceding siblings ...) (?) @ 2013-11-25 19:35 ` M A Young 2013-11-26 17:58 ` Fabio Fantoni 2013-11-26 17:58 ` Fabio Fantoni -1 siblings, 2 replies; 149+ messages in thread From: M A Young @ 2013-11-25 19:35 UTC (permalink / raw) To: Fabio Fantoni Cc: Vladimir 'φ-coder/phcoder' Serbinenko, xen-devel, The development of GNU GRUB 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-25 19:35 ` [Xen-devel] " M A Young @ 2013-11-26 17:58 ` Fabio Fantoni 2013-11-26 18:12 ` Andrey Borzenkov 2013-11-26 18:12 ` [Xen-devel] " Andrey Borzenkov 2013-11-26 17:58 ` Fabio Fantoni 1 sibling, 2 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-26 17:58 UTC (permalink / raw) To: M A Young Cc: Vladimir 'φ-coder/phcoder' Serbinenko, xen-devel, The development of GNU GRUB 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-26 17:58 ` Fabio Fantoni @ 2013-11-26 18:12 ` Andrey Borzenkov 2013-11-26 18:12 ` [Xen-devel] " Andrey Borzenkov 1 sibling, 0 replies; 149+ messages in thread From: Andrey Borzenkov @ 2013-11-26 18:12 UTC (permalink / raw) To: The development of GNU GRUB Cc: Vladimir 'φ-coder/phcoder' Serbinenko, fabio.fantoni, xen-devel, M A Young В 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-26 17:58 ` Fabio Fantoni 2013-11-26 18:12 ` Andrey Borzenkov @ 2013-11-26 18:12 ` Andrey Borzenkov 2013-11-26 19:16 ` [Xen-devel] " Andrew Cooper ` (2 more replies) 1 sibling, 3 replies; 149+ messages in thread From: Andrey Borzenkov @ 2013-11-26 18:12 UTC (permalink / raw) To: The development of GNU GRUB Cc: Vladimir 'φ-coder/phcoder' Serbinenko, fabio.fantoni, xen-devel, M A Young В 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-26 18:12 ` [Xen-devel] " Andrey Borzenkov @ 2013-11-26 19:16 ` Andrew Cooper 2013-11-27 11:32 ` Fabio Fantoni 2013-11-27 11:32 ` [Xen-devel] " Fabio Fantoni 2 siblings, 0 replies; 149+ messages in thread From: Andrew Cooper @ 2013-11-26 19:16 UTC (permalink / raw) To: Andrey Borzenkov Cc: M A Young, The development of GNU GRUB, fabio.fantoni, xen-devel, Vladimir 'φ-coder/phcoder' Serbinenko 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-11-26 19:16 ` Andrew Cooper 0 siblings, 0 replies; 149+ messages in thread From: Andrew Cooper @ 2013-11-26 19:16 UTC (permalink / raw) To: Andrey Borzenkov Cc: M A Young, The development of GNU GRUB, fabio.fantoni, xen-devel, Vladimir 'φ-coder/phcoder' Serbinenko 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-26 18:12 ` [Xen-devel] " Andrey Borzenkov 2013-11-26 19:16 ` [Xen-devel] " Andrew Cooper @ 2013-11-27 11:32 ` Fabio Fantoni 2013-11-27 11:32 ` [Xen-devel] " Fabio Fantoni 2 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-27 11:32 UTC (permalink / raw) To: Andrey Borzenkov, The development of GNU GRUB Cc: Vladimir 'φ-coder/phcoder' Serbinenko, xen-devel, M A Young 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-26 18:12 ` [Xen-devel] " Andrey Borzenkov 2013-11-26 19:16 ` [Xen-devel] " Andrew Cooper 2013-11-27 11:32 ` Fabio Fantoni @ 2013-11-27 11:32 ` Fabio Fantoni 2013-11-27 11:50 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-27 11:50 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2 siblings, 2 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-27 11:32 UTC (permalink / raw) To: Andrey Borzenkov, The development of GNU GRUB Cc: Vladimir 'φ-coder/phcoder' Serbinenko, xen-devel, M A Young 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-27 11:32 ` [Xen-devel] " Fabio Fantoni @ 2013-11-27 11:50 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-27 11:50 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-27 11:50 UTC (permalink / raw) To: Fabio Fantoni Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-27 11:32 ` [Xen-devel] " Fabio Fantoni 2013-11-27 11:50 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-27 11:50 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-27 15:59 ` Fabio Fantoni 2013-11-27 15:59 ` [Xen-devel] " Fabio Fantoni 1 sibling, 2 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-27 11:50 UTC (permalink / raw) To: Fabio Fantoni Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-27 11:50 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-27 15:59 ` Fabio Fantoni 2013-11-27 15:59 ` [Xen-devel] " Fabio Fantoni 1 sibling, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-27 15:59 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-27 11:50 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-27 15:59 ` Fabio Fantoni @ 2013-11-27 15:59 ` Fabio Fantoni 2013-11-27 16:03 ` Vladimir 'φ-coder/phcoder' Serbinenko ` (3 more replies) 1 sibling, 4 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-27 15:59 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young 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. >> > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-27 15:59 ` [Xen-devel] " Fabio Fantoni @ 2013-11-27 16:03 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-27 16:24 ` Fabio Fantoni 2013-11-27 16:24 ` [Xen-devel] " Fabio Fantoni 2013-11-27 16:03 ` Vladimir 'φ-coder/phcoder' Serbinenko ` (2 subsequent siblings) 3 siblings, 2 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-27 16:03 UTC (permalink / raw) To: Fabio Fantoni Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-27 16:03 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-27 16:24 ` Fabio Fantoni 2013-11-27 16:24 ` [Xen-devel] " Fabio Fantoni 1 sibling, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-27 16:24 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-27 16:03 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-27 16:24 ` Fabio Fantoni @ 2013-11-27 16:24 ` Fabio Fantoni 2013-11-27 17:35 ` Andrey Borzenkov 2013-11-27 17:35 ` [Xen-devel] " Andrey Borzenkov 1 sibling, 2 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-27 16:24 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young 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. >> > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-27 16:24 ` [Xen-devel] " Fabio Fantoni @ 2013-11-27 17:35 ` Andrey Borzenkov 2013-11-27 17:35 ` [Xen-devel] " Andrey Borzenkov 1 sibling, 0 replies; 149+ messages in thread From: Andrey Borzenkov @ 2013-11-27 17:35 UTC (permalink / raw) To: Fabio Fantoni Cc: Vladimir 'φ-coder/phcoder' Serbinenko, M A Young, xen-devel, The development of GNU GRUB В 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-27 16:24 ` [Xen-devel] " Fabio Fantoni 2013-11-27 17:35 ` Andrey Borzenkov @ 2013-11-27 17:35 ` Andrey Borzenkov 2013-11-28 13:07 ` Fabio Fantoni 2013-11-28 13:07 ` [Xen-devel] " Fabio Fantoni 1 sibling, 2 replies; 149+ messages in thread From: Andrey Borzenkov @ 2013-11-27 17:35 UTC (permalink / raw) To: Fabio Fantoni Cc: Vladimir 'φ-coder/phcoder' Serbinenko, M A Young, xen-devel, The development of GNU GRUB В 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-27 17:35 ` [Xen-devel] " Andrey Borzenkov @ 2013-11-28 13:07 ` Fabio Fantoni 2013-11-28 13:07 ` [Xen-devel] " Fabio Fantoni 1 sibling, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-28 13:07 UTC (permalink / raw) To: Andrey Borzenkov Cc: Vladimir 'φ-coder/phcoder' Serbinenko, M A Young, xen-devel, The development of GNU GRUB 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-27 17:35 ` [Xen-devel] " Andrey Borzenkov 2013-11-28 13:07 ` Fabio Fantoni @ 2013-11-28 13:07 ` Fabio Fantoni 2013-11-28 14:05 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-28 14:05 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 2 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-28 13:07 UTC (permalink / raw) To: Andrey Borzenkov Cc: Vladimir 'φ-coder/phcoder' Serbinenko, M A Young, xen-devel, The development of GNU GRUB 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-28 13:07 ` [Xen-devel] " Fabio Fantoni @ 2013-11-28 14:05 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-28 14:17 ` Fabio Fantoni 2013-11-28 14:17 ` Fabio Fantoni 2013-11-28 14:05 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 2 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-28 14:05 UTC (permalink / raw) To: Fabio Fantoni Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-28 14:05 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-28 14:17 ` Fabio Fantoni 2013-11-29 11:28 ` Fabio Fantoni 2013-11-29 11:28 ` Fabio Fantoni 2013-11-28 14:17 ` Fabio Fantoni 1 sibling, 2 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-28 14:17 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-28 14:17 ` Fabio Fantoni @ 2013-11-29 11:28 ` Fabio Fantoni [not found] ` <52987D7F.3050006@gmail.com> 2013-12-05 15:50 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-29 11:28 ` Fabio Fantoni 1 sibling, 2 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-29 11:28 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
[parent not found: <52987D7F.3050006@gmail.com>]
[parent not found: <52988F86.6050008@m2r.biz>]
* Re: [Xen-devel] pvgrub2 is merged [not found] ` <52988F86.6050008@m2r.biz> @ 2013-12-03 10:31 ` Fabio Fantoni 0 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-12-03 10:31 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GNU GRUB, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-12-03 10:31 ` Fabio Fantoni 0 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-12-03 10:31 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GNU GRUB, xen-devel [-- 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 ### ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-03 10:31 ` Fabio Fantoni @ 2013-12-03 10:33 ` Vladimir 'φ-coder/phcoder' Serbinenko -1 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-03 10:33 UTC (permalink / raw) To: Fabio Fantoni; +Cc: The development of GNU GRUB, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-12-03 10:33 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-03 10:33 UTC (permalink / raw) To: Fabio Fantoni; +Cc: The development of GNU GRUB, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-03 10:33 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-03 11:22 ` Fabio Fantoni -1 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-12-03 11:22 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GNU GRUB, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-12-03 11:22 ` Fabio Fantoni 0 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-12-03 11:22 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GNU GRUB, xen-devel 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
[parent not found: <529DC07E.8000201@gmail.com>]
[parent not found: <529DE3FD.90002@m2r.biz>]
* Re: [Xen-devel] pvgrub2 is merged [not found] ` <529DE3FD.90002@m2r.biz> @ 2013-12-03 15:33 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-03 16:16 ` Fabio Fantoni 0 siblings, 1 reply; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-03 15:33 UTC (permalink / raw) To: Fabio Fantoni, The development of GRUB 2 [-- Attachment #1: Type: text/plain, Size: 2888 bytes --] 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 Did you try with kernel embed in GRUB? Did you try root/linux/initrd/boot sequence manually? [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-03 15:33 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-03 16:16 ` Fabio Fantoni 2013-12-06 11:11 ` Fabio Fantoni 0 siblings, 1 reply; 149+ messages in thread From: Fabio Fantoni @ 2013-12-03 16:16 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko, The development of GRUB 2 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? > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-03 16:16 ` Fabio Fantoni @ 2013-12-06 11:11 ` Fabio Fantoni 2013-12-06 11:32 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 1 reply; 149+ messages in thread From: Fabio Fantoni @ 2013-12-06 11:11 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko, The development of GRUB 2 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 :( ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-06 11:11 ` Fabio Fantoni @ 2013-12-06 11:32 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-06 14:44 ` Fabio Fantoni 0 siblings, 1 reply; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-06 11:32 UTC (permalink / raw) To: Fabio Fantoni; +Cc: The development of GRUB 2 [-- Attachment #1: Type: text/plain, Size: 5041 bytes --] 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. > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-06 11:32 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-06 14:44 ` Fabio Fantoni 2013-12-06 14:55 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 1 reply; 149+ messages in thread From: Fabio Fantoni @ 2013-12-06 14:44 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-06 14:44 ` Fabio Fantoni @ 2013-12-06 14:55 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-06 15:22 ` Fabio Fantoni 0 siblings, 1 reply; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-06 14:55 UTC (permalink / raw) To: Fabio Fantoni; +Cc: The development of GRUB 2 [-- Attachment #1: Type: text/plain, Size: 6024 bytes --] 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-06 14:55 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-06 15:22 ` Fabio Fantoni 2013-12-07 10:06 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 1 reply; 149+ messages in thread From: Fabio Fantoni @ 2013-12-06 15:22 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2 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) Thanks for any reply. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-06 15:22 ` Fabio Fantoni @ 2013-12-07 10:06 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-09 10:06 ` Fabio Fantoni 0 siblings, 1 reply; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-07 10:06 UTC (permalink / raw) To: Fabio Fantoni; +Cc: The development of GRUB 2 [-- Attachment #1: Type: text/plain, Size: 6986 bytes --] 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. Is there anything in your xl dmesg Meanwhile I implemented vfb/vkbd in phcoder/vfb branch. > Thanks for any reply. > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-07 10:06 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-09 10:06 ` Fabio Fantoni 2013-12-17 10:44 ` Fabio Fantoni 0 siblings, 1 reply; 149+ messages in thread From: Fabio Fantoni @ 2013-12-09 10:06 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2 [-- Attachment #1: Type: text/plain, Size: 7663 bytes --] 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. [-- Attachment #2: pvgrub2-xl-dmesg.txt --] [-- Type: text/plain, Size: 2725 bytes --] (XEN) d2:v0: unhandled page fault (ec=0010) (XEN) Pagetable walk from 00000000deadbf22: (XEN) L4[0x000] = 000000023e640027 000000000003fdfa (XEN) L3[0x003] = 0000000000000000 ffffffffffffffff (XEN) domain_crash_sync called from entry.S: fault at ffff82d080228d70 create_bounce_frame+0x133/0x143 (XEN) Domain 2 (vcpu#0) crashed on cpu#4: (XEN) ----[ Xen-4.4-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: 4 (XEN) RIP: e033:[<00000000deadbf22>] (XEN) RFLAGS: 0000000000000216 EM: 1 CONTEXT: pv guest (XEN) rax: 0000000000000000 rbx: 000000000000004a rcx: 000000000300002a (XEN) rdx: 00000000deadbeef rsi: 00000000deadbeef rdi: 00000000deadbf22 (XEN) rbp: 00000000000130f4 rsp: 000000000041b980 r8: 000000003fbd6a40 (XEN) r9: 000000003fbd6880 r10: 0000000000000007 r11: 0000000000000246 (XEN) r12: 000000003ee11ca0 r13: 000000003f2deac2 r14: 000000003fc0e4e0 (XEN) r15: 0000000000003000 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) cr3: 000000023e641000 cr2: 00000000deadbf22 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) Guest stack trace from rsp=000000000041b980: (XEN) 000000000300002a 0000000000000246 0000000000000010 00000000deadbf22 (XEN) 000000010000e030 0000000000010016 000000000041b9c8 000000000000e02b (XEN) 0000000000003000 000000003f2dda8d 0000000000000000 0000000000000000 (XEN) 0000000000002fff ffffffff82fff000 000000003fbeafa0 000000000042b7b8 (XEN) 000000003fbeaf40 000000003fbe0e40 000000000001e000 000000000000001e (XEN) 0000000002ca2000 0000000002a99000 0000000000000000 0000000000003000 (XEN) 0000000002ca0000 000000003f039bb6 ffffffff82c99000 0000000000002c9c (XEN) 000000000000001e 0000000002a99000 ffffffff82dba000 ffffffff818bb1e0 (XEN) 0000000000002c9c 0000000002c99000 000000000001e000 0000000000003000 (XEN) 0000000000000018 000000000041bad8 000000012f64626b 000000003fbeafa0 (XEN) 0000000000000018 0000000000000001 0000000000000001 0000000000000001 (XEN) 0000000000000000 0000000000000000 00000000000001fe 00000000000001ff (XEN) ffffffff82c99000 0000000000002c9c 000000000000001e 0000000002a99000 (XEN) ffffffff82dba000 ffffffff818bb1e0 0000000326c22001 0000000000002c9a (XEN) 0000000326c23001 0000000000002c9b 00000003277a0001 000000000003fffe (XEN) 000000032779f001 000000000003ffff 0000000000000001 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 000000003f5c5100 00000000000026ba 0000000000000000 0000000000000001 (XEN) 000000003f3a1b60 000000003f3d8cd9 0000000000018c30 000000003f5c50a0 (XEN) 0000000000000034 0000000100000001 000000003f5c5120 000000003f3a1b60 [-- Attachment #3: pvgrub2-xl-create.log --] [-- Type: text/plain, Size: 11868 bytes --] xl -vvv create -c /etc/xen/sid.cfg Parsing config from /etc/xen/sid.cfg libxl: debug: libxl_create.c:1339:do_domain_create: ao 0x80c1d0: create: how=(nil) callback=(nil) poller=0x80c0a0 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:783: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=0x80c578: 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="", 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 : 2074 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=0x42b7b8 xc: detail: elf_parse_binary: phdr: paddr=0x42b7b8 memsz=0x1ea700 xc: detail: elf_parse_binary: memory: 0x0 -> 0x615eb8 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 = 0x615eb8 xc: detail: virt_entry = 0x0 xc: detail: p2m_base = 0xffffffffffffffff domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> 0x615eb8 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 -> 0x616000 (pfn 0x0 + 0x616 pages) domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x0+0x616 at 0x7f1103835000 xc: detail: elf_load_binary: phdr 0 at 0x7f1103835000 -> 0x7f110385011f xc: detail: elf_load_binary: phdr 2 at 0x7f1103c607b8 -> 0x7f1103e4aeb8 domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0x616000 -> 0x816000 (pfn 0x616 + 0x200 pages) domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x616+0x200 at 0x7f1103635000 domainbuilder: detail: xc_dom_alloc_page : start info : 0x816000 (pfn 0x816) domainbuilder: detail: xc_dom_alloc_page : xenstore : 0x817000 (pfn 0x817) domainbuilder: detail: xc_dom_alloc_page : console : 0x818000 (pfn 0x818) 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 : 0x819000 -> 0x822000 (pfn 0x819 + 0x9 pages) domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x819+0x9 at 0x7f110362c000 domainbuilder: detail: xc_dom_alloc_page : boot stack : 0x822000 (pfn 0x822) domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x823000 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 0x818, mfn 0x326c22 domainbuilder: detail: clear_page: pfn 0x817, mfn 0x326c23 domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x816+0x1 at 0x7f1106544000 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 : 2074 kB domainbuilder: detail: domU mmap : 8320 kB domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xbef71 domainbuilder: detail: shared_info_x86_64: called domainbuilder: detail: vcpu_x86_64: called domainbuilder: detail: vcpu_x86_64: cr3: pfn 0x819 mfn 0x326c21 domainbuilder: detail: launch_vm: called, ctxt=0x7f110362a004 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=0x80d6d0: deregister unregistered libxl: debug: libxl_dm.c:1316:libxl__spawn_local_dm: Spawning device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: /usr/lib/xen/bin/qemu-system-i386 libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: -xen-domid libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: 2 libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: -chardev libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-2,server,nowait libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: -mon libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: chardev=libxl-cmd,mode=control libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: -nodefaults libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: -xen-attach libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: -name libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: sid libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: -vnc libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: 0.0.0.0:0,to=99 libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: -k libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: it libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: -machine libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: xenpv libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: -m libxl: debug: libxl_dm.c:1318:libxl__spawn_local_dm: 1025 libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x80c7b0 wpath=/local/domain/0/device-model/2/state token=3/0: register slotnum=3 libxl: debug: libxl_create.c:1353:do_domain_create: ao 0x80c1d0: inprogress: poller=0x80c0a0, flags=i libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x80c7b0 wpath=/local/domain/0/device-model/2/state token=3/0: event epath=/local/domain/0/device-model/2/state libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x80c7b0 wpath=/local/domain/0/device-model/2/state token=3/0: event epath=/local/domain/0/device-model/2/state libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch w=0x80c7b0 wpath=/local/domain/0/device-model/2/state token=3/0: deregister slotnum=3 libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x80c7b0: deregister unregistered libxl: debug: libxl_qmp.c:697:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-2 libxl: debug: libxl_qmp.c:297:qmp_handle_response: message type: qmp libxl: debug: libxl_qmp.c:547:qmp_send_prepare: next qmp command: '{ "execute": "qmp_capabilities", "id": 1 } ' libxl: debug: libxl_qmp.c:297:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:547:qmp_send_prepare: next qmp command: '{ "execute": "query-chardev", "id": 2 } ' libxl: debug: libxl_qmp.c:297:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:547:qmp_send_prepare: next qmp command: '{ "execute": "query-vnc", "id": 3 } ' libxl: debug: libxl_qmp.c:297:qmp_handle_response: message type: return libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x80f6c8 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: register slotnum=3 libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x80f6c8 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: event epath=/local/domain/0/backend/vif/2/0/state libxl: debug: libxl_event.c:646:devstate_watch_callback: backend /local/domain/0/backend/vif/2/0/state wanted state 2 still waiting state 1 libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x80f6c8 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: event epath=/local/domain/0/backend/vif/2/0/state libxl: debug: libxl_event.c:642:devstate_watch_callback: backend /local/domain/0/backend/vif/2/0/state wanted state 2 ok libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch w=0x80f6c8 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: deregister slotnum=3 libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x80f6c8: 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=0x80f750: deregister unregistered libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x80f750: deregister unregistered libxl: debug: libxl_event.c:1740:libxl__ao_progress_report: ao 0x80c1d0: progress report: callback queued aop=0x80e2c0 libxl: debug: libxl_event.c:1560:libxl__ao_complete: ao 0x80c1d0: complete, rc=0 libxl: debug: libxl_event.c:1147:egc_run_callbacks: ao 0x80c1d0: progress report: callback aop=0x80e2c0 libxl: debug: libxl_event.c:1532:libxl__ao__destroy: ao 0x80c1d0: 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-09 10:06 ` Fabio Fantoni @ 2013-12-17 10:44 ` Fabio Fantoni 2013-12-17 11:03 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-17 11:59 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 2 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-12-17 10:44 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2 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. 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-17 10:44 ` Fabio Fantoni @ 2013-12-17 11:03 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-17 13:11 ` Fabio Fantoni 2013-12-17 11:59 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 1 reply; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-17 11:03 UTC (permalink / raw) To: Fabio Fantoni; +Cc: The development of GRUB 2 [-- Attachment #1: Type: text/plain, Size: 9673 bytes --] 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> > 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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-17 11:03 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-17 13:11 ` Fabio Fantoni 2013-12-17 13:32 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 1 reply; 149+ messages in thread From: Fabio Fantoni @ 2013-12-17 13:11 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2 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. 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. >> > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-17 13:11 ` Fabio Fantoni @ 2013-12-17 13:32 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-17 13:55 ` Fabio Fantoni 0 siblings, 1 reply; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-17 13:32 UTC (permalink / raw) To: Fabio Fantoni; +Cc: The development of GRUB 2 [-- Attachment #1: Type: text/plain, Size: 11023 bytes --] 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. > 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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-17 13:32 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-17 13:55 ` Fabio Fantoni 0 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-12-17 13:55 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-12-17 13:55 ` Fabio Fantoni 0 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-12-17 13:55 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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. >>>> >> > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-17 13:55 ` Fabio Fantoni @ 2013-12-17 14:08 ` Vladimir 'φ-coder/phcoder' Serbinenko -1 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-17 14:08 UTC (permalink / raw) To: Fabio Fantoni; +Cc: The development of GRUB 2, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-12-17 14:08 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-17 14:08 UTC (permalink / raw) To: Fabio Fantoni; +Cc: The development of GRUB 2, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-17 14:08 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-17 14:10 ` Fabio Fantoni -1 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-12-17 14:10 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-12-17 14:10 ` Fabio Fantoni 0 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-12-17 14:10 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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. >>>>>> >> > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-17 14:10 ` Fabio Fantoni @ 2013-12-17 14:35 ` Fabio Fantoni -1 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-12-17 14:35 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-12-17 14:35 ` Fabio Fantoni 0 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-12-17 14:35 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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. >>>>>>> >>> >> > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-17 14:35 ` Fabio Fantoni @ 2013-12-18 14:58 ` Vladimir 'φ-coder/phcoder' Serbinenko -1 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-18 14:58 UTC (permalink / raw) To: Fabio Fantoni; +Cc: The development of GRUB 2, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-12-18 14:58 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-18 14:58 UTC (permalink / raw) To: Fabio Fantoni; +Cc: The development of GRUB 2, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-18 14:58 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-18 19:39 ` Stefano Stabellini -1 siblings, 0 replies; 149+ messages in thread From: Stefano Stabellini @ 2013-12-18 19:39 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, Fabio Fantoni, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-12-18 19:39 ` Stefano Stabellini 0 siblings, 0 replies; 149+ messages in thread From: Stefano Stabellini @ 2013-12-18 19:39 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, Fabio Fantoni, xen-devel [-- 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); ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-12-18 19:39 ` Stefano Stabellini @ 2013-12-18 20:20 ` Vladimir 'φ-coder/phcoder' Serbinenko -1 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-18 20:20 UTC (permalink / raw) To: Stefano Stabellini; +Cc: The development of GRUB 2, Fabio Fantoni, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-12-18 20:20 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-18 20:20 UTC (permalink / raw) To: Stefano Stabellini; +Cc: The development of GRUB 2, Fabio Fantoni, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-18 20:20 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-19 11:54 ` Stefano Stabellini -1 siblings, 0 replies; 149+ messages in thread From: Stefano Stabellini @ 2013-12-19 11:54 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, Fabio Fantoni, xen-devel, 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-12-19 11:54 ` Stefano Stabellini 0 siblings, 0 replies; 149+ messages in thread From: Stefano Stabellini @ 2013-12-19 11:54 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, Fabio Fantoni, xen-devel, 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? ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-19 11:54 ` Stefano Stabellini @ 2013-12-20 12:14 ` Vladimir 'φ-coder/phcoder' Serbinenko -1 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-20 12:14 UTC (permalink / raw) To: Stefano Stabellini; +Cc: The development of GRUB 2, Fabio Fantoni, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-12-20 12:14 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-20 12:14 UTC (permalink / raw) To: Stefano Stabellini; +Cc: The development of GRUB 2, Fabio Fantoni, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-20 12:14 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2014-01-06 12:23 ` Stefano Stabellini -1 siblings, 0 replies; 149+ messages in thread From: Stefano Stabellini @ 2014-01-06 12:23 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, Fabio Fantoni, xen-devel, 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2014-01-06 12:23 ` Stefano Stabellini 0 siblings, 0 replies; 149+ messages in thread From: Stefano Stabellini @ 2014-01-06 12:23 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, Fabio Fantoni, xen-devel, 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-20 12:14 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2014-11-07 15:20 ` Stefano Stabellini -1 siblings, 0 replies; 149+ messages in thread From: Stefano Stabellini @ 2014-11-07 15:20 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, Fabio Fantoni, xen-devel, 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2014-11-07 15:20 ` Stefano Stabellini 0 siblings, 0 replies; 149+ messages in thread From: Stefano Stabellini @ 2014-11-07 15:20 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, Fabio Fantoni, xen-devel, 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. > > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-17 10:44 ` Fabio Fantoni 2013-12-17 11:03 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-17 11:59 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-17 11:59 UTC (permalink / raw) To: Fabio Fantoni; +Cc: The development of GRUB 2 [-- Attachment #1: Type: text/plain, Size: 9054 bytes --] 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. > I could reproduce some of problems after I sorted out where debian expects the binaries. Lokking into it. > 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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-29 11:28 ` Fabio Fantoni @ 2013-12-05 15:50 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-05 15:50 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-05 15:50 UTC (permalink / raw) To: Fabio Fantoni Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-12-05 15:50 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-05 15:50 UTC (permalink / raw) To: Fabio Fantoni Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-12-05 15:50 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko (?) @ 2013-12-05 16:04 ` Fabio Fantoni -1 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-12-05 16:04 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-05 15:50 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko (?) (?) @ 2013-12-05 16:04 ` Fabio Fantoni -1 siblings, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-12-05 16:04 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-28 14:17 ` Fabio Fantoni 2013-11-29 11:28 ` Fabio Fantoni @ 2013-11-29 11:28 ` Fabio Fantoni 1 sibling, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-29 11:28 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-28 14:05 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-28 14:17 ` Fabio Fantoni @ 2013-11-28 14:17 ` Fabio Fantoni 1 sibling, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-28 14:17 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-28 13:07 ` [Xen-devel] " Fabio Fantoni 2013-11-28 14:05 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-28 14:05 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-28 14:05 UTC (permalink / raw) To: Fabio Fantoni Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-27 15:59 ` [Xen-devel] " Fabio Fantoni 2013-11-27 16:03 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-27 16:03 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-27 16:10 ` [Xen-devel] " M A Young 2013-11-27 16:10 ` M A Young 3 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-27 16:03 UTC (permalink / raw) To: Fabio Fantoni Cc: Andrey Borzenkov, The development of GNU GRUB, xen-devel, M A Young [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-27 15:59 ` [Xen-devel] " Fabio Fantoni 2013-11-27 16:03 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-27 16:03 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-27 16:10 ` M A Young 2013-11-27 16:10 ` M A Young 3 siblings, 0 replies; 149+ messages in thread From: M A Young @ 2013-11-27 16:10 UTC (permalink / raw) To: Fabio Fantoni Cc: Andrey Borzenkov, Vladimir 'φ-coder/phcoder' Serbinenko, xen-devel, The development of GNU GRUB [-- Attachment #1: Type: TEXT/PLAIN, Size: 1016 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-27 15:59 ` [Xen-devel] " Fabio Fantoni ` (2 preceding siblings ...) 2013-11-27 16:10 ` [Xen-devel] " M A Young @ 2013-11-27 16:10 ` M A Young 3 siblings, 0 replies; 149+ messages in thread From: M A Young @ 2013-11-27 16:10 UTC (permalink / raw) To: Fabio Fantoni Cc: Andrey Borzenkov, Vladimir 'φ-coder/phcoder' Serbinenko, xen-devel, The development of GNU GRUB [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-25 19:35 ` [Xen-devel] " M A Young 2013-11-26 17:58 ` Fabio Fantoni @ 2013-11-26 17:58 ` Fabio Fantoni 1 sibling, 0 replies; 149+ messages in thread From: Fabio Fantoni @ 2013-11-26 17:58 UTC (permalink / raw) To: M A Young Cc: Vladimir 'φ-coder/phcoder' Serbinenko, xen-devel, The development of GNU GRUB 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-14 18:57 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 18:59 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 18:59 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 18:59 UTC (permalink / raw) To: M A Young; +Cc: The development of GNU GRUB, xen-devel [-- 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 ^ permalink raw reply related [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-14 17:32 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 18:48 ` M A Young @ 2013-11-14 18:48 ` M A Young 1 sibling, 0 replies; 149+ messages in thread From: M A Young @ 2013-11-14 18:48 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GNU GRUB, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-14 17:03 ` [Xen-devel] " M A Young 2013-11-14 17:32 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 17:32 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 17:32 UTC (permalink / raw) To: M A Young; +Cc: The development of GNU GRUB, xen-devel [-- 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 ^ permalink raw reply related [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-13 20:14 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 12:27 ` M A Young @ 2013-11-14 12:27 ` M A Young 1 sibling, 0 replies; 149+ messages in thread From: M A Young @ 2013-11-14 12:27 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GNU GRUB, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-13 19:06 ` [Xen-devel] " M A Young (?) (?) @ 2013-11-13 20:14 ` Vladimir 'φ-coder/phcoder' Serbinenko -1 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-13 20:14 UTC (permalink / raw) To: M A Young; +Cc: The development of GNU GRUB, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-09 20:52 pvgrub2 is merged Vladimir 'φ-coder/phcoder' Serbinenko ` (2 preceding siblings ...) 2013-11-10 4:47 ` Andrey Borzenkov @ 2013-11-10 4:47 ` Andrey Borzenkov 2013-11-11 10:10 ` [Xen-devel] " Ian Campbell ` (4 subsequent siblings) 8 siblings, 0 replies; 149+ messages in thread From: Andrey Borzenkov @ 2013-11-10 4:47 UTC (permalink / raw) To: The development of GNU GRUB; +Cc: phcoder, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-09 20:52 pvgrub2 is merged Vladimir 'φ-coder/phcoder' Serbinenko ` (3 preceding siblings ...) 2013-11-10 4:47 ` Andrey Borzenkov @ 2013-11-11 10:10 ` Ian Campbell 2013-11-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko ` (2 more replies) 2013-11-11 10:10 ` Ian Campbell ` (3 subsequent siblings) 8 siblings, 3 replies; 149+ messages in thread From: Ian Campbell @ 2013-11-11 10:10 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-11 10:10 ` [Xen-devel] " Ian Campbell @ 2013-11-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-11 11:54 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 9:48 ` [Xen-devel] " Dario Faggioli 2 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-11 11:54 UTC (permalink / raw) To: Ian Campbell; +Cc: The development of GRUB 2, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-11 10:10 ` [Xen-devel] " Ian Campbell 2013-11-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-11 12:06 ` Ian Campbell 2013-11-11 12:06 ` [Xen-devel] " Ian Campbell 2013-11-14 9:48 ` [Xen-devel] " Dario Faggioli 2 siblings, 2 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-11 11:54 UTC (permalink / raw) To: Ian Campbell; +Cc: The development of GRUB 2, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-11 11:54 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-11 12:06 ` Ian Campbell 2013-11-11 12:06 ` [Xen-devel] " Ian Campbell 1 sibling, 0 replies; 149+ messages in thread From: Ian Campbell @ 2013-11-11 12:06 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-11 11:54 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-11 12:06 ` Ian Campbell @ 2013-11-11 12:06 ` Ian Campbell 2013-11-11 12:52 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-11 12:52 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 2 replies; 149+ messages in thread From: Ian Campbell @ 2013-11-11 12:06 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-11 12:06 ` [Xen-devel] " Ian Campbell @ 2013-11-11 12:52 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-11 12:52 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-11 12:52 UTC (permalink / raw) To: Ian Campbell; +Cc: The development of GRUB 2, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-11 12:06 ` [Xen-devel] " Ian Campbell 2013-11-11 12:52 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-11 12:52 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-11 12:52 UTC (permalink / raw) To: Ian Campbell; +Cc: The development of GRUB 2, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-11 10:10 ` [Xen-devel] " Ian Campbell @ 2013-11-14 9:48 ` Dario Faggioli 2013-11-11 11:54 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 9:48 ` [Xen-devel] " Dario Faggioli 2 siblings, 0 replies; 149+ messages in thread From: Dario Faggioli @ 2013-11-14 9:48 UTC (permalink / raw) To: Ian Campbell Cc: Vladimir 'φ-coder/phcoder' Serbinenko, xen-devel, The development of GRUB 2 [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2013-11-14 9:48 ` Dario Faggioli 0 siblings, 0 replies; 149+ messages in thread From: Dario Faggioli @ 2013-11-14 9:48 UTC (permalink / raw) To: Ian Campbell Cc: Vladimir 'φ-coder/phcoder' Serbinenko, xen-devel, The development of GRUB 2 [-- Attachment #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 #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-09 20:52 pvgrub2 is merged Vladimir 'φ-coder/phcoder' Serbinenko ` (4 preceding siblings ...) 2013-11-11 10:10 ` [Xen-devel] " Ian Campbell @ 2013-11-11 10:10 ` Ian Campbell 2013-11-13 16:36 ` Ian Campbell ` (2 subsequent siblings) 8 siblings, 0 replies; 149+ messages in thread From: Ian Campbell @ 2013-11-11 10:10 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-09 20:52 pvgrub2 is merged Vladimir 'φ-coder/phcoder' Serbinenko ` (5 preceding siblings ...) 2013-11-11 10:10 ` Ian Campbell @ 2013-11-13 16:36 ` Ian Campbell 2013-11-13 16:36 ` [Xen-devel] " Ian Campbell 2013-11-29 13:24 ` Colin Watson 8 siblings, 0 replies; 149+ messages in thread From: Ian Campbell @ 2013-11-13 16:36 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-09 20:52 pvgrub2 is merged Vladimir 'φ-coder/phcoder' Serbinenko ` (6 preceding siblings ...) 2013-11-13 16:36 ` Ian Campbell @ 2013-11-13 16:36 ` Ian Campbell 2013-11-13 18:25 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-13 18:25 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-29 13:24 ` Colin Watson 8 siblings, 2 replies; 149+ messages in thread From: Ian Campbell @ 2013-11-13 16:36 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-13 16:36 ` [Xen-devel] " Ian Campbell @ 2013-11-13 18:25 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-13 18:25 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-13 18:25 UTC (permalink / raw) To: Ian Campbell; +Cc: The development of GRUB 2, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-13 16:36 ` [Xen-devel] " Ian Campbell 2013-11-13 18:25 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-13 18:25 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 8:37 ` Ian Campbell 2013-11-14 8:37 ` Ian Campbell 1 sibling, 2 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-13 18:25 UTC (permalink / raw) To: Ian Campbell; +Cc: The development of GRUB 2, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-13 18:25 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-14 8:37 ` Ian Campbell 2013-12-11 11:47 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-11 11:47 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 8:37 ` Ian Campbell 1 sibling, 2 replies; 149+ messages in thread From: Ian Campbell @ 2013-11-14 8:37 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-14 8:37 ` Ian Campbell @ 2013-12-11 11:47 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-11 11:51 ` Ian Campbell 2013-12-11 11:51 ` [Xen-devel] " Ian Campbell 2013-12-11 11:47 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 2 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-11 11:47 UTC (permalink / raw) To: Ian Campbell; +Cc: The development of GRUB 2, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-12-11 11:47 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-11 11:51 ` Ian Campbell 2013-12-11 11:51 ` [Xen-devel] " Ian Campbell 1 sibling, 0 replies; 149+ messages in thread From: Ian Campbell @ 2013-12-11 11:51 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-11 11:47 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-11 11:51 ` Ian Campbell @ 2013-12-11 11:51 ` Ian Campbell 2013-12-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko ` (2 more replies) 1 sibling, 3 replies; 149+ messages in thread From: Ian Campbell @ 2013-12-11 11:51 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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. > > > > > > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-11 11:51 ` [Xen-devel] " Ian Campbell @ 2013-12-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-11 14:34 ` Dario Faggioli ` (3 more replies) 2013-12-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko 2014-01-06 15:35 ` [Xen-devel] " Lars Kurth 2 siblings, 4 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-11 11:54 UTC (permalink / raw) To: Ian Campbell; +Cc: The development of GRUB 2, xen-devel [-- Attachment #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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-12-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-11 14:34 ` Dario Faggioli 2013-12-11 14:34 ` [Xen-devel] " Dario Faggioli ` (2 subsequent siblings) 3 siblings, 0 replies; 149+ messages in thread From: Dario Faggioli @ 2013-12-11 14:34 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, Ian Campbell, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-11 14:34 ` Dario Faggioli @ 2013-12-11 14:34 ` Dario Faggioli 2013-12-14 17:13 ` Leif Lindholm 2013-12-14 17:13 ` [Xen-devel] " Leif Lindholm 3 siblings, 0 replies; 149+ messages in thread From: Dario Faggioli @ 2013-12-11 14:34 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, Ian Campbell, xen-devel [-- Attachment #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 #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-12-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-11 14:34 ` Dario Faggioli 2013-12-11 14:34 ` [Xen-devel] " Dario Faggioli @ 2013-12-14 17:13 ` Leif Lindholm 2013-12-14 17:13 ` [Xen-devel] " Leif Lindholm 3 siblings, 0 replies; 149+ messages in thread From: Leif Lindholm @ 2013-12-14 17:13 UTC (permalink / raw) To: The development of GNU GRUB; +Cc: Ian Campbell, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko ` (2 preceding siblings ...) 2013-12-14 17:13 ` Leif Lindholm @ 2013-12-14 17:13 ` Leif Lindholm 3 siblings, 0 replies; 149+ messages in thread From: Leif Lindholm @ 2013-12-14 17:13 UTC (permalink / raw) To: The development of GNU GRUB; +Cc: Ian Campbell, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-12-11 11:51 ` [Xen-devel] " Ian Campbell 2013-12-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko 2014-01-06 15:35 ` [Xen-devel] " Lars Kurth 2 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-11 11:54 UTC (permalink / raw) To: Ian Campbell; +Cc: The development of GRUB 2, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-12-11 11:51 ` [Xen-devel] " Ian Campbell @ 2014-01-06 15:35 ` Lars Kurth 2013-12-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko 2014-01-06 15:35 ` [Xen-devel] " Lars Kurth 2 siblings, 0 replies; 149+ messages in thread From: Lars Kurth @ 2014-01-06 15:35 UTC (permalink / raw) To: Ian Campbell, Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged @ 2014-01-06 15:35 ` Lars Kurth 0 siblings, 0 replies; 149+ messages in thread From: Lars Kurth @ 2014-01-06 15:35 UTC (permalink / raw) To: Ian Campbell, Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-14 8:37 ` Ian Campbell 2013-12-11 11:47 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-11 11:47 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-11 11:47 UTC (permalink / raw) To: Ian Campbell; +Cc: The development of GRUB 2, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-13 18:25 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 8:37 ` Ian Campbell @ 2013-11-14 8:37 ` Ian Campbell 1 sibling, 0 replies; 149+ messages in thread From: Ian Campbell @ 2013-11-14 8:37 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GRUB 2, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-09 20:52 pvgrub2 is merged Vladimir 'φ-coder/phcoder' Serbinenko ` (7 preceding siblings ...) 2013-11-13 16:36 ` [Xen-devel] " Ian Campbell @ 2013-11-29 13:24 ` Colin Watson 2013-11-29 17:44 ` Andrey Borzenkov ` (2 more replies) 8 siblings, 3 replies; 149+ messages in thread From: Colin Watson @ 2013-11-29 13:24 UTC (permalink / raw) To: grub-devel 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? 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. Thanks, -- Colin Watson [cjwatson@ubuntu.com] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-29 13:24 ` Colin Watson @ 2013-11-29 17:44 ` Andrey Borzenkov 2013-11-29 18:16 ` Colin Watson ` (2 more replies) 2013-11-29 17:44 ` Andrey Borzenkov 2013-11-30 10:36 ` Vladimir 'φ-coder/phcoder' Serbinenko 2 siblings, 3 replies; 149+ messages in thread From: Andrey Borzenkov @ 2013-11-29 17:44 UTC (permalink / raw) To: grub-devel, xen-devel В 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-29 17:44 ` Andrey Borzenkov @ 2013-11-29 18:16 ` Colin Watson 2013-12-02 9:48 ` Ian Campbell 2013-12-02 9:48 ` [Xen-devel] " Ian Campbell 2 siblings, 0 replies; 149+ messages in thread From: Colin Watson @ 2013-11-29 18:16 UTC (permalink / raw) To: grub-devel On Fri, Nov 29, 2013 at 09:44:27PM +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. I'm not subscribed there, and was hoping not to have to start by explaining PV-GRUB2, especially since I don't fully understand it myself yet. :-) > 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. This is why I want to know exactly what's compatible with what, indeed. I can answer part of the question by code inspection: I see in grub-core/loader/i386/xen.c that the GRUB Xen port can only load Linux kernels that exactly match its own architecture. That means that we have four entities, any of which are potentially 32-bit or 64-bit, and we need to know the full compatibility matrix: dom0 ... can run? ... domU ... can load? ... GRUB ... can load? ... guest kernel I gather that OpenSUSE only supports 64-bit hypervisors? If so then you probably don't care about the first part, but I'd still like to understand it. I would assume that you can't run a 64-bit GRUB on a 32-bit domU because the guest won't have a suitable memory layout, but I don't know for sure. I also assume that if you have a 32-bit hypervisor you can't run anything 64-bit on top of it, but ditto. It would be nice to know why the restriction that GRUB must match the guest kernel exists, and whether this is intrinsic or fixable. -- Colin Watson [cjwatson@ubuntu.com] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-29 17:44 ` Andrey Borzenkov 2013-11-29 18:16 ` Colin Watson @ 2013-12-02 9:48 ` Ian Campbell 2013-12-02 9:48 ` [Xen-devel] " Ian Campbell 2 siblings, 0 replies; 149+ messages in thread From: Ian Campbell @ 2013-12-02 9:48 UTC (permalink / raw) To: Andrey Borzenkov; +Cc: grub-devel, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-11-29 17:44 ` Andrey Borzenkov 2013-11-29 18:16 ` Colin Watson 2013-12-02 9:48 ` Ian Campbell @ 2013-12-02 9:48 ` Ian Campbell 2013-12-02 10:37 ` Samuel Thibault ` (3 more replies) 2 siblings, 4 replies; 149+ messages in thread From: Ian Campbell @ 2013-12-02 9:48 UTC (permalink / raw) To: Andrey Borzenkov; +Cc: grub-devel, xen-devel 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-02 9:48 ` [Xen-devel] " Ian Campbell @ 2013-12-02 10:37 ` Samuel Thibault 2013-12-02 10:46 ` Ian Campbell 2013-12-02 10:46 ` [Xen-devel] " Ian Campbell 2013-12-02 10:37 ` Samuel Thibault ` (2 subsequent siblings) 3 siblings, 2 replies; 149+ messages in thread From: Samuel Thibault @ 2013-12-02 10:37 UTC (permalink / raw) To: Ian Campbell; +Cc: Andrey Borzenkov, grub-devel, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-12-02 10:37 ` Samuel Thibault @ 2013-12-02 10:46 ` Ian Campbell 2013-12-02 10:46 ` [Xen-devel] " Ian Campbell 1 sibling, 0 replies; 149+ messages in thread From: Ian Campbell @ 2013-12-02 10:46 UTC (permalink / raw) To: Samuel Thibault; +Cc: Andrey Borzenkov, grub-devel, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-02 10:37 ` Samuel Thibault 2013-12-02 10:46 ` Ian Campbell @ 2013-12-02 10:46 ` Ian Campbell 1 sibling, 0 replies; 149+ messages in thread From: Ian Campbell @ 2013-12-02 10:46 UTC (permalink / raw) To: Samuel Thibault; +Cc: Andrey Borzenkov, grub-devel, xen-devel 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-12-02 9:48 ` [Xen-devel] " Ian Campbell 2013-12-02 10:37 ` Samuel Thibault @ 2013-12-02 10:37 ` Samuel Thibault 2013-12-03 17:27 ` [Xen-devel] " Colin Watson 2013-12-03 17:27 ` Colin Watson 3 siblings, 0 replies; 149+ messages in thread From: Samuel Thibault @ 2013-12-02 10:37 UTC (permalink / raw) To: Ian Campbell; +Cc: Andrey Borzenkov, grub-devel, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-02 9:48 ` [Xen-devel] " Ian Campbell 2013-12-02 10:37 ` Samuel Thibault 2013-12-02 10:37 ` Samuel Thibault @ 2013-12-03 17:27 ` Colin Watson 2013-12-03 17:41 ` Ian Campbell 2013-12-03 17:41 ` Ian Campbell 2013-12-03 17:27 ` Colin Watson 3 siblings, 2 replies; 149+ messages in thread From: Colin Watson @ 2013-12-03 17:27 UTC (permalink / raw) To: The development of GNU GRUB; +Cc: xen-devel 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] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [Xen-devel] pvgrub2 is merged 2013-12-03 17:27 ` [Xen-devel] " Colin Watson @ 2013-12-03 17:41 ` Ian Campbell 2013-12-03 17:41 ` Ian Campbell 1 sibling, 0 replies; 149+ messages in thread From: Ian Campbell @ 2013-12-03 17:41 UTC (permalink / raw) To: Colin Watson; +Cc: The development of GNU GRUB, xen-devel 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-12-03 17:27 ` [Xen-devel] " Colin Watson 2013-12-03 17:41 ` Ian Campbell @ 2013-12-03 17:41 ` Ian Campbell 1 sibling, 0 replies; 149+ messages in thread From: Ian Campbell @ 2013-12-03 17:41 UTC (permalink / raw) To: Colin Watson; +Cc: The development of GNU GRUB, xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-12-02 9:48 ` [Xen-devel] " Ian Campbell ` (2 preceding siblings ...) 2013-12-03 17:27 ` [Xen-devel] " Colin Watson @ 2013-12-03 17:27 ` Colin Watson 3 siblings, 0 replies; 149+ messages in thread From: Colin Watson @ 2013-12-03 17:27 UTC (permalink / raw) To: The development of GNU GRUB; +Cc: xen-devel 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-29 13:24 ` Colin Watson 2013-11-29 17:44 ` Andrey Borzenkov @ 2013-11-29 17:44 ` Andrey Borzenkov 2013-11-30 10:36 ` Vladimir 'φ-coder/phcoder' Serbinenko 2 siblings, 0 replies; 149+ messages in thread From: Andrey Borzenkov @ 2013-11-29 17:44 UTC (permalink / raw) To: grub-devel, xen-devel В 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: pvgrub2 is merged 2013-11-29 13:24 ` Colin Watson 2013-11-29 17:44 ` Andrey Borzenkov 2013-11-29 17:44 ` Andrey Borzenkov @ 2013-11-30 10:36 ` Vladimir 'φ-coder/phcoder' Serbinenko 2 siblings, 0 replies; 149+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-11-30 10:36 UTC (permalink / raw) To: grub-devel [-- Attachment #1: Type: text/plain, Size: 1663 bytes --] On 29.11.2013 14:24, Colin Watson wrote: > 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? > GRUB port has to match the architecture of domU kernel. This is limitation of Xen architecture and it's one that is difficult to change and it's unlikely to be. But the architecture of Dom0 may be different from DomU one. Typically grub-xen would installed on host and not guest. Packaging should provide grub.xen standalone file. I intend to add grub.xen compilation target to upstream once we gathered information on what we put in grub.cfg there. > 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. We need 2 variants as it's common enouh to run 32-bit VMs on 64-bit host and grub-xen is typically on host. > 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. > > Thanks, > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 149+ messages in thread
end of thread, other threads:[~2014-11-07 15:37 UTC | newest] Thread overview: 149+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-11-09 20:52 pvgrub2 is merged Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-09 21:01 ` Samuel Thibault 2013-11-09 21:01 ` [Xen-devel] " Samuel Thibault 2013-11-10 4:47 ` Andrey Borzenkov 2013-11-11 11:51 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-11 11:51 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-13 19:06 ` M A Young 2013-11-13 19:06 ` [Xen-devel] " M A Young 2013-11-13 20:14 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 12:27 ` M A Young 2013-11-14 17:03 ` M A Young 2013-11-14 17:03 ` [Xen-devel] " M A Young 2013-11-14 17:32 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 18:48 ` M A Young 2013-11-14 18:57 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 18:57 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 18:59 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 21:11 ` M A Young 2013-11-14 21:11 ` [Xen-devel] " M A Young 2013-11-14 21:43 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 21:43 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-25 15:56 ` Fabio Fantoni 2013-11-25 15:56 ` [Xen-devel] " Fabio Fantoni [not found] ` <CAEaD8JOKf7J8ZRfRH_s03UQ9xw=qDziutHNoZs=NTKo3oN_vJg@mail.gmail.com> 2013-11-25 16:26 ` Fabio Fantoni 2013-11-25 19:35 ` M A Young 2013-11-25 19:35 ` [Xen-devel] " M A Young 2013-11-26 17:58 ` Fabio Fantoni 2013-11-26 18:12 ` Andrey Borzenkov 2013-11-26 18:12 ` [Xen-devel] " Andrey Borzenkov 2013-11-26 19:16 ` Andrew Cooper 2013-11-26 19:16 ` [Xen-devel] " Andrew Cooper 2013-11-27 11:32 ` Fabio Fantoni 2013-11-27 11:32 ` [Xen-devel] " Fabio Fantoni 2013-11-27 11:50 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-27 11:50 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-27 15:59 ` Fabio Fantoni 2013-11-27 15:59 ` [Xen-devel] " Fabio Fantoni 2013-11-27 16:03 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-27 16:24 ` Fabio Fantoni 2013-11-27 16:24 ` [Xen-devel] " Fabio Fantoni 2013-11-27 17:35 ` Andrey Borzenkov 2013-11-27 17:35 ` [Xen-devel] " Andrey Borzenkov 2013-11-28 13:07 ` Fabio Fantoni 2013-11-28 13:07 ` [Xen-devel] " Fabio Fantoni 2013-11-28 14:05 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-28 14:17 ` Fabio Fantoni 2013-11-29 11:28 ` Fabio Fantoni [not found] ` <52987D7F.3050006@gmail.com> [not found] ` <52988F86.6050008@m2r.biz> 2013-12-03 10:31 ` Fabio Fantoni 2013-12-03 10:31 ` Fabio Fantoni 2013-12-03 10:33 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-03 10:33 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-03 11:22 ` Fabio Fantoni 2013-12-03 11:22 ` Fabio Fantoni [not found] ` <529DC07E.8000201@gmail.com> [not found] ` <529DE3FD.90002@m2r.biz> 2013-12-03 15:33 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-03 16:16 ` Fabio Fantoni 2013-12-06 11:11 ` Fabio Fantoni 2013-12-06 11:32 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-06 14:44 ` Fabio Fantoni 2013-12-06 14:55 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-06 15:22 ` Fabio Fantoni 2013-12-07 10:06 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-09 10:06 ` Fabio Fantoni 2013-12-17 10:44 ` Fabio Fantoni 2013-12-17 11:03 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-17 13:11 ` Fabio Fantoni 2013-12-17 13:32 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-17 13:55 ` Fabio Fantoni 2013-12-17 13:55 ` Fabio Fantoni 2013-12-17 14:08 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-17 14:08 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-17 14:10 ` Fabio Fantoni 2013-12-17 14:10 ` Fabio Fantoni 2013-12-17 14:35 ` Fabio Fantoni 2013-12-17 14:35 ` Fabio Fantoni 2013-12-18 14:58 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-18 14:58 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-18 19:39 ` Stefano Stabellini 2013-12-18 19:39 ` Stefano Stabellini 2013-12-18 20:20 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-18 20:20 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-19 11:54 ` Stefano Stabellini 2013-12-19 11:54 ` Stefano Stabellini 2013-12-20 12:14 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-20 12:14 ` Vladimir 'φ-coder/phcoder' Serbinenko 2014-01-06 12:23 ` Stefano Stabellini 2014-01-06 12:23 ` Stefano Stabellini 2014-11-07 15:20 ` Stefano Stabellini 2014-11-07 15:20 ` Stefano Stabellini 2013-12-17 11:59 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-05 15:50 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-05 15:50 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-05 16:04 ` Fabio Fantoni 2013-12-05 16:04 ` [Xen-devel] " Fabio Fantoni 2013-11-29 11:28 ` Fabio Fantoni 2013-11-28 14:17 ` Fabio Fantoni 2013-11-28 14:05 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-27 16:03 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-27 16:10 ` [Xen-devel] " M A Young 2013-11-27 16:10 ` M A Young 2013-11-26 17:58 ` Fabio Fantoni 2013-11-14 18:59 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 18:48 ` M A Young 2013-11-14 17:32 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 12:27 ` M A Young 2013-11-13 20:14 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-10 4:47 ` Andrey Borzenkov 2013-11-11 10:10 ` [Xen-devel] " Ian Campbell 2013-11-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-11 11:54 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-11 12:06 ` Ian Campbell 2013-11-11 12:06 ` [Xen-devel] " Ian Campbell 2013-11-11 12:52 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-11 12:52 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 9:48 ` Dario Faggioli 2013-11-14 9:48 ` [Xen-devel] " Dario Faggioli 2013-11-11 10:10 ` Ian Campbell 2013-11-13 16:36 ` Ian Campbell 2013-11-13 16:36 ` [Xen-devel] " Ian Campbell 2013-11-13 18:25 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-13 18:25 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 8:37 ` Ian Campbell 2013-12-11 11:47 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-11 11:51 ` Ian Campbell 2013-12-11 11:51 ` [Xen-devel] " Ian Campbell 2013-12-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-11 14:34 ` Dario Faggioli 2013-12-11 14:34 ` [Xen-devel] " Dario Faggioli 2013-12-14 17:13 ` Leif Lindholm 2013-12-14 17:13 ` [Xen-devel] " Leif Lindholm 2013-12-11 11:54 ` Vladimir 'φ-coder/phcoder' Serbinenko 2014-01-06 15:35 ` Lars Kurth 2014-01-06 15:35 ` [Xen-devel] " Lars Kurth 2013-12-11 11:47 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-11-14 8:37 ` Ian Campbell 2013-11-29 13:24 ` Colin Watson 2013-11-29 17:44 ` Andrey Borzenkov 2013-11-29 18:16 ` Colin Watson 2013-12-02 9:48 ` Ian Campbell 2013-12-02 9:48 ` [Xen-devel] " Ian Campbell 2013-12-02 10:37 ` Samuel Thibault 2013-12-02 10:46 ` Ian Campbell 2013-12-02 10:46 ` [Xen-devel] " Ian Campbell 2013-12-02 10:37 ` Samuel Thibault 2013-12-03 17:27 ` [Xen-devel] " Colin Watson 2013-12-03 17:41 ` Ian Campbell 2013-12-03 17:41 ` Ian Campbell 2013-12-03 17:27 ` Colin Watson 2013-11-29 17:44 ` Andrey Borzenkov 2013-11-30 10:36 ` Vladimir 'φ-coder/phcoder' Serbinenko
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.