file system recovery [gbde]
bsd at afields.ca
Sat Oct 2 13:50:38 PDT 2004
On Sat, Oct 02, 2004 at 09:08:38PM +0200, Hannes Mehnert wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> I updatet yesterday to -CURRENT (from -CURRENT from about 09/20).
> I use gbde, so I attached my gbde device (a partition, no md-device).
And that would include the latest patch to fix a gbde sector mapping
bug though that was actually committed on Sept 14th from logs. Do
you use less than 4 keys? (gbde init with number_of_keys < 4)
If you do, a necessary step is to dump and restore a filesystem
during update. See freebsd-geom list archives for more info.
If not this might be another issue.
PHK: I think we need more warnings in UPDATING for instance.
> After mounting it I was not able to access files. An ls /mnt/crypto/
> froze the system, I had to reboot.
It's not so good that this worked at all if it's the problem I'm
PHK: Should a version number be incorporated w/ master key sectors
to stop attach in these cases? If not using the key sector then
lock file/sector 0. It should be that g_bde fails to create
geom/attach if the minimum version number compat is not met by kernel.
> After reboot fsck was not able to check the attached gbde device:
> # fsck -t ufs /dev/ad0s2f.bde
> ** /dev/ad0s2f.bde
> ** Last Mounted on /mnt/crypto
> ** Phase 1 - Check Blocks and Sizes
> fsck_ufs: cannot alloc 2728847320 bytes for inoinfo
At that point, it could do more harm than good.
> I downgraded to -CURRENT from 20040915, but it was also not able
> to run fsck.
Did you rebuild and install modules? g_bde can be loaded as a module
when you run gbde(8) command.
> I also tried other superblocks (fsck -b), nothing changed, looks
> like something else broke.
> dumpfs core dumps
> dd if=/dev/ad0s2f.bde bs=1m count=20 skip=32 | strings
> returns data which is (was?) on the file system.
It shouldn't entirely work like this but some data might display
> Any ideas how to recover the data (apart from shell-skripts which use
> dd and strings)?
Use an older system or downgrade the module version if it isn't already.
Perhaps the filesystem can still be saved. Before doing anything further
first dump it to another drive. An idea in future is to do fsck -n first,
though in this case it might be misleading too.
I wish to offer the advice to anyone with similar problems in the
future, do a dd of the device first, before performing _any_ writes
to fix it.
The best strategy is (hopefully) up to date backups.
> Best Regards,
> Hannes Mehnert
Allan Fields, AFRSL - http://afields.ca
2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541
More information about the freebsd-current