I wanted to learn more about DTrace, so I started at the beginning: Chapter 1 of the Solaris Dynamic Tracing Guide. Using my installation of OpenSolaris 2008.05, I typed in the first command described, but it did not work:

$ dtrace -n BEGIN
dtrace: failed to initialize dtrace: DTrace requires additional privileges

This is because in order to use DTrace, my account needs additional privileges that were not specified when the account was created. The DTrace privileges are described in Chapter 35.

To add the necessary privileges to my account, I followed these instructions on the frequently helpful Solaris Internals performance wiki. After logging out and then logging back in, the dtrace command now works for my account. 

In this entry I'll show you how to access Microsoft Windows shares that may be running alongside OpenSolaris on your network.

Step 1: Share The Windows Folder 

The first step is to make sure the folder you want to access is shared by Windows. On Windows XP you can access this by viewing the properties for the folder and selecting the Sharing tab:

For this example, I'm going to share my entire My Documents directory. The share name will be easiest to work with from OpenSolaris if it doesn't contain any spaces, hence I'm using 'MyDocuments'.

Also make a note of the hostname or IP address of the Windows machine. Ideally you'll use a hostname, especially if your router is configured for DHCP, but you can also use an IP address as a fall back option.

To determine your hostname, run hostname from the command line:

C:\Documents and Settings\Brian>hostname
Integrity 

C:\Documents and Settings\Brian>

You can determine the IP address by running ipconfig:

C:\Documents and Settings\Brian>ipconfig

Windows IP Configuration


Ethernet adapter Wireless Network Connection:

        Connection-specific DNS Suffix  . : hsd1.ct.comcast.net.
        IP Address. . . . . . . . . . . . : 10.0.1.200
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 10.0.1.1

C:\Documents and Settings\Brian>

Finally, if you are running any type of firewall on the Windows machine, be sure to configure it so that your OpenSolaris machine is allowed to connect to it. 

Step 2: Access the Share from OpenSolaris

Option 1: Using the Connect to Server Dialog

Select Connect to Server from the Places menu

Change the Service type to Custom Location and set the Location URI to the following:

smb://[windows hostname or IP address]/[share name]

So for my example above it would be:

smb://integrity.local/MyDocuments or smb://10.0.1.200/MyDocuments.

Then give the connection a name and click connect:

You'll then find the connection available on your desktop and in the Places menu:

Upon opening the connection you can view and edit the files on the Windows share:

The connection will persist across restarts. To remove it, right-click the connection and select unmount.

Option 2: Using mount

You can run the smbutil command to view the available resources on a particular host:

bleonard@opensolaris:~$ smbutil view //integrity.local
Password:
Share        Type       Comment
-------------------------------
MyDocuments  disk       
IPC$         IPC        Remote IPC
ADMIN$       disk       Remote Admin
C$           disk       Default share

4 shares listed from 4 available
bleonard@opensolaris:~$ 

Make a home for the share. I've created a folder called IntegrityDocs off of my home folder.

Before we can do the mount we must first enable the smb client:

svcadm enable /network/smb/client

Mount the share, replacing my userid (bleonard) with yours. If you've set the share up with a password, enter it at the prompt, otherwise just press enter to proceed:

bleonard@opensolaris:~$ mount -F smbfs -o uid=bleonard,gid=staff //integrity.local/MyDocuments ~/IntegrityDocs
Password:
bleonard@opensolaris:~$ 

The uid and gid options give your user privileges to write to the share. If you leave those options out only the root user will have write privileges.

Finally, I don't believe an smbfs can be mounted at boot, however, by adding an entry to your /etc/vfstab file, you can significantly shorten the mount command as the rest of the properties will be pulled from the vfstab file. For example, I would add the following:

//integrity.local/MyDocuments - /export/home/bleonard/IntegrityDocs smbfs - no uid=bleonard,gid=staff

Now I can mount the share using either:

mount //integrity.local/MyDocuments

or:

mount /export/home/bleonard/IntegrityDocs

Here at Sun I get a lot of e-mails with links containing abbreviated domain names to Sun intranet sites. For example:

http://sunweb.central

Which is intended to mean:

http://sunweb.central.sun.com

However, my browser tries to resolve it as:

http://www.sunweb.central

Which of course fails.

The solution is to simply add the following line to /etc/resolv.conf:

search sun.com 

I used the entry that Roman wrote on Querying IPS Packages to search for the OpenSolaris IPS packages that contain gcc:

