What I know, What I don't know: Share what you know and what you don't know with Colin Zou. :-)

My desktop was installed solaris before zfs integrated. I upgraded it to build 93 via live upgrade first. Then, I want it run on zfs root. The following is the detail steps I migrate it to zfs. Not difficult, not very straightforward.

# lustatus
Boot Environment           Is       Active Active    Can    Copy     Name                       Complete Now    On Reboot Delete Status   -------------------------- -------- ------ --------- ------ ----------
1                          yes      yes    yes       no     -      

2                          yes      no     no        yes    -      

# lufslist 2
              boot environment name: 2

Filesystem              fstype    device size Mounted on          Mount Options
----------------------- -------- ------------ ------------------- --------------
/dev/dsk/c1t0d0s1       swap       2640314880 -                   -
/dev/dsk/c1t0d0s3       ufs       19732446720 /                   -
/dev/dsk/c1t0d0s7       ufs      157086397440 /export/home        -


# lufslist 1
              boot environment name: 1
              This boot environment is currently active.
              This boot environment will be active on next system boot.

Filesystem              fstype    device size Mounted on          Mount Options
----------------------- -------- ------------ ------------------- --------------
/dev/dsk/c1t0d0s1       swap       2640314880 -                   -
/dev/dsk/c1t0d0s0       ufs       19740672000 /                   -
/dev/dsk/c1t0d0s7       ufs      157086397440 /export/home        -

# ludelete 2
System has findroot enabled GRUB
Checking if last BE on any disk...
BE <2> is not the last BE on any disk.
Updating GRUB menu default setting
Changing GRUB menu default setting to <0>
File </boot/grub/menu.lst> propagation successful
File </etc/lu/GRUB_backup_menu> propagation successful
Successfully deleted entry from GRUB menu
Determining the devices to be marked free.
Updating boot environment configuration database.
Updating boot environment description database on all BEs.
Updating all boot environment configuration databases.
Boot environment <2> deleted.

# zpool create mpool c1t0d0s3
invalid vdev specification
use '-f' to override the following errors:
/dev/dsk/c1t0d0s3 overlaps with /dev/dsk/c1t0d0s2
# zpool create -f mpool c1t0d0s3

# lucreate -c 1 -n 2  -p mpool
Checking GRUB menu...
System has findroot enabled GRUB
Analyzing system configuration.
Comparing source boot environment <1> file systems with the file system(s)
you specified for the new boot environment. Determining which file systems
should be in the new boot environment.
Updating boot environment description database on all BEs.
Updating system configuration files.
The device </dev/dsk/c1t0d0s3> is not a root device for any boot environment; cannot get BE ID.
Creating configuration for boot environment <2>.
Source boot environment is <1>.
Creating boot environment <2>.
Creating file systems on boot environment <2>.
Creating <zfs> file system for </> in zone <global> on <mpool/ROOT/2>.
Populating file systems on boot environment <2>.
Checking selection integrity.
Integrity check OK.
Populating contents of mount point </>.
Copying.

# luupgrade -u -n 2 -s /net/bounty/export/nv/solarisdvd.nvx_dvd/101a

# luactivate 2
# init 6

After reboot, it goes to boot environment 2 and run on a zfs root.

It is easy to setup a video conference by using ekiga.


1. Plug your USB webcam. (See the list of webcams supported on opensolairs)

You then should have the device file /dev/video0 created automatically.


2. Configure ekiga with GUI.

When the first time running Ekiga or you click Ekiga menu
Edit -> Configuration Druid, you can see a dialog pop up. After click
"Forward" button for a couple of times, you see a dialog to ask for an
account, you can just click "I do not want to sign up for the ekiga.net
free service", and then go forward. When you are asked for choosing
"Video Manager", please choose V4L2. After these configuration steps,
you
can see the application window, and then click the video camera button
to see
the video. Now you will see the local video captured by your usb webcam.


3. To connect with others to see the remote video.

It is easy to use h323 protocol to connect two PCs. Just one step:


In the address blank of Ekiga main window, type:
h323:hostname,
or
h323:ip-address, e.g., h323:192.111.111.1

