I am getting this error during boot of a Solaris 9 64-bit system. 

....
jnic146x1: Target9: Lun28 supported.
jnic146x1: Target9: Lun29 supported.
jnic146x1: Target9: Lun30 supported.
jnic146x1: Target9: Lun31 supported.
WARNING: Error writing ufs log state
WARNING: ufs log for / changed state to Error
WARNING: Please umount(1M) / and run fsck(1M)
Starting VxVM restore daemon...
VxVM starting in boot mode...
....

I am remotely managing this machine so I can't boot from CD at the
moment to fsck the root filesystem. Is this something critical or
something I can fix w/o booting from a CD?

Thx,
rhugga

Keg wrote:
> I am getting this error during boot of a Solaris 9 64-bit system. 
> 
> ...
> jnic146x1: Target9: Lun28 supported.
> jnic146x1: Target9: Lun29 supported.
> jnic146x1: Target9: Lun30 supported.
> jnic146x1: Target9: Lun31 supported.
> WARNING: Error writing ufs log state
> WARNING: ufs log for / changed state to Error
> WARNING: Please umount(1M) / and run fsck(1M)
> Starting VxVM restore daemon...
> VxVM starting in boot mode...
> ...
> 
> I am remotely managing this machine so I can't boot from CD at the
> moment to fsck the root filesystem. Is this something critical or
> something I can fix w/o booting from a CD?
> 
> Thx,
> rhugga

I have had this once, and was left with a read-only root filesystem. My, 
and I suspect, your only solution is to boot single-user from CD :-( 
Depending on your filesystem structure, the system might continue to run 
to some extent - only you can determine that.

But if the system panics, and you have a bad log area for root, I 
suspect that you *will* be paying a visit ;-)

Apols for being no help. Hopefully other people in this NG will have 
better ideas.


Beardy.

Beardy <beardy@beardy.net> wrote in message news:<41534cd1$0$42247$ed2e19e4@ptn-nntp-reader04.plus.net>...
> Keg wrote:
> > I am getting this error during boot of a Solaris 9 64-bit system. 
> > 
> > ...
> > jnic146x1: Target9: Lun28 supported.
> > jnic146x1: Target9: Lun29 supported.
> > jnic146x1: Target9: Lun30 supported.
> > jnic146x1: Target9: Lun31 supported.
> > WARNING: Error writing ufs log state
> > WARNING: ufs log for / changed state to Error
> > WARNING: Please umount(1M) / and run fsck(1M)
> > Starting VxVM restore daemon...
> > VxVM starting in boot mode...
> > ...
> > 
> > I am remotely managing this machine so I can't boot from CD at the
> > moment to fsck the root filesystem. Is this something critical or
> > something I can fix w/o booting from a CD?
> > 
> > Thx,
> > rhugga
> 
> I have had this once, and was left with a read-only root filesystem. My, 
> and I suspect, your only solution is to boot single-user from CD :-( 
> Depending on your filesystem structure, the system might continue to run 
> to some extent - only you can determine that.
> 
> But if the system panics, and you have a bad log area for root, I 
> suspect that you *will* be paying a visit ;-)
> 
> Apols for being no help. Hopefully other people in this NG will have 
> better ideas.
> 
> 
> Beardy.


Actually I ended up booting from CD an fsck'ing the filesystem several
times and I still get that error on boot. When I performed the fsck's,
it found no problems as all. I ran fsck 3 times.

Any ideas anoyone,
thx,
rhugga

Keg wrote:
> Beardy <beardy@beardy.net> wrote in message news:<41534cd1$0$42247$ed2e19e4@ptn-nntp-reader04.plus.net>...
> 
>>Keg wrote:
>>
>>>I am getting this error during boot of a Solaris 9 64-bit system. 
>>>
>>>...
>>>jnic146x1: Target9: Lun28 supported.
>>>jnic146x1: Target9: Lun29 supported.
>>>jnic146x1: Target9: Lun30 supported.
>>>jnic146x1: Target9: Lun31 supported.
>>>WARNING: Error writing ufs log state
>>>WARNING: ufs log for / changed state to Error
>>>WARNING: Please umount(1M) / and run fsck(1M)
>>>Starting VxVM restore daemon...
>>>VxVM starting in boot mode...
>>>...
>>>
>>>I am remotely managing this machine so I can't boot from CD at the
>>>moment to fsck the root filesystem. Is this something critical or
>>>something I can fix w/o booting from a CD?
>>>
>>>Thx,
>>>rhugga
>>
>>I have had this once, and was left with a read-only root filesystem. My, 
>>and I suspect, your only solution is to boot single-user from CD :-( 
>>Depending on your filesystem structure, the system might continue to run 
>>to some extent - only you can determine that.
>>
>>But if the system panics, and you have a bad log area for root, I 
>>suspect that you *will* be paying a visit ;-)
>>
>>Apols for being no help. Hopefully other people in this NG will have 
>>better ideas.
>>
>>
>>Beardy.
> 
> 
> 
> Actually I ended up booting from CD an fsck'ing the filesystem several
> times and I still get that error on boot. When I performed the fsck's,
> it found no problems as all. I ran fsck 3 times.
> 
> Any ideas anoyone,
> thx,
> rhugga

