SEO

Hello,

I have a server which we use for NFS, SMB, and CVS. It is an E250
connected to an external A1000 RAID box. The setup has been VERY
reliable for the last 7 or so years. I have to say that this has been
en exceptionally stable platform.

The internal disks are mirrored for failover and the external RAID box
houses the cvs depot, nfs and smb shares.... I use soft partitions
for the filesystems (Solaris Volume Manager). I simply grow a soft
partition and the particular filesystem when I need to.

It seems to me that volume manager is referencing c2 while the RAID
array is now, for some reason, c3. Perhaps the battery change did
this? I didn't. If so it still doesn't explain why it manifested
AFTER the OS patches and not merely AFTER the controller battery
change or drive change...... That one has me scratching my head.


Background:

2 weeks ago I replaced the controller battery in the RAID array, as
well as an internal failed disk in the RAID array device. It uses one
disk as a hot spare, and when I replaced the faulty disk with a new
one it did what it does and all was/is well with that. (or so I
thought?)

This weekend I patched the machine with the latest 9_Recommended in
order to get it up to date and to get the DST patch. The patch bundle
overwrote my inetd.conf, but I think I fixed that okay and now my CVS
server and SWAT once again start up on boot.

The problem is that for every boot, the boot process is paused for
what the system says is a missing disk device. This is odd b/c it
wasn't happening prior to the 9_Recommended patch and once the machine
is up everything looks fine and all of the expected filesystems are
present and mounted. Nothing that it is searching for is on the
vfstab.

The /var/adm/messages file complains about this:

Mar 11 17:40:53 localhostname fsck: [ID 309067 daemon.error]
localhostname: /dev/rdsk/c2t10d0s6: No such device or address

????

.....and in the device.tab this is referenced but again I can't
remember why it would be there and all of the expected partitions are
there.

disk9:/dev/rdsk/c2t10d0s2:/dev/dsk/c2t10d0s2::desc="Disk Drive"
type="disk" part="true" removable="false" capacity="212381696"
dpartlist="dpart900,dpart906"

An observation which may or may not be pertinent, (I think it is) is
that the RAID array controller calls itself disk, c3t10d0s2, which
except for one number is very close to the c2t10d0s2 that the system
is complaining about. Perhaps it changed it's name when I replaced
the controller battery? What discourages me from that notion is that
if that were so then this boot behavior should have manifested 2 weeks
ago, not just after this weekend's patch install. ??

These are my disks in format:

AVAILABLE DISK SELECTIONS:
0. c0t0d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107>
/pci@1f,4000/scsi@3/sd@0,0
1. c0t8d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107>
/pci@1f,4000/scsi@3/sd@8,0
2. c0t9d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107>
/pci@1f,4000/scsi@3/sd@9,0
3. c0t10d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107>
/pci@1f,4000/scsi@3/sd@a,0
4. c0t11d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107>
/pci@1f,4000/scsi@3/sd@b,0
5. c0t12d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107>
/pci@1f,4000/scsi@3/sd@c,0

6. c3t10d0 <Symbios-StorEDGEA1000-0301 cyl 65533 alt 2 hd 64
sec 169>
/pseudo/rdnexus@3/rdriver@a,0

As you can see, s6 is where I keep my important data:

Current partition table (original):
Total disk cylinders available: 65533 + 2 (reserved cylinders)


Part Tag Flag Cylinders Size Blocks
0 root wm 0 0
(0/0/0) 0
1 unassigned wm 0 0
(0/0/0) 0
2 backup wu 0 - 65532 337.98GB (65533/0/0)
708804928
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 usr wm 0 - 65531 337.98GB (65532/0/0)
708794112
7 unassigned wm 65532 - 65532 5.28MB (1/0/0)
10816

========

metastat shows this:

# metastat |grep c2t10d0

Device: c2t10d0s6
c2t10d0s6 10816 No Yes
Device: c2t10d0s6
c2t10d0s6 10816 No Yes
c2t10d0 Yes id1,iver@w600a0b80000a5ed90000000f3d94158d


grepping c3 shows nothing........

=================

So, could I ask for advice on how to eliminate this because every time
the machine reboots fsck pauses the bot process for operator
assistance, either enter the root passwd for maintenance or CRTL-D to
continue. So, if no one is present and the machine were rebooted, or
rebooted remotely, it wouldn't come up without operator assistance at
the console and this machine is not hooked to anything like a
networked console server device.

