Friday Mar 18, 2011

And before I forget it \*again\* ...

One of the things I'm currently responsible for (as onnv gatekeeper), is maintenance of our gatehooks. From time to time I need to make changes and test them in a sandbox, and I keep my sandbox pretty small. hg update takes a while when you have to run it over all of ON :-)

Anyway, with the most recent round of changes (to support running the hooks with Mercurial built against python 2.6), I just spent the best part of a day beating my head against two things. Firstly, I'd forgotten that my sandbox was configured to exec mercurial with the


option. This has the effect with python2.6 and Mercurial 1.3.1 of making any process exit, even a successful one (exit(0)) die with a traceback:

$ $HG push ssh://onhg@localhost//scratch/gate/trees/minirepo-131_26
pushing to ssh://onhg@localhost//scratch/gate/trees/minirepo-131_26
searching for changes
Are you sure you wish to push? [y/N]: y
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
remote: caching changes for gatehooks...
remote: ...changes cached
remote: Sanity checking your push...
remote: ...Sanity checks passed
remote: pushing to /scratch/gate/trees/minirepo-131_26-clone
remote: searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
remote: Traceback (most recent call last):
remote: File "/opt/local/mercurial/1.3.1/lib/python2.6/site-packages/mercurial/", line 43, in _runcatch
remote: return _dispatch(ui, args)
remote: File "/opt/local/mercurial/1.3.1/lib/python2.6/site-packages/mercurial/", line 449, in _dispatch
remote: return runcommand(lui, repo, cmd, fullargs, ui, options, d)
remote: File "/opt/local/mercurial/1.3.1/lib/python2.6/site-packages/mercurial/", line 317, in runcommand
remote: ret = _runcommand(ui, options, cmd, d)
remote: File "/opt/local/mercurial/1.3.1/lib/python2.6/site-packages/mercurial/", line 501, in _runcommand
remote: return checkargs()
remote: File "/opt/local/mercurial/1.3.1/lib/python2.6/site-packages/mercurial/", line 454, in checkargs
remote: return cmdfunc()
remote: File "/opt/local/mercurial/1.3.1/lib/python2.6/site-packages/mercurial/", line 448, in
remote: d = lambda: util.checksignature(func)(ui, \*args, \*\*cmdoptions)
remote: File "/opt/local/mercurial/1.3.1/lib/python2.6/site-packages/mercurial/", line 402, in check
remote: return func(\*args, \*\*kwargs)
remote: File "/opt/local/mercurial/1.3.1/lib/python2.6/site-packages/mercurial/", line 2752, in serve
remote: s.serve_forever()
remote: File "/opt/local/mercurial/1.3.1/lib/python2.6/site-packages/mercurial/", line 46, in serve_forever
remote: sys.exit(0)
remote: SystemExit: 0

The second one was equally frustrating: our hooks have a Test parameter, which you set to True or False in your gate's hgrc. Setting it to True means that the hook does not do any actual work. Guess which value I'd left it set to in my minirepo?

Friday Nov 13, 2009

Migrating from Solaris Express to OpenSolaris

There's currently no way to do an in-place upgrade0 from Solaris Express's SysV packaging to OpenSolaris' IPS packaging, so you have to think outside the box just a little.

My Ultra 40 M2 has been happily chugging away with SXCE builds since I took delivery of it, but with build 131 fast approaching (when we start delivering a nightly IPS repo rather than SysV packages), I figured I should put some effort into migrating to the new world. Fortunately for me, I've been running with ZFS root since it was first available (build 80 or so), and when I reinstalled my laptop last year I put OpenSolaris on it. It's been upgraded to snv_126 in the last week, too.

Here's what I did.

After making sure I had enough space in my u40m2 ("blinder") root pool, I created a zfs snapshot of the current BE on the laptop ("gedanken"). Then destroyed it, pruned sundry filesystems and a bunch of packages which I don't need (eg, I have no use for almost all the localisations), and re-created the snapshot.

gedanken# zfs snapshot rpool/ROOT/opensolaris-7@yay
blinder# zfs create rpool/ROOT/opensolaris-7

Then I sent it from gedanken to blinder:

gedanken# zfs send rpool/ROOT/opensolaris-7@yay | \\
    ssh blinder zfs recv -v rpool/ROOT/opensolaris-7


received 20.8GB stream in 2707 seconds (7.85MB/sec)

Now the action switches to blinder:

(add entry to grub menu.lst, remember to set the default)