$ pkg search -r gcc
INDEX      ACTION    VALUE                     PACKAGE
basename   hardlink  usr/sfw/bin/gcc           pkg:/SUNWgcc@3.4.3-0.79
basename   hardlink  usr/sfw/bin/gcc           pkg:/SUNWgcc@3.4.3-0.86
basename   hardlink  usr/sfw/bin/gcc           pkg:/SUNWgcc@3.4.3-0.89
basename   hardlink  usr/sfw/bin/gcc           pkg:/SUNWgcc@3.4.3-0.90
...

The pkg search command found one package: SUNWgcc.

If you look at the man page for pkg, you will notice that in the description of the search subcommand it says: "Search for the token 'token', and display the FMRIs in which the token was found.  Which tokens are indexed are action-dependent, but may include content hashes and pathnames."

Kuldip Oberoi pointed out to me that because not all tokens are searched by pkg search, the results might not always list all packages of interest.  And with the token "gcc" that is in fact the case.  Kuldip suggested:

pkg list -a | grep gcc

But in the end, I modified that a bit to be:

$ pkg list -sa | grep gcc | uniq
SUNWgcc                        gcc - The GNU C compiler
SUNWgccruntime                 GCC Runtime libraries
gcc-dev                        GNU Tools Development cluster

It took longer to run the command, but notice that additional packages were found: SUNWgccruntime and gcc-dev.

The descriptions for SUNWgcc and SUNWgccruntime give me a good sense of what those packages contain, but I was not sure what the term "GNU Tools Development cluster" really encompasses. In my first attempt to find out, I used:

$ pkg contents -r gcc-dev
PATH

Hmmm... not very helpful. That is because by default, the contents subcommand just displays the PATH attribute values from a package; for example:

$ pkg contents SUNWgccruntime
PATH
usr
usr/sfw
usr/sfw/lib
usr/sfw/lib/amd64
usr/sfw/lib/amd64/libfrtbegin.a
usr/sfw/lib/amd64/libg2c.a
usr/sfw/lib/amd64/libg2c.la
usr/sfw/lib/amd64/libg2c.so
...

Unlike the SUNWgccruntime package, the gcc-dev package does not contain any files so that is why there are no PATH entries. To find out what gcc-dev does contain, I add the -m flag so that I can see the complete contents of the package:

$ pkg contents -rm gcc-dev
set name=fmri value=pkg:/gcc-dev@0.5.11,5.11-0.86:20080504T074641Z
set name=authority value=opensolaris.org
set name=description value="GNU Tools Development cluster"
depend fmri=pkg:/SUNWgcc@3.4.3-0.86 type=require
depend fmri=pkg:/SUNWmercurial@0.9.5-0.86 type=require
depend fmri=pkg:/SUNWsvn@1.4.3-0.86 type=require
depend fmri=pkg:/SUNWgnu-automake-19@1.9.6-0.86 type=require
depend fmri=pkg:/SUNWaconf@2.61-0.86 type=require
depend fmri=pkg:/SUNWcvs@1.12.13-0.86 type=require
depend fmri=pkg:/SUNWlibtool@1.5.22-0.86 type=require
depend fmri=pkg:/SUNWgnu-automake-110@1.10-0.86 type=require
depend fmri=pkg:/SUNWgmake@3.81-0.86 type=require
depend fmri=pkg:/SUNWsprot@0.5.11-0.86 type=require
depend fmri=pkg:/SUNWbison@2.3-0.86 type=require
depend fmri=pkg:/SUNWflexlex@2.5.33-0.86 type=require
depend fmri=pkg:/SUNWgdb@6.3-0.86 type=require

So gcc-dev contains no files of its own - just dependencies on other packages.  It provides a convenient way to install all of those dependent packages via a single command:

pfexec pkg install gcc-dev

Lack of sound has been a big drag on my day to day use of OpenSolaris, often forcing me to return to OS X when I need to hear something. Earlier today Gregg pointed me to New OSS Drivers Fix Sound Issues in OpenSolaris on Mac OS X - and lo and behold - they do - at least in VirtualBox. 

Some other things to note is that in VirtualBox for Mac OS X, the audio is disabled by default. To enable the audio, select Settings (the OpenSolaris virtual machine must be powered down) and then Audio. Select Enable Audio and set the Host Audio Driver to CoreAudio:

