/devices/pseudo/bitbucket@0:bitbucket: Musings from the bitbucket

We moved the ONNV gate to use Sun Studio 12 during this last week.

As it happens, I've been asked to maintain a build server for a related group, and to help that group bootstrap their development. I realised that I really should find out what patches are required for Sun Studio 12 so that we've got the same toolchain in use, and a quick mail to Nick resulted in the following lists:

X86/X64

Patch applied	Current rev	Patch description
124873-04	06	Sun Studio 12_x86: Patch for dbx 7.6 Debugger
126996-03	04	Sun Studio 12_x86: Patch for Performance Analyzer Tools
124864-07	07	Sun Studio 12_x86: Patch for Sun C++ Compiler
124868-06	06	Sun Studio 12_x86: Patch for C 5.9 compiler
124869-02	02	Sun Studio 12_x86: Patch for Sun Performance Library
124876-02	02	Sun Studio 12_x86: Patch for Debugger GUI 3.0
126496-02	02	Patch for Sun Studio 12_x86 debuginfo handling
126498-09	09	Sun Studio 12_x86: Sun Compiler Common patch for x86 backend
126504-01	01	Sun Studio 12_x86: Patch for Sun Distributed Make 7.8
127002-04	04	Sun Studio 12_x86: Patch for Fortran 95 8.3 Compiler
127003-01	01	Sun Studio 12_x86: Patch for Fortran 95 8.3 Dynamic Libraries
127144-03	03	Sun Studio 12_x86: Patch for Fortran 95 8.3 Support Library
127148-01	01	Sun Studio 12_x86: Patch for update notification
127153-01	01	Sun Studio 12_x86: Patch for IDE
127157-01	01	Sun Studio 12_x86: Patch for install utilities.

SPARC

Patch applied	Current rev	Patch description
124870-02	03	Sun Studio 12: Patch for Sun Performance Library
124872-04	06	Sun Studio 12: Patch for dbx 7.6 Debugger
126995-03	04	Sun Studio 12: Patch for Performance Analyzer Tools
127000-04	05	Sun Studio 12: Patch for Fortran 95 8.3 Compiler
124861-08	08	Sun Studio 12: Compiler Common patch for Sun C C++ F77 F95
124863-07	07	Sun Studio 12: Patch for Sun C++ Compiler
124867-02	07	Sun Studio 12: Patch for C 5.9 compiler
124875-02	02	Sun Studio 12: Patch for Debugger GUI 3.0
126495-02	02	Patch for Sun Studio 12 debuginfo handling
126503-01	01	Sun Studio 12: Patch for Sun Distributed Make 7.8
127001-01	01	Sun Studio 12: Patch for Fortran 95 8.3 Dynamic Libraries
127143-03	03	Sun Studio 12: Patch for Fortran 95 8.3 Support Library
127147-01	01	Sun Studio 12: Patch for update notification
127152-01	01	Sun Studio 12: Patch for IDE
127156-01	01	Sun Studio 12: Patch for install utilities.

You can get these patches from SunSolve. Update: Thanks to Cyril (see comments) for pointing out my typo for the rev of 124864. Another case of "typing while tired" . Cyril - it's fixed now.

I've had a busy week. Apart from getting my ducks in a row for a backport of Pluggable fwflash(1m) and my redesign + reimplementation of stmsboot(1m) to a Solaris 10 Update, I also pushed two rather interesting changesets into builds 99 and 100:

• arcmsr(7d), the Areca SAS/SATA RAID card driver (build 99), and


• ITU construction utilities (build 100).

Why are these important? First off, the arcmsr(7d) driver is the first storage driver that we've integrated as a result of an RFE coming in via http://bugs.opensolaris.org.


