Date: Sun, 16 Jan 2011 02:04:37 +0100 From: "Christopher J. Ruwe" <cjr@cruwe.de> To: freebsd-stable@freebsd.org Subject: Re: geli problems after installkernel & installworld Message-ID: <20110116020437.4e3e697e@dijkstra> In-Reply-To: <20110115213056.GE5335@garage.freebsd.pl> References: <20110113220019.0c18c7ef@dijkstra> <20110115213056.GE5335@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Sat, 15 Jan 2011 22:30:56 +0100
Pawel Jakub Dawidek <pjd@FreeBSD.org> wrote:
> On Thu, Jan 13, 2011 at 10:00:19PM +0100, Christopher J. Ruwe wrote:
> > I use a mostly geli encrypted hd on my Thinkpad R500,
> > with /compat, /usr, /tmp and /var all on the encrypted geli
> > provider.
> >
> > After an upgrade of kernel and world (STABLE), I experience a weird
> > issue: While booting, I am asked for the geli passphrase as usual.
> > Completing password authentication for geli returns a success
> > message,
> >
> > cryptosoft0: <software crypto> on motherboard
> > GEOM_ELI: Device ada0p3.eli created.
> > GEOM_ELI: Encryption: AES-CBC 256
> > GEOM_ELI: Crypto: software
> >
> > however, the zpool on geli is unavailable.
> >
> > Logging in a root, I can attach the geli provider manually as geli
> > itself should do from /etc/rc.conf. After a successful zfs mount
> > -a, I can resume as usual after manually starting
> > the /usr/local/rc.d services.
> >
> > Neither have I noticed a change in the device names nor any unusual
> > messages from dmesg. Currently, I am doing a new compile run on
> > world and kernel to attempt anew tomorrow.
> >
> > Am I missing something?
>
> Can you show the output of 'geli list' from a running system?
>
Sure I can ... I'll additionally comment the output with what I do to.
First I boot and my /usr/local/rc.d/ - schripts do not start. Likewise
does zsh.
From doing geli list, I get (on stdout)
Geom name: ada0p3.eli
State: ACTIVE
EncryptionAlgorithm: AES-CBC
KeyLength: 256
Crypto: software
UsedKey: 0
Flags: SINGLE-KEY, NATIVE-BYTE-ORDER, BOOT, RW-DETACH
Providers:
1. Name: ada0p3.eli
Mediasize: 249656594432 (233G)
Sectorsize: 4096
Mode: r0w0e0
Consumers:
1. Name: ada0p3
Mediasize: 249656596992 (233G)
Sectorsize: 512
Mode: r1w1e1
Doing a zpool status -v gives on stdout
pool: ntank
state: UNAVAIL
status: One or more devices could not be opened. There are insufficient
replicas for the pool to continue functioning.
action: Attach the missing device and online it using 'zpool online'.
see: http://www.sun.com/msg/ZFS-8000-3C
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
ntank UNAVAIL 0 0 0 insufficient replicas
ada0p3.eli UNAVAIL 0 0 0 cannot open
pool: rpool
state: ONLINE
status: The pool is formatted using an older on-disk format. The pool
can still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'. Once this is done, the
pool will no longer be accessible on older software versions.
scrub: none requested
config:
NAME STATE READ
WRITE CKSUM rpool
ONLINE 0 0 0
gptid/3ab00705-d22f-11df-8e1b-002713b40a7b ONLINE 0
0 0
errors: No known data errors
and on stderr ( I noticed the output on stderr as I ran the command, so
I just typed that)
GEOM_ELI[1]: Device ada0p3.eli is still open, so it cannot be definitely
removed.
GEOM_ELI[1]: Detached ada0p3.eli on last close.
When doing a geli attach -k /pathtomykey/key /dev/ada0p3 directly
followed by a zfs mount -a, I have my filesystems where I am used to
finding them. I run my /usr/local/rc.ds from there and am functional
again.
Then (I post this anwe, I will point out why later on), I get for geli
list
Geom name: ada0p3.eli
State: ACTIVE
EncryptionAlgorithm: AES-CBC
KeyLength: 256
Crypto: software
UsedKey: 0
Flags: SINGLE-KEY, NATIVE-BYTE-ORDER, BOOT
Providers:
1. Name: ada0p3.eli
Mediasize: 249656594432 (233G)
Sectorsize: 4096
Mode: r1w1e1
Consumers:
1. Name: ada0p3
Mediasize: 249656596992 (233G)
Sectorsize: 512
Mode: r1w1e1
I never noticed that before, but, as I did not know which geli output
you were asking for (the one not working or the one working), I diffed
the two files and noticed, that directly after booting, the RW-DETACH
flag is set. I do not know what that means nor do I know whether that
matters, I find that curious, though.
Thank you for your help, have a nice Sunday, kind regards,
--
Christopher J. Ruwe
TZ GMT + 1
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (FreeBSD)
iQIcBAEBAgAGBQJNMkQsAAoJEJTIKW/o3iwU9+sQAJRiF2DLAwiW+j0tD4kFEAl5
UzFaKSmAbg6ujZtfaI04U3lMcm08NkET390SN98GLyu82OwwiW2jgHLU+5DL6yTZ
2fgnaLQd0ztYv5ynUwzMZSCVTMI8Du9NKy1zenzMe4WHRFZThZAqVW3U4VazRhlz
AjhXQPD04nQI0AJW1N+9vPTzIshmYm3PPlzsj5VcaKhjixaP2jcJmQLlEkc1fr2u
hPM62ZoFO0WP1raayaeu9t5No0lO1dHeWynyY6vAeraye2ldQE+LqA5b1GRhgEus
5Q6RdkbAyukXv7RQ1QaV01enUup5kLNYQPKN4rPiIaLIv57tJjcRuj00ZceugwQl
5Deh1Nuo1axljlGvbLrfbUPsUmW1ofD7aZmNuGX2+nAt8w2Z9JsDsUYqnzcNEcE5
0WOkpET/reVoIP1/bk+yI4DV+R6+rR6ta5yVYTIhQn4GGN12PLHKNspZ/qxXh6Wu
6raOH0N6oqU6GNTtlB8u0CHi/nYBGiYRNNljhX7mO1hgnW+sDpLYvzNPy+3BLJxi
9dU+VM81vrTeTs0OrfTYK9Fe10QETQvaRn69c6BG7ViiHKNi5IJ067LOEizQmdOL
ImOetX1knCZvTU/6i7e2L9ECqmRQc2f7tuVZ6SdL87aLfQyOuuBdzNBsr2KLPmJ0
bfZkjI20Vtq5ETWzPJoO
=D9rF
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110116020437.4e3e697e>