Leave the Audio Controller as ICH AC97. Now when you start OpenSolaris, it will believe it has the Intel AC97 audio controller. If you installed the OSS drivers w/out first enabling the audio, you can run ossdetect to rediscover the devices. If all goes well, you should see the audio driver in the Device Driver Utility:

You can also run osstest to ensure the package is correctly installed:

bleonard@opensolaris:~$ osstest
Sound subsystem and version: OSS 4.0 (b1016/200806171344) (0x00040003)
Platform: SunOS/i86pc 5.11 snv_86

*** Scanning sound adapter #-1 ***
/dev/oss/ich0/pcm0 (audio engine 0): Intel ICH (2415)
Note! Device is in use (by PID 0/VMIX) but will try anyway
- Performing audio playback test... 
  <left> OK <right> OK <stereo> OK <measured srate="" 47860.00="" hz="" (-0.29%)=""> 

*** All tests completed OK ***
bleonard@opensolaris:~$ 

I also tested this build of OSS (1016) on my native installation of OpenSolaris and was disappointed that I still hear silence. Oh well, I'll try once again when OSS build 1017 is released.

OpenSolaris only allows me to ping machines in my local network by IP address:

bleonard@opensolaris:/etc$ ping 10.0.1.200
10.0.1.200 is alive
bleonard@opensolaris:/etc$ ping -s integrity.local
ping: unknown host integrity.local
bleonard@opensolaris:/etc$ 

While doing some digging I found the Service Discovery project, which uses Multicast DNS (mDNS) to locate services on the network. mDNS is managed by SMF and disabled by default. To use it, first copy the /etc/nsswitch.dns file to /etc/nsswitch.conf:

cd /etc 
pfexec cp nsswitch.conf nsswitch.conf.orig
pfexec cp nsswitch.dns nsswitch.conf

Then enable the mDNS service:

svcadm enable /network/dns/multicast

Now the hostnames on your local network are properly resolved:

bleonard@opensolaris:/etc$ ping -s integrity.local
PING integrity.local: 56 data bytes
64 bytes from 10.0.1.200: icmp_seq=0. time=1.011 ms
64 bytes from 10.0.1.200: icmp_seq=1. time=1.009 ms
64 bytes from 10.0.1.200: icmp_seq=2. time=0.939 ms
64 bytes from 10.0.1.200: icmp_seq=3. time=0.985 ms
^C
----integrity.local PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms)  min/avg/max/stddev = 0.939/0.986/1.011/0.033
bleonard@opensolaris:/etc$

This is great because the IP addresses are assigned by DHCP, so I no longer have to keep track of changing IP addresses.

This is a #2 part in a series of posts about what makes OpenSolaris interesting (you can read reason #1: ZFS here). We'll go through different technologies and features that make OpenSolaris a compelling operating system.

Reason #2: SMF

SMF stands for Service Management Facility. It's a new way of managing system services (well introduced in Solaris 10 so it's not bleeding edge anymore), better than the original rc.d scripts which are still being used in Linux. Rc.d scripts are various scripts that are executed during system startup and shutdown and are located in /etc/rc.d, /etc/rc.* and /etc/init.d directories. At first let's look at the problems that the old "rc.d" way has:

1. No reasonable way to handle dependencies - the only way you can define the sort-of-dependencies is by specifying numbers in the names of the script. This way you can say that script #1 is executed before script #2. But you can't really define multiple dependencies and if one script fails, there's no easy way to prevent some other process from starting if it depends on the script that failed.

2. Services need to be started sequentially - they cannot be started in parallel (because of the awkward way of specifying dependencies).

3. Services don't get restarted automatically - if a service fails there exists no process to check if it failed or attempt to start it again - if you want this kind of functionality you need to write it yourself or search for some other tool.

4. Creating new services requires lots of shell hacking - what people usually do is they copy the existing script and update it as they need. This process can easily lead to hidden errors.

5. Monitoring of services is hard - e.g. if a service fails you often don't know about it until you check the status of the process - but there's no easy way to map the service name to a process ID - you need to know which process was started by the service (which can be found out by parsing the shell script which may not be the most pleasant thing to do).

6. Maybe I forgot some other problems rc.d scripts have, but I can say in general it's an old architecture that doesn't satisfy requirements for high availability and observability that current systems have. Which is why SMF was created.

So what is SMF?

SMF is a replacement of rc.d (startup/shutdown) scripts but it solves more than that - it solves the whole problematics of managing services.