Normally we'd go through months of legal back-n-forth getting licensing arranged and back-to-back support agreements with SLAs... a big undertaking. After the rfe was filed (by the CEO of Areca Technologies as it happens), the arcmsr(7d) code went through Sun's Open Source Review process (it's BSD-licensed), and then it was a matter of getting the code to compile within the existing ON driver.


The second reason this is important is because our group (Solaris Storage drivers) now has a much better idea about how to get this sort of integration to actually happen. One thing that people always complain about is that $OtherOSen always have better (more wide-ranging) driver support than OpenSolaris, so now we've got a better idea about what to do, I hope we'll be able to make getting drivers integrated more easily.


Thirdly, the ITU construction utilities supersede the existing SUNWpkgd tools - which are old, enforced an arbitrary breakdown between 32- and 64-bit packages, and were pretty darned useless for patching boot and installation media when it comes to Grub. With the code which I integrated on Wednesday morning (yay first heads-up message for the build!) those restrictions now no longer apply - making the task of, oh, I dunno.... testing installation of OpenSolaris to volumes in a new RAID card (to pull an example out of thin air)... much easier. We're all winning with this.



I would like to publicly thank Billion Wu and Erich Chen of Areca Technologies for their assistance (and patience!) with getting arcmsr(7d) integrated.


I would also like to thank Jongki Suwandi who wrote the initial version of the ITU construction tools, and Jan Setje-Eilers for passing them on to me.

#FF35C5. That is all.

At the third stroke, the time will be 11pm US/Pacific......

From 11pm US/Pacific the NV gate is not accepting any more putbacks and is not under the control of teamware.

Time to start dancing (on the grave of teamware {cue evil cackle}).

I'm really looking forward to the new way of working - with Mercurial and the collection of associated utilities which people like Rich, Dave, Bill and MJN have been working on for ages to smooth the transition. Of course, that collection is called "Cadmium" - it's layered on top of Mercurial. (See the Periodic Table). It took me ages to get it.

I've helped out with the mega_sas project here and there over the last 7 or so months, and so I'm really glad to see that the project page is now live and unhidden.

We'll be adding to the content on the page as time goes by, updating progress towards the project goals which we outlined in the project proposal email.

Just saw this in my mailbox from mjnelson:

Author: mjnelson
Repository: /hg/onnv/onnv-gate
Latest revision: 935563142864dcc57ff3b20395393f5f0323921f
Total changesets: 1
Log message:
6538468 add Mercurial support to ON developer tools
6658967 /etc/publickey entries get removed on upgrade
Portions of 6538468 contributed by Rich Lowe.
Portions of 6538468 contributed by Mike Gerdts.
[extensive list of files changed removed]

Along with a copy (or 6!) of the associated flag day message:

Flag day: ON Developer Tools upgraded to support Mercurial




There's more associated doco to come, of course, but from now on if you're building OpenSolaris (ok, the ON consolidation) from the source then you should really get up to speed on how your workspace management tools behave.

This is all in preparation for the close of build 96: from the open of build 97 the ON gate will be managed with Mercurial.... as a precursor to the eventual move of the gate outside Sun's network and opening up the contribution process yet more.

So we're getting there, bit by bit by bit.

So... it's a little late, but better late than never. Now that I've got my u40m2 re-configured and redone my local source code repositories (not hg repos... yet), I figured it was time to make the other part of what I've mentioned to customers a reality.

The first part is this: bringing over the source from $GATE, wx init, cd $SRC, /usr/bin/make setup on both UltraSPARC and x64 buildboxen, and then zfs snapshot followed by two zfs clone ops so that I get to build on UltraSPARC and x64 buildboxen in the same workspace at the same time.

Yes, this is a really ugly workaround for Should be able to build for sparc and x86 in a single workspace, and while I'm the RE for that bug, it's probably not going to be fixed for a while.


So here's the afore-mentioned "other part": a kinda-sorta replacement for bringover, using ZFS snapshots and clones. Both Bill and DarrenM have mentioned something of this in the past, and you know what - the script I just hacked together is about 3 lines of content, 1 line of #! magic and 16 lines of arg checking.

Herewith is the script. No warranties, guarantees or anything. Use at your own risk. It works for me, but your mileage may vary. Suggestions and improvements cheerfully accepted.

#!/bin/ksh
#
# CDDL HEADER START
#
# The contents of this file are subject to the terms of the
# Common Development and Distribution License (the "License").
# You may not use this file except in compliance with the License.
#
# You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
# or http://www.opensolaris.org/os/licensing.
# See the License for the specific language governing permissions
# and limitations under the License.
#
# When distributing Covered Code, include this CDDL HEADER in each
# file and include the License file at usr/src/OPENSOLARIS.LICENSE.
# If applicable, add the following below this CDDL HEADER, with the
# fields enclosed by brackets "[]" replaced with your own identifying
# information: Portions Copyright [yyyy] [name of copyright owner]
#
# CDDL HEADER END
#
#
# Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
#
# Version number? if this needs a rev.... there's something 
# really, really wrong


# we use the following process to snapshot, clone
# and mount an up to date image of $GATE ::
# zfs snapshot sink/$GATE@$wsname  {$GATE is onnv-gate|on10-feature-patch|on10-patch}
# zfs clone sink/$GATE@wsname sink/src/$wsname  ## ignore "failed to mount"
# zfs set mountpoint=/scratch/src/build/{rfes|bugs}/$wsname sink/src/$wsname


# arg1 is "b" or "r" - bug or rfe
# arg2 is $GATE - onnv-gate, on10-feature-patch, on10-patch
# arg3 is wsname


# first, some sanity checking of the args
#

if [ "$1" != "b" -a "$1" != "r" ]; then
   echo "Is this a bug (b) or an rfe (r) ?"
   exit 1;
fi

if [ "$2" != "onnv-gate" -a "$2" != "on10-feature-patch" -a "$2" != "on10-patch" ]; then
    echo "unknown / invalid gate specified ($2). Please choose one of "
    echo "onnv-gate, on10-feature-patch or on10-patch."
    exit 2;
fi

GATE=$2
BR=
WSNAME=$3

if [ "$1" = "b" ]; then
    BR="bugs"
else
    BR="rfes"
fi

    

#
# ASSUMPTION1: our $GATE is a dataset under pool "sink"
# ASSUMPTION2: we have another dataset called "sink/src"
# ASSUMPTION3: our user has delegated admin privileges, and can mount
#              a cloned snapshot under /scratch/src/.....

zfs snapshot sink/$GATE@$WSNAME
zfs clone sink/$GATE@$WSNAME sink/src/$WSNAME >> /dev/null 2>&1
zfs set mountpoint=/scratch/src/build/$BR/$WSNAME sink/src/$WSNAME
exit 0

Note the ASSUMPTIONx lines - they're specific to my workstation, you will almost definitely want to change them to suit your system.

Back when I got my first real break as a sysadmin, one of my first tasks was to upgrade the Uni's finance office server, a SparcServer 1000. Running Solaris 2.5 with a gaggle of external unipacks and multipacks for Oracle 7.$mumble, I organised an outage with the DBAs and the Finance stakeholders, practiced installing Solaris 2.6 on a new system (we'd just got an E450), and at the appointed time on the Saturday morning I rocked up and got to work on my precisely specified upgrade plan.

