In RTFR - Or make sure you do read all of the README, I saw some pretty bad times to make the cscope database. The times were 23 minutes to build the cscope cross-references and 5 minutes to build the ctags cross-references.

I tried again on an idle system:

cscope: index has 12818774 references to 629823 symbols
xref: usr/src: built cscope cross-reference in 8m36s
/zoo/ws/kanigix/usr/src/tools/proto/opt/onbld/bin/xref -f -x tags
xref: usr/src: building ctags cross-reference
xref: usr/src: built ctags cross-reference in 2m21s
Time spent in user mode   (CPU seconds) : 68.39s
Time spent in kernel mode (CPU seconds) : 31.77s
Total time                              : 10:59.52s
CPU utilisation (percentage)            : 15.1%

Much better. Either the build is more IO intensive or this process is more CPU intensive. The system was page swapping like crazy during the test last night.

I've been fixated on getting cscope to work - I started down the path of trying to figure out everything I need to set in the environment to just get it to run.

In Solaris development, you always do something like:

$ cd /zoo/ws
$ ws kanigix

And the 'ws' script sets up all of your environment variables. Thus when you want to build the cscope database:

$ cd $SRC
$ make cscope.out tags

And you are off. Well, I was trying to do that in OpenSolaris and failing. I knew $SRC need to be set and I was digging my way deeper into getting it all hacked up. Then I reread the README, which you are supposed to read first, really, the whole thing.

Well I had, several times in the distant past. I've even recently skimmed parts of it to find stuff I needed. I should have reread it all. Anyway, to do what I want is already simple, just use 'bldenv':

[tdh@kanigix onnv-gate.first]> pwd
/zoo/ws/onnv-gate.first
[tdh@kanigix onnv-gate.first]> bldenv -d ./opensolaris.sh
Build type   is  DEBUG
RELEASE      is  
VERSION      is  kanigix
RELEASE_DATE is  January 2007

The top-level 'setup' target is available to build headers and tools.

Using /bin/tcsh as shell.
[tdh@kanigix onnv-gate.first]> cd $SRC
[tdh@kanigix src]> make cscope.out tags
/zoo/ws/onnv-gate.first/usr/src/tools/proto/opt/onbld/bin/xref -f -x cscope.out
xref: usr/src: building cscope cross-reference
...
cscope: building symbol index: temporary file size is 250223167 bytes
cscope: index has 12814195 references to 629827 symbols
xref: usr/src: built cscope cross-reference in 23m00s
/zoo/ws/onnv-gate.first/usr/src/tools/proto/opt/onbld/bin/xref -f -x tags
xref: usr/src: building ctags cross-reference
xref: usr/src: built ctags cross-reference in 4m55s
Time spent in user mode   (CPU seconds) : 70.00s
Time spent in kernel mode (CPU seconds) : 42.30s
Total time                              : 28:02.98s
CPU utilisation (percentage)            : 6.6%

Pretty slow - I was in the middle of a build. But that should be CPU bound and this IO bound. I'll test an idle system later.

I then use a simple alias to remember the options to invoke it:

alias csf cscope-fast -e -p 3 -d -q

But again, the real morale of the entry is, "Read the README, Really!"

I never got the onboard ethernet working on that new box - kanigix. At times nge0 would come up, but then it decided to stay down. I've mainly stayed in WinXP (remember it is for playing games with my son or by myself) or gotten things over via an USB harddrive. You can imagine that gets old.

Well, I have a bug filed on this and I'm off to Connectathon 2007 on Tuesday. I want to be able to access the box while I'm gone. I added a serial console, so I would at least be able to do some simple commands to help debug the issue. And then, a thought smacked me, why can't I add an ethernet card to it? So I picked one at random from my pile of old cards - I ended up getting a cheap GigE card. I thought I was getting a solid 10/100 card. But WinXP installed a driver and the Sun Device Detection Tool said there was a driver. And now I've got a working system:

[tdh@kanigix ~]> ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
rge0: flags=201000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS> mtu 1500 index 2
        inet 192.168.2.115 netmask ffffff00 broadcast 192.168.2.255

Aahhh. I'm really glad, because this machine is quiet and builds scream on it.

As last mentioned, I'm seeing this on boot:

Jan 28 20:40:54 kanigix genunix: [ID 104096 kern.warning] WARNING: system call missing from bind file
Jan 28 20:40:54 kanigix genunix: [ID 684969 kern.warning] WARNING: Cannot mount /system/dfs

How do we debug this? Well, first we find the first message in the source: usr/src/uts/common/os/modconf.c. In mod_getsysent():

        if ((sysnum = mod_getsysnum(mod_name)) == -1) {
                cmn_err(CE_WARN, "system call missing from bind file");
                return (NULL);
        }

Okay, this is actually looking familiar - I think I hit it before. Now I did a diff from my code before and after the merge with the latest source - and I didn't see anything glaring. Bzzt, found it after some searching. If we look at the top of make_syscallname():

                cmn_err(CE_WARN, "!Couldn't add system call \"%s %d\". "
                    "It conflicts with \"%s %d\" in /etc/name_to_sysnum.",
                    name, sysno, *cp, sysno);

So what does /etc/name_to_sysnum contain for entry 140?

adjtime                 138
systeminfo              139
seteuid                 141
forksys                 142
fork1                   143

So this is the reason I'm seeing the error on the machines. Now I have to figure out why BFU is messing up. (Note, I know I ran ACR afterwards on both of the boxes.)

I say it is BFU, but let's check. Inside the source workspace:

adjtime                 138
systeminfo              139
sharefs                 140
seteuid                 141
[tdh@warlock os]> pwd
/zoo/ws/onnv-gate/usr/src/uts/intel/os

And lets check the proto area:

[tdh@warlock os]> pwd
/zoo/ws/onnv-gate/proto/root_i386/etc
adjtime                 138
systeminfo              139
seteuid                 141
forksys                 142

Ouch, BFU is innocent! What is the deal? I looked in the nightly logs and couldn't find anything. I looked in the previous nightly log, which was the fresh install:

/usr/bin/rm -f /zoo/ws/onnv-gate/proto/root_i386/etc/name_to_sysnum; install -s -m 644 -f /zoo/ws/onnv-gate/proto/root_i386/etc ../../intel/os/name_to_sysnum

Okay, the error is that by not clobbering everything and starting fresh, /etc/name_to_sysnum did not get remade. I'll claim that this is a bug in the makefile - there should be a dependency which gets checked. My solution? Rebuild from scratch.

One thing I would like you to notice is that I debugged this issue without actually looking at a core file or stepping through a debugger. That would have taken longer. Instead, I mainly relied on grep, diff, find, OpenGrok, and cscope. With a different bug, or with code which I knew was not working, I might have delved in with kmdb. I'm glad I did not have to.

A second thing to note, I can just add in the entry for 140 to /etc/name_to_sysnum to get the system running correctly.

I actually did that on one of the two systems, the other is rebuilding the source from scratch. Here are some neat interactions:

[tdh@mrx ~]> ls -la /etc/dfs/sharetab 
lrwxrwxrwx   1 root     root          25 Jan 28 01:17 /etc/dfs/sharetab -> ../../system/dfs/sharetab
[tdh@mrx ~]> ls -la /system/dfs/sharetab
-r--r--r--   1 root     root           0 Jan 28 22:01 /system/dfs/sharetab
[tdh@mrx ~]> share -F nfs / -o rw 
Could not share: /: no permission
[tdh@mrx ~]> sudo !!
sudo share -F nfs / -o rw
[tdh@mrx ~]> ls -la /system/dfs/sharetab
-r--r--r--   1 root     root          13 Jan 28 22:01 /system/dfs/sharetab
[tdh@mrx ~]> cat /system/dfs/sharetab
/       -o      nfs     rw      

