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>
index | next in thread | previous in thread | raw e-mail
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.
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061018084439.6451312c>