The hostname or ip address belong to the PC that you want to call. Then type return or click the call button to issue the call. After the peer accepted the call, then you are connected. Remote video will be displayed on both sides.


Note: If ekiga can not detect the webcam but the /dev/video0 file is already created, it might be the file permission problem. The access to /dev/video0 is
granted to login user only. So, if you are running ekiga using another user
name, then ekiga can not detect the webcam. Just change the user to the
login user will make it work.


Tips: After you are connected, clicked the "View" menu to try various ways of displaying remote/local video or zoom the video.

ugen (USB generic) driver in Solaris is useful for users because it exports device nodes for each of the end point of a USB device. Users can access the raw data of the USB device via the ugen nodes. libusb or openusb interfaces are built upon this driver. It is not that staight forward that in what cases ugen nodes will be exported. Recently I was asked by people who want to utilize ugen device nodes in their projects. The following is trying to summarize all the cases.

ugen nodes are exported by default for the following devices:
1. Any USB devices that have not a class or vendor unique driver in
solaris.
2. USB storage devices bound to scsa2usb(7D) driver. (refer to
scsa2usb(7D) manpage)
3. USB printer devices bound to usbprn(7D) driver. (refer to
usbprn(7D) manpage)
4. For a multi-interface USB device, usb_mid driver is by default
attached to it.

If none of the device's interfaces are explicitly
bound to the ugen(7D) driver, then usb_mid driver will create ugen
nodes for the device.

ugen nodes are not by default exported for some USB devices (a USB mouse, for example),
because it is bound to hid driver by USB class number and hid driver
does not create ugen nodes.

VNC is really a good tool for sharing desktops to your remote peers.
The following is my personal experience with VNC on OpenSolaris. I am
running OpenSolaris build 86. It should be the same case in other
builds.


1. Check the binaries I am using:

$ which vncserver

/usr/bin/vncserver

$ which vncviewer

/usr/bin/vncviewer


2. I add a new user "vncuser" with "Basic Solaris User" privilege.
(This step is just my personal favor. But it helps you to have a clean
test environment.)

# users-admin


3. Try the first run.

$ su - vncuser

$ vncserver


Some files will be created in $HOME/.vnc/ directory, including "xstartup".

Connect to the vncserver.

$ vncviewer localhost:1


A VNC desktop window appears.


4. The default window manager seems not that good. Edit the file
"xstartup" to use JDS desktop. Comment all lines, and add
"gnome-session" to it.

$ cat xstartup

#!/bin/sh


#[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources

#xsetroot -solid grey

#vncconfig -iconic &

#xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &

#twm &

gnome-session


5. Run vncserver again. This time I specify more options to customize
it a bit. (Check manpage vncserver(1) for details of the options.)

$ vncserver :16 -alwaysshared -deferupdate 100 -geometry 1024x768 -depth 16


Run vncviewer:

$ vncviewer localhost:16


I then see a nice desktop window appears.


BTW, to kill the VNC servers that are run above, just type:

$ vncserver -kill :1

$ vncserver -kill :16

The Wireless USB technology from usb.org tries to make it easy for end
users to connect a wireless USB device with a wireless USB host, quoted
from the specification: “The goal is that end users view it as the same
as wired USB, just without the wires.”. However, there have to be
something different because of the difference of wireless and wired
environment. The most significant thing is "Association". It is
something happened before the first time that a wireless USB device can
be enumerated by the host system.

Association is special for wireless host and device, it is new for
wired USB users and it is not a straight forward concept for most
people. But if we take a look at the following question, we might know
it well.

Suppose two PC boxes are put in one room, each of them has a WUSB host.
A user brings a WUSB device to the room and turn on the device radio.
The question is, which PC box should enumerate the device? Or the
question can be asked in another way, how can the user choose a PC box
with which he would like to connect the wireless device?

