DragonFly users List (threaded) for 2006-06
Re: FreeBSD 6.1 install wiped my DragonFly partitions!
Ok, I got a DF livecd.
It seems like /dev/ad0s1c remained intact, therefore the root fs is
still visible. However trying ad0s1d or ad0s1e(mounting them) produces
Invalid Superblock error. fsck reports that those filesystems are not
even UFS. I desperately need to recover /home.
I was thinking if i could recreate the disklable then id get them back,
but the problem is, i have no idea what my disklabel was! Anyway to find
On Sun, 2006-06-11 at 13:01 +1000, Dmitri Nikulin wrote:
> On 6/11/06, elekktretterr@xxxxxxxxxxxxxx <elekktretterr@xxxxxxxxxxxxxx> wrote:
> > That's what I get when I decide to try out FreeBSD again. Can I still
> > recover the data somehow? What to do now? Grub says it can't find
> > partition.
> It happens. If it only wiped the MBR, not the partitions themselves,
> you're not in for too much pain. I find it's by far the easiest in
> NetBSD because its unique disklabel format means you won't need to
> modify the MBR beyond what's required to find the disklabel. Then
> merely set partitions in that label which have the exact same 'start'
> and 'size' as the ones you lost (even if they were inside the
> DragonFly disklabel - it doesn't matter) and mount them. I used to
> think the system was very stupid and meaningless, but it's very useful
> for just ignoring the brain-dead way the BIOS requires partitioning to
> be done.
> Of course actually figuring out the exact offsets is hard... you may
> actually find it easier to manually (NOT USING THE INSTALLER) create a
> DragonFly disklabel identical to what you had (for this exact reason I
> strongly recommend taking notes during installations) and, without
> newfsing anything, try to mount the file systems.
> But if you mean FreeBSD actually newfs'd over them, well, you're going
> to have a very hard time. At best you can look for the sequences of
> data themselves, since actually restoring the file system structure is
> fantasitcally difficult if the inodes have already been blasted by
> newfs. Your job is simplified by the fact that UFS2 doesn't have to
> initialise inodes at newfs time, but that's only a minor
> simplification considering the root of the tree is gone, making the
> rest guesswork to an extent.
> -- Dmitri Nikulin