Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Oct 2017 18:03:48 +0300
From:      Rostislav Krasny <rosti.bsd@gmail.com>
To:        Eugene Grosbein <eugen@grosbein.net>
Cc:        freebsd-stable <freebsd-stable@freebsd.org>
Subject:   Re: Installing amd64 FreeBSD 11.1 in dual-boot with Windows 7 on an MBR partitioned disk
Message-ID:  <CANt7McEUP1MC32zJt0%2BbOi-1A6FFXr-C2D6ibKB5gZKr5xWEyQ@mail.gmail.com>
In-Reply-To: <59D7BE53.5050409@grosbein.net>
References:  <CANt7McGqZG0mJFmuQgE4_rFu_0kmnyUCUCZyrrThKMjJtnyewA@mail.gmail.com> <59D7BE53.5050409@grosbein.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 6, 2017 at 8:33 PM, Eugene Grosbein <eugen@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?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANt7McEUP1MC32zJt0%2BbOi-1A6FFXr-C2D6ibKB5gZKr5xWEyQ>