vxinstall causing vxconfigd & egettxt error on reboot
NYCeyes
I installed Veritas Volume Manager on a clean, well patched Solaris O/S.
I ran vxinstall and encapsulated the O/S disk c1t0d0, and brought
in, as a new disk, what will be its mirror, c2t0d0. The the system
rebooted (actually it reboots twice)...
I keep getting the following error on the second boot attempt
======================================================================
VxVM starting in boot mode...
vxvm:vxconfigd: ERROR: enable failed: Internal configuration daemon
error
No such file or directory; aborting
/etc/rcS.d/S25vxvm-sysboot: egettxt: not found
syncing file systems... done
======================================================================
Has any one seen this?
(Note: forget about suggesting this as a resolution,
dmp -> ../dsk
rdmp -> ../rdsk
I already know about that, and its not the problem).
Veritas backline is stumped; im trying to get it into engineering.
TIA
Andy Patel
disk to another disk, VxVM does not make that disk bootable...Best thing is
to run /usr/sbin/vxrootmir manually to make sure mirror gets boot image...
Doug Hughes
> Hi:
>
> I installed Veritas Volume Manager on a clean, well patched Solaris O/S.
> I ran vxinstall and encapsulated the O/S disk c1t0d0, and brought
> in, as a new disk, what will be its mirror, c2t0d0. The the system
> rebooted (actually it reboots twice)...
>
> I keep getting the following error on the second boot attempt
> ======================================================================
> VxVM starting in boot mode...
> vxvm:vxconfigd: ERROR: enable failed: Internal configuration daemon
> error
> No such file or directory; aborting
> /etc/rcS.d/S25vxvm-sysboot: egettxt: not found
>
> syncing file systems... done
> ======================================================================
>
> Has any one seen this?
>
I'm kind of surprised that they don't recognize this. It has been around
for a very long time. By any chance to you have any of the Sun Alternate
Pathing stuff installed (AP). There is a conflict with AP and DMP (Veritas'
dynamic multipathing). Sometimes during install the dmp stuff doesn't get
fully installed.
So, you have two choices, you can either disable DMP entirely, or add
the appropriate forceload statement to /etc/system by hand. If you don't
plan on using DMP, I suggest the former.
Procedure:
1.remove /kernel/drv/vxdmp
2.relink DMP and RDMP directories
cd /dev/vx
mv dmp dmp.old
ln -s /dev/dsk dmp
mv rdmp rdmp.old
ln -s /dev/rdsk rdmp
3.reboot
----
OR
----
edit /etc/system
find line containing: vxvm_START
and right after it add:
foreload drv/vxdmp
reboot
Sun S&R (symptoms and resolutions) 17757
____________________________________________________________________________
Doug Hughes Engineering Network Services
System/Net Admin Auburn University
do...@eng.auburn.edu
NYCeyes
thats not the problem either. I have that & VxVM working
perfectly on tons of other machines. On those machines
the latter is used (i.e. the forceload in /etc/system). The
link (r)dmp -> ../(r)dsk is not used on those systems and
they work fine.
This is something else (something very delicate).
I cant believe that Veritas cannot look into the source
and come up with all of the things that can cause this.
Thanks
nyc
fish...@my-deja.com
Hmmm... I would tend to agree with Doug. (Doug knows his stuff) We had
an odd vxconfigd problem yesterday. It was unlike anything I had ever
seen before. Soon as I disabled DMP, problem disappeared. If you're
not going to be using DMP why not disable it anyways? Just a thought.
John
Actual Sun Bug:
4110503 as_setprot heuristic gave my process a wedgie
Sent via Deja.com http://www.deja.com/
Before you buy.
NYCeyes
If it works though, the question that begs to be answered is...
why did this not cause the same problem on other
machines (I also have to determine wether EMC
PowerPath would be affected by this change).
As I mentioned before, DMP is not disabled on the
working machines.
I'll post the results.
Thanks Doug.
Doug Hughes wrote:
>
> Have you tried disabling DMP alltogether?
> That egettxt thing is usually a sign that something
> is wrong in DMP. Sort of their catch-all generic DMP
> error.
>
> --
NYCeyes
Sun 5 years ago. Never seen anything like it (so pesky).
Exactly like you said:
> It happens during the install phase, and only some of the time.
Yet it is so easy to reproduce...
Build a machine; install VM on it; run vxinstall and encap
root and bring in the mirror disk as a new disk, and reboot.
(I actually prefer to use a small slice and avoid
encapsulating root; but Im doing it this way for a reason;
another story for another time :-))
Now lets say that works. Dont bother running vxrootmir or
vxassist to complete the mirroring process. Reverse everything
and take volume manager out of the picture. So....
rm -rf /var/vxvm/*
rm /etc/vx/reconfig.d/state.d/*
touch /etc/vx/reconfig.d/state.d/install-db,
mv /etc/vfstab.prevm /etc/vfstab,
restore the old /etc/system,
restore the old O/S disk partitioning,
rm /dev/vx/(r)dsk/*
rm /dev/vx/(r)dmp/*
rm /etc/vx/elm/*
rm /etc/vx/reconfig.d/c[0-9][0-9]*
rm -rf /etc/vx/reconfig.d/disk.d/*
reboot
It should come up without volume manager..
Now do vxinstall exactly as you did the first time...
The error will occur. Its actually very easy to reproduce
I'll let you know how it goes...
Milton
Doug Hughes wrote:
>
> >I hear you Doug. I could do this and will try it.
> >If it works though, the question that begs to be answered is...
> >why did this not cause the same problem on other
> >machines (I also have to determine wether EMC
> >PowerPath would be affected by this change).
> >
> >As I mentioned before, DMP is not disabled on the
> >working machines.
> >
>
> It's a weird thing, I've got to admit. It happens during
> the install phase, and only some of the time. I've seen
> this sort of thing before from other posters. Usually
> disabling DMP will get rid of it. There are also hacks
> you can make to the startup scripts to get rid of it.
NYCeyes
A well intentioned dba, in an attempt to keep the machine
running efficiently, has a modunload script running in
cron (he doesnt understand that Solaris cleans up
after itself). Guess what one of the things was being
mod-unloaded...
Yep.... drv/vxdmp, which has to be loaded when vxinstall
is run.
So it didn't matter that the correct entries were in
/etc/system.
This explains why the other machines did not have the
problem... the cron job wasn't on them.
Time to change the root passwd.
Thanks for the help all,
Milton