Lofland bLOG

There is bug in Veritas volume manager 3.5 and greater with an encapsulated rootdisk and ufs logging enabled. We enable ufs logging on systems running Solaris 8, and on Solaris 9 it is enabled by default. The error message you see is below as well as a resolution to this problem. Anyone with systems running Solaris 8 or greater needs to verify that logging is either disabled or that the necessary patch for Veritas volume manager is applied. See the sunsolve article for patch numbers and fixes.

ERROR MESSAGE ON THE CONSOLE
00:19:24: WARNING: Error writing ufs log state
00:19:32: WARNING: ufs log for / changed state to Error
00:19:32: WARNING: Please umount(1M) / and run fsck(1M)
00:19:33: WARNING: Error writing master during ufs log roll
00:19:33: WARNING: ufs log for / changed state to Error
00:19:33: WARNING: Please umount(1M) / and run fsck(1M)
00:19:34: Cannot mount root on /pseudo/vxio@0:0 fstype ufs

http://sunsolve.sun.com/search/document.do?assetkey=1-26-57636-1

Example commands to check your server:
grep -i /rootvol /etc/vfstab
pkginfo -l VRTSvxvm | grep VERSION
patchadd -p | grep 112392

If you do not want to apply the patch, you can add nologging to the end of the rootvol and var mount lines in /etc/vfstab like this: (one line with and one without)
/dev/vx/dsk/rootvol /dev/vx/rdsk/rootvol / ufs 1 no nologging
/dev/vx/dsk/var /dev/vx/rdsk/var /var ufs 1 no -

You must reboot for the above to take affect, either way. It may take two reboots for it to actually “take” when going from “nologging” to “-” The first boot creates the metaspace for the log, and the second actually starts logging.

IF you DO get a machine that will not boot because of this, then you can try booting from the oscopy disk and fixing things like this:

In the OBP:

ok setenv auto-boot? false
ok reset-all
(it won’t try to boot since auto-boot is false)

ok boot oscopy -s

vxdisk list

ksh -o vi

mount /dev/dsk/c1t0d0s0 /mnt
cd /mnt
ls -la
cd
umount /mnt
fsck /dev/dsk/c1t0d0s0 /mnt
#IF var also has trouble:

mount /dev/dsk/c1t0d0s5 /mnt/var
cd /mnt/var
umount /mnt/var
mount -o nologging n/dev/dsk/c1t0d0s5 /mnt/var
umount /mnt/var
umount /mnt
You have to keep doing it until all errors are gone. You could try this:

for i in 0 5 6 7
do
fsck -o f -y /dev/rdsk/c1t0d0s${i}
done

SAME
fsck -o f -y /dev/rdsk/c1t0d0s${i}

OVER AND OVER until ALL errors are gone
See if it will work:

mount -o nologging /dev/dsk/c1t0d0s0 /mnt
You must also change the logging status:
cd /mnt/etc
vi vfstab

in vfstab
add nologging to the end of the rootvol and var mount lines

The default route is carried in a file called /etc/defaultrouter which is read at boot time. In order to avoid having to reboot, you can also add a default route manually and delete the old one.

Here are the steps I took to change the default route on a host recently:

#first do a traceroute for later comparison

traceroute knownhost.anothersub.net

#This command will show you the current default route
netstat -rn

#just for the record, take a look at what the route is now, if any
cat /etc/defaultrouter

#This sets the new default route for the next reboot
echo “10.0.0.1″ > /etc/defaultrouter

#Again, just checking to be sure it worked!
cat /etc/defaultrouter

#Now we add the new default route to the current routing table
#If you are going to reboot, you do not need to do this step
route add default 10.0.0.1

#and we take out the old one
#If you are going to reboot, you do not need to do this step
route delete default 192.168.0.1

#Now we check that the new route is in and the old one is gone
netstat -rn

#and we do one last traceroute and compare it to the first one to see that our work had some affect
traceroute knownhost.anothersub.net

I usually log all of this, just for the record.

NOTE that you can do this while connected remotely via SSH. It will not drop your connection, although it doesn’t hurt to have a console connection open and logged in case you change it to a non-working gateway and need to quickly putit back!