I just tried sys-suspend on a Blade 100 with either Solaris 9 9/05
or Solaris 10 3/05 installed. With both OS versions, the resume boot
fails with:

cprboot: can't open /.CPR
please reboot
Program terminated

I know that there were problems in the past (Solaris 7/8?) with
resuming after sys-suspend when / is a logging filesystem, but
I thought those had been fixed, esp. as logging is now default
for all filesystems.

Is this still a general problem (bugid 4491494 from Apr/2005 seems
to suggest this), or is it a local problem ?

mp.
--
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna

Martin Paul schrieb:
> I just tried sys-suspend on a Blade 100 with either Solaris 9 9/05
> or Solaris 10 3/05 installed. With both OS versions, the resume boot
> fails with:
>
> cprboot: can't open /.CPR
> please reboot
> Program terminated
>
> I know that there were problems in the past (Solaris 7/8?) with
> resuming after sys-suspend when / is a logging filesystem, but
> I thought those had been fixed, esp. as logging is now default
> for all filesystems.
>
> Is this still a general problem (bugid 4491494 from Apr/2005 seems
> to suggest this), or is it a local problem ?
>
> mp.

I had the same problem on a Blade 1000 and a different one with
a crash that is under investigation on a Blade 2500. Concerning the
"can't open /.CPR" error I asked if this is a known problem and
received a negative answert. But I did not ask any further as
I don't need suspend/resume on this machine.

Tom

Thomas Maier-Komor <maierkom@lpr.e-technik.no-spam.tu-muenchen.de> wrote:
> I had the same problem on a Blade 1000 and a different one with
> a crash that is under investigation on a Blade 2500. Concerning the
> "can't open /.CPR" error I asked if this is a known problem and
> received a negative answert. But I did not ask any further as
> I don't need suspend/resume on this machine.

Strange. For me the behaviour is consistent both with Solaris 9
and 10 - resume fails with the above mentioned error when / is
logging, and works without a problem when root is nologging.

As logging is default now, everybody should see the problem when
using sys-suspend. I can only guess that no one is actually using
it, and therefore the problem hasn't been mentioned here more often.

mp.
--
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna

Martin Paul schrieb:
> Thomas Maier-Komor <maierkom@lpr.e-technik.no-spam.tu-muenchen.de> wrote:
>
>>I had the same problem on a Blade 1000 and a different one with
>>a crash that is under investigation on a Blade 2500. Concerning the
>>"can't open /.CPR" error I asked if this is a known problem and
>>received a negative answert. But I did not ask any further as
>>I don't need suspend/resume on this machine.
>
>
> Strange. For me the behaviour is consistent both with Solaris 9
> and 10 - resume fails with the above mentioned error when / is
> logging, and works without a problem when root is nologging.
>
> As logging is default now, everybody should see the problem when
> using sys-suspend. I can only guess that no one is actually using
> it, and therefore the problem hasn't been mentioned here more often.
>
> mp.

That is, what I guessed, too. But the person handling my case
said, he does suspend/resume on a regular basis without a
problem. Maybe his filesystem isn't logging. I will ask him...

Tom

Thomas Maier-Komor schrieb:
> Martin Paul schrieb:
>
>> Thomas Maier-Komor <maierkom@lpr.e-technik.no-spam.tu-muenchen.de> wrote:
>>
>>> I had the same problem on a Blade 1000 and a different one with
>>> a crash that is under investigation on a Blade 2500. Concerning the
>>> "can't open /.CPR" error I asked if this is a known problem and
>>> received a negative answert. But I did not ask any further as
>>> I don't need suspend/resume on this machine.
>>
>>
>>
>> Strange. For me the behaviour is consistent both with Solaris 9
>> and 10 - resume fails with the above mentioned error when / is
>> logging, and works without a problem when root is nologging.
>>
>> As logging is default now, everybody should see the problem when
>> using sys-suspend. I can only guess that no one is actually using
>> it, and therefore the problem hasn't been mentioned here more often.
>>
>> mp.
>
>
> That is, what I guessed, too. But the person handling my case
> said, he does suspend/resume on a regular basis without a
> problem. Maybe his filesystem isn't logging. I will ask him...
>
> Tom

