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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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
В 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? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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=xenDoes 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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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. > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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-develSo 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
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. > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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.gitI 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
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. > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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); } } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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 > EOFYou 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.cfgI 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
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
В 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
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
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 ... > ... > fiI 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
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. > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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
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. >>> >> > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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
В 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
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
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. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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
В 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
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
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
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
Vladimir 'φ-coder/phcoder' Serbinenko
2013-Dec-03 10:33 UTC
Re: [Xen-devel] pvgrub2 is merged
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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-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
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
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
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? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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 > EOFAbout 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