Do you have a Veritas encapsulated root filesystem? What device are you 
fsck'ing? I suspect that Veritas is getting in the way somehow, and 
although I am not a Veritas expert at all, there are many who contribute 
here.

Keg,

this problem has been introduced lately by some Veritas patch ... The 
recommended workaround is to abandon the logging feature until this 
problem has been resolved (i.e., remount your root w/ nologging and make 
the appropriate changes in /etc/vfstab).

HIH,
- Thomas

Keg wrote:
> I am getting this error during boot of a Solaris 9 64-bit system. 
> 
> ...
> jnic146x1: Target9: Lun28 supported.
> jnic146x1: Target9: Lun29 supported.
> jnic146x1: Target9: Lun30 supported.
> jnic146x1: Target9: Lun31 supported.
> WARNING: Error writing ufs log state
> WARNING: ufs log for / changed state to Error
> WARNING: Please umount(1M) / and run fsck(1M)
> Starting VxVM restore daemon...
> VxVM starting in boot mode...
> ...
> 
> I am remotely managing this machine so I can't boot from CD at the
> moment to fsck the root filesystem. Is this something critical or
> something I can fix w/o booting from a CD?
> 
> Thx,
> rhugga


-- 
--
Thomas Hildebrandt	

Thomas Hildebrandt - Sun Germany - ES - SSE <thomas.hildebrandt@sun.com> wrote in message news:<417651B3.6020509@sun.com>...
> Keg,
> 
> this problem has been introduced lately by some Veritas patch ... The 
> recommended workaround is to abandon the logging feature until this 
> problem has been resolved (i.e., remount your root w/ nologging and make 
> the appropriate changes in /etc/vfstab).
> 
> HIH,
> - Thomas
> 
> Keg wrote:
> > I am getting this error during boot of a Solaris 9 64-bit system. 
> > 
> > ...
> > jnic146x1: Target9: Lun28 supported.
> > jnic146x1: Target9: Lun29 supported.
> > jnic146x1: Target9: Lun30 supported.
> > jnic146x1: Target9: Lun31 supported.
> > WARNING: Error writing ufs log state
> > WARNING: ufs log for / changed state to Error
> > WARNING: Please umount(1M) / and run fsck(1M)
> > Starting VxVM restore daemon...
> > VxVM starting in boot mode...
> > ...
> > 
> > I am remotely managing this machine so I can't boot from CD at the
> > moment to fsck the root filesystem. Is this something critical or
> > something I can fix w/o booting from a CD?
> > 
> > Thx,
> > rhugga
> 
> 
> --

Is the log state really bad or is it just a false positive? Man, IMHO
this is something Veritas should have _immediately_ fixed. No biggie,
we are migrating away from Veritas anyways, since we use ufs with
logging almost exclusively now and all our RAID is done via hardware
on our SAN. With ASM and Oracle RAC we no longer have the need.

Thanks for the info.
rhugga

Keg wrote:
> 
> Thomas Hildebrandt - Sun Germany - ES - SSE <thomas.hildebrandt@sun.com> wrote in message news:<417651B3.6020509@sun.com>...
> > Keg,
> >
> > this problem has been introduced lately by some Veritas patch ... The
> > recommended workaround is to abandon the logging feature until this
> > problem has been resolved (i.e., remount your root w/ nologging and make
> > the appropriate changes in /etc/vfstab).
> >
> > HIH,
> > - Thomas
> >
> > Keg wrote:
> > > I am getting this error during boot of a Solaris 9 64-bit system.
> > >
> > > ...
> > > jnic146x1: Target9: Lun28 supported.
> > > jnic146x1: Target9: Lun29 supported.
> > > jnic146x1: Target9: Lun30 supported.
> > > jnic146x1: Target9: Lun31 supported.
> > > WARNING: Error writing ufs log state
> > > WARNING: ufs log for / changed state to Error
> > > WARNING: Please umount(1M) / and run fsck(1M)
> > > Starting VxVM restore daemon...
> > > VxVM starting in boot mode...
> > > ...
> > > I am remotely managing this machine so I can't boot from CD at the
> > > moment to fsck the root filesystem. Is this something critical or
> > > something I can fix w/o booting from a CD?
> > >
> > > Thx,
> > > rhugga
> >
> > --
> 
> Is the log state really bad or is it just a false positive? Man, IMHO
> this is something Veritas should have _immediately_ fixed. No biggie,
> we are migrating away from Veritas anyways, since we use ufs with
> logging almost exclusively now and all our RAID is done via hardware
> on our SAN. With ASM and Oracle RAC we no longer have the need.
> 
> Thanks for the info.
> rhugga

The problem is not so much with the log being bad, technically what
happens is that we scan the log for existing committed deltas and build
the incore logmap from the ondisk logmap.
once this has been finished we need to update the ondisk logmap tail
to indicate the end of the last commit record found so we can kick
of the roll thread and know where now to continue work.
this is done upon inital mount with logging, for root
as well as for all other filesystems if not mounted read-only.

The problem is that vxvm is not ready to serve the write request we
issue that early in boot, because its volume is not yet setup for
being written to. this will happen not earlier then the vxvm startup script has
finished
which is way too late for root when mounted with logging.

the ordering of the messages gives a hint on this as well.

this problem has been exposed when we enabled logging as the default for root
which went back into solaris 9 update 7.

---
frankB