Date: Sun, 16 Jan 2011 14:24:58 +0100 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: "Christopher J. Ruwe" <cjr@cruwe.de> Cc: freebsd-stable@freebsd.org Subject: Re: geli problems after installkernel & installworld Message-ID: <20110116142458.46435fde@r500.local> In-Reply-To: <20110116020437.4e3e697e@dijkstra> References: <20110113220019.0c18c7ef@dijkstra> <20110115213056.GE5335@garage.freebsd.pl> <20110116020437.4e3e697e@dijkstra>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110116142458.46435fde>