unixpowered.com

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

This is an oldie, but a goodie. For some reason I was asked about it 3 times in a span of a week. Suppose your system was not shut down cleanly and it refuses to come up. During bootup fsck refuses to run, complaining about corrupt superblock. So, what do you do? First, get the alternate superblock locations and then run fsck using one of the alternate superblocks.

To get alternate superblock locations do:

newfs -Nv /dev/rdsk/c0t0d0s3

This will not actually format the slice. It will only print what it would do, if it was actually formating the slice. Basically, it is newfs dry run. It will also give you locations of alternate superblocks on the slice. I guess it should be mentioned that if you used non-default values while formating the slice originally, and you did not make a note of those values, this might not give you valid superblock numbers.

After you have your alternate superblock numbers you can use them to help out fsck (in this case superblock I am using is in block 8192):

fsck -y -F ufs -o b=8192 /dev/rdsk/c0t0d0s3

It might not hurt to run the above with -n option instead of -y to make sure it produces the results you are looking for.

Hopefully, the filesystem is not hosed so badly that it can not be repaired. This was more of an issue when Solaris did not have ufs logging. Nevertheless, it does not hurt to know this for one of those emergencies. Continue Reading

There are two way to create a new container: create one from scratch, which takes a little while or you can clone an existing container. Cloning is quite faster than the actual creation so it is handy to have a “gold” master container which is used for cloning. Another reason for having a “gold” master container is the fact that the container from which you are making a clone has to be halted during cloning. I did this on Solaris 10 8/07 release. Cloning consists of the following:

1. Export configuration of an existing container or create a new configuration from scratch
2. Customize the exported configuration for the new container
3. Import the new container configuration
4. Clone the “gold” master container
5. Configure the new container

First you need configuration for the new container. You can either make one from scratch or export one from existing container and customize it.
The following command will export the configuration from “gold” master container and save it into /tmp/mx1.cfg file:

bash-3.00# zonecfg -z gold export -f /tmp/mx1.cfg

Now you can edit the configuration. Word of caution, importing seems to be a little flaky. For example, if an existing container has bootargs variable set, you will need to put quotes around them in the config file. So, if my bootargs are set to -m verbose, the string will have to be enclosed in “”. Otherwise the new container configuration will not be imported properly.

Once you have the configuration ready you can import it:
bash-3.00# zonecfg -z mx1 -f /tmp/mx1.cfg

Now you can perform actual clone operation:

bash-3.00# zoneadm -z mx1 clone -m copy gold
Cloning zonepath /export/home/zones/gold...

This should not take very long. Once the operation is done you can see that the new container has been installed:

bash-3.00# zoneadm list -cv
ID NAME             STATUS     PATH                           BRAND    IP
0 global           running    /                              native   shared
- mx1              installed  /export/home/zones/mx1         native   shared
- gold             installed  /export/home/zones/gold        native   shared

At this point you can boot the new container. You will be taken through initial configuration of the container. This initial container configuration can be pain if you are rolling out a lot of containers. You can simplify the process by creating a sysidcfg file and putting it into /etc directory of the container before performing the first boot.

In my case I would put the following sysidcfg into /export/home/zones/mx1/root/etc:

system_locale=C
terminal=vt100
network_interface=primary {
hostname=mx1
}
security_policy=NONE
name_service=DNS {
domain_name=example.com
name_server=192.168.1.1
search=example.com
}
nfs4_domain=dynamic
timezone=US/Central
root_password=n2GSHfh

The nice thing about cloning is the fact that it’s fairly quick. So if you hose up a container, you can simply run

bash-3.00# zoneadm -z mx1 uninstall
Are you sure you want to uninstall zone mx1 (y/[n])? y

followed by

bash-3.00# zonecfg -z mx1 delete
Are you sure you want to delete zone mx1 (y/[n])? y

and start all over again. Continue Reading

I needed to build a print server and I had to use HP JetDirect. I also wanted to use the Containers technology for the job. Here are few things I found out in the process. This was done on Solaris 10 08/07 and JetDirect version E.10.34.

I did a little bit of searching, and all I found were conflicting reports: it should work, it does not work, it works, but not really…

First of all the container that will host JetDirect has to be full-root, as JetDirect install will put some files into /usr/spool. I suppose it would be possible to work around it and use sparse-root, even though it might be a little messy.

The problem I ran into was while creating print queues using hppi tool. During the process mknod command is called to create printer device file in /dev directory of the container. You can not use mknod inside a container and creation of the device file will fail. Sure enough, greping for mknod in JetDirect’s admin directory yields the following:

bash-3.00$ grep mknod *
addptrtoq:         mknod $DFILE c 13 2

Closer look at addptrtoq reveals the following:

HPNPMODEL=$HPNP/sh/hpnp.model
#DFILE=$HPNP/etc/$SPOOLNAME
DFILE=/dev/$SPOOLNAME
if [ ! -c $DFILE ]
then
mknod $DFILE c 13 2
fi
chmod 666 $DFILE

So to get around the problem, first you manually have to create the special file in the global zone inside /dev directory of the print server container. Then you can proceed with installing the printqueue using hppi tool.

bash-3.00# cd /export/home/zones/prtsvr/dev/
bash-3.00# mknod laser c 13 2
bash-3.00# chmod 666 laser

Now you should be able to add a printer queue without any problems. So JetDirect works just fine inside Solaris 10 Container. For me anyways… Continue Reading