1. It can handle service dependencies - you can declare how services depend on each other. Multiple dependencies are possible.

2. SMF enables parallel starting of services, because we know their dependencies. This can lead to faster start of services in case you have many services to start.

3. If a service fails it is possible to restart it - there is a service called the restarter which monitors services for you and attempts to restart them if necessary. You can control the number of attempts for restart or if you want to attempt restarting at all.

4. SMF has centralized configuration - all configuration is done using simple XML files which have well known structure.

5. Observability - you can easily list all services, find out info about individual services, list failed services (including links to log files which helps you find out quickly what went wrong). You can find out process IDs of processes managed by the service easily.

6. It is easy to "SMF-ize" your application - you just need to create the XML configuration file and import the service.

7. SMF can handle legacy "rc.d" type services. Of course it can't provide as much control and information about them but you can still use old rc.d scripts if you need to.

8. Much more - again I am probably forgetting some other advantages (e.g. having fully qualified names of services, milestones which define different levels during startup, etc.) - you'll find more advantages in the documentation.

Here are some useful commands when working with SMF:

Listing all services:

$svcs

Listing failed services:

$svcs -x

Detailed information about a service (FMRI is the Fault Management Resource Identifier which identifies the service):

$svcs -v FMRI

Showing process IDs related to a service:

$svcs -p FMRI

Finding restarter for a service:

$svcs -l FMRI

Enable a service:

$svcadm enable FMRI

Disable a service:

$svcadm disable FMRI

There is a nice article on the O'Reilly site I recommend to read about SMF: Using Solaris SMF. Even though the article was written for Solaris, the listed commands also work in OpenSolaris. It's a good reading if you want to get started with using SMF.

I had a hard time with mounting a FAT-32 partition in OpenSolaris - it just wouldn't mount. Finally I found out that I need to use the -F pcfs parameter to tell mount the filesystem type. It hit me by surprise because in Linux you don't need to specify a parameter - Linux mount will detect the filesystem type for you. So in case you want to mount a FAT-32 partition, the command looks like this:

$ mount -F pcfs /dev/dsk/c5d0p4 /mnt/dosdisk

Obviously you need to change the controller and partition number according to your hardware/disk partitioning.

<< Back to Part 4, Windows via VirtualBox

This is the only blog entry in this series that I have not actually performed on my laptop.  Instead, I experimented with the instructions in a virtual environment, using VirtualBox.  The standard disclaimers apply:

• I am describing a single hard drive system
• Messing around with the partitions and the Master Boot Record (MBR) on a disk can be dangerous.  Always back up your data first.  If you're really nervous (like me) experiment in a virtual environment first.
  

The inspiration for this entry came from a comment posted by Luca Morettoni over on Part 2: Install Ubuntu:

I have only one question: when you update the linux os and the system install a new kernel, *probably* it overwrite the OpenSolaris grub installation, or not? If yes, there is a workaround or I need to reinstall OpenSolaris grub (eg. from a liveCD)?

In my experience, a typical update of a GNU/Linux distribution does not overwrite whatever GRUB you have installed on your hard drive (although the menu.lst entries might get changed).  For example, on my old laptop I did an online update of Ubuntu from 7.04 to 7.10 and the GRUB was unchanged.

Doing a second installation (in other words, a re-install) of a GNU/Linux distribution, however, will typically overwrite whatever GRUB you have installed.  I believe there are also some situations where installing service packs for Windows will overwrite the current MBR, which would mean that the partition with OpenSolaris would no longer be marked as Active.

So the question remains: if the GRUB installed by OpenSolaris 2008.05 gets overwritten or superseded, how do you restore it?

The process is fairly easy.  I started by booting the LiveCD of OpenSolaris 2008.05.  I opened a terminal window after the desktop is displayed.  The command to use is installgrub.  If you look at the man page for installgrub, you will see that it requires three parameters.  The third parameter is the raw-device name.  Note this important piece of information from the man page about that name: "For disk devices, specify the slice where the GRUB menu file is located."

The slice? What's up with that? Since my laptop is an x86 system, I had thought that partitions are the only subdivisions of the hard drive that matter.  As Johan Hartzenberg explains so well in this blog entry, however, that is not the case. OpenSolaris uses slices to do a further subdivision of the partition on which it is installed.

The GRUB menu file is in the root slice, so you will need to know the number for the root slice. To find that out, I used this command:

$ pfexec prtvtoc /dev/rdsk/c5d0s2
*
* /dev/rdsk/c5d0s2 partition map
*
* Dimensions:
*     512 bytes/sector
*      63 sectors/track
*     255 tracks/cylinder
*   16065 sectors/cylinder
*    9297 cylinders
*    9295 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      2    00    4209030 145115145 149324174
       1      3    01      16065   4192965   4209029
       2      5    01          0 149324175 149324174
       8      1    01          0     16065     16064

Notice that the device name that I passed to prtvtoc includes a slice number: s2.  By convention s2 means the "entire disk." And therein lies the potential for confusion.  Within the context of these commands, when run on an x86/x64 system, the "entire disk" means: just the partition of the hard drive that contains OpenSolaris. In the output of prtvtoc the final table has a column heading labeled "Partition."  The "partition" numbers displayed by prtvtoc are not primary or extended partitions on my hard drive - they are instead slices within the primary partition that contains OpenSolaris. 

The Tag value for slice 0 is 2, indicating slice 0 is the root slice.  That means the syntax for the installgrub command would be:

$ pfexec installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c5d0s0 

An important note: by default installgrub does not modify the MBR. And depending on your situation, that might be what you want.  For example, if you are happy with the GRUB that a Linux installation wrote to the MBR then after running installgrub you can chainload the OpenSolaris GRUB by adding an entry to the /boot/grub/menu.lst that is used by your GNU/Linux distribution.  As an example:

title OpenSolaris 2008.05
rootnoverify (hd0,2)
chainloader +1

If, however, you do want the OpenSolaris GRUB installed to the MBR, specify the -m flag on the installgrub command line:

$ pfexec installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c5d0s0 

After installing to the MBR you will see the OpenSolaris GRUB menu when you boot from the hard drive.  If the reason you went through all this was because the installation of a GNU/Linux distribution replaced your OpenSolaris GRUB, then you need to make sure the entries in the menu.lst that the OpenSolaris GRUB uses are correct for your new GNU/Linux kernel.  At the very least, the UUID will be different, as shown in this example: 

# title        Ubuntu 8.04, kernel 2.6.24-16-generic
# root        (hd0,4)
# kernel        /vmlinuz-2.6.24-16-generic root=UUID=61d0afdc-4e12-4d74-a1ae-388ff74d7630 ro quiet splash
# initrd        /initrd.img-2.6.24-16-generic
# quiet

# title        Ubuntu 8.04, kernel 2.6.24-16-generic (recovery mode)
# root        (hd0,4)
# kernel        /vmlinuz-2.6.24-16-generic root=UUID=61d0afdc-4e12-4d74-a1ae-388ff74d7630 ro single
# initrd        /initrd.img-2.6.24-16-generic 

title		Ubuntu 8.04, kernel 2.6.24-16-generic
root		(hd0,4)
kernel		/vmlinuz-2.6.24-16-generic root=UUID=276561b9-09ea-45e7-9fbc-d2f4a273fcd9 ro quiet splash
initrd		/initrd.img-2.6.24-16-generic
quiet

title		Ubuntu 8.04, kernel 2.6.24-16-generic (recovery mode)
root		(hd0,4)
kernel		/vmlinuz-2.6.24-16-generic root=UUID=276561b9-09ea-45e7-9fbc-d2f4a273fcd9 ro single
⁞initrd		/initrd.img-2.6.24-16-generic

A new version (0.4) of NetBeans DTrace GUI plug-in is ready for download from NetBeans Update Center.

New features include:

- Chime (the DTrace output visualization) is embedded into the NetBeans DTrace GUI Plugin. Chime is fully integrated with NB DTrace GUI.
- The new version of DTraceToolkit is integrated with the new release of NB DTrace GUI. Users can debug and tune their Java, JavaScripts, PyThon, Ruby, Php, C, C++, and etc. applications using the new version of DTrace GUI on Solaris platfrom.
- New & enhanced UI.
- An Open-Sourced project at netbeans.org. Developers can participate in future implementations such as DTrace Editor which includes Dtrace code completion, syntax checking and code folding.
- Works with Sun Studio IDE Express releases.
- Works with NetBeans IDE 6.0, 6.1, and 6.5.

For more information, see:
http://www.netbeans.org/kb/docs/ide/NetBeans_DTrace_GUI_Plugin_0_4.html

