Alan Hargreaves' Weblog

Windows, OpenSolaris and VirtualBox

Over the weekend (as I knew we were going to have some network stuff going on) I installed Virtual Box on my notebook on the Windows disk (I have nevada on the other disk [yes I have a notebook with two 250gb discs]) and then installed a release candidate ISO of OpenSolaris 2009.06. I copied a backup of my punchin credentials and the two packages I needed onto the FAT32 partition of the windows disc from within nevada and then got to work setting things up.

Gotcha #1, don't try to do the install with only 512mb memory, it looks like it's working, but it just sits there doing precious little. I used up about an hour of battery on the train trying this. I got off the train at Tuggerah and went to McDonalds to both get dinner and finish the install, which then went along happily (I chose McDonalds mainly because they also have free wifi).

Installed the punchin packages and restored the credentials. It actually took a bit of research to find out how to use sharing. Doing it from the Windows side with Virtual Box was relatively straightforward, but doing it from the OpenSolaris side was not so obvious. I ended up finding it after hitting the User Guide. I'd called the directory I wanted "share", from OpenSolaris I had to do

$ pfexec mount -F vboxfs share /mnt

Once I'd done that it just worked fine. Everything looked great, except I'd now run out of battery with no power points easily in sight. Oh well headed home.

Once connected to the power everything seemed to work. I dropped the memory back to half a gig (as I run a few things in windows that are kinda memory hungry), and it worked fine for me all weekend just on the notebook.

Arrived at work today to find that for reasons that I won't go into today, the workstation that I normally run my Sun Ray IIFS from was off the internal network, making my Sun Ray useless to me.

I ran up Virtual Box on the notebook and then started the OpenSolaris that I had to start working. A little into the day it occurred to me that I have two 22" screens and a full sized keyboard and mouse sitting next to the notebook, currently doing very little. The keyboard and mouse are in their own unpowered usb hub plugged into the Sun Ray. OK they are now plugged into the notebook. That made a huge difference to productivity.

I then unplugged the digital connection from the screen and attached that to the notebook. Now I have a mirror of what's on the notebook and it is also easier to read. Productivity goes up again.

You know, I could go one step further by instead of mirroring the screens actually going dual screen, such that I have the windows session displayed on teh notebook and then I could go full screen (1600x1200) for OpenSolaris.

Once I arranged things that the mouse moved in the correct direction between the two, this is wonderful and surprisingly usable (well more so once i upped the memory for the OpenSolaris part to 768mb).

Gotcha #2, don't install the VDI files on a FAT32 filesystem, which is what I did because that's where I had the most free space. Everything worked wonderfully until the size of the dynamic disc that I had allocated hit 4gb. Then I started getting errors about full disks from Virtual Box. OK moving the VDI file to the NTFS wasn't that hard. I had to first physically copy it, then release and remove it from within Virtual box, then attach it again from the NTFS disc.

And that's how I ended up getting my job done today. I'm pretty happy with how it worked out.

Posted at 07:09PM May 25, 2009 by Alan Hargreaves in OpenSolaris  |  Comments[6]

Installing "extra" packages against OpenSolaris 2008.11 (with or without support repository updates)

It took me a bit to work out what was going on here (including a number of re-installs to make sure I hadn't screwed up), so I thought it worth sharing.

First, what a failure looks like:

After following Chris's instructions for adding the extra repository, I tried to install flash from it so the kids could play their browser based flash games.

$ pfexec pkg install pkg://extra/web/firefox/plugin/flash
Creating Plan |                        
pkg: the following package(s) violated constraints:
        Package pkg:/SUNWcsl@0.5.11,5.11-0.111 conflicts with constraint in installed pkg:/entire: 
                Pkg SUNWcsl: Optional min_version: 0.5.11,5.11-0.101 max version: 0.5.11,5.11-0.101 defined by: pkg:/entire

It turns out that what is at issue here is that the extra repository now has the "fat" packages that we will be using for 2009.06. The pkg command on 2008.11 (with any number of support repository updates - I was originally on SRU4 before re-install) can't handle these so it produces that cryptic message.

So, what can we do about it?

The first step is to have a look at all versions of the package we are interested in on extra.

$ pfexec pkg list -af 'pkg://extra/web/firefox/plugin/flash'
NAME (AUTHORITY)                              VERSION         STATE      UFIX
web/firefox/plugin/flash (extra)              10.0.22.87-0.111 known      ----
web/firefox/plugin/flash (extra)              10.0.22.87-0.101 known      u---
web/firefox/plugin/flash (extra)              9.0.151-0.101   known      u---
web/firefox/plugin/flash (extra)              9.0.125-0.101   known      u---
web/firefox/plugin/flash (extra)              9.0.125-0.101   known      u---

The version 9 packages will work ok, so we simply install one of those:

$ pfexec pkg install "pkg://extra/web/firefox/plugin/flash@9.0.151-0.101"
PHASE                                          ITEMS
Indexing Packages                            554/554 
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                    1/1         3/3     2.46/2.46 

PHASE                                        ACTIONS
Install Phase                                  19/19 
Reading Existing Index                           9/9 
Indexing Packages                                1/1 

And done. The note to myself for 2009.06 is that that 4gb root disc is just not going to cut it anymore :) Time for something more reasonable.

