 Questions and Answers
Amy Rich
Q We have a V880 running Solaris 8 to which we just added two JNI Fibre Channel cards and enabled mpxio in /kernel/drv/scsi_vhci.conf by setting mpxio-disable="no". When I reboot the system, it panics, saying that it cannot mount the root filesystem (under SDS control):
Rebooting with command: boot
Boot device: new File and args:
SunOS Release 5.8 Version Generic_117350-43 64-bit
Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved.
Cannot mount root on /pseudo/md@0:0,0,blk fstype ufs
panic[cpu7]/thread=10408000: vfs_mountroot: cannot mount root
0000000010407970 genunix:vfs_mountroot+70 (10436c00, 0, 0, 104724c2, 80, 14)
%l0-3: 0000000010436c00 000000001043a3a0 000000d1fe000000 \
0000000010436e88
%l4-7: 0000000000000000 00000000104139e0 00000000000c19ed \
00000000000019ed
0000000010407a20 genunix:main+8c (104101f0, 2000, 10407ec0, 10408030, \
fff2, 1005436c)
%l0-3: 0000000000000001 0000000000000001 0000000000000015 \
0000000000000f6a
%l4-7: 0000000010429a48 00000000104782f0 00000000000da328 \
0000000000000328
skipping system dump - no dump device configured
rebooting...
Resetting ...
If I turn off mpxio, then the system boots just fine, but we obviously can't use the attached SAN properly.
A The issue is that you have mpxio enabled for all channels, including the internal FC-AL bus. This problem is covered in Sun Doc ID 4625972 at:
http://sunsolve.sun.com/search/document.do?assetkey=1-1-4625972-1
To correct this, disable mpxio for the internal FC-AL path. To determine the correct device path, take a look at the device for the boot disk by doing a metastat and then taking a look at the actual device path for the raw disk. Here's some example output for a V480:
# df /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md/dsk/d250 22199593 1388421 20589177 7% /
# metastat d250
d250: Mirror
Submirror 0: d251
State: Okay
Submirror 1: d252
State: Okay
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 45089856 blocks (21 GB)
d251: Submirror of d250
State: Okay
Size: 45089856 blocks (21 GB)
Stripe 0:
Device Start Block Dbase State Reloc Hot Spare
c2t0d0s5 0 No Okay Yes
d252: Submirror of d250
State: Okay
Size: 45089856 blocks (21 GB)
Stripe 0:
Device Start Block Dbase State Reloc Hot Spare
c0t8d0s5 0 No Okay Yes
Device Relocation Information:
Device Reloc Device ID
c2t0d0 Yes id1,ssd@w2000000c50e3404f
c0t8d0 Yes id1,sd@SFUJITSU_MAT3073N_SUN72G_000507B014MA____AAN0P52014MA
# ls -al /dev/rdsk/c2t0d0s5
lrwxrwxrwx 1 root other 74 Jul 19 14:36 /dev/rdsk/c2t0d0s5 -> \
../../devices/pci@9,600000/SUNW,qlc@2/fp@0,0/ \
ssd@w2100000c50e3404f,0:f,raw
The parent address is located after the string /devices, and the unit address is located after the string /SUNW,qlc@. Once you have this information, you need to add another line to /kernel/drv/scsi_vhci.conf to disable mpxio for that device. The 480R in the example above has the parent /pci@9,600000 and the unit 2, so the line you'd add to /kernel/drv/scsi_vhci.conf would contain:
name="qlc" parent="/pci@9,600000" unit-address="2" mpxio-disable="yes";
For the V880, the parent is /pci@8,600000 and the unit is 2, so you'd instead add the following line:
name="qlc" parent="/pci@8,600000" unit-address="2" mpxio-disable="yes";
Once you've modified /kernel/drv/scsi_vhci.conf, reboot the machine with the command reboot -- -r to perform a reconfiguration boot.
Q I'm running BIND 9.2.4 with multiple master and slave files. I've attempted to add a new slave to the configuration file, but after I restart named, the changes disappear. Here's a snippet from the offending configuration file after I've made the changes, but before I do the restart:
options {
directory "/var/lib/named";
dump-file "/var/log/named_dump.db";
statistics-file "/var/log/named.stats";
forwarders { 10.0.0.253; };
listen-on port 53 { 127.0.0.1; 10.0.0.254; };
allow-query { localhost; 10.0.0.0/24; };
allow-transfer { none; }
notify no;
};
zone "localhost" {
type master;
file "localhost.zone";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "127.0.0.zone";
};
zone "." in {
type hint;
file "root.hint";
};
zone "0.0.10.IN-ADDR.ARPA" {
type master;
file "master/10.0.0.zone";
allow-transfer { 10.0.0.253; };
};
zone "my.domain" {
type master;
file "master/my.domain.zone";
allow-transfer { 10.0.0.253; };
};
zone "my.second.domain" {
type slave;
file "slave/my.second.domain.zone";
masters { 10.0.0.253; };
};
Then after the restart, my changes disappear:
options {
directory "/var/lib/named";
dump-file "/var/log/named_dump.db";
statistics-file "/var/log/named.stats";
forwarders { 10.0.0.253; };
listen-on port 53 { 127.0.0.1; 10.0.0.254; };
allow-query { localhost; 10.0.0.0/24; };
allow-transfer { none; }
notify no;
};
zone "localhost" {
type master;
file "localhost.zone";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "127.0.0.zone";
};
zone "." in {
type hint;
file "root.hint";
};
zone "0.0.10.IN-ADDR.ARPA" {
type master;
file "master/10.0.0.zone";
allow-transfer { 10.0.0.253; };
};
zone "my.domain" {
type master;
file "master/my.domain.zone";
allow-transfer { 10.0.0.253; };
};
I'm stumped as to why the slave I added disappears when others remain. It's only the changes that I make to the config file that get wiped out. Am I restarting named incorrectly?
A You don't specify your operating system, but some have startup scripts that copy named.conf from a master configuration directory to a running directory before starting. This is often done in chrooted settings, for example. Look for another named.conf located in /etc or other configuration directories on your machine and also take a look at your BIND/named init script to see whether it's doing an explicit copy from somewhere before starting the daemon. If you find a master copy, make the edits to it instead so that your changes are propagated intact to the configuration file in the runtime directory.
Q I've been evaluating Solaris 10 Zones, but I can't seem to get any of my init scripts to run when I create a new non-global zone. I realize that I should be porting these to use the XML files instead of Bourne shell startup scripts, but, really, I just want to experiment at this stage! I set up the initial configuration as follows:
# zonecfg -z test
test: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:test> create
zonecfg:test> set autoboot=true
zonecfg:test> set zonepath=/zones/test
zonecfg:test> add net
zonecfg:test:net> set address=192.168.1.5
zonecfg:test:net> set physical=bge0
zonecfg:test:net> end
zonecfg:test> add attr
zonecfg:test:attr> set name=comment
zonecfg:test:attr> set type=string
zonecfg:test:attr> set value="test zone"
zonecfg:test:attr> end
zonecfg:test> verify
zonecfg:test> commit
zonecfg:test> exit
Then I did the install:
# zoneadm -z test install
Preparing to install zone <test>.
Creating list of files to copy from the global zone.
Copying <3196> files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize <1613> packages on the zone.
Initialized <1613> packages on zone.
Zone <test> is initialized.
The file </zones/test/root/var/sadm/system/logs/install_log> contains
a log of the zone installation.
If I check the status, it says it installed correctly:
# zoneadm list -v
ID NAME STATUS PATH
0 global running /
- test installed /zones/test
Everything looks good, so I boot the zone:
# zoneadm -z test boot
But when I log into the zone and run svcs to check on the state of things, many services are offline or uninitialized and the system claims not even to have made it to the default service level:
# svcs
STATE STIME FMRI
online 9:23:56 svc:/system/svc/restarter:default
online 9:23:58 svc:/network/loopback:default
online 9:23:58 svc:/system/filesystem/root:default
online 9:23:58 svc:/network/physical:default
online 9:24:01 svc:/milestone/network:default
online 9:24:01 svc:/system/filesystem/usr:default
online 9:24:02 svc:/milestone/name-services:default
online 9:24:02 svc:/system/identity:node
online 9:24:02 svc:/system/device/local:default
online 9:24:02 svc:/milestone/devices:default
online 9:24:03 svc:/system/filesystem/minimal:default
online 9:24:03 svc:/system/rmtmpfiles:default
online 9:24:03 svc:/system/name-service-cache:default
online 9:24:03 svc:/system/cryptosvc:default
online 9:24:04 svc:/application/print/cleanup:default
online 9:24:04 svc:/system/identity:domain
online 9:24:04 svc:/network/initial:default
online 9:24:04 svc:/network/service:default
online 9:24:05 svc:/system/manifest-import:default
online 9:24:05 svc:/milestone/single-user:default
online 9:24:06 svc:/system/filesystem/local:default
online 9:24:06 svc:/system/cron:default
online 9:24:06 svc:/application/font/fc-cache:default
online 9:24:09 svc:/system/coreadm:default
online 9:24:09 svc:/system/keymap:default
online 4:15:23 svc:/system/filesystem/autofs:default
offline 9:23:58 svc:/network/rpc/bind:default
offline 9:23:58 svc:/system/sysidtool:system
offline 9:23:58 svc:/milestone/sysconfig:default
offline 9:23:58 svc:/system/utmp:default
offline 9:23:58 svc:/system/console-login:default
offline 9:23:59 svc:/network/nfs/status:default
offline 9:23:59 svc:/network/nfs/nlockmgr:default
offline 9:24:00 svc:/network/inetd:default
offline 9:24:00 svc:/system/system-log:default
offline 9:24:00 svc:/network/nfs/client:default
offline 9:24:00 svc:/network/smtp:sendmail
offline 9:24:01 svc:/milestone/multi-user:default
offline 9:24:01 svc:/milestone/multi-user-server:default
offline 9:24:01 svc:/network/ssh:default
offline 9:24:03 svc:/application/print/ipp-listener:default
offline 9:24:09 svc:/system/sac:default
uninitialized 9:24:00 svc:/network/rpc/gss:default
uninitialized 9:24:02 svc:/application/font/stfsloader:default
uninitialized 9:24:03 svc:/application/print/rfc1179:default
uninitialized 9:24:03 svc:/application/x11/xfs:default
uninitialized 9:24:04 svc:/network/finger:default
uninitialized 9:24:05 svc:/network/ftp:default
uninitialized 9:24:05 svc:/network/login:rlogin
uninitialized 9:24:05 svc:/network/nfs/rquota:default
uninitialized 9:24:05 svc:/network/rpc/rstat:default
uninitialized 9:24:06 svc:/network/rpc/rusers:default
uninitialized 9:24:06 svc:/network/rpc/smserver:default
uninitialized 9:24:06 svc:/network/security/ktkt_warn:default
uninitialized 9:24:06 svc:/network/shell:default
uninitialized 9:24:08 svc:/network/telnet:default
uninitialized 9:24:09 svc:/network/rpc-100235_1/rpc_ticotsord:default
uninitialized 9:24:09 svc:/network/rpc-100083_1/rpc_tcp:default
uninitialized 9:24:09 svc:/network/rpc-100068_2-5/rpc_udp:default
Even after I run svcadm enable -t svc:/milestone/multi-user:default to try to enable multi-user mode, it still claims to be offline. I think I've followed all of the instructions correctly, but it's clear that my zone is pretty crippled. Can you point out where I went wrong?
A You missed one vital step when creating your new zone. When you boot it for the first time, it has no internal naming configuration. You need to connect to the zone's console (using zlogin -C test instead of plain zlogin test) and follow the prompts to finish the install. The zone uses sysidcfg to perform the configuration, so the screens look just like those encountered after a sys-unconfig or during an initial install of Solaris 10 from CD or DVD.
The hostname of the zone defaults to the zone name, but the chosen name should resolve to one of the zone's IPv4 addresses based on whatever the zone uses as a naming service (DNS, LDAP, files, NIS, NIS+, etc). You can pre-configure most of the necessary information by creating a sysidcfg file in the zone's /etc directory before booting it for the first time. See the man pages on sysidtool and sysidcfg for more information on the syntax of the sysidcfg file.
Once you finish the system identification steps, the zone should enter multi-user mode and all of the services should come online.
Amy Rich has more than a decade of Unix systems administration experience in various types of environments. Her current roles include that of Senior Systems Administrator for the University Systems Group at Tufts University, Unix systems administration consultant, author, and charter member of LOPSA. She can be reached at: qna@oceanwave.com.
|