I figure that I have to change/update the volume manager to use c3
instead of c2, but I wanted to run that by some pros and perhaps its
not that easy. Right now all of my filesystems are there and I didn't
want to change such a thing willy nilly without checking.

I set all of this stuff up several years back and am a bit rusty, so
hence my question to the groups. Better to consult first than to do
it without realizing the ramifications and make a fatal error. ;-)




Thank You for taking the time,

Tom

In comp.unix.solaris Tom <the.worlok@gmail.com> wrote:
> I have a server which we use for NFS, SMB, and CVS. It is an E250
> connected to an external A1000 RAID box. The setup has been VERY
> reliable for the last 7 or so years. I have to say that this has been
> en exceptionally stable platform.

> The internal disks are mirrored for failover and the external RAID box
> houses the cvs depot, nfs and smb shares.... I use soft partitions
> for the filesystems (Solaris Volume Manager). I simply grow a soft
> partition and the particular filesystem when I need to.

> It seems to me that volume manager is referencing c2 while the RAID
> array is now, for some reason, c3. Perhaps the battery change did
> this? I didn't. If so it still doesn't explain why it manifested
> AFTER the OS patches and not merely AFTER the controller battery
> change or drive change...... That one has me scratching my head.

I've seen that on A1000s in the past. I've even seen a difference
between the controller reported by 'df' and the controller reported by
'format'. That can be a bit worrying....

> 2 weeks ago I replaced the controller battery in the RAID array, as
> well as an internal failed disk in the RAID array device. It uses one
> disk as a hot spare, and when I replaced the faulty disk with a new
> one it did what it does and all was/is well with that. (or so I
> thought?)

Should have been

> This weekend I patched the machine with the latest 9_Recommended in
> order to get it up to date and to get the DST patch. The patch bundle
> overwrote my inetd.conf, but I think I fixed that okay and now my CVS
> server and SWAT once again start up on boot.

> The problem is that for every boot, the boot process is paused for
> what the system says is a missing disk device. This is odd b/c it
> wasn't happening prior to the 9_Recommended patch and once the machine
> is up everything looks fine and all of the expected filesystems are
> present and mounted. Nothing that it is searching for is on the
> vfstab.

> The /var/adm/messages file complains about this:

> Mar 11 17:40:53 localhostname fsck: [ID 309067 daemon.error]
> localhostname: /dev/rdsk/c2t10d0s6: No such device or address

> ????

Can you post the contents of /etc/vfstab?

> ....and in the device.tab this is referenced but again I can't
> remember why it would be there and all of the expected partitions are
> there.

> disk9:/dev/rdsk/c2t10d0s2:/dev/dsk/c2t10d0s2::desc="Disk Drive"
> type="disk" part="true" removable="false" capacity="212381696"
> dpartlist="dpart900,dpart906"

> An observation which may or may not be pertinent, (I think it is) is
> that the RAID array controller calls itself disk, c3t10d0s2, which
> except for one number is very close to the c2t10d0s2 that the system
> is complaining about. Perhaps it changed it's name when I replaced
> the controller battery? What discourages me from that notion is that
> if that were so then this boot behavior should have manifested 2 weeks
> ago, not just after this weekend's patch install. ??

I doubt the battery had anything to do with it.


> These are my disks in format:

> AVAILABLE DISK SELECTIONS:
> 0. c0t0d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107>
> /pci@1f,4000/scsi@3/sd@0,0
> 1. c0t8d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107>
> /pci@1f,4000/scsi@3/sd@8,0
> 2. c0t9d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107>
> /pci@1f,4000/scsi@3/sd@9,0
> 3. c0t10d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107>
> /pci@1f,4000/scsi@3/sd@a,0
> 4. c0t11d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107>
> /pci@1f,4000/scsi@3/sd@b,0
> 5. c0t12d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107>
> /pci@1f,4000/scsi@3/sd@c,0

> 6. c3t10d0 <Symbios-StorEDGEA1000-0301 cyl 65533 alt 2 hd 64
> sec 169>
> /pseudo/rdnexus@3/rdriver@a,0

> As you can see, s6 is where I keep my important data:

> Current partition table (original):
> Total disk cylinders available: 65533 + 2 (reserved cylinders)


