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

[Rostislav Krasny]

Hi there,

I try to install amd64 FreeBSD 11.1 in dual-boot with Windows 7 on an
MBR partitioned disk and I can't make it bootable. My Windows 7 uses
its standard MBR partitioning scheme (1. 100MB System Reserved
Partition; 2 - 127GB disk C partition) and there is about 112GB of
free unallocated disk space that I want to use to install FreeBSD on
it. As an installation media I use the
FreeBSD-11.1-RELEASE-amd64-mini-memstick.img flashed on a USB drive.

During the installation, if I choose to use Guided Partitioning Tool
and automatic partitioning of the free space, I get a pop-up message
that says:

======
The existing partition scheme on this disk
(MBR) is not bootable on this platform. To
install FreeBSD, it must be repartitioned.
This will destroy all data on the disk.
Are you sure you want to proceed?
[Yes] [No]
======

If instead of the Guided Partitioning Tool I choose to partition the
disk manually I get a similar message as a warning and the
installation process continues without an error, but the installed
FreeBSD system is not bootable. Installing boot0 manually (boot0cfg
-Bv /dev/ada0) doesn't fix it. The boot0 boot loader is able to boot
Windows but it's unable to start the FreeBSD boot process. It only
prints hash symbols when I press F3 (the FreeBSD slice/MBR partition
number).

I consider this as a critical bug. But maybe there is some workaround
that allows me to install the FreeBSD 11.1 as a second OS without
repartitioning the entire disk?

My hardware is an Intel Core i7 4790 3.6GHz based machine with 16GB
RAM. The ada0 disk is 238GB SanDisk SD8SBAT256G1122 (SSD).
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"

[Karl Denninger]

You have to do the partitioning and then install FreeBSD's boot manager
by hand.  It /does /work; I ran into the same thing with my Lenovo X220
and was able to manually install it, which works fine to dual-boot
between Windows and FreeBSD-11.  I had to do it manually because the
installer detected that the X220 was UEFI capable and insisted on
GPT-partitioning the disk, which is incompatible with dual-boot and the
existing MBR-partitioned Windows installation.

You want the partition layout to look like this:

$ gpart show
=>       63  500118129  ada0  MBR  (238G)
         63    4208967     1  ntfs  (2.0G)
    4209030  307481727     2  ntfs  (147G)
  311690757          3        - free -  (1.5K)
  311690760  165675008     3  freebsd  [active]  (79G)
  477365768     808957        - free -  (395M)
  478174725   21928725     4  ntfs  (10G)
  500103450      14742        - free -  (7.2M)

=>        0  165675008  ada0s3  BSD  (79G)
          0    8388608       1  freebsd-ufs  (4.0G)
    8388608  136314880       2  freebsd-ufs  (65G)
  144703488   20971519       4  freebsd-swap  (10G)
  165675007          1          - free -  (512B)

MBR has only four partitions; the "standard" Windows (7+) install uses
/three. /The "boot"/repair area, the main partition and, on most
machines, a "recovery" partition.  That usually leaves partition 3 free
which is where I stuck FreeBSD.   Note that you must then set up slices
on Partition 3 (e.g. root/usr/swap) as usual.

--
Karl Denninger
ka...@denninger.net <mailto:ka...@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

[Karl Denninger]

BTW if you're getting the "#" when you hit the partition key that means
the /second stage /boot loader is /not /on the partition you selected;
the bootmanager can't find it.  This can be manually installed with:

# gpart bootcode -b /boot/boot ada0s3

"s3" is the partition in question upon which you created the BSD-labeled
structure.

One thing to be aware of is that you must adjust Windows group policy if
you intend to use Bitlocker, or it will declare the disk structure
changed and refuse to take your key (demanding the recovery key)
whenever the FreeBSD boot manager changes the active "next boot" flag. 
By default /any /change in the boot structure will set off Bitlocker;
you can relax it to not get so cranked, but you need to do so /before
/encrypting the partition under Windows.

I run GELI encryption on the FreeBSD partition which is why I have a
separate (small) boot filesystem; that too has to be manually set up for
an installation like this using MBR.  It works well.

[Eugene Grosbein]

06.10.2017 22:17, Rostislav Krasny wrote:

> I consider this as a critical bug. But maybe there is some workaround
> that allows me to install the FreeBSD 11.1 as a second OS without
> repartitioning the entire disk?
>
> My hardware is an Intel Core i7 4790 3.6GHz based machine with 16GB
> RAM. The ada0 disk is 238GB SanDisk SD8SBAT256G1122 (SSD).

bsdinstall (current installer) is seriously flawed comparing with sysinstall (previous one)
when we talk about installing FreeBSD to a slice within MBR.

You still can install FreeBSD by invoking a shell from bsdinstall
and using gpart:

gpart add -t freebsd -a 4096 ada0 # dedicate all unallocated space for ada0s3
gpart create -s BSD -n 20 ada0s3 # create BSD label able to contain upto 20 partitions
gpart bootcode -b /boot/boot0 ada0 # install menu-driven boot manager BootEasy to MBR
gpart bootcode -b /boot/boot ada0s3 # install FreeBSD-specific UFS boot code to its slice
gpart set -a active -i 1 ada0 # make sure MBR has exactly one active partition
gpart add -t freebsd-swap -s 4G -i 2 # allocate 4G for a swap ada0s3b (choose size of your like)
gpart add -t freebsd-ufs -s 2G # allocate 2G for root partition ada0s3a
newfs -L root /dev/ada0s3a
gpart add -t freebsd-ufs -s 1G # allocate 1G for read-only /usr partition ada0s3d
newfs -L usr /dev/ada0s3d
gpart add -t freebsd-ufs -s 4G # allocate 4G for /var ada0s3e
newfs -L var /dev/ada0s3e
gpart add -t freebsd-ufs -s 10G # allocate 10G /usr/local: future installed ports & packages
newfs -L usrl /dev/ada0s3f
gpart add -t freebsd-ufs # allocate all other space for /home
newfs -L home /dev/ada0s3g

Then you will have mount new ada0s3a, create mount points for other partitions there,
create etc/fstab, extract *.txz from distibution media and it will boot just fine.

[Nenhum_de_Nos]

On Fri, October 6, 2017 14:33, Eugene Grosbein wrote:
> 06.10.2017 22:17, Rostislav Krasny wrote:
>
>> I consider this as a critical bug. But maybe there is some workaround
>> that allows me to install the FreeBSD 11.1 as a second OS without
>> repartitioning the entire disk?
>>
>> My hardware is an Intel Core i7 4790 3.6GHz based machine with 16GB
>> RAM. The ada0 disk is 238GB SanDisk SD8SBAT256G1122 (SSD).
>
> bsdinstall (current installer) is seriously flawed comparing with
> sysinstall (previous one)
> when we talk about installing FreeBSD to a slice within MBR.

I sure miss sysinstall from the very bottom of my heart.

I had the very same problem the OP said, about a month ago. I just didn't
got the issue, so I installed 10.3-R and did upgrade via freebsd-update.

The OP setup is close to mine, I will try to use the command list below
and see what it gets me. It was really disappointing not being able to
install 11.1 on this new machine. I am saving a 10.3R pendrive forever. If
anyone need, just say I upload the dd'ed image :)

I also tested on another older machine, same thing.

matheus

--
"We will call you Cygnus,
the God of balance you shall be."

[Nenhum_de_Nos]

On Fri, October 6, 2017 18:13, Nenhum_de_Nos wrote:
>
> On Fri, October 6, 2017 14:33, Eugene Grosbein wrote:
>> 06.10.2017 22:17, Rostislav Krasny wrote:
>>
>>> I consider this as a critical bug. But maybe there is some workaround
>>> that allows me to install the FreeBSD 11.1 as a second OS without
>>> repartitioning the entire disk?
>>>
>>> My hardware is an Intel Core i7 4790 3.6GHz based machine with 16GB
>>> RAM. The ada0 disk is 238GB SanDisk SD8SBAT256G1122 (SSD).
>>
>> bsdinstall (current installer) is seriously flawed comparing with
>> sysinstall (previous one)
>> when we talk about installing FreeBSD to a slice within MBR.
>
> I sure miss sysinstall from the very bottom of my heart.
>
> I had the very same problem the OP said, about a month ago. I just didn't
> got the issue, so I installed 10.3-R and did upgrade via freebsd-update.
>
> The OP setup is close to mine, I will try to use the command list below
> and see what it gets me. It was really disappointing not being able to
> install 11.1 on this new machine. I am saving a 10.3R pendrive forever. If
> anyone need, just say I upload the dd'ed image :)
>
> I also tested on another older machine, same thing.
>
> matheus

For the OP, try reading here
https://forums.freebsd.org/threads/62030/#post-358133

