unixpowered.com

Last week I was presented with the following error on one of the Solaris 10 boxes:

svc.configd: smf(5) database integrity check of:

/etc/svc/repository.db

failed. The database might be damaged or a media error might have
prevented it from being verified. Additional information useful to
your service provider is in:

/etc/svc/volatile/db_errors

The system will not be able to boot until you have restored a working
database. svc.startd(1M) will provide a sulogin(1M) prompt for recovery
purposes. The command:

/lib/svc/bin/restore_repository

can be run to restore a backup version of your repository. See
http://sun.com/msg/SMF-8000-MY for more information.

Having never seen this error, I was thinking: “this is gonna be interesting…”. Thankfully the error was pretty verbose so I started to disect it section by section. Yeah, service repository got hosed, somehow, and I can potentially find some usefull info in /etc/svc/volatile/db_errors. Unfortunatelly, there was nothing of use in there.

The restore_repository script mentioned gave me little more hope. I also went and checked out the page URL. After reading the page I decided to go ahead and try to restore the service repository.

I logged in to the box in single user mode and took a look at the restore script to get an idea of what it might do. Then, I ran it. Fortunatelly, the script was pretty good at doing checks and told me that I can not proceed any further because / filesystem is mounted RO. To fix this I was asked to run:

bash-3.00# /lib/svc/method/fs-root
bash-3.00# /lib/svc/method/fs-usr

Once the filesystems were fixed up I ran the restore_repository script. I was asked which backup copy I wanted to restore and that was it. The system rebooted and came back up fine. This turned out to be a pretty good learning experience and http://www.sun.com/msg/SMF-8000-MY is very well worth reading. Continue Reading

This list focuses mostly on mirror operations. I use Solaris Volume Manager quite a bit when mirroring internal drives. There are tons of additional features and commands, if you use SVM for  things other than mirroring. In that case you might want to look at check out Solaris Volume Manager Administration Guide.

Create database replicas:
metadb -f -a -c [number_of_replicas] [device]
metadb -f -a -c 3 c0t0d0s7

Delete all database replicas from device:
metadb -d [device]
metadb -d c0t0d0s7

Display status of database replicas:
metadb -i
metadb -i

Display metadevice status:
metastat
metastat

Create simple concat/stripe metadevice:
metainit -f [concat_metadevice] 1 1 [device]
metainit -f d21 1 1 c0t0d0s1

Create a mirror with one submirror:
metainit [mirror_metadevice] -m [submirror_metadevice]
metainit d20 -m d21

Attach a submirror to one sided mirror:
metattach [mirror_metadevice] [submirror_metadevice]
metattach d20 d22

Detach a submirror from a mirror:
metadetach [mirror_metadevice] [submirror_metadevice]
metadetach d20 d22

Clear a metadevice:
metaclear [metadevice]
metaclear d22

Offline a submirror:
metaoffline [mirror_metadevice] [submirror_metadevice]
metaoffline d20 d22

Online a submirror:
metaonline [mirror_metadevice] [submirror_metadevice]
metaonline d20 d22

Enable a failed component:
metareplace -e [metadevice] [device]
metareplace -e d21 c0t0d0s1

Rename a metadevice:
metarename [old_metadevice] [new_metadevice]
metarename d20 d30

Switch metadevice names:
metarename [metadevice_1] [metadevice_2]
metarename -x d20 d30

Configure system for root metadevice:
metaroot [metadevice]
metaroot d10 Continue Reading

Cloning Solaris Container is pretty straight forward. But what if you want to have an identical container on another host? In a nutshell:

1. Make a clone of an existing container on host A
2. Detach the clone
3. Compress it and move it to host B
4. Create configuration for the moved container
5. Decompress the container on host B
6. Attach the decompressed container

I have done this on Solaris 10 8/07. Before going any further, it is important that both host A and host B are running the same release of Solaris and they are both at the same patch level. Otherwise, you will almost certainly run into a situation where the container will refuse to attach to the new host.