If you want documentation for OpenSolaris, the best place to go is the OpenSolaris docs community. I have discovered by a coincidence that these guys have a ZIP archive with the most current versions of all documents for various OpenSolaris technologies. It's over 46 MB of zipped documents (wow) and the zipped tarball can be downloaded from dlc.sun.com. The link I provide goes to the current consolidation, if you check the link in the future it will contain updated zip created from the most up-to-date documentation.

Support for audio is always a bit different on each operating system I use, even when running on the exact same laptop. For example, with Windows Vista when I plug into the headphone jack the laptop's built-in speakers are automatically muted.  That is not the case with Ubuntu 8.04 or OpenSolaris 2008.05.

The audio chipset is an Intel 82801H and while I can get sound out of the speakers when running Ubuntu 8.04, I cannot seem to get the headphone jack to work.  :-/  With OpenSolaris 2008.05 I have had much better success.  The speakers work and so does the headphone jack.  But when I plug into the headphone jack the speakers are not automatically muted.

The fix is easy enough.  I right-click the volume control on the toolbar and select Open Volume Control:

 That brings up a dialog that shows that Line Out is on:

Turning Line Out off turns off the speakers. 

And there is also a command line utility in OpenSolaris that will accomplish the same thing: audioplay. It is similar (but not identical) to the play command from the sox package. The audioplay command has a -p option that allows you to specify headphone, speaker, or line.

PowerTOP v1.1 was released earlier this week. Dave Stewart initially turned me onto PowerTOP with his comment to my Results of Power Management blog. PowerTOP for OpenSolaris stems from what was originally a Linux project - its goal to show you what's chewing up your CPU cycles - especially important for laptop users looking to maximize battery life.

Let's start with the results:

The display can be broken into 5 parts: C States, P States, Wakeups, Power Usage and Top Causes for Wakeups. I'll cover each based on the snapshot above.

C States

Your CPU is either working on something or resting. When it's working, the CPU is in state 0, when it's resting it is in some state greater than 0, depending on how deep it's sleeping. From the snapshot above you see that it's been working about 25% of the time and idle for 75%. Of more interest you can see that it spends on average only 0.6ms resting before it is awoken to work again.

P-States

P-States shows the frequency at which your CPU is currently running. In the snapshot above, I'm currently running at my max speed of 2400 Mhz. But if I sit and let it idle I can watch my CPU step its way down to my lowest supported speed of 800 Mhz. The number is shown as a percentage but I don't see how it would ever be anything other than 100%.

Wakeups

Here we see how many times my machine is awoken per second. According to the PowerTOP website, "When running a full GNOME desktop, 3 wakeups per second is achievable". At 1269 Wakeups per seconds, I'm obviously far from achieving that goal.

The interval is just the refresh interval. The default is 5 seconds and you can control this with the -t option when starting PowerTOP.

Power Usage

As a laptop user (for whom PowerTOP is really targeted), this is the most interesting set of statistics. First you see the ACPI estimate of power usage in watts - obviously the higher this number, the shorter your battery life will be, which is the second statistic given based on the wattage. If you watch your CPU step its way down, you'll also see the wattage decrease and the estimated battery life increase.

Top Causes for Wakeups

This list contains the top items causing your CPU to awaken. The items in this list are over my head, but if you understand this stuff, you can begin to investigate why your battery life sucks and try to take steps to improve it. I found several examples of folks doing just that when doing my research on PowerTOP. 

Suggestions? 

One nice feature the Linux version of PowerTOP has that's missing on OpenSolaris is suggestions on improving power usage. This saves you from having to decipher the cryptic list above. It has been filed as an enhancement request: Include Suggestions. Note, the one suggestion that PowerTOP does make is to enable power management if it is not already turned on:

Installing and Running PowerTOP

Download PowerTOP and save it to your desktop.

Open a terminal and untar the archive:

tar -xf Desktop/SUNWpowertop-1.1_5961.5.11-i386.pkg.tar 

Install the package:

pfexec pkgadd -d SUNWpowertop-1.1_5961.5.11-i386.pkg 

And run:

pfexec powertop

If you need to pull files from an ISO image file, is it unnecessary to first burn the image to a CD or DVD. By using the lofiadm command you can just mount the ISO and browse its contents.

The lofiadm command associates a file with a block device (you must provide an absolute path to the file). The device that becomes associated with the ISO is returned:

bleonard@opensolaris:~$ pfexec lofiadm -a ~/Desktop/sol-10-u5-ga-x86-dvd.iso 
/dev/lofi/1
bleonard@opensolaris:~$ 

Running lofiadm with no parameters will list the associated devices:

bleonard@opensolaris:~$ lofiadm
Block Device             File                          	Options
/dev/lofi/1              /export/home/bleonard/Desktop/sol-10-u5-ga-x86-dvd.iso	-
bleonard@opensolaris:~$ 

Now the device can be mounted:

bleonard@opensolaris:~$ pfexec mount -F hsfs /dev/lofi/1 /mnt
bleonard@opensolaris:~$ ls /mnt
boot  Copyright  installer  JDS-THIRDPARTYLICENSEREADME  License  Solaris_10
bleonard@opensolaris:~$

The lofiadm and mount steps can be combined into one as follows:

pfexec mount -F hsfs `pfexec lofiadm -a ~/Desktop/sol-10-u5-ga-x86-dvd.iso` /mnt

When finished, use the following to unmount and detach the image:

pfexec umount /mnt

pfexec lofiadm -d /dev/lofi/1 

<< Back to Part 3, Install OpenSolaris

After setting up my triple-boot system, I was not content.  I want access to Windows Vista and Ubuntu 8.04 without having to restart my system.  I mostly run OpenSolaris and rebooting to switch to Vista or Ubuntu is a disruption.  If I need to do some sort of benchmarking or a lengthy task on Vista or Ubuntu then it is worth the time to reboot.  But there are several use cases where I just want to do something quickly and then go back to what I was doing in OpenSolaris.

With Vista, typically I just want to edit an OpenOffice document, usually a presentation.  I frequently edit presentations that were originally created by someone who was running OpenOffice on Windows.  Since OpenOffice does not embed the actual fonts in the document, editing a document created on Windows while running OpenOffice on a non-Windows operating system can cause problems.  Even with fonts such as Arial - Arial on Windows is not exactly the same as Arial on OpenSolaris, Ubuntu, etc.  As a result, items in the documents frequently do not align correctly.

So I need the ability to quickly and easily run Windows Vista for just a few minutes without having to shutdown OpenSolaris, boot Vista, and then shutdown Vista and restart OpenSolaris.  There is an easy solution: VirtualBox.

Installing VirtualBox is painless, just be sure to download the correct version for OpenSolaris: 32 or 64 bit.  On my system, which has an Intel Core 2 Duo chip, OpenSolaris runs in 64-bit mode, as confirmed by the isainfo command:

gs145266@opensolaris-gs-08.05:~$ isainfo -k
amd64  

VirtualBox is a small download and it installs quickly.  It is very easy to use - I did not need the documentation until I started doing advanced configuration type stuff.

In VirtualBox I created a virtual machine for Windows Vista and then I had to make a choice:

1. Use the existing Vista installation that was already on my hard disk.  In other words, configure the virtual machine to use the NTFS partition on my hard drive and let it boot Windows Vista from the same installation that boots from the bare metal.
2. Create a virtual disk image (.vdi) file and configure the virtual machine to use it.  The .vdi file would be empty, so this would require getting a Vista DVD so that I could run the Windows installer, etc.

I ultimately decided to go with option 2 because of complications with option 1:

• There are some Windows configuration and activation issues.  There is a very detailed tutorial available that describes how to accomplish option 1 with Ubuntu as the host operating system and Windows XP as the guest operating system that is running in the virtual machine.  I assume the same basic approach would work with OpenSolaris as the host and Vista as the guest, but I am not very knowledgeable about the differences between XP and Vista, especially in the all-important area of hardware profiles (which are key to making option 1 work).
  
• VirtualBox has a nice feature that I like to use called "guest additions." These are device drivers that get added to the guest operating system to enable full screen mode, seamless mode, better mouse integration, etc.  According to that tutorial, if you choose option 1 then installing the guest additions is a bad idea because after the guest additions are installed, Windows will no longer boot from the bare metal.
  

Option 2 was easy to setup and then I was able to run the installer for Windows Vista from a DVD. I added the VirtualBox guest additions and everything worked great.

There was just one problem: when running Vista in that VirtualMachine, I have no access to all that data on my hard drive's NTFS partition. It should be noted, this is not a limitation of VirtualBox - it is possible to configure "shared folders" that allow the installation of Vista that is running in a virtual machine to read/write any directory that OpenSolaris can access.

