Not sure if this is the correct place.... (laptop, dual-boot EFI)

Karl Denninger karl at denninger.net
Sun Jan 27 18:51:58 UTC 2019


Here's a write-up on it -- it was /much /simpler than I expected and
unlike my X220 didn't require screwing with group policy for Bitlocker
to coexist with a dual-boot environment.

https://market-ticker.org/akcs-www?post=234936

Feel free to grab/reproduce/link to/whatever; hope this helps others. 
It runs very nicely on 12-RELEASE -- the only thing I've noted thus far
is the expected lack of 5g WiFi support.

On 1/26/2019 15:04, Karl Denninger wrote:
> Nevermind!
>
> I set the "-g" flag on the provider and.... voila.  Up she comes; the
> loader figured out that it had to prompt for the password and it was
> immediately good.
>
> Now THAT'S easy compared with the convoluted BS I had to do (two
> partitions, fully "by-hand" install, etc) for 11 on my X220.
>
> Off to the races I go; now I have to figure out what I have to set in
> Windows group policy so Bitlocker doesn't throw up every time I boot
> FreeBSD (this took a bit with my X220 since the boot manager tickled
> something that Bitlocker interpreted as "someone tampered with the
> system.")  Maybe this will be a nothingburger too (which would be great
> if true.)
>
> I'm going to write this one up when I've got it all solid and post it on
> my blog; hopefully it will help others.
>
> On 1/26/2019 14:26, Karl Denninger wrote:
>>  1/26/2019 14:10, Warner Losh wrote:
>>> On Sat, Jan 26, 2019 at 1:01 PM Karl Denninger <karl at denninger.net
>>> <mailto:karl at denninger.net>> wrote:
>>>
>>>     Further question....  does boot1.efi (which I assume has to be
>>>     placed on
>>>     the EFI partition and then something like rEFInd can select it)
>>>     know how
>>>     to handle a geli-encrypted primary partition (e.g. for root/boot so I
>>>     don't need an unencrypted /boot partition), and if so how do I tell it
>>>     that's the case and to prompt for the password?
>>>
>>>
>>> Not really. The whole reason we ditched boot1.efi is because it is
>>> quite limited in what it can do. You must loader.efi for that.
>>>  
>>>
>>>     (If not I know how to set up for geli-encryption using a non-encrypted
>>>     /boot partition, but my understanding is that for 12 the loader was
>>>     taught how to handle geli internally and thus you can now install
>>>     12 --
>>>     at least for ZFS -- with encryption on root.  However, that wipes the
>>>     disk if you try to select it in the installer, so that's no good
>>>     -- and
>>>     besides, on a laptop zfs is overkill.)
>>>
>>>
>>> For MBR stuff, yes. For loader.efi, yes. For boot1.efi, no: it did not
>>> and will not grow that functionality.
>>>
>>> Warner
>>>  
>> Ok, next dumb question -- can I put loader.efi in the EFI partition
>> under EFI/FreeBSD as "bootx64.efi" there (from reading mailing list
>> archives that appears to be yes -- just copy it in) and, if yes, how do
>> I "tell" it that when it finds the freebsd-ufs partition on the disk it
>> was started from (which, if I'm reading correctly, it will scan and look
>> for) that it needs to geli attach the partition before it dig into there
>> and find the rest of what it needs to boot?
>>
>> That SHOULD allow me to use an EFI boot manager to come up on initial
>> boot, select FreeBSD and the loader.efi (named as bootx64.efi in
>> EFI/FreeBSD) code will then boot the system.
>>
>> I've looked as the 12-RELEASE man page(s) and it's not obvious how you
>> tell the loader to look for the partition and then attach it via GELI
>> (prompting for the password of course) before attempting to boot it;
>> obviously a "load" directive (e.g. geom_eli_load ="YES") makes no sense
>> as the thing you'd "load" is on the disk you'd be loading it from and
>> its encrypted.. .never mind that loader.conf violates the 8.3 filename
>> rules for a DOS filesystem.
>>
>> Thanks!
>>
-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20190127/7d378204/attachment.bin>


More information about the freebsd-stable mailing list