Thursday Oct 30, 2008

Said Syed's OKCOSUG talk

Just got back from my first Oklahoma City OpenSolaris User Group meeting. It was fun. Said gave a presentation on sizing provisioning for attaching storage to VMware's ESX. It provided a good overview on VMotion and SVMotion.

But of more interest to me was Said's interest in serving the customer. Not only did he try to shape the presentation to those in the audience, he wanted to learn how to convey information better in his blog. I hope I was able to help.

One thing that I learned about customer service and blogging from him was that he flat out told the audience, if you have a question, post a comment in one of my blog entries and I'll get back to you. I.e., he is flipping the push model of the author delivering in blogging to a pull model of the reader driving content. I was floored by this and came away wondering how to have a free floating request section such that comment fields stay true to the blog article and new content can be driven.

Also of interest was the audience member who basically asked when was Sun's xVM going to support NFSv4.1. We don't even have it close to shipping and already people want it in configurations we aren't thinking about!


Originally posted on Kool Aid Served Daily
Copyright (C) 2008, Kool Aid Served Daily

Monday Oct 06, 2008

Pushing your open gate to OpenSolaris

In Setting up a Development Project Gate, I showed you the steps I took to setup a shared development gate. The only thing I left out was the automatic push to a Mercurial repository on OpenSolaris. I'll take you through these steps now.

By the way, thanks to Dave Marker for sharing how ONNV does this and writing some Python tools to automate the majority of the push.

Get a repository

First you need to get a project leader for your project to create a workspace for you on hg.opensolaris.org. They can do this by logging to OpenSolaris and going to the project page. Then they select 'SCM Management'. Next 'Add Repository' and remember to click the Mercurial radio button on the next screen. The page is pretty explanatory and the only thing to remember is that it might spew up a message about the project already existing. It also seems to take 5-10 minutes for the project space to show up.