I have created a cloned container called mx2. First, I have detached the container:

bash-3.00# zoneadm -z mx2 detach

Then I compressed the container directory so I could move it to host B. It does not really matter which tool you use to compress the directory. Just make sure you preserve permissions, ownership or ACL’s . For me, for some reason tar had a little of an ordeal compressing the container directory:

bash-3.00# cd /export/home/zones
bash-3.00# tar cf mx2.tar mx2
tar: mx2/root/usr/jdk/instances/jdk1.5.0/jre/lib/sparc/cpu/sparcv9+vis/sparcv9/libclib_jiio.so: symbolic link too long
tar: mx2/root/usr/jdk/instances/jdk1.5.0/jre/lib/sparc/cpu/sparcv9+vis2/sparcv9/libclib_jiio.so: symbolic link too long

Once I had the directory compressed I scp-ied it to host B. Then I decompressed it in the zones directory:

bash-3.00# cd /export/home/zones
bash-3.00# tar xf mx2.tar

I have recreated the problematic symlinks mentioned above manually. If you are having trouble attaching the container check that container configurations are the same on both systems.

Before you can attach a container, you need to have container configuration in place. Without it you will not be able to attach the container.

Make sure your configuration is correct. I was attaching full root container and the system was complaining that the container being attached is missing some packages. In reality, my container configuration was for sparse root container. It turned out that when I was importing container configuration, some inherit-package-dir statements were added which has caused attach operation to fail. I had to remove those manually.

So, again, before attaching the container make sure your container configuration is good, you are inheriting correct package directories, etc. Once you have that right, you can attach the new container:

bash-3.00# zoneadm -z mx2 attach

That’s it. Depending on your needs you might want to change hostname, ip address and so on.

Some interesting linkage:

Solaris Containers replication
Continue Reading

I was trying to mount a RHEL 4 NFS share in Solaris 10. But for whatever reason I just could not seem to get it mounted. It would always come back with “Not owner” error:

bash-3.00# mount -F nfs carbon:/media/cdrecorder /mnt/carbon
nfs mount: mount: /mnt/carbon: Not owner

So, I checked and rechecked my settings with no success. Then, I remembered reading something somewhere about NFS v4 in Linux being not so great at one time. Since the Linux box was running RHEL 4 I tought this might be my problem. So, I decided to force mount using NFS v3, since Solaris 10 will try to mount the Linux share using NFS v4 first.

bash-3.00# mount -F nfs -o vers=3 carbon:/media/cdrecorder /mnt/carbon
bash-3.00# cd /mnt/carbon
bash-3.00#

That worked well. Since this was one time mounting job, I did not bother any further. If I would be doing this on regular basis I would probably edit /etc/default/nfs on the Solaris box and force maximum NFS client version to be v3. Continue Reading

If you ever used ZFS on a LUN and then tried to reuse that LUN for UFS you might have noticed a “weird” disk label on it. This is known as EFI label.

Here is how it looks in format command:

partition> p
Current partition table (original):
Total disk sectors available: 73383902 + 16384 (reserved sectors)

Part Tag Flag First Sector Size Last Sector
0 usr wm 34 34.99GB 73383902
1 unassigned wm 0 0 0
2 unassigned wm 0 0 0
3 unassigned wm 0 0 0
4 unassigned wm 0 0 0
5 unassigned wm 0 0 0
6 unassigned wm 0 0 0
8 reserved wm 73383903 8.00MB 73400286

If you use straight format command there is no way to get rid of EFI label. Instead, you have to use -e option with format to get to expert features:

bash-3.00# format -e

With -e options when you label the LUN you will be asked about the type of label you want to put on the disk:

format> label
[0] SMI Label
[1] EFI Label
Specify Label type[1]: 0
Warning: This disk has an EFI label. Changing to SMI label will erase all
current partitions.
Continue? y
Auto configuration via format.dat[no]? yes

I suppose you could alternatively use dd command and blank out the whole disk. Continue Reading