xen discuss - May 2009 - Re: Is there such thing like kernel-headers for Solaris ?

To build the kernel bits you have to do something like this:

download and install the build tools:

    wget http://dlc.sun.com/osol/on/downloads/b115/SUNWonbld.i386.tar.bz2
    cp SUNWonbld.i386.tar.bz2 /tmp
    bunzip2 /tmp/SUNWonbld.i386.tar.bz2
    (cd /tmp; tar xf SUNWonbld.i386.tar.bz2)

su to root, and:

    pkgadd -d /tmp SUNWonbld


After the package is installed, quit from the root shell.


setup the opensolaris.sh file (back to you normal user userid, in the onnv-3.4
directory):

    cp usr/src/tools/env/opensolaris.sh .


edit the opensolaris.sh file that we''ve copied to the onnv-3.4
directory;
variables you need to change are:

    GATE:
        GATE=onnv-3.4;

    CODEMGR_WS:
        change /export to the directory where you unpacked onnv-3.4

    STAFFER:
        change it to your Solaris login username (the build logs are mailed
        to this account)

    SPRO_ROOT:
        set it to the directory where you''ve installed the studio12
compiler,
        in case you didn''t use the default of /opt/SUNWspro



Make sure that the onbuild tools and the sun studio12 compiler is in your $PATH

    export PATH=/opt/onbld/bin:/opt/SUNWspro/bin:$PATH


It seems there is a problem with the iprb driver when building onnv-3.4 outside
of Sun,
so I had to modify one Makefile:

% hg diff
diff --git a/usr/src/pkgdefs/SUNWos86r/Makefile
b/usr/src/pkgdefs/SUNWos86r/Makefile
--- a/usr/src/pkgdefs/SUNWos86r/Makefile
+++ b/usr/src/pkgdefs/SUNWos86r/Makefile
@@ -31,7 +31,7 @@ MACHDATAFILES += i.sdconf
 CLOBBERFILES += $(MACHDATAFILES)
 
 LICENSEFILES += $(OSBL)
-LICENSEFILES += ../../../closed/uts/intel/io/iprb/THIRDPARTYLICENSE
+$(CLOSED_BUILD)LICENSEFILES +=
../../../closed/uts/intel/io/iprb/THIRDPARTYLICENSE
 
 .KEEP_STATE:



Build everything, from the onnv-3.4 directory:

    nightly opensolaris.sh




When the build is complete you should receive an email message
with subject "Nightly i386 Build of onnv-3.4 Completed."

In case there are failures, you''ll find log files in the
onnv-3.4/log/log-2009-MM-DD... subdirectories (it uses
a current timestamp as part of the directory name).


                     ============================
Assuming the onnv-3.4 build completed without errror, you
can install the compiled bits like this:

Snapshot and clone your zfs root filesystem

    zfs snapshot rpool/ROOT/snv-114@onnv-3.4
    zfs clone -o mountpoint=legacy rpool/ROOT/snv-114@onnv-3.4
rpool/ROOT/onnv-3.4

Mount the cloned zfs root and install (bfu) the compiled onnv-3.4 bits:

    mount -F zfs rpool/ROOT/onnv-3.4 /mnt


    PATH=/opt/onbld/bin:$PATH

    FASTFS=/opt/onbld/bin/`uname -p`/fastfs
    BFULD=/opt/onbld/bin/`uname -p`/bfuld
    EXTRACT_HOSTID=/opt/onbld/bin/`uname -p`/extract_hostid
    ACR=/opt/onbld/bin/acr
    GZIPBIN=/usr/bin/gzip

    export PATH FASTFS BFULD ACR GZIPBIN EXTRACT_HOSTID

    bfu /export/onnv-3.4/archives/i386/nightly-nd /mnt


When the bfu script has completed a shell is started. Run
the automatic conflict resolution utility for the root directory
that you''ve just upgraded:

    acr /mnt


After acr has completed quit from shell.

Now you have to construct a new grub boot entry for the new
zfs root; edit /rpool/boot/grub/menu.lst; the new boot 
entries should look like this:


title Solaris Express Community Edition (onnv-3.4)
bootfs rpool/ROOT/onnv-3.4
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS -kv
module$ /platform/i86pc/$ISADIR/boot_archive

title Solaris xVM (onnv-3.4)
bootfs rpool/ROOT/onnv-3.4
kernel$ /boot/$ISADIR/xen.gz com1=9600,8n1 console=vga
module$ /platform/i86xpv/kernel/$ISADIR/unix
/platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS -kv
module$ /platform/i86pc/$ISADIR/boot_archive


Reboot.

Try to boot the first entry "Solaris Express Community Edition
(onnv-3.4)".
This should boot using the new onnv-3.4 kernel, but without xen / xvm 
support.

When it works ok, reboot, and try the second entry "Solaris xVM
(onnv-3.4)".
This should boot the new xen / xvm enabled dom0 kernel.
-- 
This message posted from opensolaris.org

Stuck at this point

-bash-3.2# nightly opensolaris.sh
/tmp/onnv-3.4_nightly.lock: No such file or directory
i386 build of onnv-3.4 apparently already started by  on  as .

I was waiting for about 20 minutes at this point...Should I wait longer ?
Nothing under log folders.

Thanks for the help.
-- 
This message posted from opensolaris.org

> Stuck at this point
> 
> -bash-3.2# nightly opensolaris.sh
> /tmp/onnv-3.4_nightly.lock: No such file or directory
> i386 build of onnv-3.4 apparently already started by  on  as .
> 
Are you trying to build when logged in as user root?

I''m building as a non-root user; I''m buildig under
the ${STAFFER} user.

I suspect it is failing in the /opt/onbld/bin/nightly script in the
create_lock() shell function:


create_lock() {
	lockf=$1
	lockvar=$2

	ldir=`dirname $lockf`
	[ -d $ldir ] || newdir $ldir || exit 1
	eval $lockvar=$lockf

	while ! staffer ln -s $hostname.$STAFFER.$$ $lockf 2> /dev/null; do
        ....




The "staffer" command is an internal shell function in the nightly
script that tries to run a command under the userid ${STAFFER};
I suspect STAFFER isn''t set to a valid user name for your system.


In case this doesn''t help fixing the problem, try to remove the
"2> /dev/null"
stderr output redirect in the above "staffer ln -s  ..." command in
the /opt/onbld/bin/nightly script, so that you can see the error
message that is reported here...

> I was waiting for about 20 minutes at this
> point...Should I wait longer ?
> Nothing under log folders.
I suspect it is looping in the create_lock function,
thinking that another compilation is already running
because the lock symbolic link cannot be created.

Btw. the full nightly compilation can take some time,
my 2GHz dual core cpu systems need 2 - 2.5 hours
for the full compilation. And that''s with disabled 
"shadow compilation" (export CW_NO_SHADOW=1)
so that each file is compiled with SunC only, and
not twice with SunC and gcc.
-- 
This message posted from opensolaris.org

Ok.Everything worked out except I cannot boot into "Solaris xVM
(onnv-3.4)"

It stucks(See attached screenshot)


Booting into "Solaris Express Community Edition (onnv-3.4)" is OK

Please advice.Thanks.
-- 
This message posted from opensolaris.org

> Ok.Everything worked out except I cannot boot into
> "Solaris xVM (onnv-3.4)"
> 
> It stucks(See screenshot here
> 
> http://cmsintegra.com/xvm_logs/message.jpg
Is that perhaps the xvm 3.4 dom0 MSI interrupt issue?

  http://mail.opensolaris.org/pipermail/xen-discuss/2009-June/004427.html
-- 
This message posted from opensolaris.org

Bingo !!!
That was it.
Everything works! Finally I can move my freebsd stuff from esx...By-by vmware !

One probably last question.Is there reason why kernel boots with "DEBUG
ENABLED" mode ? Is it possible turn it off ?

Many,many thanks.
-- 
This message posted from opensolaris.org

> Is there reason why kernel
> boots with "DEBUG ENABLED" mode ? Is it possible turn it off ?
The kernel can be compiled with full debugging enabled,
or it can be compiled as release binary bits.

This is controlled by the -D and -F NIGHTLY_OPTIONS
in the opensolaris.sh file.  If you remove the -D -F options
and recompile with "nightly opensolaris.sh" you''ll get
release binaries ( onnv-3.4/archives/i386/nightly-nd/ )
-- 
This message posted from opensolaris.org

Probably I''m missing something.I removed ''D'' and
''F'' options from opensolaris.sh

Changed the following line
from
NIGHTLY_OPTIONS="-FNnaCDlmrt";
To
NIGHTLY_OPTIONS="-NnaClmrt";

rerun
nightly opensolaris.sh

And repeated the whole process:

zfs snapshot rpool/ROOT/snv_114@onnv-3.4-nodebug
zfs clone -o mountpoint=legacy rpool/ROOT/snv_114@onnv-3.4-nodebug
rpool/ROOT/onnv-3.4-nodebug
mount -F zfs rpool/ROOT/onnv-3.4-nodebug /mnt
bfu /root/onnv-3.4/archives/i386/nightly /mnt
acr /mnt

Adjusted menu.lst boot option to "rpool/ROOT/onnv-3.4-nodebug"

Rebooted ,selected a right option from boot menu,but still boots with
''DEBUG ENABLED'' mode.

Please advice.
Thanks a lot.
-- 
This message posted from opensolaris.org

On Sat, 06 Jun 2009 16:04:51 -0700 (PDT)
Alex Gor <no-reply@opensolaris.org> wrote:
> Probably I''m missing something.I removed ''D'' and
''F'' options from opensolaris.sh
> 
> Changed the following line
> from
> NIGHTLY_OPTIONS="-FNnaCDlmrt";
> To
> NIGHTLY_OPTIONS="-NnaClmrt";
> 
> rerun
> nightly opensolaris.sh
> 
> And repeated the whole process:
> 
> zfs snapshot rpool/ROOT/snv_114@onnv-3.4-nodebug
> zfs clone -o mountpoint=legacy rpool/ROOT/snv_114@onnv-3.4-nodebug
rpool/ROOT/onnv-3.4-nodebug
> mount -F zfs rpool/ROOT/onnv-3.4-nodebug /mnt
> bfu /root/onnv-3.4/archives/i386/nightly /mnt
> acr /mnt
> 
> Adjusted menu.lst boot option to "rpool/ROOT/onnv-3.4-nodebug"
> 
> Rebooted ,selected a right option from boot menu,but still boots with
''DEBUG ENABLED'' mode.
Did you set the bootfs property on rpool before rebooting??

# zpool set bootfs=rpool/ROOT/onnv-3.4-nodebug rpool
# reboot



James C. McPherson
--
Senior Kernel Software Engineer, Solaris
Sun Microsystems
http://blogs.sun.com/jmcp	http://www.jmcp.homeunix.com/blog
Kernel Conference Australia - http://au.sun.com/sunnews/events/2009/kernel

Alex Gor wrote:
> Probably I''m missing something.I removed ''D'' and
''F'' options from opensolaris.sh
> 
> Changed the following line
> from
> NIGHTLY_OPTIONS="-FNnaCDlmrt";
> To
> NIGHTLY_OPTIONS="-NnaClmrt";
> 
> rerun
> nightly opensolaris.sh
> 
> And repeated the whole process:
> 
> zfs snapshot rpool/ROOT/snv_114@onnv-3.4-nodebug
> zfs clone -o mountpoint=legacy rpool/ROOT/snv_114@onnv-3.4-nodebug
rpool/ROOT/onnv-3.4-nodebug
> mount -F zfs rpool/ROOT/onnv-3.4-nodebug /mnt
> bfu /root/onnv-3.4/archives/i386/nightly /mnt
this should be
bfu /root/onnv-3.4/archives/i386/nightly-nd /mnt

> acr /mnt
> 
> Adjusted menu.lst boot option to "rpool/ROOT/onnv-3.4-nodebug"
> 
> Rebooted ,selected a right option from boot menu,but still boots with
''DEBUG ENABLED'' mode.
> 
> Please advice.
> Thanks a lot.

Thanks Mark,that made a trick.
Also I removed -kv option from menu.lst to disable verbose mode.

Huge Thanks everyone for helping me in that issue.
Special thank to Jürgen.
-- 
This message posted from opensolaris.org
_______________________________________________
xen-discuss mailing list
xen-discuss@opensolaris.org