It is not a question at all if in a wired case: the user just plug the
device to the PC box with which he want to connect the device. In
wireless case, a new way must be invented to let the specific wireless
hosts and devices know that which device should be connected to which
host. So, usb.org comes the technologies called "Association Model". It
makes the specific WUSB host and device create a shared CC (Connection
Context). A CC includes three elements: CHID (Connection Host ID), CDID
(Connection Device ID), CK(Connection Key). Once the CC is created
during the association process, it will be saved in the non-volatile
memory on both host and device. Thus, the host and device will "know"
each other and trust each other in a wireless environment.

According to WUSB specification, there are two Association Models optional for device manufactures and users.

- Cable Association

  User need to connect the WUSB device with his PC box with a USB cable
for a few seconds. The WUSB host on the PC box then talks to the device
to create a CC. The user then unplug the WUSB device and need not to
plug it any longer, unless he decide to connect the WUSB device with
another PC. With the CC stored in both WUSB host and device, when user
turn on the device radio, because the device and host already know each
other, they can authentication each other and be connected just as
wired USB. The only difference is, the connection is over air.

- Numeric Association

  User need not a USB cable in this case. But the WUSB device need to
have a screen to display digit numbers. The process is, user turns on
the device radio, and run the WUSB administration software on the host
to specify a WUSB host on the system to start to associate itself with
the device which is beaconing. The specified WUSB host then talk to the
device over air and create a CC. Because it is performed in the open
radio, user is asked manually confirm the association. A digital number
is displayed both on the host system screen and the device screen. If
they are the same, user press OK on both sides. If not, then the
association is not right.

From the host software's view, there must be an utility to manage the
CCs stored in host system. Because, on one system (e.g., a PC box),
there could be multiple WUSB hosts. And also, there could be multiple
WUSB devices associated with a WUSB host. What's more, when system
booting up, a daemon is needed to load the CCs from file system to the
WUSB host driver instances. A specific CC belongs to a specific WUSB
host instance.
To support the above issue, on Solaris, a software design is under
review. A daemon wusbd is introduced to be used to manage the CCs for
WUSB hosts and devices. It add/remove the CCs to CC database, load the
CC to host driver instances. A admin tool wusbadm is introduced for
user interfaces. It sends requests to wusbd when needs to operate CCs.

After the association process, from the host software view or the end
user view, it is all the same as wired USB devices, e.g., device
enumeration, USB client driver attach, connect/disconnect event
handling, devfs nodes, etc.

One of the goals for this design is the similar as the what the WUSB
spec tells, to have a simple user interface and make end user view WUSB
the same as wired ones. Connect and play, just without wires. Users
just need to turn on the device radio to connect, or, turn off the
device to disconnect. And something better in WUSB case: there are
always enough "ports" there. A WUSB host is supposed able to connect up
to 127 WUSB devices, theoretically. So, you just put WUSB devices
around your PC box, associated for once, then enjoy them as USB ones,
and without wires.

It happened on this Tuesday (December 11, 2007). By running the latest Solaris Express on laptops, we had the first dual way Ekiga video conference between Sun engineering teams in Beijing and headquarter staff in MPK, US. During the whole meeting, which lasted more than one hour, the video stream is quite stable and the video quality is fine. I like video conferences much than audio only ones. People smile to each other and wave to each other, very nice. Many people know each other by emails or by conference calls, now, they see faces and smiles.

Not like some dedicated video conference equipments, the hardware equipments we used are very simple, just a laptop + a webcams + a projector. All are low cost commodity devices. In Beijing conference room, we use a Lenovo laptop running Solaris Express (build 76) and a Logitech USB webcam. US staff were using the similar equipments.

More detail usage info about Ekiga application and USB webcam driver can be found in my previous blogs:
USB webcams and video conferencing on Solaris
Have a larger video size in Ekiga

amsn is a nice instance chatting application. It supports video chatting. A talent community member just ported it to Solaris. I received emails from him and had a chance to see the screen shots of amsn running on Solaris. It looks great! The video is captured from a USB webcam which is supported by usbvc(7D) driver. The following link is also from him, the patch for Solaris is submitted to amsn community:

http://www.amsn-project.net/forums/viewtopic.php?p=25214#25214