That all went swimmingly (though looooooooowly) until the time came to reboot after the final SDS 4.1 mirror had been created. The primary system board decided that it really didn't like me, and promptly died along with the boot prom.


PANIC!!


At that point I didn't know all that much about the innards of the SS1000 otherwise I probably would have just engaged in some swaptronics with the other three boards. However, I was green, nervous, and - by that point - very tired of sitting in a cold, loud machine room for 12 hours. Turned the box off, rang the local Sun support office and left a message (we didn't have weekend coverage on any of our systems then), rang my boss and the primary stakeholder in the Finance unit and went home.

Come Monday morning, all hell broke loose - the Accounts groups were unable to do any work, and the DBAs had to do a very quick enable of the DR system so I could get time to work on the problem with Sun. The "quick enable" took around 4 hours, if I'm remembering it correctly. Fortunately for me, not only were the DBAs quite sympathetic and very quick to help, but Miriam on the support phone number (who later hired me) was able to diagnose the problem and organise a service call to replace the faulty board. She also calmed me down, which I really, really appreciated. (Thankyou Miriam!)

So ... why am I dredging this up? Because I've just done a LiveUpgrade (LU) from Solaris Nevada build 91 to build 93, with ZFS root, and it took me a shade under 90 minutes. Total. Including the post-installation reboot. Not only would I have gone all gooey at the idea of being able to do something like LU back in that job, but if I could have done it with ZFS and not had to reconfigure all the uni- and multi-pack devices I probably could have had the whole upgrade done in around 4 or 5 hours rather than 12. (Remember, of course, that while the SS1000 could take quite a few cpus, they were still very very very very sloooooooooow).

Here's a trancript of this evening's upgrade:

# uname -a
SunOS gedanken 5.11 snv_91 i86pc i386 i86xpv

(remove the snv_91 LU packages)
pkgrm SUNWlu... packages from snv_91
(add the snv_93 LU packages)
pkgadd SUNWlu... packages from snv_93

(Create my LU config)

# lucreate -n snv_93 -p rpool
Checking GRUB menu...
Analyzing system configuration.
No name for current boot environment.
INFORMATION: The current boot environment is not named - assigning name .
Current boot environment is named .
Creating initial configuration for primary boot environment .
The device  is not a root device for any boot environment; cannot get BE ID.
PBE configuration successful: PBE name  PBE Boot Device .
Comparing source boot environment  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.
Creating configuration for boot environment .
Source boot environment is .
Creating boot environment .
Cloning file systems from boot environment  to create boot environment .
Creating snapshot for  on .
Creating clone for  on .
Setting canmount=noauto for  in zone  on .
Saving existing file  in top level dataset for BE  as //boot/grub/menu.lst.prev.
File  propagation successful
Copied GRUB menu from PBE to ABE
No entry for BE  in GRUB menu
Population of boot environment  successful.
Creation of boot environment  successful.
-bash-3.2# zfs list
NAME                             USED  AVAIL  REFER  MOUNTPOINT
rpool                           50.0G   151G    35K  /rpool
rpool/ROOT                      7.06G   151G    18K  legacy
rpool/ROOT/snv_91               7.06G   151G  7.06G  /
rpool/ROOT/snv_91@snv_93        71.5K      -  7.06G  -
rpool/ROOT/snv_93                128K   151G  7.06G  /tmp/.alt.luupdall.2695
rpool/WinXP-Host0-Vol0          3.57G   151G  3.57G  -
rpool/WinXP-Host0-Vol0@install  4.74M      -  3.57G  -
rpool/dump                      4.00G   151G  4.00G  -
rpool/export                    7.47G   151G    19K  /export
rpool/export/home               7.47G   151G  7.47G  /export/home
rpool/gate                      5.86G   151G  5.86G  /opt/gate
rpool/hometools                 2.10G   151G  2.10G  /opt/hometools
rpool/optcsw                     225M   151G   225M  /opt/csw
rpool/optlocal                  1.20G   151G  1.20G  /opt/local
rpool/scratch                   14.4G   151G  14.4G  /scratch
rpool/swap                         4G   155G  64.6M  -

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

Golly, that was so easy! Here I was rtfming for the LU with UFS syntax.... not needed at all.

# time luupgrade -u -s /media/SOL_11_X86 -n snv_93

No entry for BE  in GRUB menu
Copying failsafe kernel from media.
Uncompressing miniroot
Uncompressing miniroot archive (Part2)
13367 blocks
Creating miniroot device
miniroot filesystem is 
Mounting miniroot at 
Mounting miniroot Part 2 at 
Validating the contents of the media .
The media is a standard Solaris media.
The media contains an operating system upgrade image.
The media contains  version <11>.
Constructing upgrade profile to use.
Locating the operating system upgrade program.
Checking for existence of previously scheduled Live Upgrade requests.
Creating upgrade profile for BE .
Checking for GRUB menu on ABE .
Saving GRUB menu on ABE .
Checking for x86 boot partition on ABE.
Determining packages to install or upgrade for BE .
Performing the operating system upgrade of the BE .
CAUTION: Interrupting this process may leave the boot environment unstable 
or unbootable.
Upgrading Solaris: 100% completed
Installation of the packages from this media is complete.
Restoring GRUB menu on ABE .
Adding operating system patches to the BE .
The operating system patch installation is complete.
ABE boot partition backing deleted.
PBE GRUB has no capability information.
PBE GRUB has no versioning information.
ABE GRUB is newer than PBE GRUB. Updating GRUB.
GRUB update was successful.
Configuring failsafe for system.
Failsafe configuration is complete.
INFORMATION: The file  on boot 
environment  contains a log of the upgrade operation.
INFORMATION: The file  on boot 
environment  contains a log of cleanup operations required.
WARNING: <3> packages failed to install properly on boot environment .
INFORMATION: The file  on 
boot environment  contains a list of packages that failed to 
upgrade or install properly.
INFORMATION: Review the files listed above. Remember that all of the files 
are located on boot environment . Before you activate boot 
environment , determine if any additional system maintenance is 
required or if additional media of the software distribution must be 
installed.
The Solaris upgrade of the boot environment  is partially complete.
Installing failsafe
Failsafe install is complete.

