Rostislav Krasny
2017-Oct-07 15:03 UTC
Installing amd64 FreeBSD 11.1 in dual-boot with Windows 7 on an MBR partitioned disk
On Fri, Oct 6, 2017 at 8:33 PM, Eugene Grosbein <eugen at 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
2017-Oct-07 15:26 UTC
Installing amd64 FreeBSD 11.1 in dual-boot with Windows 7 on an MBR partitioned disk
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 <rosti.bsd at gmail.com> wrote:> On Fri, Oct 6, 2017 at 8:33 PM, Eugene Grosbein <eugen at 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? > _______________________________________________ > freebsd-stable at freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org" >