Posted at 03:41PM May 22, 2009 by Alan Hargreaves in OpenSolaris  |  Comments[3]

multithreaded processes and mdb

Today I had to look at a gcore of devfsadm. Most specifically I wanted to have at what the threads in cond_wait() were doing. I haven't done a lot with such stuff in userland before so thought it would make a good short blog topic on things that can be done.

First off we run up mdb

#  mdb /usr/sbin/devfsadm devfsadm.gcore
Loading modules: [ libsysevent.so.1 libnvpair.so.1 libc.so.1 libavl.so.1 libuutil.so.1 ld.so.1 ]
> 

Great, we got all the modules. So, what lwps have we got?

> $L
lwpids 1, 2, 3, 4, 5 and 6 are in core of process 135.

So we have six threads, let's have a look at the registers in first one (note that this is on SPARC).

> 1::regs
%g0 = 0x00000000                 %l0 = 0x00000000 
%g1 = 0x0000001d                 %l1 = 0x00043748 
%g2 = 0x0003cb2c                 %l2 = 0xffbff8ac 
%g3 = 0x00038000                 %l3 = 0x00000001 
%g4 = 0x0003cb2c                 %l4 = 0x00000000 
%g5 = 0x00000000                 %l5 = 0x00000000 
%g6 = 0x00000000                 %l6 = 0x00000000 
%g7 = 0xff342a00                 %l7 = 0x00000001 
%o0 = 0xff342c40                 %i0 = 0x00000001 
%o1 = 0xff13b90c libc.so.1`pause+0x50 %i1 = 0x0003a2a4 
%o2 = 0xff1c3800 libc.so.1`_uberdata %i2 = 0xff342a00 
%o3 = 0x00000000                 %i3 = 0x00039954 
%o4 = 0xff342a00                 %i4 = 0x00016964 
%o5 = 0x00000000                 %i5 = 0x00000000 
%o6 = 0xffbff850                 %i6 = 0xffbff8b0 
%o7 = 0xff13b914 libc.so.1`pause+0x58 %i7 = 0x00015ce4 

 %psr = 0x00000044 impl=0x0 ver=0x0 icc=nzvc
                   ec=0 ef=0 pil=0 s=0 ps=64 et=0 cwp=0x4
  %y = 0x00000000
  %pc = 0xff14c160 libc.so.1`_pause+4
  %npc = 0xff14c164 libc.so.1`_pause+8
  %sp = 0xffbff850
  %fp = 0xffbff8b0                    

 %wim = 0x00000082
 %tbr = 0x00000000

Now to have a look at the stack we simply find the %sp value and use it with the stack dcmd.

> 0xffbff850::stack
0x15ce4(0, 43b48, 39db4, 4, 2276c, 38000)
main+0x358(0, 39f2c, ffbffdec, 398e4, 1, 38000)
_start+0x108(0, 0, 0, 0, 0, 0)

Note that this gives the stack frames above the current and not the current. From the value of %pc above we can see where we are executing in the current frame. You can also see that we the caller does not have an entry in the symbol table. Unfortunately, on Solaris 10, devfsadm has a lot of functions and variables declared as static, which really does make debugging a pain. Fortunately this is not the case in Nevada/OpenSolaris.

Looking at the other lwps is as simple as listing the lwp id in front of the regs dcmd and repeating what we just did. I won't go into how I worked out which of the static routines we were executing in for the other lwps in cond_wait(), save to say that there are only a couple of places that make that call in the code, and matching up the assembly around the locations to the source (especially looking at called functions), makes this not too difficult.

Posted at 04:46PM May 04, 2009 by Alan Hargreaves in Solaris  |