Date: Tue, 27 Feb 2007 14:21:59 +0100 (CET) From: Christian Baer <christian.baer@uni-dortmund.de> To: freebsd-geom@freebsd.org Subject: geli mirror with -a won't format Message-ID: <es1b9n$297j$1@nermal.rz1.convenimus.net>
next in thread | raw e-mail | index | archive | help
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@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. :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?es1b9n$297j$1>