No solition so far :(

[Rostislav Krasny]

On Fri, Oct 6, 2017 at 8:33 PM, Eugene Grosbein <eu...@grosbein.net> wrote:
> 06.10.2017 22:17, Rostislav Krasny wrote:
>
>> I consider this as a critical bug. But maybe there is some workaround
>> that allows me to install the FreeBSD 11.1 as a second OS without
>> repartitioning the entire disk?
>>
>> My hardware is an Intel Core i7 4790 3.6GHz based machine with 16GB
>> RAM. The ada0 disk is 238GB SanDisk SD8SBAT256G1122 (SSD).
>
> bsdinstall (current installer) is seriously flawed comparing with sysinstall (previous one)
> when we talk about installing FreeBSD to a slice within MBR.

I think the bug is somewhere in the following code taken from partedit_x86.c
https://svnweb.freebsd.org/base/release/11.1.0/usr.sbin/bsdinstall/partedit/partedit_x86.c?revision=321354&view=co
or in the code that fills the "machdep.bootmethod" sysctl

static const char *
x86_bootmethod(void)
{
static char fw[255] = "";
size_t len = sizeof(fw);
int error;

if (strlen(fw) == 0) {
error = sysctlbyname("machdep.bootmethod", fw, &len, NULL, -1);
if (error != 0)
return ("BIOS");
}

return (fw);
}

int
is_scheme_bootable(const char *part_type)
{

if (strcmp(part_type, "GPT") == 0)
return (1);
if (strcmp(x86_bootmethod(), "BIOS") == 0) {
if (strcmp(part_type, "BSD") == 0)
return (1);
if (strcmp(part_type, "MBR") == 0)
return (1);
}

return (0);
}

I've checked and found following:
If booted from the installation media (USB drive) the
"machdep.bootmethod" is UEFI.
If booted from the already installed and updated 11.1-RELEASE-p1
system the "machdep.bootmethod" is BIOS.

This explains why I got that "is not bootable on this platform" error
message and similar warning (in case of manual partitioning). In my
case the part_type is "MBR" and the x86_bootmethod() returns "UEFI",
so is_scheme_bootable() returns 0 and triggers the bug.

I also made a screenshot of my BIOS boot mode configuration:
http://i63.tinypic.com/k3g2v.jpg
As you can see the legacy boot mode is enabled and the secure boot
mode is disabled.

If the machdep.bootmethod made to represent the BIOS configuration
then it's value seems to be wrong.
If it represents something else it should not be used in the above and
probably in other bsdinstall code.

> You still can install FreeBSD by invoking a shell from bsdinstall
> and using gpart:
>
> gpart add -t freebsd -a 4096 ada0 # dedicate all unallocated space for ada0s3
> gpart create -s BSD -n 20 ada0s3 # create BSD label able to contain upto 20 partitions
> gpart bootcode -b /boot/boot0 ada0 # install menu-driven boot manager BootEasy to MBR
> gpart bootcode -b /boot/boot ada0s3 # install FreeBSD-specific UFS boot code to its slice
> gpart set -a active -i 1 ada0 # make sure MBR has exactly one active partition
> gpart add -t freebsd-swap -s 4G -i 2 # allocate 4G for a swap ada0s3b (choose size of your like)
> gpart add -t freebsd-ufs -s 2G # allocate 2G for root partition ada0s3a
> newfs -L root /dev/ada0s3a
> gpart add -t freebsd-ufs -s 1G # allocate 1G for read-only /usr partition ada0s3d
> newfs -L usr /dev/ada0s3d
> gpart add -t freebsd-ufs -s 4G # allocate 4G for /var ada0s3e
> newfs -L var /dev/ada0s3e
> gpart add -t freebsd-ufs -s 10G # allocate 10G /usr/local: future installed ports & packages
> newfs -L usrl /dev/ada0s3f
> gpart add -t freebsd-ufs # allocate all other space for /home
> newfs -L home /dev/ada0s3g
>
> Then you will have mount new ada0s3a, create mount points for other partitions there,
> create etc/fstab, extract *.txz from distibution media and it will boot just fine.

This commands list is too long to be run manually during the
installation and without any web/email access. I've just installed
FreeBSD again using the manual partitioning (ignored the warning
message) and then I ran two following commands:

boo0cfg -Bv /dev/ada0

gpart bootcode -b /boot/boot ada0s3

This made my FreeBSD 11.1 system bootable. The only issue now is a low
console resolution. When I boot from the installation media (the USB
drive) the console resolution is high/native already at the boot
loader/menu stage. When I boot the installed system the console
resolution is low. I compared /boot/loader.conf of both and didn't
find much difference. In the installation media it has just one line
that defines some timeout and in the installed system it's empty. How
can I fix the console resolution issue? How the installation media
does it?

[Warner Losh]

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


On Sat, Oct 7, 2017 at 8:03 AM, Rostislav Krasny <rost...@gmail.com>
wrote:

[Rostislav Krasny]

On Sat, Oct 7, 2017 at 6:26 PM, Warner Losh <i...@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.

[Karl Denninger]

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.

[Eugene Grosbein]

07.10.2017 22:26, Warner Losh 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.

My home desktop is UEFI-capable and but switched to BIOS/MBR mode
and it dual-boots FreeBSD/Windows 8.1 just fine.

[Karl Denninger]

On 10/7/2017 12:12, Eugene Grosbein wrote:
> 07.10.2017 22:26, Warner Losh 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.
> My home desktop is UEFI-capable and but switched to BIOS/MBR mode
> and it dual-boots FreeBSD/Windows 8.1 just fine.

Windows (including Windows 10) doesn't "require" UEFI but the current
installer will set it up that way on a "from scratch" installation.  If
you have it on an MBR disk (e.g. you started with 7 or 8, for example)
it will boot and run just fine from it, and in fact if you have a legacy
license and try to change to UEFI (with a full, from-scratch reload) you
run the risk of it declaring your license invalid!  You can /probably
/get around that by getting in touch with Microsoft but why do so
without good reason?