real    83m24.299s
user    13m33.199s
sys     24m8.313s

# zfs list
NAME                             USED  AVAIL  REFER  MOUNTPOINT
rpool                           52.5G   148G  36.5K  /rpool
rpool/ROOT                      9.56G   148G    18K  legacy
rpool/ROOT/snv_91               7.07G   148G  7.06G  /
rpool/ROOT/snv_91@snv_93        18.9M      -  7.06G  -
rpool/ROOT/snv_93               2.49G   148G  5.53G  /tmp/.luupgrade.inf.2862
rpool/WinXP-Host0-Vol0          3.57G   148G  3.57G  -
rpool/WinXP-Host0-Vol0@install  4.74M      -  3.57G  -
rpool/dump                      4.00G   148G  4.00G  -
rpool/export                    7.47G   148G    19K  /export
rpool/export/home               7.47G   148G  7.47G  /export/home
rpool/gate                      5.86G   148G  5.86G  /opt/gate
rpool/hometools                 2.10G   148G  2.10G  /opt/hometools
rpool/optcsw                     225M   148G   225M  /opt/csw
rpool/optlocal                  1.20G   148G  1.20G  /opt/local
rpool/scratch                   14.4G   148G  14.4G  /scratch
rpool/swap                         4G   152G  64.9M  -
-bash-3.2# lustatus
Boot Environment           Is       Active Active    Can    Copy      
Name                       Complete Now    On Reboot Delete Status    
-------------------------- -------- ------ --------- ------ ----------
snv_91                     yes      yes    yes       no     -         
snv_93                     yes      no     no        yes    -         

# luactivate snv_93
System has findroot enabled GRUB
Generating boot-sign, partition and slice information for PBE 
Saving existing file  in top level dataset for BE  as //etc/bootsign.prev.
WARNING: <3> packages failed to install properly on boot environment .
INFORMATION:  on boot 
environment  contains a list of packages that failed to upgrade or 
install properly. Review the file before you reboot the system to 
determine if any additional system maintenance is required.

Generating boot-sign for ABE 
Saving existing file  in top level dataset for BE  as //etc/bootsign.prev.
Generating partition and slice information for ABE 
Copied boot menu from top level dataset.
Generating direct boot menu entries for PBE.
Generating xVM menu entries for PBE.
Generating direct boot menu entries for ABE.
Generating xVM menu entries for ABE.
Disabling splashimage
Re-enabling splashimage
No more bootadm entries. Deletion of bootadm entries is complete.
Changing GRUB menu default setting to <0>
Done eliding bootadm entries.

**********************************************************************

The target boot environment has been activated. It will be used when you 
reboot. NOTE: You MUST NOT USE the reboot, halt, or uadmin commands. You 
MUST USE either the init or the shutdown command when you reboot. If you 
do not use either init or shutdown, the system will not boot using the 
target BE.

**********************************************************************

In case of a failure while booting to the target BE, the following process 
needs to be followed to fallback to the currently working boot environment:

1. Boot from Solaris failsafe or boot in single user mode from the Solaris 
Install CD or Network.

2. Mount the Parent boot environment root slice to some directory (like 
/mnt). You can use the following command to mount:

     mount -Fzfs /dev/dsk/c1t0d0s0 /mnt

3. Run  utility with out any arguments from the Parent boot 
environment root slice, as shown below:

     /mnt/sbin/luactivate

4. luactivate, activates the previous working boot environment and 
indicates the result.

5. Exit Single User mode and reboot the machine.

**********************************************************************

Modifying boot archive service
Propagating findroot GRUB for menu conversion.
File  propagation successful
File  propagation successful
File  propagation successful
File  propagation successful
Deleting stale GRUB loader from all BEs.
File  deletion successful
File  deletion successful
File  deletion successful
Activation of boot environment  successful.

# date
Friday,  4 July 2008  9:45:41 PM EST


# init 6
propagating updated GRUB menu
Saving existing file  in top level dataset for BE  as //boot/grub/menu.lst.prev.
File  propagation successful
File  propagation successful
File  propagation successful
File  propagation successful