Besides the fact that it is down in /system, there is no way for you to tell that this is not really a file, but an interface into memory. Also, this is just the prototype, I recently decided to not use a symlink and instead fix up GFS to understand a file without a parent directory.

Since I'm showcasing my In-Kernel Sharetab project at Connectathon 2007 on OpenSolaris, I thought I would get it into a mercurial download of the source code from OpenSolaris.org. It sounds easy, but I've got 66 files checked out for editing (existing and new) and the source control for OpenSolaris is different than that for Solaris. Okay, the OpenSolaris one is probably pulled over nightly from the Solaris gate, but they are different interfaces to the code.

The good news is that I have no desire to putback from the OpenSolaris codebase. I just need to identify how to get my changes pushed on top of the OpenSolaris codebase. Also, the last time I synced my changes were up to the codebase of a month ago. We had a major Flag day since then - and as far as I can tell, the OpenSolaris code reflects that change.

So the first thing I have to do is get my code in sync with the current nightly, which I suspect is very close for my purposes with the OpenSolaris code. I reparent my workspace, tell it to bringover, and then resolve the conflicts in 22 files. Not bad, I only had to step in twice for the automatic conflict resoloution.

A tool we use at Sun is 'wx' and it can create backups of active files in a workspace. So once I had a good merge, I told it to backup again (I took a backup before the merge as well in case I had to roll it back). That process created a tar file with just the copies of the active fileset.

I took that over to my OpenSolaris build machine and did a diff between all 66 files. It wasn't that bad, I had managed to sync up to a close enough copy. Once I saw there were no problems, I untarred into the workspace, made sure via diff that the files were what I said to use, and then started off a build. I also kicked off a build in the synced Solaris workspace. I wanted to make sure my merge hadn't broken anything.

The OpenSolaris build finished and it was a clean build. The Solaris one is still going. Does it mean OpenSolaris is easier to build, my home machine is faster, etc? No, in the OpenSolaris case, I told it not to clobber the existing stuff (i.e., an incremental build) and in the Solaris case I told it to start from scratch. Why? Well, I'm not checking in the OpenSolaris code, I knew exactly what I was changing. I had no clue what all changed in the merge for the Solaris workspace.

Now I've got to BFU a system with those bits and see if I get what I expect. The big issue for that is that the OpenSolaris build machine I used is behind a VPN firewall. It is 10 feet from the test box, but unless I want to lose all of my other sessions (including the work build). Luckily, we don't need complete access to it, we just need the BFU archives:

[tdh@warlock onnv-gate]> ls -la archives/i386/nightly/
total 569421
drwxr-xr-x   2 tdh      staff         11 Jan 28 00:24 .
drwxr-xr-x   3 tdh      staff          3 Jan 28 00:23 ..
-rw-r--r--   1 tdh      staff      64348 Jan 28 00:24 conflict_resolution.gz
-rw-r--r--   1 tdh      staff    76112168 Jan 28 00:23 generic.kernel
-rw-r--r--   1 tdh      staff    24045508 Jan 28 00:23 generic.lib
-rw-r--r--   1 tdh      staff    2367696 Jan 28 00:23 generic.root
-rw-r--r--   1 tdh      staff    1280000 Jan 28 00:23 generic.sbin
-rw-r--r--   1 tdh      staff    178135616 Jan 28 00:24 generic.usr
-rw-r--r--   1 tdh      staff    2580480 Jan 28 00:23 i86pc.boot
-rw-r--r--   1 tdh      staff    4853760 Jan 28 00:23 i86pc.root
-rw-r--r--   1 tdh      staff    1187840 Jan 28 00:23 i86pc.usr
[tdh@warlock onnv-gate]> tar cf sht_bfu.tar archives
[tdh@warlock onnv-gate]> ls -la sht_bfu.tar 
-rw-r--r--   1 tdh      staff    290636800 Jan 28 00:50 sht_bfu.tar
[tdh@warlock onnv-gate]> bzip2 sht_bfu.tar
Time spent in user mode   (CPU seconds) : 94.17s
Time spent in kernel mode (CPU seconds) : 0.71s
Total time                              : 1:36.39s
CPU utilisation (percentage)            : 98.4%
[tdh@warlock onnv-gate]> ls -la sht_bfu.tar.bz2
-rw-r--r--   1 tdh      staff    97782474 Jan 28 00:50 sht_bfu.tar.bz2

