Date: Wed, 01 Oct 2014 17:19:37 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-stable@freebsd.org Subject: Re: Encrypted (GELI) root on ZFS troubles Message-ID: <542C7DF9.3060404@denninger.net> In-Reply-To: <542C7903.3010906@denninger.net> References: <542C71C9.1050907@denninger.net> <542C7794.8040502@FreeBSD.org> <542C7903.3010906@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 10/1/2014 4:58 PM, Karl Denninger wrote: > On 10/1/2014 4:52 PM, Andriy Gapon wrote: >> On 02/10/2014 00:27, Karl Denninger wrote: >>> So here's the fun part of what I'm trying to do (and getting frustrated >>> with) >>> >>> I have set up a GPT disk with the following setup: >>> >>> => 34 625142381 da2 GPT (298G) >>> 34 6 - free - (3.0K) >>> 40 1024 1 freebsd-boot (512K) >>> 1064 4194304 2 freebsd-zfs [bootme] (2.0G) >>> 4195368 134217728 3 freebsd-swap (64G) >>> 138413096 486729312 4 freebsd-zfs (232G) >>> 625142408 7 - free - (3.5K) >>> >>> Then on freebsd-boot I have written the bootloaders. >>> >>> The "bootme" filesystem has *only* the /boot directory copied over from >>> the rest of the system's root directory (that is, the kernel, loadables, >>> /boot/loader.conf, etc); that pool is called "zboot" >>> >>> Partition 4 has the label "root0" on it, and thus shows up in /dev/gpt. >>> I have initialized that with geli, set the boot option flag (that is, >>> prompt on boot) and created a pool called "root" on the resulting .eli >>> device and then put the system on that. That's all ok. >>> >>> Finally, I set the bootfs on that latter pool. There is no bootfs set >>> on /zboot: >>> >>> # zpool get bootfs zboot >>> NAME PROPERTY VALUE SOURCE >>> zboot bootfs - default >>> >>> It is set on the root pool to the proper filesystem: >>> >>> # zpool get bootfs root >>> NAME PROPERTY VALUE SOURCE >>> root bootfs root/R/10.1-CLEAN local >>> >>> The problem is that when the system boots geli "finds" the raw device >>> (in this case /dev/da0p4), prompts for the password and attaches there >>> instead of in /dev/gpt. The gpt label is missing --- and equally bad >>> the "root" pool does not appear to import at boot time either. >>> >>> As a result the system tries to mount root from /zboot (even though it's >>> not been told to, and HAS been told where to mount off the root pool), >> As far as *I* can see, you have not told the kernel what your root fs should be, >> so it is using a default root filesystem which the same filesystem from where >> the kernel itself was loaded. >> >>> but there's no init in there (or anything else other than the boot >>> filesystem itself) and as a result I get an immediate panic. >>> > Various wikis on setting this up have strongly suggested that > /boot/loader.conf no longer needs to have the root filesystem declared > explicitly as it is able to locate it via looking in the pool metadata. > Is this wrong in this specific case? > > (Not a huge deal if so, but it's not at all clear that's true -- and it > doesn't do anything for the issue of geli grabbing the base device > rather than the /dev/gpt one.) > Ah, the kernel will not cross a zpool to look for bootfs; if it's not set on the pool it comes from it will not look further. Setting it explicitly in /boot/loader.conf worked. -- Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ [-- Attachment #2 --] 0 *H 01 0 + 0 *H O0K030 *H 01 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 130824190344Z 180823190344Z0[1 0 UUS10UFlorida10UKarl Denninger1!0 *H karl@denninger.net0"0 *H 0 bi՞] MNԿawx?`)'ҴcWgR@BlWh+ u}ApdCF JVй~FOL }EW^bچYp3K& ׂ(R lxڝ.xz?6 &nsJ +1v9 v/( kqĪp[vjcK%fϻe?iq]z lyzFO'ppdX//Lw(3 JI A*S#՟H[f|CGqJKoo y.oEuOw$ /섀$삻J9b|A P~8]D1YI<"""Y^T2iQ2 b yH)] Ƶ0y$ _N 6XqMC 9 XgώjGTP"#nˋ"Bk1 00 U 0 0 `HB0 U 0, `HB OpenSSL Generated Certificate0 U |8 ˴d[20 U #0]Af4 U3x&^"408 `HB+)https://cudasystems.net:11443/revoked.crl0 *H gBwH] j\x`( &gW32"Uf^. ^Iϱ k!DQA g{(w /)\N'[ oRW @C HO>)XrTNɘ!u`xt5(=f\-l3<@C6mnhv##1ŃbH͍_Nq aʷ?rk$^9TIa!kh,D -ct1 0001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 + ;0 *H 1 *H 0 *H 1 141001221937Z0# *H 1F̓[>5pB0l *H 1_0]0 `He*0 `He0 *H 0*H 0 *H @0+0 *H (0 +71001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 *H 101 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 *H aRSkVIhUU1ˬ:ט {rgV N+pTtMHMႻNe>jx˫'} jF>4,+4Ȝh)Ac(_:[&4p<#x]5ƛy;2Z[ޒ* $tl|bѴ2J C<S, Bsࠦ0͙U !l"S w]i8ZkȚ)PjHVMs nN@?X2 K8a ~d=(HR4d,fYMy%,rq l4C' א{pT(1]G2ܸrC$;'':c }fHPC4#5bϩՍSB=M^QVg$*U IOuy(?d79;l|2<d-`7IQ$XE-"{Pp !.jN֞ϧ/FbLJ9hVˋ'2<3
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?542C7DF9.3060404>