# zpool set boots=rpool/ROOT/opensolaris-7 rpool
# zfs set canmount=noauto rpool/ROOT/opensolaris-7
# zfs set mountpoint=/ rpool/ROOT/opensolaris-7

Time for some customisations on the new pool:

# zfs set mountpoint=/mnt rpool/ROOT/opensolaris-7
# cp /etc/ssh/sshd\*key\* /mnt/etc/ssh
# cp /etc/hostid /mnt/etc/hostid
# cp /etc/inet/hosts /mnt/etc/inet/hosts
# cp /etc/X11/xorg.conf /mnt/etc/X11
# cp /etc/hostname.nge0 /mnt/etc
# cp /var/spool/cron/cronjobs/onhg /mnt/var/spool/cron/cronjobs

I think that's it, I really should have run this from within script(1)!

# cd /
# zfs umount rpool/ROOT/opensolaris-7
# zfs set mountpoint=/ rpool/ROOT/opensolaris-7

Time for the acid test!

# init 6
[dammit, this "fast reboot" stuff is TOO FAST!]
root@blinder:~# cat /etc/release 
                       OpenSolaris Development snv_127 X86
           Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                           Assembled 06 November 2009
root@blinder:~# uname -a
SunOS blinder 5.11 snv_127 i86pc i386 i86pc

and X came up just fine.

After making sure that all the bits that I expected were there, I was very pleased to call this exercise a success.

The only bit that remains to be done is configuring my non-global zone but I'll leave that for another post.

Tuesday Aug 11, 2009

Vodafone Mobile Broadband with a Huawei K3520/E169

Since I'll be even more remote from my office for a few days, due to acceptance of my talk about gatekeeping for SAGE-AU, I thought I should acquire one of those funky mobile broadband solutions so I could keep in contact with the gate.

It's been a bit of a pain to get working, but now it is I figure I should provide some details what I've done.

Firstly, a big thankyou to my mate Arjen who brought his Huawei E220 dongle over and let me muck around with it for a few hours.

The solution I chose was Vodafone's Mobile Prepaid Broadband, which comes with a Huawei E169, aka K3520 usb dongle. This has the increasingly popular "ZeroCD(tm)" feature - when you plug it in, it defaults to showing a storage device (usb device class 8) rather than as a communications device (usb device class 2). This storage device has the windows drivers and application on it, which then kicks the device into being a communications device. All good, or something, as long as you're running XP, Vista or Mac OS X.

Not so good, clearly, for yours truly.

A bunch of google hits came up with,, and, which got me started - I need to use the usbsacm(7D) driver, so it was time to update_drv. Being a bit lazy, and suspecting that there'd be a few options that needed covering, I just hand-edited /etc/driver_aliases to add in all the possible compatible entries for the device (starting with usb12d1,1001.0). Still no joy - darn thing was still showing up as a storage device even after hotplugging.

On the off-chance that the attached-at-power-on state might be different I rebooted with it attached, ... lo and behold, it was different! No usb,class8, just compatible properties which allowed me to attach it to the usbsacm driver, and get 3 /dev/term entries. After a hotplug op, however, it was back to showing up as a storage device, which was most undesirable.

So I tried looking for what solutions the linux world has come up with to the problem, came across usb_modeswitch (which gave the clue that sending a "USB_REQ_SET_FEATURE, 00000001" would kick it properly), and also some Huawei forum posts.

One thread in particular caught my eye: Thread: K3520 (E169) microSD lost which featured a comment from a Huawei employee instructing the user to utter "at\^u2diag=255" in a hyperterm session in order to get back their microSD card slot.

So being inquisitive, and making a guess, when I had the dongle connected from boot, I ran

# tip /dev/term/0
and hotplugged the device. On re-insertion (after waiting 1 minute), I saw that there was no storage device found, just usbsacm instances. W0000t!

So now all I had to do was trawl my memories to recall how to do ppp (eeeek!) and would be connectable.

Therein lies a lot of pain, so I'll cut straight to the "this works for me" part:

The aliases I've got in /etc/driver_aliases are

usbsacm "usb12d1,1001.0"
usbsacm "usb12d1,1001"

The peers file that I'm using is

logfile /var/tmp/pppd.log
asyncmap a0000
idle 300
lcp-echo-interval 0
connect '/usr/bin/chat -s -t60 -f /etc/ppp/voda-chat'

Note that I symlinked /dev/term/0 to /dev/huawei - purely because I wanted to.