> Part Tag Flag Cylinders Size Blocks
> 0 root wm 0 0
> (0/0/0) 0
> 1 unassigned wm 0 0
> (0/0/0) 0
> 2 backup wu 0 - 65532 337.98GB (65533/0/0)
> 708804928
> 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 usr wm 0 - 65531 337.98GB (65532/0/0)
> 708794112
> 7 unassigned wm 65532 - 65532 5.28MB (1/0/0)
> 10816

> ========

> metastat shows this:

> # metastat |grep c2t10d0

> Device: c2t10d0s6
> c2t10d0s6 10816 No Yes
> Device: c2t10d0s6
> c2t10d0s6 10816 No Yes
> c2t10d0 Yes id1,iver@w600a0b80000a5ed90000000f3d94158d


> grepping c3 shows nothing........

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

On Mar 12, 12:12 pm, Darren Dunham <ddun...@redwood.taos.com> wrote:


>
> Can you post the contents of /etc/vfstab?
>

#device device mount FS fsck
mount mount
#to mount to fsck point type pass at
boot options
#
#/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr ufs 1
yes -
fd - /dev/fd fd - no -
/proc - /proc proc - no -
/dev/md/dsk/d5 - - swap - no -
/dev/md/dsk/d2 /dev/md/rdsk/d2 / ufs 1 no -
/dev/md/dsk/d8 /dev/md/rdsk/d8 /usr ufs 1 no -
/dev/md/dsk/d11 /dev/md/rdsk/d11 /var ufs 1
no -
#/dev/md/dsk/d14 /dev/md/rdsk/d14 /home ufs
2 yes -
swap - /tmp tmpfs - yes -
/dev/md/dsk/d28 /dev/md/rdsk/d28 /export/qa/qa-aix2
ufs 1 yes logging
#/dev/md/dsk/d29 /dev/md/rdsk/d29 /mgrbuild
ufs 1 yes -
/dev/md/dsk/d26 /dev/md/rdsk/d26 /tools ufs 1
yes -
/dev/md/dsk/d30 /dev/md/rdsk/d30 /cvsdepot ufs 1 yes logging
/dev/md/dsk/d31 /dev/md/rdsk/d31 /datasafe ufs 1 yes logging
#/dev/md/dsk/d27 /dev/md/rdsk/d27 /localcvs ufs 1 yes -


=============

metastat:

---snip-----

d31: Soft Partition
Device: c2t10d0s6
State: Okay
Size: 327155712 blocks (156 GB)
Device Start Block Dbase Reloc
c2t10d0s6 10816 No Yes

Extent Start Block Block count
0 16788034 264241152
1 339749444 62914560

d30: Soft Partition
Device: c2t10d0s6
State: Okay
Size: 75497472 blocks (36 GB)
Device Start Block Dbase Reloc
c2t10d0s6 10816 No Yes

Extent Start Block Block count
0 10817 16777216
1 281029187 58720256

Device Relocation Information:
Device Reloc Device ID
c0t10d0 Yes id1,sd@SSEAGATE_ST336704LSUN36G_3CD1LDW100002132DR 60
c0t9d0 Yes id1,sd@SSEAGATE_ST336704LSUN36G_3CD1LG0D00002132DP NZ
c0t8d0 Yes id1,sd@SSEAGATE_ST336704LSUN36G_3CD1LBTN00007129JX Z3
c0t0d0 Yes id1,sd@SSEAGATE_ST336704LSUN36G_3CD1K51900002133FL PV
c2t10d0 Yes id1,iver@w600a0b80000a5ed90000000f3d94158d


====================================

So yes, d31 and d30 are mounted in vfstab, and metastat reports them
as belonging to c2.... when in fact they are c3..... ...and it's a
mystery to me that everything still mounts okay and is up and
available???


So, should I just issue a meta command to volume manager to update
those virtual disks to point to c3.... instead of c2...??



Thanks,

Tom

In comp.sys.sun.hardware Tom <the.worlok@gmail.com> wrote:
> On Mar 12, 12:12 pm, Darren Dunham <ddun...@redwood.taos.com> wrote:
>> Can you post the contents of /etc/vfstab?

