I've got two encrypted partitions I backup whenever
neccessary. I do a cdrecord directly from /dev/hdaX to cd.
To mount I just do a losetup -e serpent /dev/loopX
/dev/hdaX
I restore backups with cat /dev/cdrom > /dev/hdaX
This used to work before my upgrade to a Slackware 8
with kernel 2.4.20 (used to have a heavily patched
Slackware 7.something which had 2.4.3), now, if I try
to restore old backups, made under my previous system,
the filesystems are corrupted; mounting succeeds, but I
only get (some) directories, content is missing completely.
Backups taken after my system upgrade work just as before.
Superblocks are found OK, but apparently the inode maps
are foobar.
Ideas?
I also have an image of my old system (cat /dev/hdaX |
gzip > image), my partition table hasn't changed since
I took it, but I really don't feel like restoring it,
then restoring the new system for just for one file...
Logged In: NO
Adding the solution to my own problem here...
I suddenly got the idea of creating a vmware instance of my
old installation and trying to read with that!-)
And yep, you guessed it; it WORKED!
I first did a cat /dev/cdrom > stuff.img
Then told vmware to handle it as a /dev/hdb.
I didn't even need to cat this into a virtual partition, I
mounted it, read the stuff and everything worked..
Got the file out and no problems.
Anyway, are version incompatibilities like this one common
in losetup and/or the serpent crypto module?
If they are, I think I'd better keep this vmware
installation ready for any future backups I might not be
able to recover :-(...
Logged In: NO
Try mounting it with a loop device, running e2fsck on the
loop, etc.
N.B. You should NOT image a mounted filesystem! Remount it
ro, first.
There may (I am not aware) also be bug fixes which broke
serpent.
You could try installing your old kernel in lilo.conf, and
use it pro tem.
Also, consider using dd conv=sync bs=2k when reading/writing
CD-R.