Hi, guys, I converted my rootfs to zfs, to boot via grub, I need add "-B $ZFS-BOOTFS" option, as following, kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS But I don''t know how to set this parameter when I want to boot xVM? title Solaris xVM kernel$ /boot/$ISADIR/xen.gz module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix I tried to append "-B $ZFS-BOOTFS" on the "kernel" line and "module" line, but failed to mount the root file system. Do you know how could I do this? This message posted from opensolaris.org
> I converted my rootfs to zfs, to boot via grub, I > need add "-B $ZFS-BOOTFS" option, as following, > > kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS > > But I don''t know how to set this parameter when I want to boot xVM?Did you set the zpool''s default "bootfs" property? If you didn''t (or you have multiple zfs boot filesystems on the pool), you can also set it with the "bootfs" grub command, like this: title Solaris Express Community Edition snv_66 X86 (b66, Xen dom0) root (,0,g) bootfs files/s11-root-xen kernel$ /boot/$ISADIR/xen.gz module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS -vk module$ /platform/i86pc/$ISADIR/boot_archive> I tried to append "-B $ZFS-BOOTFS" on the "kernel" > line and "module" line, but failed to mount the root > file system.What is the exact error message? Is it from grub, or from the Solaris kernel?> Do you know how could I do this?Note that you need grub from snv_75 or newer, otherwise you can''t boot xen from a zfs filesystem; this is bug 6584697, Synopsis: Can''t boot Xen / Solaris dom0 if root is using ZFS http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6584697 This message posted from opensolaris.org
Jürgen Keil wrote:>> I converted my rootfs to zfs, to boot via grub, I >> need add "-B $ZFS-BOOTFS" option, as following, >> >> kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS >> >> But I don''t know how to set this parameter when I want to boot xVM? > > Did you set the zpool''s default "bootfs" property? If you didn''t > (or you have multiple zfs boot filesystems on the pool), > you can also set it with the "bootfs" grub command, like this: > > title Solaris Express Community Edition snv_66 X86 (b66, Xen dom0) > root (,0,g) > bootfs files/s11-root-xen > kernel$ /boot/$ISADIR/xen.gz > module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS -vk > module$ /platform/i86pc/$ISADIR/boot_archive > > >> I tried to append "-B $ZFS-BOOTFS" on the "kernel" >> line and "module" line, but failed to mount the root >> file system. > > What is the exact error message? Is it from grub, or > from the Solaris kernel? > >> Do you know how could I do this? > > Note that you need grub from snv_75 or newer, otherwise > you can''t boot xen from a zfs filesystem; this is bug 6584697, > Synopsis: Can''t boot Xen / Solaris dom0 if root is using ZFS > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6584697stage2/builtins.c -- module_dollar_func() looks wrong to me... I wonder if mb_cmdline += grub_strlen(cmdline_sav) + 1; should be mb_cmdline = cmdline_sav + grub_strlen(cmdline_sav) + 1; since mb_cmdline is modified in module_func(). MRJ -- Mark Johnson <mark.johnson@sun.com> Sun Microsystems, Inc. (781) 442-0869
Hi, jkeil, Thanks so much for the help. And my env is snv_75 x86. Following is my grub configuration: title Solaris xVM bootfs rootpool/rootfs kernel$ /boot/$ISADIR/xen.gz module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS -vk module$ /platform/i86pc/$ISADIR/boot_archive The error messages I got were: WARNING: init(1M) exited with fatal signal 9: restarting automatically ... ... ... ... WARNING: init(1M) exited with fatal signal 9: restarting automatically And the error message kept showing up, and can not stop. Regards, This message posted from opensolaris.org
> Hi, jkeil, > > Thanks so much for the help. And my env is snv_75 x86. > > Following is my grub configuration: > > title Solaris xVM > bootfs rootpool/rootfs > kernel$ /boot/$ISADIR/xen.gz > module$ /platform/i86xpv/kernel/$ISADIR/unix/platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS -vk> module$ /platform/i86pc/$ISADIR/boot_archive > > The error messages I got were: > > WARNING: init(1M) exited with fatal signal 9: restarting automaticallyOk, so it starts to boot just fine from the zfs rootfs! And it must have mounted some kind of root filesystem, too. Kernel is already trying to fork the first user level process, init(1M). But apparently either /sbin/init or one of the shared libraries needed for /sbin/init is missing / corrupted / broken... The dynamic linker would kill it''s own process id with signal 9 if something is seriously wrong with the program''s shared libraries. The only time I got this "init(1M) exited with fatal signal 9" problem was when trying to boot snv_66 or newer on old x86 systems that don''t have SSE support in the CPU, e.g. on boxes with Pentium-II or AMD K7 cpus. In this case init is killed with signal 9, because /lib/libc.so.1 is tagged with "I need SSE support", but Pentium-II / AMD-K7 doesn''t have SSE support. Root cause is that /lib/libc.so.1 shouldn''t be tagged with hwcap "SSE"; that''s bug 6332924: Synopsis: snv_24 /usr/ccs/bin/as adds new HWCAP tags to previously untagged objects http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6332924> ... ... > ... ... > WARNING: init(1M) exited with fatal signal 9: restarting automatically > > And the error message kept showing up, and can not stop.I believe that Joseph Bonasera hit the same problem when he tried to verify / integrate the fix for 6584697; see the description text for bug 6584697: » I''m going to investigate fixing this by locating the GRUB ZFS memory areas dynamically down from the top of physical memory or the 4 Gig addresssibility limit, whichever is lower. So I managed to get a lab system into this setup.. By grub fix worked enough to get Xen to boot and dom0 to make it through startup.. However... startup.c:1970: Enabling interrupts startup.c:1981: startup_end() done startup.c:2072: Unmapping lower boot pages startup.c:2089: Releasing boot pages startup.c:2103: Boot pages released WARNING: init(1M) exited on fatal signal 9: restarting automatically WARNING: init(1M) exited on fatal signal 9: restarting automatically « =============================================== What about this bug: Bug ID: 6423745 Synopsis: zfs root pool created while booted 64 bit can not be booted 32 bit http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6423745 =============================================== And there also is this thread; apparently there are more problems when /usr is on a separate zfs filesystem, but is not in the same zpool as the zfs root: http://www.opensolaris.org/jive/thread.jspa?threadID=40631#158930
I hit the init exited on fatal signal 9 twice: The first time when I created the zfs root while I was still in the 32 bit install environment and before rebooting in 64 bit mode. The second time when I tried to create a zfs root from another zfs root. See: http://www.opensolaris.org/jive/thread.jspa?messageID=163513#163513 If you want to have /usr on a separate pool that will work as long as you copy /usr/lib/libdiskmgt.so* to the root filesystem: umount /zfsroot/usr /usr/sfw/bin/gtar Ccp /usr lib/libdiskmgt.so* | /usr/sfw/bin/gtar Cxp /zfsroot/usr This message posted from opensolaris.org
> The error messages I got were: > > WARNING: init(1M) exited with fatal signal 9: > restarting automaticallyCan you try to boot you standard solaris (non zfs root), then manually mount your rootpool/rootfs at /mnt and verify that these files exist and have the expected elf hwcaps: # mount -F zfs rootpool/rootfs /mnt # file /mnt/sbin/init /mnt/sbin/init: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available # file /mnt/lib/libpam.so.1 /mnt/lib/libpam.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available # file /mnt/lib/libbsm.so.1 /mnt/lib/libbsm.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available # file /mnt/lib/libcontract.so.1 /mnt/lib/libcontract.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available # file /mnt/lib/libscf.so.1 /mnt/lib/libscf.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available # file /mnt/lib/libc.so.1 /mnt/lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [CX8 FPU], dynamically linked, not stripped, no debugging information available This message posted from opensolaris.org
I have destroyed my ufs root slice. Here is the result I got from the running system, the only different one is the /lib/libc.so.1 file /lib/libc.so.1 /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE MMX CMOV SEP CX8 FPU], dynamically linked, not stripped, no debugging information available My laptop has a dual-core intel processor. This message posted from opensolaris.org
Hi, jkeil, My /usr is on the same pool as zfsroot. And I created my rootpool after a normal boot (i.e., it''s 64 bits kernel); and as I can see, the xen.gz is loaded from /boot/amd64. Regards, This message posted from opensolaris.org
Yong Sun wrote:> I have destroyed my ufs root slice. Here is the result I got from the running system, the only different one is the /lib/libc.so.1 > > file /lib/libc.so.1 > /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE MMX CMOV SEP CX8 FPU], dynamically linked, not stripped, no debugging information available > > My laptop has a dual-core intel processor. > > > This message posted from opensolaris.org > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.org >Tha''s strange. All dual core Intel processors also have SSE2 and afaik SSE3 also. Why aren''t the flags showing up? James
Hi James, I''m running Intel Core 2 Duo, the flags are the same: bash-3.2$ file /lib/libc.so.1 /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE MMX CMOV SEP CX8 FPU], dynamically linked, not stripped, no debugging information available I can boot xVM (b75a) from zfs boot (compressed) without any problem. Rgds, Andre W. James Cornell wrote:> Yong Sun wrote: > >> I have destroyed my ufs root slice. Here is the result I got from the running system, the only different one is the /lib/libc.so.1 >> >> file /lib/libc.so.1 >> /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE MMX CMOV SEP CX8 FPU], dynamically linked, not stripped, no debugging information available >> >> My laptop has a dual-core intel processor. >> >> >> This message posted from opensolaris.org >> _______________________________________________ >> xen-discuss mailing list >> xen-discuss@opensolaris.org >> >> > Tha''s strange. All dual core Intel processors also have SSE2 and afaik > SSE3 also. Why aren''t the flags showing up? > > James > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.org >
Hi, Andre, Would you share your grub configuration? And I followed the instructions on http://www.opensolaris.org/os/community/zfs/boot/zfsboot-manual/ to setup my zfs boot. So my grub file is on /rootpool/boot/grub/menu.lst. Regards, Andre Wenas wrote:> Hi James, > > I''m running Intel Core 2 Duo, the flags are the same: > bash-3.2$ file /lib/libc.so.1 > /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE MMX > CMOV SEP CX8 FPU], dynamically linked, not stripped, no debugging > information available > > I can boot xVM (b75a) from zfs boot (compressed) without any problem. > > Rgds, > Andre W. > > James Cornell wrote: >> Yong Sun wrote: >> >>> I have destroyed my ufs root slice. Here is the result I got from >>> the running system, the only different one is the /lib/libc.so.1 >>> >>> file /lib/libc.so.1 >>> /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE MMX >>> CMOV SEP CX8 FPU], dynamically linked, not stripped, no debugging >>> information available >>> >>> My laptop has a dual-core intel processor. >>> >>> >>> This message posted from opensolaris.org >>> _______________________________________________ >>> xen-discuss mailing list >>> xen-discuss@opensolaris.org >>> >> Tha''s strange. All dual core Intel processors also have SSE2 and afaik >> SSE3 also. Why aren''t the flags showing up? >> >> James >> _______________________________________________ >> xen-discuss mailing list >> xen-discuss@opensolaris.org >> >
Andre Wenas wrote:> Hi James, > > I''m running Intel Core 2 Duo, the flags are the same: > bash-3.2$ file /lib/libc.so.1 > /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE MMX > CMOV SEP CX8 FPU], dynamically linked, not stripped, no debugging > information available > > I can boot xVM (b75a) from zfs boot (compressed) without any problem. > > Rgds, > Andre W. > > James Cornell wrote: >> Yong Sun wrote: >> >>> I have destroyed my ufs root slice. Here is the result I got from >>> the running system, the only different one is the /lib/libc.so.1 >>> >>> file /lib/libc.so.1 >>> /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE MMX >>> CMOV SEP CX8 FPU], dynamically linked, not stripped, no debugging >>> information available >>> >>> My laptop has a dual-core intel processor. >>> >>> >>> This message posted from opensolaris.org >>> _______________________________________________ >>> xen-discuss mailing list >>> xen-discuss@opensolaris.org >>> >> Tha''s strange. All dual core Intel processors also have SSE2 and afaik >> SSE3 also. Why aren''t the flags showing up? >> >> James >> _______________________________________________ >> xen-discuss mailing list >> xen-discuss@opensolaris.org >> >Ah, I see, libc is only sse/mmx aware. Did you build xVM from source? Or is there binaries somewhere, they were supposed to be out a few days ago. Can you tell me what build steps you used, since the instructions are dated? James
Hi Yong Sun, Here is my grub menu.lst: # boot title Solaris xVM 75 ZFS root (hd0,2,e) bootfs xenpool/snv_75 kernel$ /boot/$ISADIR/xen.gz module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS module$ /platform/i86pc/$ISADIR/boot_archive bash-3.2$ df -k / Filesystem kbytes used avail capacity Mounted on xenpool/snv_75 6451200 3220132 3055481 52% / The filesystem is compressed: bash-3.2$ zfs get compression xenpool/snv_75 NAME PROPERTY VALUE SOURCE xenpool/snv_75 compression on local bash-3.2$ zfs get compressratio xenpool/snv_75 NAME PROPERTY VALUE SOURCE xenpool/snv_75 compressratio 1.74x - /etc/vfstab: xenpool/snv_75 - / zfs - no - bash-3.2$ sudo xm list Name ID Mem VCPUs State Time(s) Domain-0 0 1874 2 r----- 107.7 Based on experience few mistake that can cause zfs root doesn''t work: * Must use latest stage1 stage2 files when you do installgrub. Sometimes when you install new build, you are still using old stage* files from earlier build. * Don''t forget to set zfs mountpoint=legacy * Wrong entry in vfstab * Forget to modify /boot/solaris/filelist.ramdisk to include /etc/zfs/zpool.cache * Forget to re-create bootarchive. Rgds, Andre W. Yong Sun wrote:> Hi, Andre, > > Would you share your grub configuration? And I followed the instructions > on http://www.opensolaris.org/os/community/zfs/boot/zfsboot-manual/ to > setup my zfs boot. So my grub file is on /rootpool/boot/grub/menu.lst. > > Regards, > > Andre Wenas wrote: > >> Hi James, >> >> I''m running Intel Core 2 Duo, the flags are the same: >> bash-3.2$ file /lib/libc.so.1 >> /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE MMX >> CMOV SEP CX8 FPU], dynamically linked, not stripped, no debugging >> information available >> >> I can boot xVM (b75a) from zfs boot (compressed) without any problem. >> >> Rgds, >> Andre W. >> >> James Cornell wrote: >> >>> Yong Sun wrote: >>> >>> >>>> I have destroyed my ufs root slice. Here is the result I got from >>>> the running system, the only different one is the /lib/libc.so.1 >>>> >>>> file /lib/libc.so.1 >>>> /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE MMX >>>> CMOV SEP CX8 FPU], dynamically linked, not stripped, no debugging >>>> information available >>>> >>>> My laptop has a dual-core intel processor. >>>> >>>> >>>> This message posted from opensolaris.org >>>> _______________________________________________ >>>> xen-discuss mailing list >>>> xen-discuss@opensolaris.org >>>> >>>> >>> Tha''s strange. All dual core Intel processors also have SSE2 and afaik >>> SSE3 also. Why aren''t the flags showing up? >>> >>> James >>> _______________________________________________ >>> xen-discuss mailing list >>> xen-discuss@opensolaris.org >>> >>> > > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.org >
Hi, Andre, Thanks so much for sharing your configuration. > Based on experience few mistake that can cause zfs root doesn''t work: > * Must use latest stage1 stage2 files when you do installgrub. Sometimes when you install > new build, you are still using old stage* files from earlier build. > * Don''t forget to set zfs mountpoint=legacy > * Wrong entry in vfstab > * Forget to modify /boot/solaris/filelist.ramdisk to include /etc/zfs/zpool.cache > * Forget to re-create bootarchive. I think I had done correct steps, since I could boot off zfs-root with non-xVM kernel. But I failed to boot zfsroot with xVM, do you have any idea about that? Regards, Andre Wenas wrote:> Hi Yong Sun, > > Here is my grub menu.lst: > # boot > title Solaris xVM 75 ZFS > root (hd0,2,e) > bootfs xenpool/snv_75 > kernel$ /boot/$ISADIR/xen.gz > module$ /platform/i86xpv/kernel/$ISADIR/unix > /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS > module$ /platform/i86pc/$ISADIR/boot_archive > > bash-3.2$ df -k / > Filesystem kbytes used avail capacity Mounted on > xenpool/snv_75 6451200 3220132 3055481 52% / > > The filesystem is compressed: > bash-3.2$ zfs get compression xenpool/snv_75 > NAME PROPERTY VALUE SOURCE > xenpool/snv_75 compression on local > > bash-3.2$ zfs get compressratio xenpool/snv_75 > NAME PROPERTY VALUE SOURCE > xenpool/snv_75 compressratio 1.74x - > > /etc/vfstab: > xenpool/snv_75 - / zfs - no - > > bash-3.2$ sudo xm list > Name ID Mem VCPUs State > Time(s) > Domain-0 0 1874 2 r----- > 107.7 > > Based on experience few mistake that can cause zfs root doesn''t work: > * Must use latest stage1 stage2 files when you do installgrub. > Sometimes when you install new build, you are still using old stage* > files from earlier build. > * Don''t forget to set zfs mountpoint=legacy > * Wrong entry in vfstab > * Forget to modify /boot/solaris/filelist.ramdisk to include > /etc/zfs/zpool.cache > * Forget to re-create bootarchive. > > Rgds, > Andre W. > > Yong Sun wrote: >> Hi, Andre, >> >> Would you share your grub configuration? And I followed the >> instructions on >> http://www.opensolaris.org/os/community/zfs/boot/zfsboot-manual/ to >> setup my zfs boot. So my grub file is on /rootpool/boot/grub/menu.lst. >> >> Regards, >> >> Andre Wenas wrote: >> >>> Hi James, >>> >>> I''m running Intel Core 2 Duo, the flags are the same: >>> bash-3.2$ file /lib/libc.so.1 >>> /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE MMX >>> CMOV SEP CX8 FPU], dynamically linked, not stripped, no debugging >>> information available >>> >>> I can boot xVM (b75a) from zfs boot (compressed) without any problem. >>> >>> Rgds, >>> Andre W. >>> >>> James Cornell wrote: >>> >>>> Yong Sun wrote: >>>> >>>> >>>>> I have destroyed my ufs root slice. Here is the result I got from >>>>> the running system, the only different one is the /lib/libc.so.1 >>>>> >>>>> file /lib/libc.so.1 >>>>> /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE >>>>> MMX CMOV SEP CX8 FPU], dynamically linked, not stripped, no >>>>> debugging information available >>>>> >>>>> My laptop has a dual-core intel processor. >>>>> >>>>> >>>>> This message posted from opensolaris.org >>>>> _______________________________________________ >>>>> xen-discuss mailing list >>>>> xen-discuss@opensolaris.org >>>>> >>>> Tha''s strange. All dual core Intel processors also have SSE2 and >>>> afaik >>>> SSE3 also. Why aren''t the flags showing up? >>>> >>>> James >>>> _______________________________________________ >>>> xen-discuss mailing list >>>> xen-discuss@opensolaris.org >>>> >> >> _______________________________________________ >> xen-discuss mailing list >> xen-discuss@opensolaris.org >> >
Can you boot xVM using ufs root ? Yong Sun wrote:> Hi, Andre, > > Thanks so much for sharing your configuration. > > > Based on experience few mistake that can cause zfs root doesn''t work: > > * Must use latest stage1 stage2 files when you do installgrub. > Sometimes when you install > > new build, you are still using old stage* files from earlier build. > > * Don''t forget to set zfs mountpoint=legacy > > * Wrong entry in vfstab > > * Forget to modify /boot/solaris/filelist.ramdisk to include > /etc/zfs/zpool.cache > > * Forget to re-create bootarchive. > > I think I had done correct steps, since I could boot off zfs-root with > non-xVM kernel. But I failed to boot zfsroot with xVM, do you have any > idea about that? > > Regards, > > Andre Wenas wrote: > >> Hi Yong Sun, >> >> Here is my grub menu.lst: >> # boot >> title Solaris xVM 75 ZFS >> root (hd0,2,e) >> bootfs xenpool/snv_75 >> kernel$ /boot/$ISADIR/xen.gz >> module$ /platform/i86xpv/kernel/$ISADIR/unix >> /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS >> module$ /platform/i86pc/$ISADIR/boot_archive >> >> bash-3.2$ df -k / >> Filesystem kbytes used avail capacity Mounted on >> xenpool/snv_75 6451200 3220132 3055481 52% / >> >> The filesystem is compressed: >> bash-3.2$ zfs get compression xenpool/snv_75 >> NAME PROPERTY VALUE SOURCE >> xenpool/snv_75 compression on local >> >> bash-3.2$ zfs get compressratio xenpool/snv_75 >> NAME PROPERTY VALUE SOURCE >> xenpool/snv_75 compressratio 1.74x - >> >> /etc/vfstab: >> xenpool/snv_75 - / zfs - no - >> >> bash-3.2$ sudo xm list >> Name ID Mem VCPUs State >> Time(s) >> Domain-0 0 1874 2 r----- >> 107.7 >> >> Based on experience few mistake that can cause zfs root doesn''t work: >> * Must use latest stage1 stage2 files when you do installgrub. >> Sometimes when you install new build, you are still using old stage* >> files from earlier build. >> * Don''t forget to set zfs mountpoint=legacy >> * Wrong entry in vfstab >> * Forget to modify /boot/solaris/filelist.ramdisk to include >> /etc/zfs/zpool.cache >> * Forget to re-create bootarchive. >> >> Rgds, >> Andre W. >> >> Yong Sun wrote: >> >>> Hi, Andre, >>> >>> Would you share your grub configuration? And I followed the >>> instructions on >>> http://www.opensolaris.org/os/community/zfs/boot/zfsboot-manual/ to >>> setup my zfs boot. So my grub file is on /rootpool/boot/grub/menu.lst. >>> >>> Regards, >>> >>> Andre Wenas wrote: >>> >>> >>>> Hi James, >>>> >>>> I''m running Intel Core 2 Duo, the flags are the same: >>>> bash-3.2$ file /lib/libc.so.1 >>>> /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE MMX >>>> CMOV SEP CX8 FPU], dynamically linked, not stripped, no debugging >>>> information available >>>> >>>> I can boot xVM (b75a) from zfs boot (compressed) without any problem. >>>> >>>> Rgds, >>>> Andre W. >>>> >>>> James Cornell wrote: >>>> >>>> >>>>> Yong Sun wrote: >>>>> >>>>> >>>>> >>>>>> I have destroyed my ufs root slice. Here is the result I got from >>>>>> the running system, the only different one is the /lib/libc.so.1 >>>>>> >>>>>> file /lib/libc.so.1 >>>>>> /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE >>>>>> MMX CMOV SEP CX8 FPU], dynamically linked, not stripped, no >>>>>> debugging information available >>>>>> >>>>>> My laptop has a dual-core intel processor. >>>>>> >>>>>> >>>>>> This message posted from opensolaris.org >>>>>> _______________________________________________ >>>>>> xen-discuss mailing list >>>>>> xen-discuss@opensolaris.org >>>>>> >>>>>> >>>>> Tha''s strange. All dual core Intel processors also have SSE2 and >>>>> afaik >>>>> SSE3 also. Why aren''t the flags showing up? >>>>> >>>>> James >>>>> _______________________________________________ >>>>> xen-discuss mailing list >>>>> xen-discuss@opensolaris.org >>>>> >>>>> >>> _______________________________________________ >>> xen-discuss mailing list >>> xen-discuss@opensolaris.org >>> >>> > > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.org >
Hi, Andre, Yes, I used to boot xVM using ufs root, but now I had destroyed my ufs root slice :( Regards, Andre Wenas wrote:> Can you boot xVM using ufs root ? > > Yong Sun wrote: >> Hi, Andre, >> >> Thanks so much for sharing your configuration. >> >> > Based on experience few mistake that can cause zfs root doesn''t work: >> > * Must use latest stage1 stage2 files when you do installgrub. >> Sometimes when you install >> > new build, you are still using old stage* files from earlier >> build. >> > * Don''t forget to set zfs mountpoint=legacy >> > * Wrong entry in vfstab >> > * Forget to modify /boot/solaris/filelist.ramdisk to include >> /etc/zfs/zpool.cache >> > * Forget to re-create bootarchive. >> >> I think I had done correct steps, since I could boot off zfs-root >> with non-xVM kernel. But I failed to boot zfsroot with xVM, do you >> have any idea about that? >> >> Regards, >> >> Andre Wenas wrote: >> >>> Hi Yong Sun, >>> >>> Here is my grub menu.lst: >>> # boot >>> title Solaris xVM 75 ZFS >>> root (hd0,2,e) >>> bootfs xenpool/snv_75 >>> kernel$ /boot/$ISADIR/xen.gz >>> module$ /platform/i86xpv/kernel/$ISADIR/unix >>> /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS >>> module$ /platform/i86pc/$ISADIR/boot_archive >>> >>> bash-3.2$ df -k / >>> Filesystem kbytes used avail capacity Mounted on >>> xenpool/snv_75 6451200 3220132 3055481 52% / >>> >>> The filesystem is compressed: >>> bash-3.2$ zfs get compression xenpool/snv_75 >>> NAME PROPERTY VALUE SOURCE >>> xenpool/snv_75 compression on local >>> >>> bash-3.2$ zfs get compressratio xenpool/snv_75 >>> NAME PROPERTY VALUE SOURCE >>> xenpool/snv_75 compressratio 1.74x - >>> >>> /etc/vfstab: >>> xenpool/snv_75 - / zfs - no - >>> >>> bash-3.2$ sudo xm list >>> Name ID Mem VCPUs >>> State Time(s) >>> Domain-0 0 1874 2 >>> r----- 107.7 >>> >>> Based on experience few mistake that can cause zfs root doesn''t work: >>> * Must use latest stage1 stage2 files when you do installgrub. >>> Sometimes when you install new build, you are still using old stage* >>> files from earlier build. >>> * Don''t forget to set zfs mountpoint=legacy >>> * Wrong entry in vfstab >>> * Forget to modify /boot/solaris/filelist.ramdisk to include >>> /etc/zfs/zpool.cache >>> * Forget to re-create bootarchive. >>> >>> Rgds, >>> Andre W. >>> >>> Yong Sun wrote: >>> >>>> Hi, Andre, >>>> >>>> Would you share your grub configuration? And I followed the >>>> instructions on >>>> http://www.opensolaris.org/os/community/zfs/boot/zfsboot-manual/ to >>>> setup my zfs boot. So my grub file is on /rootpool/boot/grub/menu.lst. >>>> >>>> Regards, >>>> >>>> Andre Wenas wrote: >>>> >>>> >>>>> Hi James, >>>>> >>>>> I''m running Intel Core 2 Duo, the flags are the same: >>>>> bash-3.2$ file /lib/libc.so.1 >>>>> /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE >>>>> MMX CMOV SEP CX8 FPU], dynamically linked, not stripped, no >>>>> debugging information available >>>>> >>>>> I can boot xVM (b75a) from zfs boot (compressed) without any problem. >>>>> >>>>> Rgds, >>>>> Andre W. >>>>> >>>>> James Cornell wrote: >>>>> >>>>>> Yong Sun wrote: >>>>>> >>>>>> >>>>>>> I have destroyed my ufs root slice. Here is the result I got >>>>>>> from the running system, the only different one is the >>>>>>> /lib/libc.so.1 >>>>>>> >>>>>>> file /lib/libc.so.1 >>>>>>> /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE >>>>>>> MMX CMOV SEP CX8 FPU], dynamically linked, not stripped, no >>>>>>> debugging information available >>>>>>> >>>>>>> My laptop has a dual-core intel processor. >>>>>>> >>>>>>> >>>>>>> This message posted from opensolaris.org >>>>>>> _______________________________________________ >>>>>>> xen-discuss mailing list >>>>>>> xen-discuss@opensolaris.org >>>>>>> >>>>>> Tha''s strange. All dual core Intel processors also have SSE2 and >>>>>> afaik >>>>>> SSE3 also. Why aren''t the flags showing up? >>>>>> >>>>>> James >>>>>> _______________________________________________ >>>>>> xen-discuss mailing list >>>>>> xen-discuss@opensolaris.org >>>>>> >>>> _______________________________________________ >>>> xen-discuss mailing list >>>> xen-discuss@opensolaris.org >>>> >> >> _______________________________________________ >> xen-discuss mailing list >> xen-discuss@opensolaris.org >> >
> I have destroyed my ufs root slice. Here is the > result I got from the running system, the only > different one is the /lib/libc.so.1 > > file /lib/libc.so.1 > /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 > Version 1 [SSE MMX CMOV SEP CX8 FPU], dynamically > linked, not stripped, no debugging information > availableHmm, I think the problem with the above file command is that it doesn''t show the information for the lib/libc.so.1 file in the root filesystem, but the information for the special "hwcap" optimized libc.so variant that is loopback mounted on top of the /lib/libc.so.1 file. That is, if you check with "mount | grep libc.so", you''ll probably notice that some /usr/lib/libc/libc_hwcap?.so.1 file is currently mounted on top of /lib/libc.so.1 When you''ve booted on metal, try this: # mount -F lofs -o nosub / /mnt # file /mnt/lib/libc.so.1 /mnt/lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [CX8 FPU], dynamically linked, not stripped, no debugging information available> My laptop has a dual-core intel processor. > > $ psrinfo -vp > The physical processor has 2 virtual processors (0 1) > x86 (GenuineIntel 6F2 family 6 model 15 step 2 clock 1829 MHz) > Intel(r) Core(tm)2 CPU T5600 @ 1.83GHz > > $ isainfo -v > 64-bit amd64 applications > cx16 mon sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu > 2-bit i386 applications > ahf cx16 mon sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpuHmm, my current theory is that under xVM, the "sep" cpuid feature isn''t available. The zfs root procedure has copied the /usr/lib/libc/libc_hwcap1.so.1 file (which was mounted on top of the unoptimized /lib/libc.so.1 file on metal) as lib/libc.so.1 in the root filesystem. When you boot into xVM dom0, "sep" isn''t available, so a lib/libc.so.1 that requires the "SEP" cpu feature cannot be used and the dynamic linker kills the /sbin/init process with signal 9. If that theory is correct, you have to restore the original root filesystem /lib/libc.so.1 file from the installation media. Restoring that lib/libc.so.1 file in the root filesystem probably works best when you havn''t mounted that filesystem as root filesystem, otherwise the file in the root filesystem is hidden by the optimized libc shared library mounted on top of it. Booting into solaris failsafe, mounting the zfs root filesystem under /a and fixing /a/lib/libc.so.1 should work. This message posted from opensolaris.org
James Cornell wrote:> Yong Sun wrote: > > I have destroyed my ufs root slice. Here is the result I got from the running system, the only different one is the /lib/libc.so.1 > > > > file /lib/libc.so.1 > > /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE MMX CMOV SEP CX8 FPU], dynamically linked, not stripped, no debugging information available > > > > My laptop has a dual-core intel processor. > > That''s strange. All dual core Intel processors also > have SSE2 and afaik SSE3 also. Why aren''t the flags showing up?There is a /usr/lib/libc/libc_hwcap2.so.1 shared C library with SSE2 support, but this library also needs AMD system call support; which probably isn''t available with Intel Core processors: /usr/lib/libc/libc_hwcap2.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE2 SSE MMX CMOV AMD_SYSC CX8 FPU], dynamically linked, not stripped, no debugging information available So the best one usable on Intel Core processors is the /usr/lib/libc/libc_hwcap1.so.1 one... This message posted from opensolaris.org
Hi, Jürgen, Thank you so much, it works now!!! Regards, Jürgen Keil wrote:>> I have destroyed my ufs root slice. Here is the >> result I got from the running system, the only >> different one is the /lib/libc.so.1 >> >> file /lib/libc.so.1 >> /lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 >> Version 1 [SSE MMX CMOV SEP CX8 FPU], dynamically >> linked, not stripped, no debugging information >> available >> > > Hmm, I think the problem with the above file command is > that it doesn''t show the information for the lib/libc.so.1 file > in the root filesystem, but the information for the special > "hwcap" optimized libc.so variant that is loopback mounted > on top of the /lib/libc.so.1 file. > > That is, if you check with "mount | grep libc.so", you''ll > probably notice that some /usr/lib/libc/libc_hwcap?.so.1 > file is currently mounted on top of /lib/libc.so.1 > > When you''ve booted on metal, try this: > > # mount -F lofs -o nosub / /mnt > # file /mnt/lib/libc.so.1 > /mnt/lib/libc.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [CX8 FPU], dynamically linked, not stripped, no debugging information available > > > >> My laptop has a dual-core intel processor. >> >> $ psrinfo -vp >> The physical processor has 2 virtual processors (0 1) >> x86 (GenuineIntel 6F2 family 6 model 15 step 2 clock 1829 MHz) >> Intel(r) Core(tm)2 CPU T5600 @ 1.83GHz >> >> $ isainfo -v >> 64-bit amd64 applications >> cx16 mon sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu >> 2-bit i386 applications >> ahf cx16 mon sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu >> > > Hmm, my current theory is that under xVM, the "sep" cpuid feature > isn''t available. The zfs root procedure has copied the > /usr/lib/libc/libc_hwcap1.so.1 file (which was mounted on top of > the unoptimized /lib/libc.so.1 file on metal) as lib/libc.so.1 in the > root filesystem. When you boot into xVM dom0, "sep" isn''t available, > so a lib/libc.so.1 that requires the "SEP" cpu feature cannot be used > and the dynamic linker kills the /sbin/init process with signal 9. > > > If that theory is correct, you have to restore the original > root filesystem /lib/libc.so.1 file from the installation media. > Restoring that lib/libc.so.1 file in the root filesystem probably > works best when you havn''t mounted that filesystem as root > filesystem, otherwise the file in the root filesystem is hidden > by the optimized libc shared library mounted on top of it. > > Booting into solaris failsafe, mounting the zfs root > filesystem under /a and fixing /a/lib/libc.so.1 should work. > > > This message posted from opensolaris.org > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.org >