I believe Solaris users will enjoy it!
 

Learned from an Ekiga developer, Ekiga supports a larger video size if you change the default value by gconf-editor. It is easy to have a larger video size in Ekiga application. I tried the following on my Solaris desktops, it works.

Login JDS, run 

# gconf-editor

In the gconf-editor window, select apps->ekiga->devices->video->size. Change the value of size from 0 to 1. Before quit, click somewhere else to save the change. Done.

Note, you need to "fully" quit Ekiga before change the above value. My favorite way is to run 'pkill ekiga' first.

The following are steps to build OpenSolaris. My co-workers and I figured out these steps according to the documents on OpenSolaris.org. These steps are easy to follow and tested on Solaris Express build 63.

1. Download & Install Build Environment:

1.1 Download Compiler (Sun Studio is the preferred compiler, and it is free)
Install the compiler according to the instructions at the download site.
The result should have the compilers installed in /opt/SUNWspro.

1.2 Download ON build tools package (SUNWonbld.PLATFORM.tar.bz2)
http://dlc.sun.com/osol/on/downloads/current/
and install:

# cd $TEMP
# bunzip2 -c SUNWonbld.i386.tar.bz2 |tar xvf -

# yes y | pkgadd -d ./ SUNWonbld

1.3 Fetch ON (OS & Network) source code

# hg clone ssh://anon@hg.opensolaris.org/hg/onnv/onnv-gate

Source tar balls have been deprecated in favour of the onnv project's Mercurial repository. Please see the onnv project page for more information on how to checkout/clone the repository to download the source.

1.4 Download Encumbered binaries tarball (on-closed-bins[-nd].PLATFORM.tar.bz2) for debug and non-debug version

http://dlc.sun.com/osol/on/downloads/current/

Need to extract from tarball and put root_i386 and root_i386-nd under $CODEMGR_WS/closed,

For example:

If the source code is in "/export/testws/usr/src", then the binaries will be in "/export/testws/closed/root_PLATFORM"
(i.e., closed/root_i386 or closed/root_sparc). For non-debug version, it is closed/root_i386-nd or closed/root_sparc-nd.

2. Environment setup

2.1 PATH

# PATH=/opt/SUNWspro/bin:/opt/onbld/bin:/opt/onbld/bin/i386:$PATH

2.2 Copy and set environment file

# cp usr/src/tools/env/opensolaris.sh /export/testws/
modify opensolaris.sh for your $CODEMGR_WS, $STAFF, $MAILTO settings

• change GATE to none or the name of the top-level directory (e.g., "testws").

• change CODEMGR_WS to the your workspace (e.g., "/export/testws").

• change STAFFER to your login (e.g., root).

• (optional) change MAILTO to you email address.

• (optional) customize VERSION. This is the string that "uname -v"
  will print.

3. Build

3.1 Nightly Build (build the whole ON source)

# nightly ./opensolaris.sh & tail -f log/nightly.log
nightly options:

• -n: no bringover (default)

• -i: incremental build (no clobber)

• -D: do a build with DEBUG on

• -F: do not do a non-DEBUG build

3.2 Single module Build

• make a single module:

  bldenv opensolaris.sh; cd usr/src/uts/intel/i915; make

• Building Opensolaris

• A Chinese Guide of OpenSolaris build (it's for snv_23 only, but is quite workable with current builds)ON/Nevada project page
  
• Glossary(consolidation, gate, ON, Nevada, putback, workspace, WOS, etc.)

• Operating System/Networking (ON) Download Center

• OpenSolaris Download Center, which contains:

• ON source

• SUNWonbld

• on-closed-bins

Live upgrade, I like it. I have been using it for years.
 
There is a GUI tool to perform live upgrade, a little trick is, you need run xterm first, then type lu in xterm window.

$ xhost +

access control disabled, clients can connect from any host

$ su

Password:

# xterm

Then in xterm,

# lu

By this GUI tool, you need not to remember the command names. And it is very straight forward. I tested it on both Solaris 10 and Solaris Express developer edition.

For more info about live upgrade, search document at http://docs.sun.com/