Date: Wed, 18 Oct 2006 08:44:39 +1000 From: Norberto Meijome <freebsd@meijome.net> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: freebsd-stable@freebsd.org Subject: Re: kernel panic mounting /tmp - 6.2-PRERELEASE Message-ID: <20061018084439.6451312c@localhost> In-Reply-To: <20061017223350.GA73392@lor.one-eyed-alien.net> References: <20061018002558.3a2bcdf6@localhost> <20061017145946.GB68977@lor.one-eyed-alien.net> <20061018071155.4331765a@localhost> <20061017223350.GA73392@lor.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 17 Oct 2006 17:33:50 -0500
Brooks Davis <brooks@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
obviously.
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?
_________________________
{Beto|Norberto|Numard} Meijome
Do not take away the camels hump, you may be stopping him from being a camel.
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061018084439.6451312c>