VxVM : Can't open /dev/vx/rdsk/bootdg/rootvol
M.H
When the server started, it drops on the maintenance shell because it
can't mount the /dev/vx/rdsk/bootdg/rootvol.
Trying to do a "fsck -F ufs ..." did not help.
Any hints please !
The output of some vxvm commands (on the maintenace shell ):
bash-2.03# mount /dev/vx/rdsk/bootdg/rootvol /mnt
mount: /dev/vx/rdsk/bootdg/rootvol not a block device
bash-2.03# fsck -F ufs /dev/vx/rdsk/bootdg/rootvol
Can't open /dev/vx/rdsk/bootdg/rootvol
bash-2.03# vxdg list
NAME STATE ID
rootdg enabled 1021303648.6.lerenan
bash-2.03# vxdiskadm
VxVM vxdiskadm ERROR V-5-2-3540 Cannot create lock file
/var/spool/locks/.DISKAD
D.LOCK
================
bash-2.03# vxprint -Ath
Disk group: rootdg
DG NAME NCONFIG NLOG MINORS GROUP-ID
ST NAME STATE DM_CNT SPARE_CNT APPVOL_CNT
DM NAME DEVICE TYPE PRIVLEN PUBLEN STATE
RV NAME RLINK_CNT KSTATE STATE PRIMARY DATAVOLS SRL
RL NAME RVG KSTATE STATE REM_HOST REM_DG REM_RLNK
CO NAME CACHEVOL KSTATE STATE
VT NAME NVOLUME KSTATE STATE
V NAME RVG/VSET/CO KSTATE STATE LENGTH READPOL
PREFPLEX UTYPE
PL NAME VOLUME KSTATE STATE LENGTH LAYOUT
NCOL/WID MODE
SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE
MODE
SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM
MODE
SC NAME PLEX CACHE DISKOFFS LENGTH [COL/]OFF DEVICE
MODE
DC NAME PARENTVOL LOGVOL
SP NAME SNAPVOL DCO
dg rootdg default default 63000 1021303648.6.lerenan
dm rootdg01 c0t1d0s2 auto 9423 35358848 -
dm rootdg02 c0t0d0s2 auto 9423 35358848 -
v rootdg023vol - DISABLED ACTIVE 103664 ROUND -
gen
pl rootdg023vol-01 rootdg023vol DISABLED ACTIVE 103664 CONCAT -
RW
sd rootdg02-03 rootdg023vol-01 rootdg02 35250472 103664 0 c0t0d0
ENA
pl rootdg023vol-02 rootdg023vol DISABLED ACTIVE 103664 CONCAT -
RW
sd rootdg01-03 rootdg023vol-02 rootdg01 35222200 103664 0 c0t1d0
ENA
v rootvol - ENABLED ACTIVE 33158344 ROUND -
root
pl rootvol-01 rootvol ENABLED ACTIVE 33158344 CONCAT -
RW
sd rootdg02-02 rootvol-01 rootdg02 2092128 33158344 0 c0t0d0
ENA
pl rootvol-02 rootvol ENABLED ACTIVE 33158344 CONCAT -
RW
sd rootdg01-02 rootvol-02 rootdg01 2063856 33158344 0 c0t1d0
ENA
v swapvol - ENABLED ACTIVE 2063856 ROUND -
swap
pl swapvol-01 swapvol ENABLED ACTIVE 2063856 CONCAT -
RW
sd rootdg02-01 swapvol-01 rootdg02 0 2063856 0 c0t0d0
ENA
pl swapvol-02 swapvol ENABLED ACTIVE 2063856 CONCAT -
RW
sd rootdg01-01 swapvol-02 rootdg01 0 2063856 0 c0t1d0
ENA
========
BR
haed
neo4897
you should try /usr/lib/fs/vxfs/fsck /dev/??? or fsck -F vxfs
/dev/**********
VJ
Darren Dunham
> The output of some vxvm commands (on the maintenace shell ):
> bash-2.03# mount /dev/vx/rdsk/bootdg/rootvol /mnt
> mount: /dev/vx/rdsk/bootdg/rootvol not a block device
Don't mount the 'rdsk' device, mount the 'dsk' device. That's the 'not
a block device' error.
> bash-2.03# fsck -F ufs /dev/vx/rdsk/bootdg/rootvol
> Can't open /dev/vx/rdsk/bootdg/rootvol
Why do both of these commands have "bootdg" in them when everything in
your output is in the "rootdg" diskgroup? Is there a typo in your
/etc/vfstab?
> bash-2.03# vxdg list
> NAME STATE ID
> rootdg enabled 1021303648.6.lerenan
...as verified right there.
--
Darren Dunham ddu...@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. >
Darren Dunham
> you should try /usr/lib/fs/vxfs/fsck /dev/??? or fsck -F vxfs
> /dev/**********
No. VxFS can never be used as a boot filesystem. He's using a UFS
filesystem.
Colin B.
> Hi,
>
> When the server started, it drops on the maintenance shell because it
> can't mount the /dev/vx/rdsk/bootdg/rootvol.
It's not bootdg, it's rootdg. Note that the Veritas commands are all giving
you information on volumes in rootdg, and your Sun error messages are
complaining about bootdg. I suspect you have this mythical bootdg in
/etc/vfstab as well.
Colin
Groups Poster
> M.H <hae...@excite.com> wrote:
> > Hi,
> >
> > When the server started, it drops on the maintenance shell because
it
> > can't mount the /dev/vx/rdsk/bootdg/rootvol.
>
> It's not bootdg, it's rootdg.
No it is not. With Vol manager 4.0 the bootdisk in in bootdg by
default. If you manually set it to rootdg it creates a link.
ls -l /dev/vx/dsk/bootdg/
lrwxrwxrwx 1 root root 6 May 13 06:57
/dev/vx/dsk/bootdg/ -> rootdg
It is setup to fsck/mount bootdg in the vfstab as well.
Groups Poster
> Hi,
>
> When the server started, it drops on the maintenance shell because
it
> can't mount the /dev/vx/rdsk/bootdg/rootvol.
Can you please cut and paste what you have for rootvol in the vfstab.
Is it maybe trying to mount the raw device?
> bash-2.03# mount /dev/vx/rdsk/bootdg/rootvol /mnt
> mount: /dev/vx/rdsk/bootdg/rootvol not a block device
Like Darren said you should mount the dsk and not rdsk.
> bash-2.03# vxdiskadm
> VxVM vxdiskadm ERROR V-5-2-3540 Cannot create lock file
> /var/spool/locks/.DISKAD
> D.LOCK
Probably because /var isnt mounted.
>
> ================
> bash-2.03# vxprint -Ath
> Disk group: rootdg
The vxprint looks ok. Can you post an output of vxdisk list too?
>
> BR
> haed
Colin B.
> Colin B. wrote:
>> M.H <hae...@excite.com> wrote:
>> > Hi,
>> >
>> > When the server started, it drops on the maintenance shell because
> it
>> > can't mount the /dev/vx/rdsk/bootdg/rootvol.
>>
>> It's not bootdg, it's rootdg.
>
> No it is not. With Vol manager 4.0 the bootdisk in in bootdg by
> default. If you manually set it to rootdg it creates a link.
Be that as it may, the OP clearly has a rootdg, NOT a bootdg. Consider:
> bash-2.03# vxprint -Ath
> Disk group: rootdg
> ...
Colin
Groups Poster
> Be that as it may, the OP clearly has a rootdg, NOT a bootdg.
Consider:
>
> > bash-2.03# vxprint -Ath
> > Disk group: rootdg
> > ...
Your actual disk group name may be rootdg (mine are just to be
consistent with the older VxVM) but 4.0 still uses bootdg in the
vfstab/startup scripts.
eg:
# vxdctl list
Volboot file
version: 3/1
seqno: 0.3
cluster protocol version: 50
hostid: mymachine
defaultdg: rootdg
bootdg: rootdg
# vxdg list
NAME STATE ID
rootdg enabled 1112965225.18.mymachine
T3dg enabled 1089819053.1231.mymachine
# grep rootvol /etc/vfstab
#NOTE: volume rootvol (/) encapsulated partition c1t0d0s0
/dev/vx/dsk/bootdg/rootvol /dev/vx/rdsk/bootdg/rootvol / ufs 1 no
logging
>
> Colin
M.H
1. My /etc/vfstab is correct :
/dev/vx/dsk/bootdg/rootvol /dev/vx/rdsk/bootdg/rootvol /
ufs 1 no -
2. I'm using VxVM 4.0 so having bootdg in /etc/vfstab is normal.
3. Just to clarify something about my broblem:
This is a test server with two disks ( boot(c0t0d0s0 &
bootmirror(c0t1d0s0) disks). I want to test the "VERITAS[TM] Volume
Manager 3.x/4.x: Installing Kernel patches" below (when i want to
install a solaris kernel patch, i want to put the bootmirror disk
OFFLINE anf if the patching goes wrong I can boot from the bootmirror
disk as explained in the document).
- 1st problem: When I offline the bootmirror(c0t1d0s0) disk , after
I booting from cdrom, the /dev/dsk/c0t1d0s0 is not clean, I should fsck
and correct some problems.
-2nd problem: When I reboot the system from the bootmirror disk and
before "Reattaching the plexes rootvol-01, swapvol-01, to the relevant
volume and resync." (see below) , the system drops on the maintenance
shell because it can't mount /dev/vx/dsk/bootdg/rootvol as I said on the
my first mail.
Thanks for the help.
======= Begin of the document=======
Document Audience: SPECTRUM
Document ID: 79356
Title: VERITAS[TM] Volume Manager 3.x/4.x: Installing Kernel patches.
Update Date: Tue Jan 04 00:00:00 MST 2005
Products: VERITAS Volume Manager 3.5 Software, VERITAS Volume Manager
4.0 Software
Technical Areas: Administration
Last Updated By: Fiona Turnbull
Keyword(s):VxVM installing kernel patches
Description:
If a problem occurs during patching, a customer may wish to recover from
the mirrored rootdisk. Since all plexes will be in a clean state, the
procedure differs from recovering after disk failure.
Document Body:
When a customer installs Kernel patches in single-user mode, vxvol will
automatically resynchronize the data from the rootdisk to the rootmirror
as all plexes are in a clean state after a reboot.
If there has been a problem during the patching process and the customer
needs to restore from the rootmirror, they need to ensure that this
resync does not occur.
In order to achieve this, each plex on the rootmirror needs to be
off-lined. It is then possible to boot from its underlying partitions
of the root mirror and change the state of the rootdisk to detached.
Then, booting from the mirror, vxvol will mirror the data from the
rootmirror to the rootdisk.
Below is the recommended procedure when splitting a VxVM mirror for
patching.
The plexes are defined as follows:
rootvol-01
swapvol-01
var-01
usr-01
The rootmirror has the following plexes:
rootvol-02 swapvol-02 var-02 usr-02
1. Split the mirror
Offline the mirrors for the system volumes via the command line:
# vxmend off rootvol-02
# vxmend off swapvol-02
# vxmend off var-02
# vxmend off usr-02
2. Patch the software
Bring the system to the correct run-level to perform the software patching.
3. If successful, re-enable the mirrors and resync them:
# vxmend on rootvol-02
# vxmend on swapvol-02
# vxmend on var-02
# vxmend on usr-02
# vxrecover -s
4. If unsuccesful, use the procedure below.
*
Boot the system
OBP> boot cdrom -sw
*
After mounting the root partition of the rootmirror disk, backup
and edit the /etc/vfstab file. Replace the /dev/vx entries with
underlying slice entries for all filesystems that reside on the system disk.
*
Backup and edit the /etc/system file, removing the following two
entries:
rootdev:/pseudo/vxio@0:0
set vxio:vol_rootdev_is_volume=1
*
Touch the /etc/vx/reconfig.d/state.d/install-db file to prevent
VxVM from starting on the next boot from this disk.
*
Shutdown and explicitly boot from the mirror disk.
*
Start-up VxVM processes manually.
# rm /etc/vx/reconfig.d/state.d/install-db
# vxiod set 10
# vxconfigd -d
# vxdctl init <hostname>
# vxdctl enable
*
Change the states of the volumes rootvol, swapvol and var so that
rootvol-01, swapvol-01, var-01 and usr-01 plexes are detached, and
rootvol-02, swapvol-02, var-02 and usr-02 plexes are now the only clean
plex in each of the volumes.
# vxplex -f det rootvol-01
# vxmend on rootvol-02
# vxmend fix clean rootvol-02
*
Restore the saved /etc/vfstab and /etc/system files.
*
Reboot the system, booting explicitly from the mirror disk again.
*
Reattach the plexes rootvol-01, swapvol-01, var-01 and usr-01 to
the relevant volume and resync.
# vxplex att rootvol-01 rootvol-02
# vxplex att swapvol-01 swapvol-02
# vxplex att var-01 var-02
# vxplex att usr-02 usr-02
===END of the Document===========
BR
haed.
Sivakanth Mundru
If you are booted off of bootdisk disassociate the plexes corresponding
to bootmirror and vice versa.
Mount the slice 0 of the removed disk on /mnt and edit the
/mnt/etc/vfstab
to point the rootvol and swapvol to raw slices.
Comment the rootdev entries in /mnt/etc/system file.
This way even if your patches fail and if you are at ok prompt you can
just do a boot vx-bootmirror
Once you are up on the raw slices you can encapsulate the disk and
mirror the patched disk to get back to where the bootdisk was before
patch install to have a mirrored bootdisk until next patch schedule.
HTH,
S
Groups Poster
> 1. My /etc/vfstab is correct :
>
> /dev/vx/dsk/bootdg/rootvol /dev/vx/rdsk/bootdg/rootvol /
> ufs 1 no -
>
OK
> - 1st problem: When I offline the bootmirror(c0t1d0s0) disk ,
after
> I booting from cdrom, the /dev/dsk/c0t1d0s0 is not clean, I should
fsck
> and correct some problems.
That is quite possible and normal (as long as it doesnt find a zillion
errors a nd trash the filesystem)
> -2nd problem: When I reboot the system from the bootmirror disk
and
> before "Reattaching the plexes rootvol-01, swapvol-01, to the
relevant
> volume and resync." (see below) , the system drops on the maintenance
> shell because it can't mount /dev/vx/dsk/bootdg/rootvol as I said on
the
> my first mail.
In the document it asks you to edit the vfstab and system file and boot
off the underlying slices on the rootmirror. So there shouldnt be any
VX vols in the vfstab at this stage. After you vxmend the rootmirror as
described in the note change the system and vfsatb back and reboot. You
probably skipped the step about editing the files when booted off cd
and touching the install-db
See below:
Darren Dunham
> 3. Just to clarify something about my broblem:
> This is a test server with two disks ( boot(c0t0d0s0 &
> bootmirror(c0t1d0s0) disks). I want to test the "VERITAS[TM] Volume
> Manager 3.x/4.x: Installing Kernel patches" below (when i want to
> install a solaris kernel patch, i want to put the bootmirror disk
> OFFLINE anf if the patching goes wrong I can boot from the bootmirror
> disk as explained in the document).
Heh.
What I do, is pull the bootmirror. No vx commands, no changing
/etc/vfstab, nothing...
If there's a problem, I know the mirror disk has a valid, *bootable*
configuration. If I were to stop the mirror via commands, I'd have to
do a lot more work to get that to happen (clean up /etc/system,
/etc/vfstab on the disk, no vxvm running...)
Now if the patches work, great. Stick the disk back in, return it to
the diskgroup and let it resynchronize.
Want to back the patches out? Pull rootdisk and reintroduce
rootmirror. Boot from rootmirror, verify everything is good and return
the rootdisk to the configuration and resynchronize.
I had an E10000 without cdrom and without bootable network (OS couldn't
boot over a 'ge' device at the time). I had to go back and forth
between some disks and this worked *very* well.
Sivakanth Mundru
Nothing better than yanking out a disk to get Veritas Suppressed on a
mirrored bootdisk.
S
Darren Dunham
> Nothing better than yanking out a disk to get Veritas Suppressed on a
> mirrored bootdisk.
What do you mean by 'suppressed' here?
Sivakanth Mundru
Never mind.. I used the wrong word. I was thinking of another scenario
here.
S