Date: Sun, 12 Jan 2020 11:18:26 -0600 From: Karl Denninger <karl@denninger.net> To: freebsd-questions@freebsd.org Subject: Re: Using GELI on boot disk with GPT labels? Message-ID: <769689a9-ad6a-8b07-a03f-4986d2990aca@denninger.net> In-Reply-To: <e07b4997-f285-153b-01d3-097c94d08ebf@hashbang0.com> References: <e07b4997-f285-153b-01d3-097c94d08ebf@hashbang0.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 1/12/2020 10:30, Ben Lavery wrote: > Hi all, > > I've recently bought my first home server and am planning to run > FreeBSD 12.1-RELEASE on it. > > I would like to GELI encrypt (password based) all of the hard drives I > put into the server so that if/when they fail I can safely and > confidently dispose of them. > > When setting up the server, I followed a number of recommendations to > use GPT labels for disks with a naming scheme that would allow me to > easily identify where failed disks physically are in the server (there > are 12 bays). > However, when I booted up the server after installing on an installer > configured zpool with GELI encryption, I noted that the disk IDs (e.g. > da0p3) was being used, and this seemed to extend to disks in different > (non-root) zpools. > > I decided to do an experiment in VirtualBox with FreeBSD 12.1-RELEASE: > > 1. To install FreeBSD on ZFS with GELI encryption > https://gist.github.com/forquare/b4e12938b1240238ef64e3d6ba5d9669 > > 2. To install FreeBSD on ZFS without GELI > https://gist.github.com/forquare/8049282d742c94b67f08a81d828e8d13 > > (Links above show commands + output/details of installation) > > I found that when I didn't use GELI I was able to use GPT labels, > however when I _did_ use GELI GPT labels were not available to me. > > Is there a way to encrypt my boot pool _and_ use GPT labels? > If not, I would be interested to learn why. > > Many thanks, > Ben > The boot pool volumes typically come up as "/dev/da.....eli"; the other pools, which you name in (for example) geli_groups="system" geli_system_devices="gpt/rust1-1 gpt/rust1-2 gpt/rust2-1 gpt/rust2-2 gpt/rust3-1 gpt/rust3-2" geli_autodetach="YES" do not, since those are named explicitly and looked for after the kernel is loaded. I presume this is a function of how gptzfsboot enumerates the disks and finds the "boot" flag since that's where that happens and attaches them under geli. Not sure if you can get it to "dig inside a GPT disk" and find the labels or not. -- Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ [-- Attachment #2 --] 0 *H 010 `He 0 *H 00 H^Ōc!5 H0 *H 01 0 UUS10U Florida10U Niceville10U Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA0 170817164217Z 270815164217Z0{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA0"0 *H 0 h-5B>[;olӴ0~͎O9}9Ye*$ g !ukvʶLzN`jL>MD'7U 45CB+kY`bd~b*c3Ny-78ju]9H euέsӬDؽmgwER?&UURj'}9nWD i`XcbGz \gG=u%\Oi13ߝ4 K44pYQr]Ie/r0+eEޝݖ0C15Mݚ@JSZ(zȏ NTa(25DD5.l<g[[Z arQQ%Buȴ~~`IohRbʳڟu2MS8EdFUClCMaѳ !}ș+2k/bųE,n当ꖛ\(8 WV8 d]b yXw ܊:I39 00 U ]^§Q\ӎ0U #0T039N0b01 0 UUS10U Florida10U Niceville10U Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA @Ui0U 0 0U 0 *H :P U!>vJ n io -#ן]Wyu jǑR̀Q nƇ!G ѦF g\ yLx gw=OPycehf[ }ܷ['4ڝ\[p 6\o.B&JF" ZC{;*o*mcCcLY߾` t*S!(` ]DHP5A~/NPp6=mhk밣'doA$86hm5ӚS@ j ެEgl )0JG`%k35PaC?σ ׳HEt}!P㏏%*BxbQwaKG$6 h¦Mve; [o-Iی& I,Tc ߎ#t wPA@l0P+KXBպT zGv;NcI3&J ĬUPNa?/%W6G۟N000 k#Xd\ =0 *H 0{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA0 170817212120Z 220816212120Z0W1 0 UUS10U Florida10U Cuda Systems LLC10U karl@denninger.net0"0 *H 0 T[I-ΆϏ dn;Å@שy.us~_ZG%<MYd\gvfnsa1'6Egyjs"C [{~ _K Pn+<*pv#Q+H/7[-vqDV^U>f%GX)H.|l`M(Cr >е͇6#odc"YljҦln8@5SA0&ۖ"OGj?UDWZ5 dDB 7k-)9Izs-JAv J 6L$Ն1SmY.Lqw*SH;EF'DĦH]MOgQQ|Mٙג2Z9y@ y]}6ٽeY9Y2xˆ$T=e CǺǵbn֛{j |@LLt1[Dk5:$= ` M 00<+00.0,+0 http://ocsp.cudasystems.net:88880 U 0 0 `HB0U 0 U %0++03 `HB &$OpenSSL Generated Client Certificate0 U %՞V =;bzQ0U #0]^§Q\ӎϡ01 0 UUS10U Florida10U Niceville10U Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA H^Ōc!5 H0 U 0karl@denninger.net0 *H ۠A0-j%--$% g2#ޡ1^>{K+uGE v1ş7Af&b&O; .;A5* U)ND2bF|\= ]<sˋL!wrw٧> YMÄ3\mWR hSv!_zvl? 3_ xU%\^#O*Gk̍YI_&Fꊛ@&1n } ͬ:{hTP3B.;bU8:Z=^Gw8 !k-@xE@i,+'Iᐚ:f hztX7/(hY` O.1}a`%RW^akǂpCAufgDix UTЩ/7}%=jnVZvcF<M= 2^GKH5魉 _O4ެByʈySkw=5@h.0z> W1000{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0 `He E0 *H 1 *H 0 *H 1 200112171826Z0O *H 1B@1 Tp 3yj˓Y.ڙsa5UU GƱ=?5G0l *H 1_0]0 `He*0 `He0 *H 0*H 0 *H @0+0 *H (0 +7100{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0 *H 10{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0 *H #\41No: SjG56)x^ӧqj\ΓϒTSze.e#B;xXz[ɑei)jtڊĩJU}Z$[L~woLBX(ZIDe/= 똁j3q-)WC λ2~7 WڭB dycU5y8߁ZFn0{)b|RdؾyD%S߉sv{J)x}xf·c B,HU6ZxcjLNȌ+Gkl;R V _& >tt7=\(GǘĦ'wZ0MUZt4$&+A4 % n\f,8;,m)3Sli}ŽU xkE[ <'f)Rg Q@zuW:kugE7dmu=@,Ȑ'M7mtzju.IH_'+Ǫ'd|U;,;z^; #/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?769689a9-ad6a-8b07-a03f-4986d2990aca>