Frank Mayhar wrote:
hi, all
http://lists.freebsd.org/pipermail/freebsd-questions/2007-June/151686.html
my problem
# fsck /dev/aacd0s1f
** /dev/aacd0s1f (NO WRITE)
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes
You might also want to try ports/sysutils/ffsrecov2 before
On Tuesday 25 September 2007 06:13:10 John-Mark Gurney wrote:
Ian Smith wrote this message on Sat, Sep 22, 2007 at 13:16 +1000:
This drew a blank in -questions. I don't know where else to post it, so
I'm hoping someone here might be able to spare me a clue.
You should probably have posted
Don Lewis wrote:
On 24 Sep, sam wrote:
any solutions ?
The patch below should allow a manual fsck to run to completion. I'd
recommend running fsck -N and capturing its output. Then use the clri
# fsck -N
fsck: illegal option -- N
usage: fsck [-dfnpvy] [-B | -F] [-T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 25 Sep 2007 11:17+0400, sam wrote:
fsck: illegal option -- N
Try: fsck -n
man fsck should give you some hints on what Don was talking about.
I.e.:
-n Causes fsck to assume no as the answer to all operator questions,
Don Lewis wrote:
On 24 Sep, sam wrote:
Expect major file system lossage ...
I think this patch could be better, but this should get you going ...
Index: sbin/fsck_ffs/pass1.c
===
RCS file: /home/ncvs/src/sbin/fsck_ffs/pass1.c,v
Ivan and Kris,
I will try to get a kernel trace -- it may not happen for awhile since I am
not in the office and working remotely for awhile so it may not be easy to
get a trace... but I will check.
It looks like the problem reported by that link, and some of the links from
there though...
sam wrote:
Don Lewis wrote:
On 24 Sep, sam wrote:
Expect major file system lossage ...
I think this patch could be better, but this should get you going ...
UNEXPECTED SOFT UPDATE INCONSISTENCY
LOST 74 DIRECTORIES
UNEXPECTED SOFT UPDATE INCONSISTENCY
fsck: /dev/aacd0s1f: Segmentation
Benjie Chen wrote:
Ivan and Kris,
I will try to get a kernel trace -- it may not happen for awhile since I am
not in the office and working remotely for awhile so it may not be easy to
get a trace... but I will check.
It looks like the problem reported by that link, and some of the links from
Kris Kennaway wrote:
Does it really? i.e. did you compare the function names in detail and
find that they match precisely, or do you just mean they are both
panics of some description and I dunno what it all means? :) I ask
because the linked trace does not involve a spinlock, which means it
On 9/25/07, Matthias Fechner [EMAIL PROTECTED] wrote:
thx a lot for your really great answer, but I have some more short
questions. :)
Do you copy the release target to the Makefile in
/usr/src/release/Makefile or do you execute from another place?
Since we need to be able to reproduce our
Benjie Chen wrote:
You are right, they may not be the same. From first look it seems like
they are similar based on the description of the problems -- system
stable, then under load related to network, get panic after different
time intervals. I just assumed that kernel is typically stable
Ivan Voras wrote:
Kris Kennaway wrote:
Does it really? i.e. did you compare the function names in detail and
find that they match precisely, or do you just mean they are both
panics of some description and I dunno what it all means? :) I ask
because the linked trace does not involve a
On 25/09/2007, Kris Kennaway [EMAIL PROTECTED] wrote:
Not in the sense of transmuting a sleep mutex into a spin mutex, no.
sleep mutexes will spin when the lock holder is currently running, but
this happens within the context of the mtx_lock_sleep function itself.
Ok, thanks, this clears
On 25 Sep, sam wrote:
Don Lewis wrote:
On 24 Sep, sam wrote:
any solutions ?
The patch below should allow a manual fsck to run to completion. I'd
recommend running fsck -N and capturing its output. Then use the clri
# fsck -N
fsck: illegal option -- N
usage: fsck [-dfnpvy]
On 25 Sep, sam wrote:
sam wrote:
Don Lewis wrote:
On 24 Sep, sam wrote:
Expect major file system lossage ...
I think this patch could be better, but this should get you going ...
UNEXPECTED SOFT UPDATE INCONSISTENCY
LOST 74 DIRECTORIES
UNEXPECTED SOFT UPDATE INCONSISTENCY
fsck:
Hello Hackers
I was looking into setting up the Intel / NetBSD iSCSI Target port
on FreeBSD 6-STABLE . The first question I have is related to the use of
the iscsi target port on FreeBSD. In the original docs, bundled with the
Intel source, Intel had an example of setting up the target to
16 matches
Mail list logo