Here I reboot and then login.

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

# lufslist -n snv_91
               boot environment name: snv_91

Filesystem              fstype    device size Mounted on          Mount Options
----------------------- -------- ------------ ------------------- --------------
/dev/zvol/dsk/rpool/swap swap       4294967296 -                   -
rpool/ROOT/snv_91       zfs          20630528 /                   -


# lufslist -n snv_93
               boot environment name: snv_93
               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/zvol/dsk/rpool/swap swap       4294967296 -                   -
rpool/ROOT/snv_93       zfs       10342821376 /                   -

Cor! That was so easy I think I need to fall off my chair.

Thinking about this for a moment, I needed just 6 commands and around 90 minutes to upgrade my laptop. If only I'd had this technology available to me back then.


Finally, let me send a massive, massive thankyou to the install team and the ZFS team for all their hard work to get these technologies integrated and working pretty darned smoothly together.

I did a bios upgrade on my laptop the other day - from A05 to A08. Thought nothing of it until I re-installed the beast with build 91 to get some ZFS root goodness. (Note that currently you have to use the text-mode installer to do this).

xVM told me, none too politely, that it couldn't find any virtualization capabilities in my cpus, so it wasn't going to be my friend any more.

I logged 6714698 snv_91 xVM spurious failure on VT-enabled hardware and provided what I thought was enough info (prtpicl -v and prtconf -v output). Turns out I should have also provided the output from xm info and xm dmesg. When I did, I noticed these lines:

...
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p 
...

and

(xVM) Processor #0 6:15 APIC version 20
(xVM) Processor #1 6:15 APIC version 20
(xVM) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
(xVM) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(xVM) Using scheduler: SMP Credit Scheduler (credit)
(xVM) Detected 2194.558 MHz processor.
(xVM) VMX disabled by Feature Control MSR.
(xVM) CPU0: Intel(R) Core(TM)2 Duo CPU     T7500  @ 2.20GHz stepping 0b
(xVM) Booting processor 1/1 eip 90000
(xVM) VMX disabled by Feature Control MSR.
(xVM) CPU1: Intel(R) Core(TM)2 Duo CPU     T7500  @ 2.20GHz stepping 0b
(xVM) Total of 2 processors activated.

What the...?


Quick jump into the bios revealed that there was a new option - Virtualization support. It was, of course, turned off by default. Turning it on and booting the xVM kernel showed me some much nicer output from those commands:

xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p
                             hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 

and

(xVM) Processor #0 6:15 APIC version 20
(xVM) Processor #1 6:15 APIC version 20
(xVM) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
(xVM) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(xVM) Using scheduler: SMP Credit Scheduler (credit)
(xVM) Detected 2194.555 MHz processor.
(xVM) HVM: VMX enabled
(xVM) VMX: MSR intercept bitmap enabled
(xVM) CPU0: Intel(R) Core(TM)2 Duo CPU     T7500  @ 2.20GHz stepping 0b
(xVM) Booting processor 1/1 eip 90000
(xVM) CPU1: Intel(R) Core(TM)2 Duo CPU     T7500  @ 2.20GHz stepping 0b
(xVM) Total of 2 processors activated.

Now as soon as I get a spare cycle or three, I can go and see about building an S10 domU for backport builds. That'll be fun!

I met a bloke called Arjen Lentz years ago. And I do mean years ago. Via HUMBUG, a user group I joined at its inception. He was with MySQL at the time, either their only or perhaps one of 2 employees that the company had in Australia.

He really drove home to me that it really was possible to work remotely from your boss, and from any other colleague, and develop software, and do so effectively.

Last year he moved on from MySQL to found his own consulting company, Open Query. Training, design, tuning... anything you want to do with MySQL (and PostgreSQL for that matter) he'll be able to help you do it. As far as I know, he's doing really well. I'm not sure that I'd like the startup-on-my-own thing - makes me just a little bit nervous right now - so I've got a lot of respect for those who do. (My best mate Leighton does this as well with Bare Metal Software).

Anyway.... Arjen was interviewed by one of Australia's well-known OpenSource commentators, Sam Varghese, and that interview is now live on ITWire.

If there's truly anybody out there who still wonders how you can make money from Open Source Software, Arjen is a great example - and he only lives about 10km from me

I run two non-global zones on my workstation - one for web/dns/blog, and one for my VPN connection to Sun. Yesterday realised that there was an internal webcast I really needed to listen, so I started playing around with audio in the zone. First off, there wasn't any audio output. No /dev/audio* or /dev/sound/*.

After a bit of searching, I found that I should add a "set match" option to my zonecfg:

# zoneadm -z knockout
zonecfg:knockout> add device
zonecfg:knockout:device> set match=/dev/sound/*
zonecfg:knockout:device> end
zonecfg:knockout> commit
zonecfg:knockout> exit
# zoneadm -z knockout boot

But that didn't work. I was rather annoyed at that point, so I logged 6701076 zones should not be sound proof!. Perhaps I was a bit hasty - the RE updated the bug overnight (my time) asking "Why didn't you do the obvious thing and add a 'set match=/dev/audio*' ?"

Which was the "well, duh!" moment for me. Boy do I feel like a nong:

# zoneadm -z knockout halt
# zoneadm -z knockout
# zonecfg -z knockout
zonecfg:knockout> add device
zonecfg:knockout:device> set match=/dev/audio*
zonecfg:knockout:device> end
zonecfg:knockout> commit
zonecfg:knockout> exit
# zoneadm -z knockout boot

/me looks around sheepishly.... it works

Just read this interview with James Gosling. On the front page of the SMH no less.

My favourite quote from the article is this:

At 52, Mr Gosling is a researcher at Sun Microsystems where his main interest is software development tools. "The reason why I stay is it's filled with a bunch of nutcases. Sun is a (relatively) small organisation, so there is a culture of tolerating craziness. It is open and understanding to risk; to an idea that might not be what people are expecting."

Ain't that the truth!

I've often said (to myself, at least!) that I work with some scarysmart people here at Sun, and it's nice to know that I'm not the only one who thinks that we're more than a little wacky.

Care to get your hands on a Sun workstation? If you're going to the Sydney Tech Days or the OpenSolaris day and register on OpenSolaris.org during the event, then you'll go into a draw to win one of three Ultra 20 workstations.

I don't know the exact conditions attached - so you'll have to rock up to the event to find out

While you're attending, come along to the OpenSolaris booth where you'll find people like .... oh, me!... hanging around and talking about pretty much anything and everything related to OpenSolaris.

Technorati tags: opensolaris, ultra20, Sydney, Sun Tech Days, giveaway

Got me a new laptop two weeks ago - spiffy new Dell XPSM1530, dual core Intel T7500 cpu, 4gb ram, 320Gb sata disk, the ultrabright 1680x1050 screen, Intel 4965abg wireless, builtin webcam. Very nice.

Except that the builtin wired nic is a Marvell Yukon FE+. Not supported by skge, or yukonx from Marvell and while there's a patch for FreeBSD, it hasn't been ported or integrated into the myk driver that Masa Murayama wrote.

I logged 6660771 need GLDv3 driver support for Marvell Yukon FE+ in Solaris but it's not resolved yet.

Note for the unwary: when I tried the skge and yukonx drivers, I got system panics:

update_drv -v -a -i ' "pci11ab,22e" ' [skge|yukonx]

which results in a message like this:

ERROR: yukonx0: SkGeHwInnit: Currently not supported!

So being the Bright, Resourceful, Usually Correct and Exact person that I am, I emailed Masa directly asking for help.

A number of myk test iterations later and I've now got a working myk driver. Not totally sure when he's going to post the updated version to his website, but the version I've found success with is 2.6.0t9 - it's still missing a few things but it seems to be able to give me 11.mumble Mbyte/sec over my 100Mbit/sec switch to blinder (u40m2) - pretty good indeed.

I also needed to install the Opensound drivers but once PSARC/2008/043 is integrated I don't think that'll be necessary.

Now I can go off to the Sun TechDays conference next week with all the bits working together.

Thankyou Masa - you're a champ!

Got my travel, hotel and everything else booked today so that I can go and present (for Jim Walker) on OpenSolaris Testing at the upcoming Sun Tech Days conference at the start of March.

I'm really looking forward to it and I hope to catch up with my Sydney-based colleagues and SOSUG mates as well as our friends and family. (J's able to come with me, which is a real bonus).