sorry to reply to my own post.

I looked on sunsolve. It is a known problem. Bugid 4163575.
Work around is: disable logging.

HTH,
Tom

On Tue, 18 Oct 2005 16:21:08 +0200, Thomas Maier-Komor
<maierkom@lpr.e-technik.no-spam.tu-muenchen.de> wrote:

> I looked on sunsolve. It is a known problem. Bugid 4163575.

that one was fixed in Solaris 9.

---
frankB

"Frank Batschulat" <frank.batschulat@i_hate_spam_sun.com> writes:

>On Tue, 18 Oct 2005 16:21:08 +0200, Thomas Maier-Komor
><maierkom@lpr.e-technik.no-spam.tu-muenchen.de> wrote:

>> I looked on sunsolve. It is a known problem. Bugid 4163575.

>that one was fixed in Solaris 9.

Perhaps he should check the status of write caching on the
disks.....

Casper

In article <4354ff2f$0$10578$3b214f66@usenet.univie.ac.at>,
Martin Paul <map@par.univie.ac.at> writes:
> Thomas Maier-Komor <maierkom@lpr.e-technik.no-spam.tu-muenchen.de> wrote:
>> I had the same problem on a Blade 1000 and a different one with
>> a crash that is under investigation on a Blade 2500. Concerning the
>> "can't open /.CPR" error I asked if this is a known problem and
>> received a negative answert. But I did not ask any further as
>> I don't need suspend/resume on this machine.
>
> Strange. For me the behaviour is consistent both with Solaris 9
> and 10 - resume fails with the above mentioned error when / is
> logging, and works without a problem when root is nologging.
>
> As logging is default now, everybody should see the problem when
> using sys-suspend. I can only guess that no one is actually using
> it, and therefore the problem hasn't been mentioned here more often.

I use it on my home sparcs (not my home x86 machine, unfortunately).

It seems to be hit and miss. I had the same problem on and off
throughout S10 beta. For the last few months it's worked fine
without a hitch - and that is with / mounted with logging.

(One thing I was suspicious about was that once I had got it to work
once, it tended to work thereafter. If you re-enable logging, does its
stop working again?)

--
-Peter Tribble
L.I.S., University of Hertfordshire - http://www.herts.ac.uk/
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

Casper H.S. Dik schrieb:
> "Frank Batschulat" <frank.batschulat@i_hate_spam_sun.com> writes:
>
>
>>On Tue, 18 Oct 2005 16:21:08 +0200, Thomas Maier-Komor
>><maierkom@lpr.e-technik.no-spam.tu-muenchen.de> wrote:
>
>
>>>I looked on sunsolve. It is a known problem. Bugid 4163575.
>
>
>>that one was fixed in Solaris 9.
>
>
> Perhaps he should check the status of write caching on the
> disks.....
>
> Casper

on the blade 1000, where I had this error write caching is disabled,
isn't it?

scsi> p8

Page 0x8:
default: 88 12 90 00 ff ff 00 00 00 76 ff ff 80 02 00 00
00 00 00 00
current: 88 12 90 00 ff ff 00 00 00 76 ff ff 80 02 00 00
00 00 00 00
saved: 88 12 90 00 ff ff 00 00 00 76 ff ff 80 02 00 00
00 00 00 00
changeable: 88 12 b5 00 00 00 ff ff ff ff 00 00 a0 ff 00 00
00 00 00 00

Tom

Frank Batschulat schrieb:
> On Tue, 18 Oct 2005 16:21:08 +0200, Thomas Maier-Komor
> <maierkom@lpr.e-technik.no-spam.tu-muenchen.de> wrote:
>
>> I looked on sunsolve. It is a known problem. Bugid 4163575.
>
>
> that one was fixed in Solaris 9.
>
> ---
> frankB

the one that was fixed in Solaris 9 is 4163575, you are right.
But there is another one from Apr 27, 2005: 4491494.
The newer one refers to the older one as "Related Change Request".

So I posted the wrong one...

Tom