Installing amd64 FreeBSD 11.1 in dual-boot with Windows 7 on an MBR partitioned disk

[Karl Denninger]

On 10/7/2017 11:27, Rostislav Krasny wrote:
> On Sat, Oct 7, 2017 at 6:26 PM, Warner Losh <imp at bsdimp.com> wrote:
>> Sorry for top posting. Sounds like your BIOS will read the botox64.efi from
>> the removable USB drive, but won't from the hard drive. Force BIOS booting
>> instead of UEFI and it will install correctly. However, it may not boot
>> Windows, which I think requires UEFI these days.
>>
>> The root of the problem is that we have no way to setup the EFI boot
>> variables in the installer that we need to properly installed under UEFI.
>> I'm working on that, so you'll need to be patient...
>>
>> Warner
> My computer doesn't have any EFI partition and this explains why the
> installed FreeBSD boots in the BIOS mode on it. The installation media
> probably has the EFI partition (with the bootx64.efi) and then BIOS
> probably boots the installation media in the UEFI mode instead of the
> BIOS mode. So the "machdep.bootmethod" sysctl doesn't represent the
> BIOS boot mode configuration but a boot method the currently running
> system was booted in. If this is true then the "machdep.bootmethod"
> sysctl should not be used in bsdinstall. At least not for the
> bootability check. Something else should be used for the bootability
> check or the bsdinstall should trust the user choice.
>
> BTW this is how the EFI partition looks like in someone's Windows 7
> disk manager:
> https://www.easyuefi.com/wintousb/images/en_US/efi-system-partition.png
> and this how it looks without any EFI partition in my system (with
> Windows 7 / FreeBSD dual-boot)
> http://i68.tinypic.com/9u19b8.png
>
> I think even that NTFS System Reserved partition is not mandatory for
> Windows installation. It just used to keep Windows boot files in a
> safe, place preventing accidental deletion by a user. It's being
> created if Windows is installed on an empty disk but if you create
> just one big NTFS partition prior to the Windows installation and
> install it on that single partition it will be ok. There will be just
> more Windows system files on the C disk, for example ntldr,
> NTDETECT.COM. It can be checked on VM, for example on VirtualBox.
> _______________________________________________
The problem with the new installer appears to be that it follows this
heuristic when you boot FreeBSD media from a USB stick or similar media:

1. If the system CAN boot EFI then it WILL EFI boot the FreeBSD
installer from that media.

2. The installer sees that it booted from EFI.  It also sees a fixed
disk with a non-EFI boot environment.  It declares that fixed disk
environment "non-bootable", which is not by any means a known fact.

3. Having done that it will then "offer" to re-initialize the disk as
EFI/GPT, which is ok if you don't have anything else on there that you
want.  If you DO then it's obviously not ok, and in that instance it
both won't load the MBR boot manager *and* won't load the second-stage
MBR boot code either.

You can get around this by hand-installing both parts of the boot code,
which is what I wound up doing on my Lenovo laptop.  That machine was
originally delivered with Windows 7 and upgraded "in place" to Win10,
which is why the disk is MBR-partitioned rather than EFI/GPT, although
the machine itself does support EFI booting.

I would suggest that the FreeBSD installer should be more-intelligent
about this, but I suspect it's a fairly uncommon set of circumstances. 
Far more troublesome in the EFI world is the fact that "out-of-the-box"
multi-boot in an EFI environment is a five-alarm pain in the butt
although there are EFI boot managers that make it reasonable.

-- 
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/20171007/001021fc/attachment.bin>