The problem is that OpenSolaris 2008.05 cannot access my NTFS partition because it does not include any support for NTFS partitions.  You can add some packages to it in order to get read-only support for NTFS (see this entry from Pradhap for details), but I would like to be able to write files to the NTFS partition as well.

Once again, VirtualBox provides a solution. 

VirtualBox supports raw access by a virtual machine to the host operating system's disk drives.  The details are provided in section 9.9 of the VirtualBox 1.6.2 User Guide, which you will need to study before attempting this on your own system.  Section 9.9 includes this important warning:

I wanted to provide access to the NTFS partition only, so I attempted to follow the instructions in section 9.9.2 of the documentation.  Unfortunately, the VBoxManage command described in section 9.9.2 does not work in VirtualBox 1.6.2 when run on OpenSolaris - the bug is documented here.

Luckily, I have other operating systems installed on this machine.  :-)  I booted up Ubuntu and used the VBoxManage in my installation of VirtualBox on Ubuntu to find out the partition numbers used by VirtualBox:

gs145266@gs145266-laptop-ubu-804:~$ sudo VBoxManage internalcommands listpartitions -rawdisk /dev/sda
[sudo] password for gs145266: 
VirtualBox Command Line Management Interface Version 1.6.2
(C) 2005-2008 Sun Microsystems, Inc.
All rights reserved.
Number  Type   StartCHS       EndCHS      Size (MiB)  Start (Sect)
1       0x27  0   /32 /33  888 /172/52          6970         2048
2       0x07  888 /172/53  1023/254/63         63415     14276608
3       0xbf  1023/254/63  1023/254/63         72927    144151245
5       0x83  1023/254/63  1023/254/63           972    293507613
6       0x82  1023/254/63  1023/254/63          3827    295499673
7       0x83  1023/254/63  1023/254/63         42667    303339393

Partition 2 is the NTFS partition, so I created the files described by section 9.9.2 by using this command:

gs145266@gs145266-laptop-ubu-804:~$ sudo VBoxManage internalcommands createrawvmdk -filename /home/gs145266/part2Access.vmdk -rawdisk /dev/sda -partitions 2
VirtualBox Command Line Management Interface Version 1.6.2
(C) 2005-2008 Sun Microsystems, Inc.
All rights reserved.
RAW host disk access VMDK file /home/gs145266/part2Access.vmdk created successfully.

In addition to part2Access.vmdk, VBoxManage also created part2Access-pt.vmdk.  I copied both files to a USB drive and then rebooted the system in order to bring up OpenSolaris. 

The content of part2Access.vmdk was:

# Disk DescriptorFile
version=1
CID=4920ffa0
parentCID=ffffffff
createType="partitionedDevice"

# Extent description
RW 63 FLAT "part2Access-pt.vmdk"
RW 1985 ZERO 
RW 14274560 ZERO 
RW 129874637 FLAT "/dev/sda" 14276608
RW 149356367 ZERO 
RW 1 FLAT "part2Access-pt.vmdk" 63
RW 1991997 ZERO 
RW 63 FLAT "part2Access-pt.vmdk" 64
RW 7839657 ZERO 
RW 63 FLAT "part2Access-pt.vmdk" 127
RW 87382575 ZERO 

# The disk Data Base 
#DDB

ddb.virtualHWVersion = "4"
ddb.adapterType="ide"
ddb.geometry.cylinders="16383"
ddb.geometry.heads="16"
ddb.geometry.sectors="63"
ddb.uuid.image="840529aa-1989-46ce-c09e-7d3bbec98243"
ddb.uuid.parent="00000000-0000-0000-0000-000000000000"
ddb.uuid.modification="00000000-0000-0000-0000-000000000000"
ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000"

Note the value in bold: /dev/sda, which of course is the device name for my hard disk in Linux.  I changed it to the value that OpenSolaris would expect on my system: /dev/dsk/c5d0p0 and then saved the file.

The final step was to make it available to the virtual machine.  In order for this to work, VirtualBox has to be run with enough privileges to get raw access to the disk drive.  So I modified the GNOME menu entry for VirtualBox so that it is started by pfexec:

After starting VirtualBox, I added part2Access.vmdk as a virtual disk by using File > Virtual Disk Manager > Add. Then I was able to add it as the IDE Primary Slave device for my Vista virtual machine:

And now when I run Vista in that virtual machine, it sees my NTFS partition on my hard disk as drive E: