Date: Wed, 01 Oct 2014 16:58:27 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-stable@freebsd.org Subject: Re: Encrypted (GELI) root on ZFS troubles Message-ID: <542C7903.3010906@denninger.net> In-Reply-To: <542C7794.8040502@FreeBSD.org> References: <542C71C9.1050907@denninger.net> <542C7794.8040502@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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.) -- 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 141001215827Z0# *H 1Xk>kA@q_/0l *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 iu,}+eZ>\Sqve*u09(o%IhQ}p>[ƈfڭ9J` +р<ĖmA3&\V Jj9j|?_0lH /Wx|B{c|EḋxŗJ14^DpOzdMaY\U)Dhbol⯒ZX)[`_K6\uE#P+Qz}o#a%NB $ކ2kc>1 @Ԉha_'R涹0>wx Aϲmq-xl?] yf_{6fXC7|^S&5N eÆQΉ{U /i 8mUB&ϛ,MS zv]{ki!~) R/+beG|xu;CVp: H=@P S`[f'8obΎX6tH-8Sy2W͘`ob9ma3AHBS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?542C7903.3010906>