On Sat, Oct 02, 2004 at 09:08:38PM +0200, Hannes Mehnert wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > 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 thinking of. 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 fine. > 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 5541Received on Sat Oct 02 2004 - 18:50:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:15 UTC