The chat script is

"" AT&F
OK AT\\136u2diag=0
OK ATS7=60
OK AT+CGDCONT=1,"IP","vfprepaymbb"
OK "ATD \\052 99\\052\\052 2 \\043"

Note the use of octal characters - Solaris' /usr/bin/chat doesn't like the caret (\^), asterisk (\*) or hash (#) in a chat script, so you have to work around that by using \\136 for caret, \\052 for asterisk, and \\043 for hash. Also, note that the prepaid solution uses an Access Point Name (APN) of "vfprepaymbb" rather than the contract/postpaid "".

The other thing of interest is the ":" in the peers file. This is what I needed to add in order to get around the problem

[ID 702911 daemon.debug] Peer refused to provide his address; assuming

Once I'd done that, things seemed to work just fine. It was rather weird to see a ping time from my non-global zone to the laptop via 3G taking about 170msec even though both machines are within my arm's reach!

I just need to get some ip-up and ip-down scripts figured out, and then I'll be all raring to go.

One final thing, there are apparently a reasonably annoying bug with usbsacm:

6840063 usbsacm stops sending data out when pushed hard (fixed in snv_120), and an RFE

6588968 Provide support for 3G USB broadband modem device from Huawei Technologies.

I don't know for sure whether this works if you're not running snv_120, but rather than disabling a core, you could try

# pbind -b 0 `pgrep pppd`

as part of your ip-up script. I'm going to try it and see.

Tuesday Feb 24, 2009

It's a small thing, but pretty

For a while now I've been wanting to switch from CDE to gdm as my login manager - part of the whole "getting ready for OpenSolaris" thing. When I LU'd to 106 I thought I'd give it a try, but svcadm disable cde ; svcadm enable gdm just wasn't giving me any gui lovin'.

Today in #opensolaris on freenode, alanc pointed me towards 6768573 GDM refuses to start if Xinerama is present but not active, which referred to a workaround in the nVidia doco:

Section "Device"
Option "NoTwinViewXineramaInfo" "True"

I added this to each Device section of my xorg.conf, logged out, ran

svcadm disable cde ; svcadm enable gdm

and lo + behold, gdm started up!


A quick change of login theme accomplished via running /usr/sbin/gdmsetup and I'm a heckuvalot happier. Of course, I can't get a command-line login screen option any more (gdm limitation), but I think I'll live :-)

Wednesday Dec 31, 2008

Guess what's on the front page?

The group that I'm part of has developed a really handy netbeans plugin module to help with writing device drivers for OpenSolaris. It's called Starfish and I was delighted to see that it's the current feature "article" at the top of

There are pointers to two flash demos (demo #1 and Driver Workshop) as well. I saw one of the demos at last year's Beijing Tech Day, and was really impressed not only with the module and its presentation, but also with just how many of the attendees at the session really got stuck in with using it there and then.

Well done to Ada and the team!

Tuesday Dec 30, 2008

Under the heading of "Why didn't I do this before?"

J and I have a Lexmark Optra S 1855 with mucho extra memory and a duplexer, got it from EBay in late 2003 when we needed to print out her OT honours thesis. It used to be the case that you could get a Solaris package of utilities and drivers for it from, but sadly the only ones available from these days are for their non-EOL'd printers.

I emailed Lexmark printer support asking whether I could get a copy of the old package, but the response was less than satisfactory:

Thank you for contacting Lexmark Email support. I apologize for the delay
in response.

In reply to your email, this printer Optra S 1855 is supported on Unix AIX
system. However,there are no specific x86 drivers available on Lexmark website.
The available drivers are print-drivers-aix5-sysv.pkg.Z and drivers-aix.pkg.Z.
You need to install these drivers. Alternatively, you can install a system
generic driver.

... after a request which specifically asked for the Solaris package.

So for the last few builds I've been printing to file as postscript, then dumping the .ps direct to port 9100 on the printer's IP.... slack, I know.

Since it's the slack time of the year I figured I'd have a go at seeing whether I could get the printer setup in my non-global zone using the lp family of commands. Not pretty, and in fact, rather painful to get anywhere. Following the instructions on gave me this:

-bash-3.2# lpadmin -p fishdbl -v /dev/null -m netstandard
-bash-3.2# lpadmin -p fishdbl -o protocol=tcp -v /dev/null
-bash-3.2# lpadmin -p fishdbl -T PS -v /dev/null
-bash-3.2# lpadmin -p fishdbl -I postscript -v /dev/null
-bash-3.2# lpadmin -p fishdbl -s prfish
-bash-3.2# lpstat -t
scheduler is running
no system default destination
-bash-3.2# lpadmin -d fishdbl
fishdbl: undefined printer

And yes, "prfish" is the name of the printer on the network.

Stopping and re-starting print/server didn't help either, so I went looking for help. The gnome-ish stuff for OpenSolaris all talked about autodiscovery, which is great except that it requires hal to work, and we don't find hal in a non-global zone. Then I found the Presto project, which lead to Printing community and that mentioned CUPS.

By now I was just totally over it all, and I wanted it to just work, dagnabbit! so I enabled CUPS in the non-global zone, configured my printer queues there, and then ran these commands in the global zone:

# lpset -a printer-uri-supported=lpd://prserv/printers/fishdbl fishdbl
# lpset -a printer-uri-supported=lpd://prserv/printers/fishsgl fishsgl

.... and it was all good!

Well, except for the annoying banner page, but the comments on Dan Anderson's post mentioned that you need to add -o job-sheets=none to the invocation for cupsd and that problem goes away. A quick edit of /var/svc/manifest/application/cups.xml (look for cups-lpd), then a re-import and restart of the cups services, and I'm now really happy.

Of course, I should hassle Norm for a slightly better solution than just hacking the manifest, but I'll do that later.

Thursday Nov 13, 2008

How to write a plugin for Pluggable fwflash(1m)

As I alluded to a few months back, I've been working on backporting Pluggable fwflash(1m) to Solaris 10. Part of the process for getting a backport integrated includes writing what we call a "TOI" - Transfer Of Information. Some people might use the term "technical deep dive".... but I'd look sideways at you if you said that's what I'd been delivering :-)

While I was in Beijing with the rest of our group last month, I delivered several TOIs, foremost of which was the one I'd developed on Pluggable fwflash(1m). The others were on Areca SAS/SATA RAID card driver, and on my stmsboot redesign.

I'm very pleased to be able to provide the Open version of the fwflash presentation via this blog.

I hope you'll find it useful - please let me know.

Thursday Oct 16, 2008

On stmsboot(1m)

When I started working with SAS (November 2006), our group's project (MPxIO support in mpt(7d)) was already off and running. The part that I was responsible for was booting - which meant fixing stmsboot(1m). Initially I was disappointed that I'd been given what I thought was such a small part of the problem to work on, but I quickly realised that there was a lot more to it than my first impression revealed.

Since we were under some pretty tight time pressure, I didn't really have time to do a redesign of stmsboot to make it more sustainable. The expected arrival of ZFS root meant that there was also some uncertainty about how that would tie in - nothing was nailed down, so I had to make some guesses and keep my eyes peeled for when ZFS root eventuated and then see what further changes needed to be made. We putback those changes into snv_63, and had a few followups in subsequent builds, and all seemed ok.

Then in February 2008 there was a thread on storage-discuss about how to obtain a particular device's lun number after running devfsadm -C (or boot -r, for that matter). I did a little digging and figured out that it would indeed be possible to provide that information - if you were willing to do a little digging and make use of a scsi_vhci ioctl() or two. Using hba-private data, unfortunately, so quite unsupportable. But it got me thinking, and I logged 6673281 stmsboot needs more clues as a placeholder.

Then a short while later I noticed that the -L or -lX options to stmsboot(1m) were now broken, as of snv_83 (nobody had worked on stmsboot(1m) since I made my changes in build 63). Since this is an essential part of the actual interface, I figured it was important enough to log (6673278 stmsboot -L/l is broken on snv_83 and later) but was unable to do much about it until I got Pluggable fwflash(1m) out of the way first. I was also annoyed to find that there were problems with updating /etc/vfstab, too (6691090 stmsboot -d failed to update /etc/vfstab with non-mpxio device paths... things were not looking good, and I was watching code rot for real. Staggering!

The kicker was (6707555 stmsboot is lost in a ZFS root world, and so I knew what I had to do - redesign and rewrite stmsboot from scratch.

The Redesign

I started with 4 guiding principles:

  • require only one reboot

  • listing of MPxIO-enabled devices should be \*fast\*

  • minimise filesystem-dependent lookups, and

  • use libdevinfo and devlinks as much as possible.

I then looked at the overall effects that we need to achieve with the stmsboot(1m) command:

  • enable MPxIO for all MPxIO-capable devices

  • enable MPxIO for specific MPxIO-capable drivers

  • enable MPxIO for specific MPxIO-capable HBA ports

  • disable MPxIO for all MPxIO-capable devices

  • disable MPxIO for specific MPxIO-capable drivers

  • disable MPxIO for specific MPxIO-capable HBA ports

  • update MPxIO settings for all MPxIO-capable drivers

  • update MPxIO settings for specific MPxIO-capable drivers

  • list the mapping between non-MPxIO and MPxIO-enabled devices

  • list device guids, if available

What does the old code do?

The code makes use of a shell script (/usr/bin/stmsboot), a private binary (/lib/mpxio/stmsboot_util) and an SMF service (/lib/svc/method/mpxio-upgrade) which runs on reboot.

The private binary does the heavy lifting, providing a way for the shell script and SMF service to determine what a device's new MPxIO or non-MPxIO mapping is. The old private binary also walked through the device link entries in /dev/rdsk when called with the -L or -l $controller options, printing any device mappings. Finally, the private binary handles the task of re-writing /etc/vfstab.

The shell script (stmsboot) is the user interface part of the facility. Its chief task is to do editing of the driver.conf(4) files for the supported drivers (fp(7d) and mpt(7d)), and to set the eeprom bootpath variable on the x86/x64 platform if disabling or updating MPxIO configurations. (Failing to do this would prevent an x86/x64 host from booting). The shell script also makes backup copies of modified files, and creates a file with instructions on how to recover a system which has failed to boot properly after running the stmsboot script.

The SMF service is armed by the stmsboot script, and runs on reboot. It mounts /usr and root as read-write, invokes the private /lib/mpxio/stmsboot_util binary to rewrite the /etc/vfstab, updates the dump configuration and any SVM metadevice (/dev/md) device mappings, and then (in the old form) reboots the system.

What has changed

The new design makes use of a private cache of device data (stored using an nvlist) gathered from libdevinfo(3LIB) functions, and obviates the requirement for a second reboot since the vfstab rewriting function is reliable - we use the kernel's concept of what devices it has attached so we're always consistent. In addition, the new design provides a significant improvement in execution time when listing device mappings: we don't need to trawl through device links on disk but instead use libdevinfo functions and our private cache to provide the required information.

The data that we store in the cache for each device attached to an MPxIO-capable controller is

  • its devid (eg, id1,sd@n5000cca00510a7cc/aS_________________________________________3QF0EAFP/a

  • its physical path (eg, /pci@0,0/pci10de,5c@9/pci108e,4131@1/sd@0,0)

  • its devlink path (eg, /dev/dsk/c2t0d0, which becomes c2t0d0)

  • its MPxIO-enabled devlink path (eg, /dev/rdsk/c3t500000E011637CF0d0,
    which becomes c3t500000E011637CF0d0)

  • whether MPxIO is enabled for the device in the running system (as a boolean_t B_TRUE or B_FALSE)

These are stored as nvlist properties:

#define NVL_DEVID "nvl-devid"
#define NVL_PATH "nvl-path"
#define NVL_PHYSPATH "nvl-physpath"
#define NVL_MPXPATH "nvl-mpxiopath"
#define NVL_MPXEN "nvl-mpxioenabled"

When we've found an MPxIO-capable device, we check whether it exists in our cached version, and if not, we create an nvlist containing the above properties and keyed off the device's devid. This nvlist is added to the global nvlist. In order to speed operations later, we also add some inverse mappings to the global nvlist:

devfspath -> devid
current devlink path -> devid
current MPxIO-enabled path -> devid
device physical path -> devid

This allows us to search for any of those paths and get the appropriate devid back, the nvlist of which we can then query for the desired properties.

When the mpxio-upgrade service is invoked, we need to determine the mapping for the root device in the currently running system and mount that device as read-write in order to continue with the boot process. We do this by reading the entry for root in /etc/vfstab and finding the physical path of that device in
the running system. We mount /devices/$physicalpath as read-write, then re-invoke stmsboot_util to find the devlink (/dev/dsk...) path for root, which we then remount. This two-remount option is required because the devlink facility is not available to us at this early stage of the boot process devfsadm is not running yet) - until we can determine what the root device is and mount it as read-write.

Once root and /usr have been remounted, we can then invoke stmsboot_util to re-write the vfstab. This is a fairly simple process of scanning through each line of the file and finding those which start with /dev/dsk, determining their mapping in the current system, and re-writing that line. As a safeguard, the new version of the vfstab is written to /etc/mpxio, and we let the mpxio-upgrade script take care of copying that file to /etc/vfstab. Once the vfstab has been updated, we run dumpadm, and if necessary, metadevadm. Finally, we re-generate the system's boot archive - which in fact is the longest single operation of all!

After this, we can disable the svc:/system/device/mpxio-upgrade:default service and exit.

When the mpxio-upgrade script exits, the svc:/system/filesystem/usr:default service takes over and the boot process completes normally - with the new device mappings already active and working. No second reboot required!

I'm not going to claim that the new form of stmsboot(1m) is a beautiful thing, but I do believe that the architecture and implementation that it has now are much more solid and should be easier to extend in the future if required.

Update (17 October 2008, 07:08 Australia/Brisbane): Jason's comment reminded me that I should have mentioned - I pushed these changes into build snv_99 and you can see them in the changelog.

See also links:

Solaris Express SAN Configuration and Multipathing Guide

Solaris ZFS Administration Guide

Linker and Libraries Guide


devfsadm(1m) stmsboot(1m) zfs(1m) zpool(1m)

libdevinfo(3LIB) libnvpair(3LIB) libdevid(3LIB)

fp(7d) mpt(7d) scsi_vhci(7d)


Saturday Sep 27, 2008

Patches for Sun Studio 12 required in order to build ONNV

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:

Patch appliedCurrent revPatch description
124873-0406Sun Studio 12_x86: Patch for dbx 7.6 Debugger
126996-0304Sun Studio 12_x86: Patch for Performance Analyzer Tools
124864-0707Sun Studio 12_x86: Patch for Sun C++ Compiler
124868-0606Sun Studio 12_x86: Patch for C 5.9 compiler
124869-0202Sun Studio 12_x86: Patch for Sun Performance Library
124876-0202Sun Studio 12_x86: Patch for Debugger GUI 3.0
126496-0202Patch for Sun Studio 12_x86 debuginfo handling
126498-0909Sun Studio 12_x86: Sun Compiler Common patch for x86 backend
126504-0101Sun Studio 12_x86: Patch for Sun Distributed Make 7.8
127002-0404Sun Studio 12_x86: Patch for Fortran 95 8.3 Compiler
127003-0101Sun Studio 12_x86: Patch for Fortran 95 8.3 Dynamic Libraries
127144-0303Sun Studio 12_x86: Patch for Fortran 95 8.3 Support Library
127148-0101Sun Studio 12_x86: Patch for update notification
127153-0101Sun Studio 12_x86: Patch for IDE
127157-0101Sun Studio 12_x86: Patch for install utilities.

Patch appliedCurrent revPatch description
124870-0203Sun Studio 12: Patch for Sun Performance Library
124872-0406Sun Studio 12: Patch for dbx 7.6 Debugger
126995-0304Sun Studio 12: Patch for Performance Analyzer Tools
127000-0405Sun Studio 12: Patch for Fortran 95 8.3 Compiler
124861-0808Sun Studio 12: Compiler Common patch for Sun C C++ F77 F95
124863-0707Sun Studio 12: Patch for Sun C++ Compiler
124867-0207Sun Studio 12: Patch for C 5.9 compiler
124875-0202Sun Studio 12: Patch for Debugger GUI 3.0
126495-0202Patch for Sun Studio 12 debuginfo handling
126503-0101Sun Studio 12: Patch for Sun Distributed Make 7.8
127001-0101Sun Studio 12: Patch for Fortran 95 8.3 Dynamic Libraries
127143-0303Sun Studio 12: Patch for Fortran 95 8.3 Support Library
127147-0101Sun Studio 12: Patch for update notification
127152-0101Sun Studio 12: Patch for IDE
127156-0101Sun 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.

Friday Sep 19, 2008

Two pushes, two heads-up messages... been a busy week

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:

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

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.

Tuesday Aug 05, 2008

It's time for some dancing

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.

Saturday Jul 19, 2008

mega_sas project page now live

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.

Friday Jul 11, 2008

Another (large) step along the road

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.

Wednesday May 14, 2008

A "well, duh!" moment

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 :-)

Sunday Mar 02, 2008

A giveaway at the Sydney Tech Day

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 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: , , , ,


I work at Oracle in the Solaris group. The opinions expressed here are entirely my own, and neither Oracle nor any other party necessarily agrees with them.


« April 2014