Well, that was supposed to be personal to Doug, but I suck. Anyway, what I
was going to say for public consumption was:
Derrick J Brashear wrote:
i think logging ufs reused some inode fields we need, so logging ufs
support is unlikely
So are you saying that logging must be off?
I haven't tested
On Mon, 22 Nov 2004, Douglas E. Engert wrote:
Derrick J Brashear wrote:
i think logging ufs reused some inode fields we need, so logging ufs
support is unlikely
So are you saying that logging must be off?
The fileserver should probably warn. Actually, though, open source Solaris
may make this al
Derrick J Brashear wrote:
i think logging ufs reused some inode fields we need, so logging ufs
support is unlikely
So are you saying that logging must be off? Should the fileserver
refuse to use a partition with logging turned on or at least fsck should
warn about this? A mod for fsck might be ea
i think logging ufs reused some inode fields we need, so logging ufs
support is unlikely
___
OpenAFS-info mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-info
Stephen Joyce wrote:
On Fri, 12 Nov 2004, Douglas E. Engert wrote:
However I'm still getting the following error:
Open AFS (R) openafs 1.2.13 fsck
** /dev/rdsk/c1t0d0s3
BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE
USE AN ALTERNATE SUPER-BLOCK TO SUPPLY NEE
On Fri, 12 Nov 2004, Douglas E. Engert wrote:
> > However I'm still getting the following error:
> > Open AFS (R) openafs 1.2.13 fsck
> > ** /dev/rdsk/c1t0d0s3
> > BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST
> > ALTERNATE
> > USE AN ALTERNATE SUPER-BLOCK TO SUPPLY
Stephen Joyce wrote:
Doug (and anyone else w/ knowledge wrt Solaris),
I've still got fsck problems on solaris 9... I downloaded 1.2.13, but it
doesn't appear to have Doug's patches or the solaris interleave patch
applied... so I retrieved the patches from CVS, applied them, and built
from source (
Doug (and anyone else w/ knowledge wrt Solaris),
I've still got fsck problems on solaris 9... I downloaded 1.2.13, but it
doesn't appear to have Doug's patches or the solaris interleave patch
applied... so I retrieved the patches from CVS, applied them, and built
from source (without problems).
H
I sent in a bug report and patch on 11/2 See bug 15927.
Basicly it adds a prototype for bread and bwrite into fsck.h
You may also need the patch to the src/vfsck/setup.c added to the CVS in August to
get it to compile on Solare 9 if the sys/fs/ufs_fs.h does has been updated
Stephen Joyce wrote:
T
Thanks for working on this. Is there a solution yet? I have a development
machine (solaris 9, openafs 1.2.11) which I patched last night (before
reading the archives--doh!) and it appears to have the same, or a similar,
problem (it was fine before applying the newest patches):
The system is co
I think I found the cause of fsck problem. I am concernd that if
the fsck is run against the cooked device rather then the raw
device, it could actually cause damage, rather then doing nothing
and failing.
Solaris 9 in ufs_fs.h changes fsbtodb:
#ifdef KERNEL
#define fsbtodb(fs, b) (((daddr_t)(b)
On Sun, 31 Oct 2004, Brian Sebby wrote:
# fsck /vicepa
Open AFS (R) openafs 1.2.11 fsck
** /dev/rdsk/c0t9d0s0
CANNOT READ: BLK 0
CONTINUE? [yn] y
fsck the cooked device (/dev/dsk/c0t9d0s0). you may need to use a wrapper
or to patch vfsck to do it.
you should have mentioned this was the er
I realized that some of this came up back in August, so I apologize if I'm
going over old ground. But after searching through the archives, I'm not
entirely sure if this has ever been fixed.
I have a machine that I upgraded from Solaris 8 to Solaris 9. While we
already have a Solaris 9 AFS serv
13 matches
Mail list logo
