Hello all, I''ve patched pv-grub to allow it to boot a Solaris PV domU using an unmodified menu.lst. The attached patch has been tested with various Solaris versions (Solaris 11 Express, OpenIndiana 151a, OpenSolaris 134, Nexenta Core 3.0.1; all 64-bit). I appreciate your feedback. The patch consists mainly of Oracle''s grub modifications, which add ZFS support and Solaris-specific builtins (findroot, bootfs, kernel$, and module$). I took the relevant code from the "Oracle Solaris 11 Express 2010.11 GPL Source, Part 2" package, downloaded from: http://dlc.sun.com/opensourcecode/solaris/sol-11-exp-201011-GPLSource_2.zip The kernel$ and module$ builtins were modified to boot Xen PV Solaris kernels. The patch is against current xen-unstable. I built and tested pv-grub under Xen version 4.0.1 (Debian 4.0.1-2) amd64, with a Linux 2.6.32-5-xen-amd64 (Debian Squeeze) dom0. The location of menu.lst in the domU was specified with the "extra" variable (e.g. extra="(hd0,0,a)/boot/grub/menu.lst"). Note: I had to create a symlink "xen/include/xen/libelf -> ." (not in the patch) to build stubdom/libxc-x86_64 succesfully. Is this a bug, or is there something wrong in my setup? If you think this code is useful for other users, I''d be happy to see it included in the Xen repository. Please let me know if there''s anything that needs to be changed. Best, Kasper _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Oct 13, 2011 at 3:40 AM, Kasper Brink <K.Brink@cs.ru.nl> wrote:> Hello all, > > I''ve patched pv-grub to allow it to boot a Solaris PV domU using an > unmodified menu.lst. The attached patch has been tested with various > Solaris versions (Solaris 11 Express, OpenIndiana 151a, OpenSolaris 134, > Nexenta Core 3.0.1; all 64-bit). I appreciate your feedback.Awesome :D Can you also create a patch for pygrub? Your patch style looks weird though. You''re creating a new patch file, stubdom/grub.patches/60zfs_solaris.diff, which patches other patch files? Or is it simply manual merging problem? -- Fajar _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Fajar, On Thu, Oct 13, 2011 at 03:51:33AM +0700, Fajar A. Nugraha wrote:> Can you also create a patch for pygrub?I haven''t tested it, but it seems as though pygrub should already support ZFS via libfsimage, and it also contains some Solaris-detection logic. Perhaps the the ZFS version in libfsimage needs updating, though.> Your patch style looks weird though. You''re creating a new patch file, > stubdom/grub.patches/60zfs_solaris.diff, which patches other patch > files? Or is it simply manual merging problem?Yes, I agree this is a bit awkward. I tried to stick to the way that pv-grub is currently built: the Makefile downloads the original upstream sources of grub-0.97 from GNU''s ftp site, and then applies the set of patches in stubdom/grub.patches to it. The patch attached to my email (pv-grub_solaris.patch) creates a new file stubdom/grub.patches/60zfs_solaris.diff (which contains the Solaris-related changes to grub-0.97), and modifies stubdom/grub/Makefile (to include several new source files into pv-grub). Sorry if I didn''t make this clear! Best, Kasper _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hello, Kasper Brink, le Wed 12 Oct 2011 22:40:11 +0200, a écrit :> I''ve patched pv-grub to allow it to boot a Solaris PV domU using an > unmodified menu.lst.Great! I don''t have time to review the patch in details, but the shape looks good to me.> The attached patch has been tested with various > Solaris versions (Solaris 11 Express, OpenIndiana 151a, OpenSolaris 134, > Nexenta Core 3.0.1; all 64-bit). I appreciate your feedback.Could you also check that Linux configurations also still work? Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> The attached patch has been tested with various >> Solaris versions (Solaris 11 Express, OpenIndiana 151a, OpenSolaris 134, >> Nexenta Core 3.0.1; all 64-bit). I appreciate your feedback. > > Could you also check that Linux configurations also still work?Sure, I''ll post the results here later. Kasper _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hello Michael, On Thu, Oct 13, 2011 at 03:48:59PM +0800, Michael Li wrote:> Thank you! How can I test your utility in OVM3.0.2 platorm, I have > Solaris latest running as Guest OS, would like you activate the PV > domU with your tool.I haven''t used Oracle VM myself, but hopefully the hypervisor is sufficiently similar to vanilla Xen 4.0 that the instructions below will work. === Building pv-grub == To build a patched pv-grub, you''ll need a Linux system with developer tools installed; I used Debian Squeeze, but another distribution should be fine. You should build pv-grub on the same arch (i386 or amd64) as the domU you intend to run. Steps: hg clone http://xenbits.xen.org/hg/xen-unstable.hg/ patch -p1 -d xen-unstable.hg < pv-grub_solaris.patch cd xen-unstable.hg # I also needed the following symlink: ln -s . xen/include/xen/libelf make -C stubdom pv-grub # if the build succeeds, pv-grub will be in stubdom/mini-os-$ARCH-grub, e.g.: cp stubdom/mini-os-x86_64-grub/mini-os.gz ../pv-grub.patched.gz === Converting an existing HVM domU to PV == There was a thread on xen-discuss about converting a HVM domU to PV: http://mail.opensolaris.org/pipermail/xen-discuss/2010-February/005768.html The post above uses pygrub; with a patched pv-grub the process is similar. The tricky part is that the root pool of the domU holds information about the physical device paths of its vdevs, which is no longer correct when we switch to a PV domain. This causes the domU kernel to panic when it tries to mount the root pool. To prevent this, you must first boot the PV domain from a Solaris installation cd (iso image), and import and export the root pool: this writes the correct device paths to the pool. First, download a Solaris iso image that is at least as recent your root pool version (e.g. Solaris 11 Express). Edit the vm.cfg file of your domU: # remove "builder=..." and "device_model=..." parameters # modify "kernel", "disk" and "extra" as follows: kernel = ''/path/to/pv-grub.patched.gz'' disk = [ ''file:/path/to/domU/System.img,xvda,w'', ''file:/path/to/domU/sol-11-exp-201011-text-x86.iso,xvdc:cdrom,r'' ] # (initially, boot from the iso) extra =''(hd1)/boot/grub/menu.lst'' Start the domain and attach the console. Depending on how quick you are, you should see either a countdown timer, or a "Selected disk does not exist" error. Press "Esc" to enter the menu. Now you must edit the default menu entry to add a "root" command (I have a separate patch to pv-grub that fixes this, but that''s not really Solaris-related). Select edit > new line before > edit > enter "root (hd1)" > boot. The Solaris iso should now boot. Run the following in a shell (option 3 in the SX11 text installer): zpool import -f rpool # verify that the import succeeded zpool status zpool export rpool # verify that the export succeeded zpool status At this point you can destroy the VM. Now edit the vm.cfg to read: extra=''(hd0,0,a)/boot/grub/menu.lst'' and optionally remove the Solaris iso from the "disk" parameter. Start the vm again, and if all went correctly, you should see the grub menu, and be able to boot your PV domain into the boot environment of your choice. === Creating a new PV domU == Just follow the steps above, but instead of opening a shell for the zpool import & export step, choose "Install Solaris". I hope this works for you. Success/failure reports are welcome! Best, Kasper _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hello Samuel, On Thu, Oct 13, 2011 at 02:38:32AM +0200, Samuel Thibault wrote:> > The attached patch has been tested with various > > Solaris versions (Solaris 11 Express, OpenIndiana 151a, OpenSolaris 134, > > Nexenta Core 3.0.1; all 64-bit). I appreciate your feedback. > > Could you also check that Linux configurations also still work?I can confirm that pv-grub with the Solaris patch still works correctly for Linux domUs. This was tested with the following distributions: Debian 6.0, Ubuntu 11.10 Server, Fedora 15, and CentOS 6 (all 64-bit). For each of these domains I used a whole-disk block device (xvda), and let the OS installer create a partition structure on it (which is probably not how you would typically do it with pygrub, but for pv-grub this is more convenient). I tested both a layout with a single (ext3) partition, and with a separate /boot partition (ext2 and ext3). I didn''t notice any differences between the unpatched and patched versions of pv-grub when booting these domains. Incidentally, I was pleasantly surprised that the installers of all the mentioned distributions work just fine in a PV domU, with the exception of Ubuntu 11.10 (for which I had to manually add Xen modules to the initrd). For the others, I just added the installer iso as device "xvdb", booted into the grubdom commandline, located the kernel and initrd via tab-completion, booted these, and was then able to do the installation as normal. Kasper _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kasper Brink, le Sun 16 Oct 2011 19:45:27 +0200, a écrit :> On Thu, Oct 13, 2011 at 02:38:32AM +0200, Samuel Thibault wrote: > > > The attached patch has been tested with various > > > Solaris versions (Solaris 11 Express, OpenIndiana 151a, OpenSolaris 134, > > > Nexenta Core 3.0.1; all 64-bit). I appreciate your feedback. > > > > Could you also check that Linux configurations also still work? > > I can confirm that pv-grub with the Solaris patch still works correctly for > Linux domUs. This was tested with the following distributions: Debian 6.0, > Ubuntu 11.10 Server, Fedora 15, and CentOS 6 (all 64-bit).I''d give an Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org> on it then. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kasper Brink writes ("[Xen-devel] pv-grub Solaris support"):> I''ve patched pv-grub to allow it to boot a Solaris PV domU using an > unmodified menu.lst. The attached patch has been tested with various > Solaris versions (Solaris 11 Express, OpenIndiana 151a, OpenSolaris 134, > Nexenta Core 3.0.1; all 64-bit). I appreciate your feedback.I tried this and: ar: /u/iwj/work/xen-unstable-tools.hg/stubdom/grub-x86_32/stage2/fsys_zfs.o: No such file or directory make[2]: *** [/u/iwj/work/xen-unstable-tools.hg/stubdom/grub-x86_32/main.a] Error 1 make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/stubdom/grub'' That''s the result of hg clean --all && cp ../.config . [ in my qemu tree ] git-clean -x -d -f (make -j4 && echo ok.) 2>&1 | tee ../log My .config contains: CONFIG_QEMU=/u/iwj/work/1/qemu-iwj.git QEMU_UPSTREAM_URL=/u/iwj/work/1/qemu-upstream-unstable.git NB I have ccache and my downloads are coming from a local squid (I have http_proxy set) so it may be a race of some kind. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Ian, On Tue, Oct 25, 2011 at 07:06:55PM +0100, Ian Jackson wrote:> I tried this and: > > ar: /u/iwj/work/xen-unstable-tools.hg/stubdom/grub-x86_32/stage2/fsys_zfs.o: No such file or directory > make[2]: *** [/u/iwj/work/xen-unstable-tools.hg/stubdom/grub-x86_32/main.a] Error 1 > make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/stubdom/grub''Thanks for the report. I will try to reproduce this error in the next few days.> > That''s the result of > hg clean --all && cp ../.config . > [ in my qemu tree ] git-clean -x -d -f > (make -j4 && echo ok.) 2>&1 | tee ../log > > My .config contains: > CONFIG_QEMU=/u/iwj/work/1/qemu-iwj.git > QEMU_UPSTREAM_URL=/u/iwj/work/1/qemu-upstream-unstable.gitCould you send me the full build log for comparison? Also, is your "xen-unstable-tools.hg" based on http://xenbits.xen.org/hg/xen-unstable.hg/, or something else? Best, Kasper. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kasper Brink writes ("Re: [Xen-devel] pv-grub Solaris support"):> Could you send me the full build log for comparison?I had failed to "hg add" so my "hg clean" removed the patch file. I checked it again and it works fine. But I''m afraid I can''t apply it because I need confirmation of the copyright status. See the section on Signed-off-By on http://wiki.xen.org/xenwiki/SubmittingXenPatches Looking at the contents of your patch I see some worrying things. Can you please find the licences for all the code you''re including and arrange for appropriate copyright and licensing notices, copies of licences, etc. etc. ? Thanks, ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Oct 26, 2011 at 02:00:07PM +0100, Ian Jackson wrote:> But I''m afraid I can''t apply it because I need confirmation of the > copyright status. See the section on Signed-off-By on > http://wiki.xen.org/xenwiki/SubmittingXenPatchesThe pv-grub_solaris patch I sent previously is: Signed-off-by: Kasper Brink <K.Brink@cs.ru.nl> If you want, I will resubmit the patch according to the guidelines on the wiki, along with any necessary changes to the license and copyright notices.> Looking at the contents of your patch I see some worrying things. Can > you please find the licences for all the code you''re including and > arrange for appropriate copyright and licensing notices, copies of > licences, etc. etc. ?All the code in my patch was either taken from the "Oracle Solaris 11 Express 2010.11 GPL Source, Part 2" archive, downloaded from http://dlc.sun.com/opensourcecode/solaris/sol-11-exp-201011-GPLSource_2.zip, or written by me (small portions). The code is licensed under the GNU GPL, version 2 or later ("GPL2+"). Each file from which I copied code contains a notice stating that it is licensed under the GPL2+. Identical notices are present in the unpatched pv-grub sources, so the diff itself does not contain this information (except for newly added files). I will add a GPL2+ notice to the header of the file 60zfs_solaris.diff. The full GPL 2 license text is already in the Xen repository root, so I assume I don''t need to add that to the patch. The copyright status is a bit more diverse (see the attached list for the full details): - all the files I copied code from have an FSF copyright notice - most of these files also have a Sun Microsystems or Oracle copyright notice - there are 7 files that contain ZFS- or Solaris-related code, but do not have Sun or Oracle copyright notices. My patch preserves the copyright notices for all files, but does not add any notices that are not present in the archive distributed by Oracle. The files that do not have Sun or Oracle copyright notices are: builtins.c, common.c, disk_io.c, filesys.h, pc_slice.h, shared.h, stage2.c. I don''t think I should add such notices myself, but I could add a comment to each file along these lines: /* * Portions of this file are derived from code distributed by Oracle in 2011, * licensed under the GNU General Public License, version 2 or later. */ In summary, I propose to do the following: - add a "distributed by Oracle" comment to the files without Sun or Oracle copyright notices, and rediff - add a GPL2+ license notice to the header of 60zfs_solaris.diff - resubmit the patch according to the submission guidelines, with my sign-off, and Samuel Thibault''s acked-by. Will this be sufficient to clarify the copyright status? Best, Kasper _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Uhm, what is the outcoming of this??? I tried the patch today and succeeded in booting my fresh nexenta with it, so +1 by me. (nexenta needs some grub tweaking as boot/grub/bootsign/syspool is missing as well as a findroot (syspool,0,a) in menu.lst), but then all is fine. Regards, Florian Am 01.11.2011 15:11, schrieb Kasper Brink:> On Wed, Oct 26, 2011 at 02:00:07PM +0100, Ian Jackson wrote: >> But I''m afraid I can''t apply it because I need confirmation of the >> copyright status. See the section on Signed-off-By on >> http://wiki.xen.org/xenwiki/SubmittingXenPatches > > The pv-grub_solaris patch I sent previously is: > > Signed-off-by: Kasper Brink <K.Brink@cs.ru.nl> > > If you want, I will resubmit the patch according to the guidelines on the > wiki, along with any necessary changes to the license and copyright notices. > >> Looking at the contents of your patch I see some worrying things. Can >> you please find the licences for all the code you''re including and >> arrange for appropriate copyright and licensing notices, copies of >> licences, etc. etc. ? > > All the code in my patch was either taken from the "Oracle Solaris 11 Express > 2010.11 GPL Source, Part 2" archive, downloaded from > http://dlc.sun.com/opensourcecode/solaris/sol-11-exp-201011-GPLSource_2.zip, > or written by me (small portions). > > The code is licensed under the GNU GPL, version 2 or later ("GPL2+"). > Each file from which I copied code contains a notice stating that it is > licensed under the GPL2+. Identical notices are present in the unpatched > pv-grub sources, so the diff itself does not contain this information (except > for newly added files). > I will add a GPL2+ notice to the header of the file 60zfs_solaris.diff. The > full GPL 2 license text is already in the Xen repository root, so I assume I > don''t need to add that to the patch. > > The copyright status is a bit more diverse (see the attached list for the full > details): > - all the files I copied code from have an FSF copyright notice > - most of these files also have a Sun Microsystems or Oracle copyright notice > - there are 7 files that contain ZFS- or Solaris-related code, but do not > have Sun or Oracle copyright notices. > My patch preserves the copyright notices for all files, but does not add any > notices that are not present in the archive distributed by Oracle. > > The files that do not have Sun or Oracle copyright notices are: builtins.c, > common.c, disk_io.c, filesys.h, pc_slice.h, shared.h, stage2.c. > I don''t think I should add such notices myself, but I could add a comment > to each file along these lines: > > /* > * Portions of this file are derived from code distributed by Oracle in 2011, > * licensed under the GNU General Public License, version 2 or later. > */ > > > In summary, I propose to do the following: > - add a "distributed by Oracle" comment to the files without Sun or Oracle > copyright notices, and rediff > - add a GPL2+ license notice to the header of 60zfs_solaris.diff > - resubmit the patch according to the submission guidelines, with my sign-off, > and Samuel Thibault''s acked-by. > Will this be sufficient to clarify the copyright status? > > Best, > > Kasper > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Am 08.03.2012 14:58, schrieb Florian Manschwetus:> Uhm, what is the outcoming of this??? I tried the patch today and > succeeded in booting my fresh nexenta with it, so +1 by me. > > (nexenta needs some grub tweaking as boot/grub/bootsign/syspool is > missing as well as a findroot (syspool,0,a) in menu.lst), but then all > is fine. > > Regards, > Florian >I did a lot of research and found that modifying the nexenta menu.lst is a pain (read as, will break easy use as the auto-generated entries have to be edited every time). Looks like the current grub used by nexenta doesn''t need such help, afaik all the code is gpled, so maybe have a look there if you could easily improve your patch to get an pvgrub that works with curretn nexenta as is. Thx for this great job, Florian> Am 01.11.2011 15:11, schrieb Kasper Brink: >> On Wed, Oct 26, 2011 at 02:00:07PM +0100, Ian Jackson wrote: >>> But I''m afraid I can''t apply it because I need confirmation of the >>> copyright status. See the section on Signed-off-By on >>> http://wiki.xen.org/xenwiki/SubmittingXenPatches >> >> The pv-grub_solaris patch I sent previously is: >> >> Signed-off-by: Kasper Brink <K.Brink@cs.ru.nl> >> >> If you want, I will resubmit the patch according to the guidelines on the >> wiki, along with any necessary changes to the license and copyright notices. >> >>> Looking at the contents of your patch I see some worrying things. Can >>> you please find the licences for all the code you''re including and >>> arrange for appropriate copyright and licensing notices, copies of >>> licences, etc. etc. ? >> >> All the code in my patch was either taken from the "Oracle Solaris 11 Express >> 2010.11 GPL Source, Part 2" archive, downloaded from >> http://dlc.sun.com/opensourcecode/solaris/sol-11-exp-201011-GPLSource_2.zip, >> or written by me (small portions). >> >> The code is licensed under the GNU GPL, version 2 or later ("GPL2+"). >> Each file from which I copied code contains a notice stating that it is >> licensed under the GPL2+. Identical notices are present in the unpatched >> pv-grub sources, so the diff itself does not contain this information (except >> for newly added files). >> I will add a GPL2+ notice to the header of the file 60zfs_solaris.diff. The >> full GPL 2 license text is already in the Xen repository root, so I assume I >> don''t need to add that to the patch. >> >> The copyright status is a bit more diverse (see the attached list for the full >> details): >> - all the files I copied code from have an FSF copyright notice >> - most of these files also have a Sun Microsystems or Oracle copyright notice >> - there are 7 files that contain ZFS- or Solaris-related code, but do not >> have Sun or Oracle copyright notices. >> My patch preserves the copyright notices for all files, but does not add any >> notices that are not present in the archive distributed by Oracle. >> >> The files that do not have Sun or Oracle copyright notices are: builtins.c, >> common.c, disk_io.c, filesys.h, pc_slice.h, shared.h, stage2.c. >> I don''t think I should add such notices myself, but I could add a comment >> to each file along these lines: >> >> /* >> * Portions of this file are derived from code distributed by Oracle in 2011, >> * licensed under the GNU General Public License, version 2 or later. >> */ >> >> >> In summary, I propose to do the following: >> - add a "distributed by Oracle" comment to the files without Sun or Oracle >> copyright notices, and rediff >> - add a GPL2+ license notice to the header of 60zfs_solaris.diff >> - resubmit the patch according to the submission guidelines, with my sign-off, >> and Samuel Thibault''s acked-by. >> Will this be sufficient to clarify the copyright status? >> >> Best, >> >> Kasper >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Kasper Brink writes ("Re: [Xen-devel] pv-grub Solaris support"):> On Wed, Oct 26, 2011 at 02:00:07PM +0100, Ian Jackson wrote: > > But I''m afraid I can''t apply it because I need confirmation of the > > copyright status. See the section on Signed-off-By on > > http://wiki.xen.org/xenwiki/SubmittingXenPatches > > The pv-grub_solaris patch I sent previously is: > > Signed-off-by: Kasper Brink <K.Brink@cs.ru.nl> > > If you want, I will resubmit the patch according to the guidelines on the > wiki, along with any necessary changes to the license and copyright notices.I think given the complexity here we do need to have a resubmission with accurate copyright statements and signed-off-by. Sorry. Ian.