> #device device mount FS fsck
> mount mount
> #to mount to fsck point type pass at
> boot options
> #
> #/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr ufs 1
> yes -
> fd - /dev/fd fd - no -
> /proc - /proc proc - no -
> /dev/md/dsk/d5 - - swap - no -
> /dev/md/dsk/d2 /dev/md/rdsk/d2 / ufs 1 no -
> /dev/md/dsk/d8 /dev/md/rdsk/d8 /usr ufs 1 no -
> /dev/md/dsk/d11 /dev/md/rdsk/d11 /var ufs 1
> no -
> #/dev/md/dsk/d14 /dev/md/rdsk/d14 /home ufs
> 2 yes -
> swap - /tmp tmpfs - yes -
> /dev/md/dsk/d28 /dev/md/rdsk/d28 /export/qa/qa-aix2
> ufs 1 yes logging
> #/dev/md/dsk/d29 /dev/md/rdsk/d29 /mgrbuild
> ufs 1 yes -
> /dev/md/dsk/d26 /dev/md/rdsk/d26 /tools ufs 1
> yes -
> /dev/md/dsk/d30 /dev/md/rdsk/d30 /cvsdepot ufs 1 yes logging
> /dev/md/dsk/d31 /dev/md/rdsk/d31 /datasafe ufs 1 yes logging
> #/dev/md/dsk/d27 /dev/md/rdsk/d27 /localcvs ufs 1 yes -

Hmm...

I'm actually more interested in where that 'fsck' failure is coming
from.

If you do a 'fsck -m' (should be harmless), I'd expect a quick message
about all those devices being mounted. Is that /dev/rdsk device listed
in that output?

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

bash-2.05# fsck -m
** /dev/md/dsk/d2
ufs fsck: sanity check:/dev/md/rdsk/d2 already mounted read/write
** /dev/md/dsk/d8
ufs fsck: sanity check:/dev/md/rdsk/d8 already mounted read/write
** /dev/md/dsk/d11
ufs fsck: sanity check: /dev/md/rdsk/d11 already mounted
** /dev/md/dsk/d28
ufs fsck: sanity check: /dev/md/rdsk/d28 already mounted
** /dev/md/dsk/d26
ufs fsck: sanity check: /dev/md/rdsk/d26 already mounted
** /dev/md/dsk/d30
ufs fsck: sanity check: /dev/md/rdsk/d30 already mounted
** /dev/md/dsk/d31
ufs fsck: sanity check: /dev/md/rdsk/d31 already mounted





On Mar 12, 4:59 pm, Darren Dunham <ddun...@redwood.taos.com> wrote:


> Hmm...
>
> I'm actually more interested in where that 'fsck' failure is coming
> from.
>
> If you do a 'fsck -m' (should be harmless), I'd expect a quick message
> about all those devices being mounted. Is that /dev/rdsk device listed
> in that output?
>
> --
> Darren Dunham ddun...@taos.com
> Senior Technical Consultant TAOS http://www.taos.com/
> Got some Dr Pepper? San Francisco, CA bay area
> < This line left intentionally blank to confuse you. >

In comp.unix.solaris Tom <the.worlok@gmail.com> wrote:
> bash-2.05# fsck -m
> ** /dev/md/dsk/d2
> ufs fsck: sanity check:/dev/md/rdsk/d2 already mounted read/write
> ** /dev/md/dsk/d8
> ufs fsck: sanity check:/dev/md/rdsk/d8 already mounted read/write
> ** /dev/md/dsk/d11
> ufs fsck: sanity check: /dev/md/rdsk/d11 already mounted
> ** /dev/md/dsk/d28
> ufs fsck: sanity check: /dev/md/rdsk/d28 already mounted
> ** /dev/md/dsk/d26
> ufs fsck: sanity check: /dev/md/rdsk/d26 already mounted
> ** /dev/md/dsk/d30
> ufs fsck: sanity check: /dev/md/rdsk/d30 already mounted
> ** /dev/md/dsk/d31
> ufs fsck: sanity check: /dev/md/rdsk/d31 already mounted

Okay, so it doesn't *appear* to be coming forom 'mountall'.

WSolaris 9, you say? What I might do is edit /etc/rc2.d/S01MOUNTFSYS
and put an "echo" statements around the /sbin/mountall -l line.

echo "About to mountall"
cd /; /sbin/mountall -l
echo "Mountall completes"

Now you can at least see if the odd fsck message is coming from there or
from elsewhere (and if not there, is it before or after).

(I suggested that you run 'fsck -m', but running '/sbin/mountall -l'
wouldn't be a bad idea either. As long as it gives the same
information (only md devices), then that's good.)

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >