Menu

#3 Bad magic number in super-block while trying to open /dev/m

open
nobody
None
5
2013-03-27
2013-03-27
No

Before I did a fresh install of Fedora 18, cryptmount had been working well for quite a while and endured several system changes/upgrades.

I thought I had damaged the device somehow: Maybe by system crashes/power-off shutdown, so I reinstalled the old system I kept as backup and the device mounted very gracefully, without need to run e2fsck.

On this new system, I am running cryptmount 4.3, same as the old system. on the same hardware (AMD Turion x86_64 system) and same encrypted drive. When I built Cryptmount on this fresh Fresh Fedora 18 install, I enabled everything as it appeared to be on the old system.

Oh yea, I'm running kernel 3.6.10-4.fc18.x86_64, The old system/kernel was 3.6.7-4.fc17.x86_64.

The device is encrypted with aes and uses crypmount's built-in manager. DM_crypt is loaded. Is there anything else needing to be loaded for the kernel?

Is there anything I forgot to check? As the device is holding over 100 gig of files, I'd hate to have to re-install the old system and find a temporary place to store the un-encrypted files until I can get cryptmount working on the new install.

Thanks,

Ernie D

Discussion

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.