geli mirror with -a won't format

[Christian Baer]

Hello there, peeps!

I have been trying to create a filesystem for paranoid people like
myself. :-) What I want to make is this:

- mirror (two partitions with gmirror)
- geli with -a on that

I am not expecting anyone to manipulate my system. My data is far too
unimportant (to other people) for that. But the file systems will
contain stuff that is *very* important to me and I am hoping that -a
will give me an early warning if the data becomes corrupt due to
hardware failure. If I got the whole thing with -a wrong, then *my*
problem is solved, as I won't be using -a. :-) But it could very well be
an issue for other people.

The commands I used are these (with the replies from the system):

  sunny# geli init -v -s 4096 -K - -a HMAC/SHA256 -e blowfish -l 448 -P /dev/mirror/home
  Metadata value stored on /dev/mirror/home.
  Done.
  sunny# geli attach -v -p -k - /dev/mirror/home
  Attched to /dev/mirror/home.
  Done.

Note: The keyfile in both cases is created by a script and piped to geli.

Now strangely, this looks ok so far. But it isn't. :-/ If I use the init
without the -a I get this in /var/log/messages:

 kernel: GEOM_ELI: Device mirror/home.eli created.
 kernel: GEOM_ELI: Encryption: Blowfish-CBC 448
 kernel: GEOM_ELI:     Crypto: software

I can do a newfs, mount the provider and work with it. That all stops
when I activate authentication when initialising the provider (as shown
in the comman above). /var/log/messages gets really messy then:

 kernel: GEOM_ELI: Device mirror/home.eli created.
 kernel: GEOM_ELI: Encryption: Blowfish-CBC 448
 kernel: GEOM_ELI:  Integrity: HMAC/SHA256
 kernel: GEOM_ELI:     Crypto: software
 kernel: GEOM_ELI: mirror/home.eli:
 kernel: 4096 bytes corrupte
 kernel: d at offset
 kernel:
 kernel: 11456892928
 kernel: .
 kernel: GEOM_ELI: mirr
 kernel: or/home.eli
 kernel: : 4096 byte
 kernel: s corrupted
 kernel: at offset 0
 kernel: .
 kernel: GEOM_ELI: mir
 kernel: r
 kernel: or/home.eli
 kernel: : 4096 byte
 kernel: s corrupted
 kernel: at offset 4
 kernel: 096.
 kernel: GEOM_ELI: mirr
 kernel: or/home.eli
 kernel: : 4096 byte
 kernel: s corrupted
 kernel: at offset 0
 kernel: .
 kernel: GEOM_ELI: mirr
 kernel: or/home.eli
 kernel: : 4096 byte
 kernel: s corrupted
 kernel: at offset 0
 kernel: .
 kernel: GEOM_ELI: mi
 kernel: r
 kernel: ror/home.el
 kernel: i: 8192 byt
 kernel: es corrupte
 kernel: d
 kernel: at offset
 kernel: 0.

I have tried changing the options for -a (md5 and sha1) and -e (AES only,
3DES is so damn slow that I didn't even *want* to try it) with the same
result - basicly anyway. The output in /var/log/messages is a little
different, showing the used algorithms but otherwise the same thing.

As you can imagine, I can't even create a file system on that:

  sunny# newfs -U -O 2 /dev/mirror/home.eli
  /dev/mirror/home.eli: 10926.1MB (22376752 sectors) block size 16384,
  fragment size 4096
          using 33 cylinder groups of 336.88MB, 21560 blks, 21568 inodes.
          with soft updates
  newfs: can't read old UFS1 superblock: read error from block device: Invalid argument

I'm not sure if I messed up here or if the code might actually be
broken. uname -a says this:

FreeBSD sunny.rz1.convenimus.net 6.2-STABLE FreeBSD 6.2-STABLE #1: 
Tue Feb 27 11:08:32 CET 2007 root at sunny.rz1.convenimus.net:
/usr/obj/usr/src/sys/SUNNY  sparc64

As you can see, I am not running a standard Intel CPU, but a Sun U60
with 2 CPUs and 2GB of RAM.[1] The drives are two Seagate
Cheetah SX173404LC with 73GB each. geli worked before on this system,
but I didn't use -a back then.

Can anyone help me?

Regards
Chris

[1] Ok, you can't see all of that from the uname. :-)