Re: geli problems after installkernel & installworld
--Sig_/xVlvc0Ksf75rivFNMbnOj18
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
"Christopher J. Ruwe" <cjr@cruwe.de> wrote:
> On Sat, 15 Jan 2011 22:30:56 +0100
> Pawel Jakub Dawidek <pjd@FreeBSD.org> wrote:
>=20
> > 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.
> > >=20
> > > 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,
> > >=20
> > > cryptosoft0: <software crypto> on motherboard
> > > GEOM_ELI: Device ada0p3.eli created.
> > > GEOM_ELI: Encryption: AES-CBC 256
> > > GEOM_ELI: Crypto: software
> > >=20
> > > however, the zpool on geli is unavailable.
> > >=20
> > > 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.=20
> > >=20
> > > 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.
> > >=20
> > > Am I missing something?
> >=20
> > Can you show the output of 'geli list' from a running system?
> >=20
>=20
> Sure I can ... I'll additionally comment the output with what I do to.
>=20
> First I boot and my /usr/local/rc.d/ - schripts do not start. Likewise
> does zsh.
>=20
> From doing geli list, I get (on stdout)
>=20
> 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
>=20
> Doing a zpool status -v gives on stdout
>=20
> 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:
>=20
> NAME STATE READ WRITE CKSUM
> ntank UNAVAIL 0 0 0 insufficient replicas
> ada0p3.eli UNAVAIL 0 0 0 cannot open
>=20
> 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:
>=20
> NAME STATE READ
> WRITE CKSUM rpool
> ONLINE 0 0 0
> gptid/3ab00705-d22f-11df-8e1b-002713b40a7b ONLINE 0
> 0 0
>=20
> errors: No known data errors
>=20
> and on stderr ( I noticed the output on stderr as I ran the command, so
> I just typed that)
>=20
> GEOM_ELI[1]: Device ada0p3.eli is still open, so it cannot be definitely
> removed.
> GEOM_ELI[1]: Detached ada0p3.eli on last close.
>=20
> 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.
>=20
> Then (I post this anwe, I will point out why later on), I get for geli
> list
>=20
> 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
>=20
> 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.
I'm no sure if it's the cause of your problem,
but it certainly does matter:
http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/117158
Fabian
--Sig_/xVlvc0Ksf75rivFNMbnOj18
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (FreeBSD)
iEYEARECAAYFAk0y8a0ACgkQBYqIVf93VJ3ImwCfaQsylcgDzrj1vwY7NU9v8BwY
k1AAoKfIUEDUDqplhvjdYU1laVDYVkbI
=kN4f
-----END PGP SIGNATURE-----
--Sig_/xVlvc0Ksf75rivFNMbnOj18--
討論串 (同標題文章)
完整討論串 (本文為第 5 之 5 篇)：