Which if you know about it is okay. You can take this time to configure who has commit rights. (You'll need one account for sure, more on that later.)

As evidenced in Setting up a NFS41 gate, I had a hard time figuring out where the gate was located. It can be reached as:

hg clone ssh://anon@hg.opensolaris.org/hg/<PROJECT>/<GATE-NAME>

Note you need to configure anonymous access on the repository page for this to work. I'm not sure, but I believe this also implies anyone can write back to the gate. Tie this in with a lack of tools to maintain the gate out there (including deletion) and you can see this might be a problem.

Configure a SSH public key

This part is the scary part - scary in that you have to decide if you want automatic pushes or manual pushes.

Manual pushes

If you want manual pushes, then you need to make sure you have a SSH public key setup as described in opensolaris.org SSH key help. Then whenever you want to push a change, you would do:

hg push -R <your gate> -e "ssh -q -F ssh://<YOUR OSOL USERNAME>@hg.opensolaris.org/hg/<PROJECT>/<GATE-NAME>"

You don't have to read much more of the rest of this entry, except perhaps to make sure your proxy host is correct.

Automatic pushes

If you want automatic pushes, then you need to configure a special key pair without a passphrase. Note that this is a risk you need to manage yourself. It needs to be blank because you don't want to even store the passphrase anywhere. I've done this type of thing in the past for production systems and the trick is that you want to lock down the box you have stored the private version of the key

Follow the directions as described in opensolaris.org SSH key help to publish this key. Note that no-one will know that this passphrase is empty for this key. They still need the private copy of the key. We have to make sure that is locked down tight!

  • Use a system with a non-standard root password.
  • Strictly control admin access to the system
    • Don't hand out the root password.
    • Don't make sudo too permissive.
  • Pick a non-global account to store the data in.
  • Make sure the permissions are 700 on the directory where the key is stored.
  • If you share that homedir, make sure to read The myth of security with AUTH_SYS, which means:
    • Do not accept the default access list ooptions.
    • Set root= or use anon=-1.
    • Set the rw= and/or ro= hosts appropriately.
    • Strongly consider kerberizing the share.

There is probably more you can do, so the first thing is to accept responsibility for this setup.

Okay, having scared you, it is now time to configure this special ssh configuration:

[nfs4hg@aus1500-home ~/tmp]> mkdir opensolaris
[nfs4hg@aus1500-home ~/tmp]> chmod 700 opensolaris/
[nfs4hg@aus1500-home ~/tmp]> cp ~/opensolaris/\* .
[nfs4hg@aus1500-home ~/tmp]> more config 
Host \*.org
        GlobalKnownHostsFile /pool/nfs4hg/opensolaris/known_hosts
        ProxyCommand /usr/lib/ssh/ssh-socks5-proxy-connect -h 192.18.43.19 %h %p
        IdentityFile /pool/nfs4hg/opensolaris/id_dsa
        User <YOUR OSOL USERNAME>

You'll have to figure out whether or not you need the proxy configuration or not. And you will need to fix-up the paths for the GlobalKnownHostsFile and IdentityFile.

Also note that I've got this account already setup with a ~/.ssh directory to allow integrations to the gate. It doen't have DS keys, but I like to keep these apart. And note that id_dsa and id_dsa.txt are the keypair that you generated with the empty passphrase.

Edit hook/updateoso.py

In the copy of hook/updateoso.py I got from ssh://anon@hg.opensolaris.org/hg/scm-migration/onnv-gk-tools, I had the following minor diffs:

[nfs4hg@aus1500-home ~]> diff /pool/onnv-gk-tools/hook/updateoso.py onnv-gk-tools/hook/updateoso.py
33c33
< OSOREPO = "ssh://hg.opensolaris.org/hg/nfsv41/nfs41-gate"
---
> OSOREPO = "ssh://hg.opensolaris.org/hg/onnv/onnv-gate"
43c43
< This script must be run as user "nfs4hg".
---
> This script must be run as user "onhg".
76c76
<     home = pwd.getpwnam("nfs4hg")[5]
---
>     home = pwd.getpwnam("onhg")[5]
95c95
<     if utility.check_user("nfs4hg", m) is False:
---
>     if utility.check_user("onhg", m) is False:
97c97
<         m.write('''Can't update OpenSolaris. User != "nfs4hg"\\n''')
---
>         m.write('''Can't update OpenSolaris. User != "onhg"\\n''')

Note that I grabbed this script right after Dave Marker put it back, so I got a cutting edge version of it. I know he is about to change it such that the user and osol path are configurable variables outside of this file. I.e., you would make changes in a project specific configuration file.

Anyway, once those changes are made, go a head and make sure this line is enabled in your official clone's hgrc:

# These hooks are run from bghook() in the background
bg-changegroup.0 = python:hook.updateoso.updateoso

I'm assuming you have modeled your development gate ala onnv (and as I described in Setting up a Development Project Gate). If you haven't, then I think all you need to do is add this as the last bg.changeroup entry in your gate's hgrc.

And now you are good to go!

You might want to do the manual push I described above to seed the gate.


Originally posted on Kool Aid Served Daily
Copyright (C) 2008, Kool Aid Served Daily

Friday Oct 03, 2008

New gate and closed bins build a working pNFS community

So I have a successful community up and running. I'll push the closed binaries out later tonight. Life impinges...


Originally posted on Kool Aid Served Daily
Copyright (C) 2008, Kool Aid Served Daily

Hey, the source browser is up and running

Check out nfsv41/nfs41-gate.


Originally posted on Kool Aid Served Daily
Copyright (C) 2008, Kool Aid Served Daily

First successful push to nfs41-gate on opensolaris

We had the first developer make a real push to the nfs41-gate on the OpenSolaris NFSv41 Project Repository.

Jim Wahlig had this to push:

[thud@adept nfs41-gate]> hg incoming
comparing with ssh://anon@hg.opensolaris.org/hg/nfsv41/nfs41-gate
searching for changes
changeset:   7743:c672b1cb86be
user:        Thomas Haynes 
date:        Thu Oct 02 22:28:30 2008 -0500
summary:     Added tag closedv1 for changeset 9fab48a31a4a

changeset:   7744:763bfa203d1a
tag:         tip
user:        jwahlig@aus-build3
date:        Fri Oct 03 11:52:59 2008 -0500
summary:     fix stable storage on x86.

The only issue we encountered was that mail did not get accepted for the nfs41-discuss mailing list. I'll have to look at that.

You can also see above the tag I pushed for closedv1.


Originally posted on Kool Aid Served Daily
Copyright (C) 2008, Kool Aid Served Daily

Thursday Oct 02, 2008

How to tie our closed-bins to the new gate

I was trying to relax and I realized we would have an ongoing problem in keeping the new ssh://anon@hg.opensolaris.org/hg/nfsv41/nfs41-gate in sync with our copy of the closed binaries. But, I think we will be saved by a couple of things:

  1. We don't update the internal nfs41-gate automatically with every change in the onnv-gate. We actually normally sync up with the 2 week releases. This means that random changes to the closed source will not impact the osol gate. As a matter of fact, we control when a change causes a respin of the closed bits.
  2. Just like the ON gatekeepers tag their gate every 2 weeks, we could also use 'hg tag' to mark when the closed binaries changed. We could store the closed binaries on the project download page and when an external developer saw the tag change, they could then pick up a new copy

Plus with setting the mail to go out to the dev mailing list, people would be able to see a need to pickup a new set of closed binaries.

[thud@adept src]> hg incoming
comparing with ssh://anon@hg.opensolaris.org/hg/nfsv41/nfs41-gate
searching for changes
changeset:   7743:c672b1cb86be
tag:         tip
user:        Thomas Haynes 
date:        Thu Oct 02 22:28:30 2008 -0500
summary:     Added tag closedv1 for changeset 9fab48a31a4a

Originally posted on Kool Aid Served Daily
Copyright (C) 2008, Kool Aid Served Daily

Juggling work load

The group has so much to do and it feels like so little time to do it. I don't think anyone just codes. I'm looking at my action list and it is all over the place:

Test fix for 6738223 Can not share a single IP address
Unit testing was successful, but mini-PIT testing is mixed. I think this is more a configuration issue than a code issue.
Push code review along for 6751438 mirror mounted mountpoints panic when umounted
Frank gave me a good review/discussion, but I need another reviewer.
Figure out how to configure a minimal jumpstart
I could ask someone to do it, but I've been meaning to understand jumpstarting myself. This is an easy way to ease into it.
Open up an OpenSolaris gate for NFSv41
Chewed up a large chunk of my day. Hey, I need to do a test integration to see if it works. If it does, I have to run because Dave Marker is going to eat my beating heart. And it works! Here is my Linux box at home:
[thud@adept src]> hg incoming
comparing with ssh://anon@hg.opensolaris.org/hg/nfsv41/nfs41-gate
searching for changes
changeset:   7742:9fab48a31a4a
tag:         tip
user:        Thomas Haynes 
date:        Thu Oct 02 21:19:03 2008 -0500
summary:     Test of push to osol

[thud@adept src]> hg pull -u
pulling from ssh://anon@hg.opensolaris.org/hg/nfsv41/nfs41-gate
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
Build closed-binaries for OpenSolaris
Trivial, but time consuming. I will need to also install and test. We also just got rid of auth records, so I need to see how we are changing the configuration of the DS and MDS.
Figure out how to translate data path to guuid
The above mentioned server change really hosed up my progress on spe. I've got the final pieces in my mind, but I need to just grind it all out. And then I need to start testing. I may need to go to VirtualBoxes to get enough DSes for testing.
D'oh, need to get a VirtualBox image together for OpenSolaris
I can piggyback on the push of the closed binaries.
Modernize style of blog site
Looks dated and I want to add a tag cloud. At least one of the shared styles will do this, but I just don't want to use it.

Originally posted on Kool Aid Served Daily
Copyright (C) 2008, Kool Aid Served Daily

Setting up a NFS41 gate

We just opened up a new Mercurial gate of NFSv41 on OpenSolaris.org. Eventually it will automatically push changes as they occur to our gate. I also need to figure out a way to automatically update the closed-bins.

The hardest part was figuring out the naming convention. Some links of interest are Some work on libMicro; Mercurial transition notes and finally How to Use Mercurial (hg) Repositories. Look for For Project Leads: How to set up a Mercurial repository.

Update: Also, SCMVolunteers, look for Setting up a new (Mercurial) Project repository on OpenSolaris.org.

In any event, you can grab a copy of the source at:

hg clone ssh://anon@hg.opensolaris.org/hg/nfsv41/nfs41-gate

Note the lack of a double '/' after the FQDN - normally I would take that as a sign of a bug with Mercurial.

Note that while this compiles, you can't run it without a corresponding closed-bins.

Eventually, you should be able to browse the source via Cross Reference: nfs41-gate.

And a big thanks to David Marker for providing the help necessary to getting this to go live!


Originally posted on Kool Aid Served Daily
Copyright (C) 2008, Kool Aid Served Daily

Wednesday Oct 01, 2008

One code review out, another to come shortly

I just put a code review request out for 6751438 mirror mounted mountpoints panic when umounted on nfs-discuss (see [nfs-discuss] Code reviewers wanted for 6751438 mirror mounted mountpoints panic when umounted ).

The hardest part was finding time to test. This resulted from a fix made a couple of months ago. And at that time, both unit and mini-PIT testing showed no panics. And now the mirrormount test suite inside mini-PIT could reliably trigger a panic. Luckily, I understand what the bug is and the panics have stopped.

I'm also about to ask for a code review for 6738223 Can not share a single IP address, which is quite simple to fix and we probably never would have fixed it except for:

  1. I saw someone copying it over to the CIFS code.
  2. We've had a couple of people ask about it on nfs-discuss at OpenSolaris.

The basic issue is that you can not share to a single IP without explicitly mentioning a netmask. I go on about it in these old blog entries: [Open]Solaris and sharing subnets and single machines and Checking a host entry - some code analysis.

The fix is easier than the testing, but I'll do that in the morning after a fresh build and ask for the code review later in the day.


Originally posted on Kool Aid Served Daily
Copyright (C) 2008, Kool Aid Served Daily

Tuesday Sep 30, 2008

Build turd issues you may not see in a Flag Day or a heads up...

Sometimes when you do an incremental build, you run into some fluff that kills your build:

==== cpio archives build errors (DEBUG) ====

Failed to create generic kernel archive:	200550 blocks
cpiotranslate: kernel/misc/amd64/sysinit: no packaging info
cpiotranslate: kernel/misc/sysinit: no packaging info

And everyone is supposed to know how to handle these:

[th199096@aus-build-x86 mms]> ls -al proto/root_i386/kernel/misc/amd64/sysinit
-rwxr-xr-x   1 th199096 staff       4200 Sep 25 21:22 proto/root_i386/kernel/misc/amd64/sysinit
[th199096@aus-build-x86 mms]> rm proto/root_i386/kernel/misc/amd64/sysinit proto/root_i386/kernel/misc/sysinit
[th199096@aus-build-x86 mms]> `which nightly` -in nightly.env

Hey, what do you know, Ken Erickson did have a Flag Day for those who maintain private copies of bfu; Heads up for everyone else], but it still does not mention cleaning up the turd on your own.

After all, everyone knows how to deal with these turds.


Originally posted on Kool Aid Served Daily
Copyright (C) 2008, Kool Aid Served Daily

Monday Sep 29, 2008

Really loving that upgrade from snv85 to snv99

I love hacks which make your life easier, but I also love an evolving OS. It used to be to do ssh-agent management, I had the following in my .dtprofile (and I think dt is no longer being invoked):

###
if whence ssh-agent > /dev/null && [[ ${SSH_AGENT_PID:-0} -eq 0 ]]
then
        eval $(ssh-agent) > /dev/null
        trap "kill $SSH_AGENT_PID" EXIT
fi
(xterm -e ssh-add &)
###

I'd get a little X window and have to manually enter my pass phrases every time I rebooted.

I don't know when it was introduced, but we now have a proper keychain manager and I'm loving it.


Originally posted on Kool Aid Served Daily
Copyright (C) 2008, Kool Aid Served Daily

cdrw output looks more userfriendly

At last, a bright spot:

[root@warlock archives]> cdrw -l
Looking for CD devices...
    Node                   Connected Device                Device type
----------------------+--------------------------------+-----------------
 cdrom0               | AOPEN    COM5232/AAH PRO  1.04 | CD Reader/Writer
 cdrom1               | AOPEN    DUW1608/ARR      A04b | CD Reader/Writer

instead of ... ahh, I don't have a capture of it

Much easier to remember which is which now for me...


Originally posted on Kool Aid Served Daily
Copyright (C) 2008, Kool Aid Served Daily

One of our boxes is missing

So my w2100z is fully installed, but not fully functional. I learned some valuable lessons along the way, and I'm not yet done. Things brought back to the surface:

  • Don't forget to edit your menu.lst if your system is headless. I did it for the install media, I should do it for the system.
  • If you break the root mirror, that can leave your menu.lst pointing to the wrong side of the pool. I.e., there are I expect a copy of the boot targets for each side of the mirror. Combine these two lessons and you have a system that looks dead.
  • Just because you think the Sun Ray Server install code rocks and it has always been easy, don't forget to backup your settings.

And the big one, sometimes it is better to go to bed than futz with things just a bit longer.

I've tried both Sun Ray Software 4 Update 3 Beta for Solaris 10 5/08 X86 and Sun Ray Software 4 09/07. In both cases I've got the 26D error. I know that the firmware on the DTU is being changed between releases and the server software knows about the DTU.

I've tried the following things to get this working:

And I left it there with the last one. I'm about to restart. I think that perhaps fixing my menu.lst has caused this issue or I have to face the fact that I upgraded to too modern a build. But since I never had this problem before and I don't have my hands on the prior configurations, I'll try to get it working.

Strike part of that, I do have /etc/dt/config archived off and it shows I never did the Xserver thing:

[th199096@warlock config]> ls -la
total 26
drwxr-xr-x   2 root     other          6 Sep 25 12:41 .
drwxr-xr-x   3 root     other          3 Mar 29  2008 ..
-r--r--r--   1 root     sys         1577 Aug  1  2007 README.SUNWut
lrwxrwxrwx   1 root     root          34 Sep 29 02:58 Xconfig -> /tmp/SUNWut/config/xconfig/Xconfig
-r--r--r--   1 root     root        5868 Mar 29  2008 Xconfig.SUNWut.prototype
lrwxrwxrwx   1 root     root          35 Sep 29 02:58 Xservers -> /tmp/SUNWut/config/xconfig/Xservers

Okay, I fixed that back out and I told grub not to boot to the console. But I didn't tell eeprom(1M):

[root@warlock ~]> eeprom
ata-dma-enabled=1
atapi-cd-dma-enabled=1
ttyb-rts-dtr-off=false
ttyb-ignore-cd=true
ttya-rts-dtr-off=false
ttya-ignore-cd=true
ttyb-mode=9600,8,n,1,-
ttya-mode=9600,8,n,1,-
lba-access-ok=1
prealloc-chunk-size=0x2000
keyboard-layout=US-English
console=ttya
boot-file=bootadm: kernel command on line 64 not recognized.
boot-args=bootadm: kernel command on line 64 not recognized.
[root@warlock ~]> eeprom console=text
[root@warlock ~]>

By the way, if this is horked, so am I. :->

Okay, I'm horked. I have to come up in failsafe mode. Now how do I fix my eeprom? Luckily, is it?, I've had to do this in the past - eeprom hosed on an x86. And it has the sed command I will need because I refuse to learn how to configure my terminal! And I've saved above what the real value should be!

# pwd
/a/boot/solaris
# sed 's/text/ttya/' bootenv.rc > xxx
# diff bootenv.rc xxx
39c39
< setprop console 'text'
---
> setprop console 'ttya'
# cp xxx bootenv.rc
# reboot
Creating boot_archive for /a

So I'm not getting X on the headed headless server (i.e., I've attached a monitor). I get output there until the OS takes over.

What is in my /var/dt/Xerrors?

Fatal server error:
could not open default font 'fixed'
XIO:  fatal IO error 146 (Connection refused) on X server ":2.0"\^M
      after 0 requests (0 known processed) with 0 events remaining.\^M
failed to set default font path '/usr/openwin/lib/X11/fonts/Type1/,/usr/openwin/lib/X11/fonts/Type1/sun/,/usr/openwin/lib/X11/fonts/F3bitmaps/,/
usr/openwin/lib/X11/fonts/Speedo/,/usr/openwin/lib/X11/fonts/misc/,/usr/openwin/lib/X11/fonts/75dpi/,/usr/openwin/lib/X11/fonts/100dpi/,/usr/ope
nwin/lib/X11/fonts/TrueType'
One of the directories in the list above does not exist
or it does not contain a valid 'fonts.dir' file

Okay, lets take care of that! All of them existed and none had a valid 'fonts.dir' file. And now:

Fatal server error:
could not open default font 'fixed'
XIO:  fatal IO error 146 (Connection refused) on X server ":2.0"\^M
      after 0 requests (0 known processed) with 0 events remaining.\^M

I'm really coming to suspect X is the thing horked on this system.

Notes

It looks like something, perhaps eeprom touched my menu.lst and added a new and default setting for me:

title Diagnostic Partition
        rootnoverify (hd0,0)
        chainloader +1
#---------- ADDED BY BOOTADM - DO NOT EDIT ----------
title Solaris bootenv rc
findroot pool_rpool
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B console=ttya bootadm: kernel command on line 64 not recognized.
-B bootadm: kernel command on line 64 not recognized.
module$ /platform/i86pc/$ISADIR/boot_archive
#---------------------END BOOTADM--------------------
#BOOTADM RC SAVED DEFAULT: 0

Which yields:

krtld: Unused kernel arguments: `bootadm: kernel command on line 64 not recognized.'.
SunOS Release 5.11 Version snv_99 64-bit
Copyright 1983-2008 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
NOTICE: mount: not a UFS magic number (0x0)
Cannot mount root on /ramdisk:a fstype ufs

panic[cpu0]/thread=fffffffffbc293a0: vfs_mountroot: cannot mount root

fffffffffbc48dc0 genunix:vfs_mountroot+356 ()
fffffffffbc48df0 genunix:main+e6 ()
fffffffffbc48e00 unix:_locore_start+92 ()

skipping system dump - no dump device configured
SunOS Release 5.11 Version snv_99 64-bit
Copyright 1983-2008 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Hostname: warlock
Reading ZFS config: done.
Mounting ZFS filesystems: (8/8)

I've got the head on it, so I'm going to reinstall and see if I can at least get X working on it.


Originally posted on Kool Aid Served Daily
Copyright (C) 2008, Kool Aid Served Daily

Sunday Sep 28, 2008

First reboot after install of w2100z

Okay, so I got this configuration:

# zpool list
NAME    SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
rpool    68G  7.18G  60.8G    10%  ONLINE  -
# zpool iostat -v
                 capacity     operations    bandwidth
pool           used  avail   read  write   read  write
------------  -----  -----  -----  -----  -----  -----
rpool         7.18G  60.8G     31     14   814K   528K
  mirror      7.18G  60.8G     31     14   814K   528K
    c1t0d0s0      -      -     12      8   509K   530K
    c1t1d0s0      -      -     13      8   510K   530K
------------  -----  -----  -----  -----  -----  -----

But I don't want a mirror, I want space!

This should work, but it doesn't:

# zpool detach rpool c1t1d0s0
# zpool iostat -v
               capacity     operations    bandwidth
pool         used  avail   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
rpool       7.18G  60.8G      8      6   367K   383K
  c1t0d0s0  7.18G  60.8G      8      6   367K   383K
----------  -----  -----  -----  -----  -----  -----

# zpool add rpool c1t1d0s0
invalid vdev specification
use '-f' to override the following errors:
/dev/dsk/c1t1d0s0 overlaps with /dev/dsk/c1t1d0s2
# zpool add -f rpool c1t1d0s0
cannot add to 'rpool': root pool can not have multiple vdevs or separate logs

Ahh, I should have done some light reading, from ZFS Troubleshooting Guide:

You cannot use a RAID-Z configuration for a root pool. Only single-disk pools or pools with mirrored disks are supported.

I was thinking of reinstalling, but no, I'll go with two different pools. By the way, I understand the need for redundancy, but I'd prefer more spindles here.

# zpool create tank c1t1d0s0
invalid vdev specification
use '-f' to override the following errors:
/dev/dsk/c1t1d0s0 overlaps with /dev/dsk/c1t1d0s2
# zpool create -f tank c1t1d0s0
# zpool iostat -v
               capacity     operations    bandwidth
pool         used  avail   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
rpool       7.18G  60.8G      5      4   246K   255K
  c1t0d0s0  7.18G  60.8G      5      4   246K   255K
----------  -----  -----  -----  -----  -----  -----
tank        73.5K  68.0G      0      9  18.3K   165K
  c1t1d0s0  73.5K  68.0G      0      9  18.3K   165K
----------  -----  -----  -----  -----  -----  -----

Originally posted on Kool Aid Served Daily
Copyright (C) 2008, Kool Aid Served Daily

Time to update my w2100z

When I last configured my w2100z, it wasn't possible to have a ZFS root. And I did some funky stuff playing around with it. My current configuration (I have 2 drives, which I think should be 72G):

       0. c1t0d0 
          /pci@5,0/pci1022,7450@4/pci108e,534d@4,1/sd@0,0
Part      Tag    Flag     Cylinders        Size            Blocks
  0       root    wm     524 - 3134       20.00GB    (2611/0/0)  41945715
  1       swap    wu       1 -  523        4.01GB    (523/0/0)    8401995
  2     backup    wm       0 - 8913       68.28GB    (8914/0/0) 143203410
  3 unassigned    wm    3135 - 5745       20.00GB    (2611/0/0)  41945715
  4 unassigned    wm    5746 - 8356       20.00GB    (2611/0/0)  41945715
  5 unassigned    wm       0               0         (0/0/0)            0
  6 unassigned    wm       0               0         (0/0/0)            0
  7       home    wm    8357 - 8913        4.27GB    (557/0/0)    8948205
  8       boot    wu       0 -    0        7.84MB    (1/0/0)        16065
  9 unassigned    wm       0               0         (0/0/0)            0
       1. c1t1d0 
          /pci@5,0/pci1022,7450@4/pci108e,534d@4,1/sd@1,0
Part      Tag    Flag     Cylinders        Size            Blocks
  0      stand    wm       1 - 4466       34.21GB    (4466/0/0)  71746290
  1      stand    wm    4467 - 8932       34.21GB    (4466/0/0)  71746290
  2     backup    wu       0 - 8932       68.43GB    (8933/0/0) 143508645
  3 unassigned    wm       0               0         (0/0/0)            0
  4 unassigned    wm       0               0         (0/0/0)            0
  5 unassigned    wm       0               0         (0/0/0)            0
  6 unassigned    wm       0               0         (0/0/0)            0
  7 unassigned    wm       0               0         (0/0/0)            0
  8       boot    wu       0 -    0        7.84MB    (1/0/0)        16065
  9 unassigned    wm       0               0         (0/0/0)            0

I've shamelessly munged together output from different format commands. Anyway, the first drive has several available partitions for Live Update and grabbing in case of need. The second drive has two partitions used for ZFS.

This configuration is very flexible for doing updates. I can have several boot partitions on the root drive and I never have to worry about the data on my ZFS pool:

[root@warlock snv99]> zpool list zoo
NAME   SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
zoo     68G  51.5G  16.5G    75%  ONLINE  -
[root@warlock snv99]> zpool iostat -v
               capacity     operations    bandwidth
pool         used  avail   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zoo         51.5G  16.5G      0      1  21.9K  60.8K
  c1t1d0s0  33.6G   381M      0      0  7.31K  12.0K
  c1t1d0s1  17.9G  16.1G      0      1  14.6K  48.8K
----------  -----  -----  -----  -----  -----  -----

But I think I want to live more on the edge. I'm looking to get a more modern build on warlock:

[root@warlock snv99]> uname -a
SunOS warlock 5.11 snv_85 i86pc i386 i86pc

So, I'm going to back everything up onto an attached USB drive, and nuke the entire system.

Back in a bit

Since warlock is headless, the first task is to build an install DVD which has a modified menu.lst for grub - see Getting a Solaris bootable DVD for headless x86es.

While I'm doing that, I'm going to back up my system. I need the contents of /etc, my punchin configuration (a Sun VPN tool), my Sun Ray server configuration, and my homedirs. The rest I could probably care less about or already have saved off.

Also, I'm pretty ruthless, once I decide I don't need something, I will delete it. That gives me a better idea of how how much I still have to backup. And no, I'm not talking system stuff. Take for example here where I delete some ISO images:

[th199096@warlock isos]> df -h .
Filesystem             size   used  avail capacity  Mounted on
zoo/isos                67G    29G    16G    65%    /zoo/isos
[th199096@warlock x86]>	rm -rf snv7\* snv8\* snv90/ snv97
[th199096@warlock x86]>	df -h .
Filesystem             size   used  avail capacity  Mounted on
zoo/isos                67G    12G    33G    27%    /zoo/isos

You may not be comfortable with this approach, but once you reinstall it is gone anyway.

Cleaned out, the ISO is booting in a VirtualBox on my WinXP desktop, so I'm signing off here....


Originally posted on Kool Aid Served Daily
Copyright (C) 2008, Kool Aid Served Daily
About

tdh

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today