UFS After GELI restore metadata can't fsck or mount

vojtaz

vojtaz

Hi guys,

I've recently moved my system to new box. At first boot up I got an error with attaching my encrypted disks (GELI) saying there's a problem with metadata. So I've restored it with my backup file with geli restore. Attaching is no longer an issue now I can't mount it or even fsck.

When trying to mount:

root# mount -t ufs /dev/ad5.eli /directory

mount: /dev/ad5.eli: Invalid argument

When trying to fsck:

root# fsck_ufs /dev/ad5.eli

** /dev/ad5.eli
Cannot find file system superblock
/dev/ad5.eli: CANNOT FIGURE OUT FILE SYSTEM PARTITION


Even fsck with predefined superblock 32 or 160 fails:

root# fsck_ufs -b 32 /dev/ad5.eli

Alternate super block location: 32
** /dev/ad5.eli
32 is not a file system superblock


root# fsck_ufs -b 160 /dev/ad5.eli

Alternate super block location: 160
** /dev/ad5.eli
160 is not a file system superblock


Have no clue what to do next. Data on this disk is super important for me.

I'am using FreeBSD 8.4-stable. Also checked disk health with smartmontools, nothing there.
 
When you say you moved your system to a new box, what did you do? Physically move the hard disks or copy the data from your old hard disks onto the new hard disks in the new machine?

Since your data is important, I am hopeful you have a backup. It might be quicker to configure new GELI containers and restore from backup rather than trying to work out exactly what went wrong and how to fix it.
 
Physically move disks to new machine. I don't have backup of this disk, only mentioned metadata backup which already had been restored. From this point decrypted disk filesystem can't be recognized by mount or fsck even with predefined filesystem by -t flag.
 
You mentioned disks (plural). Did the order (and therefore numbering) of the drives change from the old machine to the new machine? If so is it possible you have restored the wrong metadata?

According to the geli(8) man page, the metadata is stored on the last sector of the provider. It is unlikely that only that last sector was damaged, so either you have more general damage to your disk or nothing was actually wrong with your metadata. If the latter, perhaps the restore has overwritten valid metadata with invalid, which is why you can attach but not access the filesystem, which now decrypts to gibberish.

Did you use the same version of FreeBSD to conduct the restore as your system is using? I see that GELI has different formats of metadata in different versions. You should be able to see what version you are now using with geli version /dev/ad5.eli. From the geli(8) man page I expect FreeBSD 8.4 can support up to version 5.

I'm afraid I don't have a magic fix for you. I suggest trying to replicate the issue with other disks that don't contain valuable data so that you can use trial and error to find a fix without further risk to your valuable data. A virtual machine might be quickest but if you can't replicate the issue there then you could install FreeBSD on a disk in your old machine then move it to your new one (this would also show you whether the disks are being numbered differently in your new system).
 
One possibility is that the disks have different geometry (in the amount of LBA sectors, the CHS values the BIOS might report can be ignored) on the new system and that throws off GELI which relies on the metadata located on the last LBA sector of the provider (disk or a partition).
 
You must log in or register to reply here.
Back
Top