All I have to do is get this file over, unpack it, and run BFU. Okay, I've done that - no serial console, so I can't show you the steps.

The good news is that it boots and I can get into it. I've failed the brickify test.

The somewhat bad news is this:

[tdh@mrx ~]> dmesg | grep dfs
Jan 28 01:21:33 mrx genunix: [ID 684969 kern.warning] WARNING: Cannot mount /system/dfs
[tdh@mrx dfs]> cd /system/dfs
[tdh@mrx dfs]> ls -la
total 4
dr-xr-xr-x   2 root     root         512 Jan 27 23:57 .
drwxr-xr-x   5 root     root         512 Jan 23 04:37 ..

I actually have to remove the /system/dfs from my prototype to get the final product. But I still need to know how I horked this all up. It isn't the symlink which is messed up, it is loading the sharefs module which is broken. Was it the merge? Or was it the blind copy into the OpenSolaris workspace? Or did a bug creep in? The other evil thought is that I've tested this on 64 bit sparc and 64 bit amd machines, but not 32 bit x86es. It could be a bug in the code.

Ouch, I put it on my new desktop (64bit AMD) and it panicked the box. I think it was not related - the backtrace was in usb (page fault in usb_ac:usb_ac_setup_connections+450 to be exact). As near as I can figure, it crashed while loading my Logitech QuickCam - see usb_ac.c. I just added that the other day, easy enough to pull for a stable system.

Note that I think it must be my QuickCam because it has a microphone and my SoundBlaster is PCI. And it is in some DEBUG code - which explains why I hadn't seen it before. I filed a new bug for it - Bug ID: 6518469 DEBUG build page faults when booting with an attached Logitech QuickCam.

Anyway, the system does put up a warning about mounting /system/dfs:

DEBUG enabled
WARNING: system call missing from bind file
WARNING: Cannot mount /system/dfs

I should have first booted this machine as a stock OpenSolaris install. Then I could have added my code. Anyway, it came up on the next boot. But I have no idea if it will crash at any time.

I'll look to see if there is a match to the backtrace of the core. As for my problem, I need to get the Solaris build finished and see how it works. I'll just work my way back through the steps (checking my backups for changes). And if that doesn't work, I'll show you the painful way of debugging a live kernel.

By the way, failure is a good experience. I've caught a potential problem with my demo 3 days before I would if I waited until the conference. I've also caught a bug before the QA people did - which they would do once I let them play with the code. In all, this has been a good use of 5 hours.

I'm not making this up - one of the skins in Jedi Knight: Jedi Academy by Lucas Arts is an old boss of mine - Paul Crozier. If you know Paul, you would have to agree:

The fun part will be passing this on to his current direct reports and letting them speculate on whether he is on the Light or Dark Side.

Okay, I must have done this twice, on different machines. The make fails, telling me that it can't build the closed source. I've unpacked the closed source, I don't think it is in the right place, but it does agree with what the opensolaris.sh states. The logs are pretty generic in the mail message:

The following command caused the error:                                                                                        
dmake: Warning: Don't know how to make target `/zoo/ws/onnv-gate/proto/root_i386/lib/libc_i18n.a'                              
dmake: Warning: Target `libc.so.1' not remade because of errors                                  

I think it is the wrong SUNWonbld, the wrong compile options, etc. I start over and get it to work on the slow machine - why? I don't know. But I sure do try and clone everything on the fast machine.

On the slow machine, this can be a 3-5 hour process. On the fast one, 1-2 hours. 30 minutes if I don't clobber everything.

I still don't know what tweaked me on to the problem. I thought it was something in the log file, but in looking back, I can't see jack. I can see this in my history file:

    38  13:15   ls -la closed/
    39  13:15   ls -la closed/root_sparc/

It is easy to spot if you know I'm building on an w2100z, i.e., an amd64 box.

So the other clue in the error logs is:

==== Build warnings (DEBUG) ====

Warning: closed binaries not properly unpacked.
                echo "Warning: closed binaries not" \
                echo "Warning: libc_i18n.a must be built" \

First, make sure you did unpack the closed encumbered stuff. If you did, then make sure you did it for the right architecture. I suspect if you have them both there, things will just work.

One thing I noticed in the BFU instructions (see Section 5 - Installing and Testing ON and Dennis Clark at How To Build NON-debug OpenSolaris - { updated for snv_20060925 }) was that you need to set some environment variables before you can proceed. Actually, it seems like the Developer's Reference at OpenSolaris.org (the Section 5 link above) doesn't mention this at all. Dennis provides the following:

# PATH=/opt/SUNWspro/bin:/opt/onbld/bin:/usr/ccs/bin:/usr/sbin:/usr/bin
# export PATH
# FASTFS=/opt/onbld/bin/`uname -p`/fastfs;export FASTFS
# BFULD=/opt/onbld/bin/`uname -p`/bfuld;export BFULD
# GZIPBIN=/usr/bin/gzip;export GZIPBIN 

Now I got bit by this at work, in preparing the Connectathon 2007 build boxes. This will lead to an additional warning:

/tmp/bfu.628850[2428]: /net/onnv.eng/export/gate/public/bin/acr: cannot open
chmod: WARNING: can't access /tmp/bfubin/acr

You could bypass this by entering an additional environment variable:

# ACR=/opt/onbld/bin/acr

You will still get a warning about the following:

Marking converted services as enabled ...
cp: cannot access /net/greenline.eng/meta0/smf/post-5090532/sysidtool.xml
bfu: could not copy /net/greenline.eng/meta0/smf/post-5090532/sysidtool.xml
cp: cannot access /net/greenline.eng/meta0/smf/post-5090532/kdmconfig.xml
bfu: could not copy /net/greenline.eng/meta0/smf/post-5090532/kdmconfig.xml

Okay, despite these warning messages, how did it come out?

[tdh@mrx grub]> uname -a
SunOS mrx 5.11 kanigix-20060123-nd i86pc i386 i86pc

The BFU script is such a big deal in OpenSolaris development and testing. You shouldn't have to setup these environment variables and you shouldn't get the warning messages. Time to roll up some sleeves and suggest a fix.

I lost connection to the SWAN (Sun Wide Area Network) yesterday. It turns out that both the punchin (Solaris IPSEC/VPN tool) servers at Sun and my home router decided to misbehave. The first really illustrated how difficult it is for a company to broadcast that services are down when they use that medium to spread knowledge. And the second was frustrating on several fronts.

I pulled a network cable slightly at one point in the early triaging, so I couldn't ping from one side of the office to the next. When I fixed that issue, I still couldn't ping outside the house. So I called up Cox 's customer service. I was really amazed by their phone system trying to triage my issue. It walked me through isolating the issue on the cable modem, then my router, and finally my computer. Like the normal technicians, it had no clue about OSes other than WinXP or Mac OSX. It would ping and probe my cable modem and the router. It made me feel good that it couldn't get past the router.

After 25 productive minutes with the automated system (I'm serious - at the end of the session with it, I knew the problem was with my router.), I got passed to a live tech. He started to repeat the stuff the automated system had me do, but I got him past that quickly. He did isolate that my cable modem was in standby - the automated system should have done that.

He had me connect my desktop up to the cable modem directly and I was getting out. So there was the nail.

Now I've done everything but reset the factory settings on this router. Evidently the WAN ethernet port is hosed. I also had at least two power outages in the morning. My computers are protected, the router is not.

Anyway, I dropped a Linksys WRT55AG in there and I remembered quickly why I hadn't done that in the past. Most broadband routers support simple firewalls and port blocking. Both the Belkin and the Netscreen 10 box allowed you to punch open a port and also allowed you to redirect it. So, port 8085 on my Belkin became port 80 on my internal web server. The Linksys does allow you to open ports, but it does not allow you to redirect them. I tried my Linksys WRT54GL, hoping since it was more modern it would be easier to configure. Nope, it still didn't have the feautures that I wanted. (I've got WRT54GL because I wanted to install a Linux distro on it and look at putting a slimmer OpenSolaris on it.) I ended up keeping the WRT54GL as my router - when I went back to the WRT54GL, it wasn't working like I wanted.

The big fear for me wasn't configuring apache to serve two addresses. No, it was in getting sendmail to listen to two ports. See, cox.net blocks port 25. They say they only block it coming out, but they also block it going in. It turns out my version of sendmail had support to handle this:

[tdh@adept mail]> diff sendmail.mc sendmail.mc.stock
113c113
< DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
---
> dnl DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
120c120
< DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
---
> dnl DAEMON_OPTIONS(`Port=XXXX, Name=MSA, M=E')dnl

If you just do the MSA change, you loose the ability get mail on port 25, so you need to also uncomment the line for MTA. Also, I had to remove the 'a' option since mail was being rejected due to not being authorized:

Diagnostic-Code: smtp; 530 5.7.0 Authentication required

So now I could get out and things could get in. This was when I found out that I still could not punchin. I thought perhaps that the router was blocking IPSEC/VPN requests, but the version of punchin I was using let me know that a IPSEC-ized ping was getting through to the punchin servers. I tried different boxes (both clients and servers), still no result. I used my laptop to get into the VPN servers. And I got a new version of punchin.

Finally, someone let me know the servers were hosed.

I've confirmed all of my services are working correctly (last time I had to change my internal server before a trip, I couldn't ssh back in). Guess I'll have to get another WRT54GL to play with.

I got a new DVD drive for mrx, my old desktop - it supports dual-layers. So I burned a Nevada b56 DVD, zapped the WinXP partition and installed Solaris to the hilt. I've been off of its WinXP partition for a week and wasn't missing anything.

So I have the base bits installed - I didn't do the Solaris Developer's Express install. But I want to now get the Sun Studio 11 bits installed. I don't want to grab them off of the web and install them when they are just sitting there. So, how do I get them?

# cd /media/SOL_11_X86
# ls -la DeveloperTools
total 30
dr-xr-xr-x   4 root     root        2048 Jan 18 23:50 .
dr-xr-xr-x   2 root     sys         4096 Jan 18 23:48 ..
dr-xr-xr-x   2 root     root        2048 Dec 12 18:21 NetBeans
-r--r--r--   1 root     root        1046 Dec 18 18:20 README
dr-xr-xr-x   3 root     root        2048 Dec 11 02:36 SunStudio
-r-xr-xr-x   1 root     root         645 Dec 18 16:07 install_devtools.sh
-r-xr-xr-x   1 root     root        2207 Dec 15 12:47 main.sh

Is it as simple as running this install script? Yep, easy to find out if we consult the README.

Whoops, looks like you can't do this from a telnet window:

# ./install_devtools.sh
Error: Can't open display:

Can we fake it out?

# /media/SOL_11_X86/DeveloperTools/main.sh
***********************
***  Sun Studio 11  ***
***********************
Installing Sun Studio 11  (16..20 minutes)

I don't care if it is pretty or not. I do care that I be able to do this on a headless box.

Hmm, while that is going on, I need to also do some light housekeeping. Before I started this, I modified the sshd to accept root logins. Now I want to add some accounts and have them show up in /home. Now, you really can't create directories in /home. Well you can, but it is a pain. So, instead, lets tell the automounter that we want it to do this for us:

# cp auto_home auto_home.stock
# diff auto_home auto_home.stock
29,30c29
< #+auto_home
< *     localhost:/export/home/&
---
> +auto_home
# svcadm restart autofs

Now, I normally have useradd(1M) create the directory for me, but I think that won't work in this case. Pretty simple to do:

# mkdir /export/home/tdh
# useradd -u 1066 -g 10 -c "Tom Haynes" -d /home/tdh tdh
# ls -la /home/tdh
total 3
drwxr-xr-x   2 root     root         512 Jan 24 01:49 .
dr-xr-xr-x   2 root     root           2 Jan 24 01:48 ..
# chown tdh:staff /export/home/tdh
# ls -la /home/tdh
total 3
drwxr-xr-x   2 tdh      staff        512 Jan 24 01:49 .
dr-xr-xr-x   2 root     root           2 Jan 24 01:48 ..

Make sure to give the account a password:

# passwd tdh
New Password:
Re-enter new Password:
passwd: password successfully changed for tdh

And we test that we can login:

[tdh@adept ~]> ssh mrx
Password:
Last login: Wed Jan 24 01:52:09 2007 from adept.internal.
Sun Microsystems Inc.   SunOS 5.11      snv_56  October 2007
$ pwd
/home/tdh
$ df -h .
Filesystem             size   used  avail capacity  Mounted on
/dev/dsk/c0d0s7         12G    12M    12G     1%    /export/home

Back to the install of the Sun Studio 11:

# /media/SOL_11_X86/DeveloperTools/main.sh
***********************
***  Sun Studio 11  ***
***********************
Installing Sun Studio 11  (16..20 minutes)
   .............
Installing 5 Sun Studio 11 patches  (9 minutes)
    120759-08    120762-03    121016-04    121018-07    121616-03
Updating Sun Studio 11 with fixed binaries.
Installing Sun Studio 11 /usr symlinks and GNOME desktop file
Sun Studio 11 installation complete.

**********************
***  NetBeans 5.5  ***
**********************
Installing NetBeans IDE 5.5 and NetBeans Enterprise Pack 5.5 (1 minute)
Installing Sun Java System Application Server 9 Update 1  (2 minutes)
Installing NetBeans GNOME desktop file
Netbeans 5.5 installation complete.

All done.  This window will exit in 20 seconds.

Great, now I need some tools like sudo and vim. I can get these off of either sunfreeware.com or blastware.org, but I'll stick to the Sun Software Companion CD. Since there isn't one out for Nevada yet, I'll use the Solaris 10 one. I've got the CD somewhere, but besides testing installs, I really can't be bothered anymore to do use physical images.

Instead, I use the loopback to load the iso and install from there:

# lofiadm -a /home/tdh/sol-10-ccd-GA-x86-iso.iso
/dev/lofi/1
# mkdir -p /isos/mnt/companion
# mount -F hsfs -o ro /dev/lofi/1 /isos/mnt/companion
# cd /isos/mnt/companion
# ./installer

And by the way, this installer happens to be smart enough to know that the machine is headless.

Once that is done, I'm going to want to setup sudo and then call it quits for the night. (Okay, actually I want to automate all of this such that I never, ever have to worry about it. I also want to install SUNWonbld, the closed bits, and the latest source drop to the public. That can all happen later.)

# /opt/sfw/sbin/visudo

And change this:

# Same thing without a password
# %wheel        ALL=(ALL)       NOPASSWD: ALL

to this:

# Same thing without a password
%staff  ALL=(ALL)       NOPASSWD: ALL

And now make sure to get the setuid bit set correctly.

# chmod +s /opt/sfw/bin/sudo

And test:

[tdh@adept ~]> scp .tcshrc mrx:/home/tdh
Password:
.tcshrc                                                                                                100% 5417     5.3KB/s   00:00
[tdh@adept ~]> ssh mrx
Password:
Last login: Wed Jan 24 02:36:08 2007 from adept.internal.
Sun Microsystems Inc.   SunOS 5.11      snv_56  October 2007
[tdh@mrx ~]> sudo w
  2:36am  up  1:03,  2 users,  load average: 0.05, 0.57, 0.68
User     tty           login@  idle   JCPU   PCPU  what
root     pts/2         1:35am        17:11         tcsh
tdh      pts/3         2:36am                      w

Note that I also changed my shell from sh to tcsh in the background. I test a very simple command to make sure sudo works.

The answer is a resounding yes. I used some ideas from Dennis Clarke's burning snv_55b DVDs while watching for black helicopters to test the theory.

First I got the five parts from http://opensolaris.org/sxcr_dvd and stitched them together:

# cat sol-nv-b55b-x86-dvd-iso-a sol-nv-b55b-x86-dvd-iso-b \
sol-nv-b55b-x86-dvd-iso-c sol-nv-b55b-x86-dvd-iso-d \
sol-nv-b55b-x86-dvd-iso-e > os-b55b-dvd.iso

Then I determined if the checksums were correct:

# /opt/sfw/bin/gmd5sum os-b55b-dvd.iso
c6d968d1761ba20178bf1cbec3b61734  os-b55b-dvd.iso
# /opt/sfw/bin/gmd5sum ../b55b/solarisdvd.iso
c6d968d1761ba20178bf1cbec3b61734  ../b55b/solarisdvd.iso
# grep c6d968d1761ba20178bf1cbec3b61734 md5sum_x86.list
c6d968d1761ba20178bf1cbec3b61734  sol-nv-b55b-x86-dvd.iso

And then I searched for even a single bit of difference:

# cmp -l ../b55b/solarisdvd.iso os-b55b-dvd.iso 
# 

So they are the same bits. I can now use either image to construct the necessary ISO for the Connectathon build machines.

By the way, the Solaris Studio 11 is now included on the x86 DVD but not the sparc one.

I found a really neat tool on BigAdmin: Sun Device Detection Tool. Okay, I got pushed there by a reply by John Brewer in a opensolaris-rfe thread: Re: SATA support. This BigAdmin article has a Java-based tool to browse your system to tell you what hardware it has and whether or not Solaris 10 11/06 has a driver to support each item.

So the hardest system I have is my Fujitsu P7010D. And here is what the tool reported:

Now I don't care about the modem - I haven't in years. As for the wifi chip, I know it is supported in Nevada and I think it should work in Solaris 10.

I just posted the presentation schedule for Connectathon 2007 as Talks 2007. The talks are open to the public (go ahead, jam the room and ask probing questions):

Parkside Hall
180 Park Ave.
San Jose, CA 95113

This is the building which is connected to the The Tech Museum of Innovation in downtown San Jose. In most other cities, I'd tell you to look for the introverted and pale computer geeks. That wouldn't work for that area.

In reading one of Stephen's older blog entries a steaming pile of p.o.o., he has the hackergotchis for the planet.opensolaris.org contributers.

I found this web tutorial: my head, so I tried to follow it to get my very own hackergotchis:

As you can see, I didn't get the drop shadow done correctly, so I decided not to do it.

One of the things we got asked about last year at Connectathon 2006 was where was the OpenSolaris station? Well, I just asked my manager that question and also volunteered to staff that station at Connectathon 2007. And he agreed that we should do it.

The commitment to OpenSolaris is pretty deep at Sun. He didn't question whether it would work, how it would impact the other stuff I'm supposed to be doing at Cthon, or impose any other typical management hurdles. He just said. "I like it!"

Now I have to figure out how to tie OpenSolaris and NFS together for the event. I don't have an outstanding body of work that is being done outside of Sun. But I don't need to have that ready, I can take a project which I've been developing at Sun.

I guess I'll get coverage of the In-Kernel Sharetab project that I have been working on - it moves /etc/dfs/sharetab into main memory. This should allow for faster bootups with a larger number of shares (the file lock is gone and think of thousands of ZFS filesystems - one per user) and also allow the delegation of ZFS filesystem creation to non-root users. /etc/dfs/sharetab is owned by root and is marked as read-only. ZFS doesn't use RBAC - it uses acls. So to modify the file, you need a setuid program to change your effective UID. With my changes, ZFS can have sharemgr make a system call to add a share for a new filesystem.