kernel panic mounting /tmp - 6.2-PRERELEASE
brooks at one-eyed-alien.net
Tue Oct 17 22:58:43 UTC 2006
On Wed, Oct 18, 2006 at 08:44:39AM +1000, Norberto Meijome wrote:
> On Tue, 17 Oct 2006 17:33:50 -0500
> Brooks Davis <brooks at one-eyed-alien.net> wrote:
> > > Gotcha - i thought as much... i hoped a dump -0 would save enough info
> > > though. I just needed to have /tmp back in place asap....
> > >
> > > i'll keep the files around for a week or so in case something comes up.
> > Good thought, but anything short of "dd if=/dev/<tmpdevices>
> > of=/path/to/some/location" probably won't preserve the corrupt bits.
> > Think of dump as a version of tar that also knows how to read file
> > systems directly. It only preserves files and their contents not the
> > actual file system bits on the disk
> Yes, I realise that now, it was late and I wasn't thinking too straight
> BTW, the mount in 6.1-RELEASE CD had no issue at all mounting the filesystem..
> dump I used was 6.1-RELEASE too . would have been user land app related, or
> actual UFS kernel code that made the difference?
That's somewhat distrubing. That sounds like a change to the UFS code
somehow made things more fragile, though it could be an access pattern
issue of some sort.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20061017/56b051be/attachment.pgp
More information about the freebsd-stable