multibooting OpenBSD 4.4 through Vista's boot manager

[ocicat]

I previously posted an earlier version of this guide on BSDForums. There, the focus had been on OpenBSD 4.0, but nothing has changed with subsequent releases of OpenBSD. I am currently using the same information with OpenBSD 4.5-beta, & I don't expect anything to change in the near future (although Windows 7 may be another story...). Nevertheless, users should back up sensitive data before proceeding if losing any is an unbearable outcome.

The official OpenBSD FAQ provides information on how to multiboot OpenBSD 4.4 using the boot manager found in Windows NT/2000/XP, but Vista no longer uses the boot.ini file of old. So, scouring the Internet ensued to find the incantation needed to boot OpenBSD via Vista's boot manager.

Microsoft has moved boot information into Boot Configuration Data (BCD), and provides the bcdedit command-line utility to fully manage this database. There are still a few duplicated features controlling multibooting found in the Systems applet GUI (Start | Control Panel | System and Maintenance | System | Advanced system settings | Advanced tab | Startup and Recovery Settings | System startup), but adding new BCD entries can only be done from the command-line.

Those familiar with earlier versions of Windows (but unfamiliar with UAC...) will undoubtedly be surprised when they try to invoke bcdedit from the command-line after logging in as an Administrator:

C:\Windows\System32>bcdedit
The boot configuration data store could not be opened.
Access is denied.

C:\Windows\System32>

In Microsoft's effort to enhance security, Vista implements stricter authority through User Access Control (UAC). Although applications may be run from an Administrator account, applications still actually run with normal user rights. To truly run bcdedit with Administrator credentials requires cmd.exe also be explicitly run with Administrator credentials. Right click on the Command Prompt icon (Start | All Programs | Accessories | Command Prompt), or open the Start window and type cmd. When the search facility shows the application's icon, right click it and select Run as administrator from the local menu.

UAC can be disabled, but this defeats the purpose of UAC's security features.

Running bcdedit with no arguments provides an overview of the BCD database:

C:\Windows\system32>bcdedit

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=C:
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {default}
resumeobject            {f4bad82f-d5dc-11db-b83c-fff6129dfa33}
displayorder            {default}
                        {current}
toolsdisplayorder       {memdiag}
timeout                 10
customactions           0x10000ba000001
                        0x54000001
custom:54000001         {572bcd55-ffa7-11d9-aae0-0007e994107d}

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Microsoft Windows Vista
locale                  en-US
inherit                 {bootloadersettings}
osdevice                partition=C:
systemroot              \Windows
resumeobject            {f4bad82f-d5dc-11db-b83c-fff6129dfa33}
nx                      OptIn

C:\Windows\system32>

To view the plethora of functions bcdedit performs, append the /? switch:

C:\Windows\system32>bcdedit /?

BCDEDIT - Boot Configuration Data Store Editor

The Bcdedit.exe command-line tool modifies the boot configuration data store.
The boot configuration data store contains boot configuration parameters and
controls how the operating system is booted. These parameters were previously
in the Boot.ini file (in BIOS-based operating systems) or in the nonvolatile
RAM entries (in Extensible Firmware Interface-based operating systems). You can
use Bcdedit.exe to add, delete, edit, and append entries in the boot
configuration data store.

For detailed command and option information, type bcdedit.exe /? <command>. For
example, to display detailed information about the /createstore command, type:

     bcdedit.exe /? /createstore

For an alphabetical list of topics in this help file, run "bcdedit /? TOPICS".

Commands that operate on a store
================================
/createstore    Creates a new and empty boot configuration data store.
/export         Exports the contents of the system store to a file. This file
                can be used later to restore the state of the system store.
/import         Restores the state of the system store using a backup file
                created with the /export command.

Commands that operate on entries in a store
===========================================
/copy           Makes copies of entries in the store.
/create         Creates new entries in the store.
/delete         Deletes entries from the store.

Run bcdedit /? ID for information about identifiers used by these commands.

Commands that operate on entry options
======================================
/deletevalue    Deletes entry options from the store.
/set            Sets entry option values in the store.

Run bcdedit /? TYPES for a list of datatypes used by these commands.
Run bcdedit /? FORMATS for a list of valid data formats.

Commands that control output
============================
/enum           Lists entries in the store.
/v              Command-line option that displays entry identifiers in full,
                rather than using names for well-known identifiers.
                Use /v by itself as a command to display entry identifiers
                in full for the ACTIVE type.

Running "bcdedit" by itself is equivalent to running "bcdedit /enum ACTIVE".

Commands that control the boot manager
======================================
/bootsequence   Sets the one-time boot sequence for the boot manager.
/default        Sets the default entry that the boot manager will use.
/displayorder   Sets the order in which the boot manager displays the
                multiboot menu.
/timeout        Sets the boot manager time-out value.
/toolsdisplayorder  Sets the order in which the boot manager displays
                    the tools menu.

Commands that control Emergency Management Services for a boot application
==========================================================================
/bootems        Enables or disables Emergency Management Services
                for a boot application.
/ems            Enables or disables Emergency Management Services for an
                operating system entry.
/emssettings    Sets the global Emergency Management Services parameters.

Command that control debugging
==============================
/bootdebug      Enables or disables boot debugging for a boot application.
/dbgsettings    Sets the global debugger parameters.
/debug          Enables or disables kernel debugging for an operating system
                entry.


C:\Windows\system32>

Providing a full tutorial on using bcdedit is beyond the scope of this document, however, understanding some of its capabilities is necessary given that this is now the interface for generating Vista boot manager configurations. Nominal study of bcdedit's capability may help diagnose problems also not foreseen by this document. Readers wanting or needing more information should search Microsoft's site for more information. One source can be found at the following:

http://technet.microsoft.com/en-us/l.../cc709667.aspx

The official OpenBSD FAQ describes what is needed to copy OpenBSD's PBR to a file:

http://openbsd.org/faq/faq4.html#Multibooting

...and this is no different when using Vista. Even if Microsoft has enhanced the boot manager interface, the basic process of booting through the MBR (Master Boot Record) has not fundamentally changed. It is still necessary to provide enough information to the boot manager to load OpenBSD's kernel into memory from its appropriate partition.

The remainder of this document will be tagged with "MANDATORY" & "SUPPLEMENTARY" as some steps are necessary while others are provided for to show additional functionality.

• MANDATORY: Once the PBR has been generated, transfer it to Vista's system partition.
• MANDATORY: Next, BCD has to be instructed to create a new boot entry/Registry subhive:

C:\Windows\system32>bcdedit /create /d "OpenBSD/i386 4.5" /application bootsector
The entry {05a763ce-d81b-11db-b3ec-000000000000} was successfully created.

C:\Windows\System32>

Note that creating a new boot manager entry returns a GUID representing a new Registry subhive. Be forewarned that this value is unique (based on the hard drive used...), so do not copy the GUID value shown above; this is provided simply for illustrative purposes. Because bcdedit identifies this new boot manager entry through the returned GUID, mark and paste the GUID for easier retrieval. It will be used several more times.

• SUPPLEMENTARY: For those wanting more context, look at what help bcdedit provides for the create option:

C:\Windows\system32>bcdedit /? create

This command creates a new entry in the boot configuration data store. If
a well-known identifier is specified, then the /application, /inherit and
/device options cannot be specified. If the <id> is not specified,
or if <id>is not well-known, then you must specify an /application, /inherit
or /device option.

bcdedit /create [{<id>}] /d <description> [-application <apptype> |
    /inherit [<apptype>] | /inherit DEVICE | /device]

    <id>                    Specifies the identifier to be used for the new
                            entry. For more information about identifiers, run
                            "bcdedit /? ID".

    <description>           Specifies the description to be applied to the new
                            entry.

    /application <apptype>  Specifies that the new entry must be an application
                            entry. <apptype> specifies the application type.
                            <apptype> can be one of the following:

                                BOOTSECTOR
                                OSLOADER
                                RESUME
                                STARTUP

                            If you use other application types instead of
                            one of these, you must also specify a well-known
                            identifier.

    /inherit [<apptype>]    Specifies that the new entry must be an inherit
                            entry, and <apptype> specifies the application
                            type. If <apptype> is not specified, then the entry
                            can be inherited by any entry. If specified,
                            <apptype> can be one of the following:

                                BOOTMGR
                                BOOTSECTOR
                                FWBOOTMGR
                                MEMDIAG
                                NTLDR
                                OSLOADER
                                RESUME

                            The modifier prevents the inherit entry from being
                            inherited by an application entry of <apptype>.

    /inherit DEVICE         Specifies that the new entry must be an inherit
                            entry, and that the entry can only be inherited by
                            a device options entry.

    /device                 Specifies that the new entry must be an additional
                            device options entry.

Examples:

The following command creates a NTLDR based OS loader entry (Ntldr):

    bcdedit /create {ntldr} /d "Earlier Windows OS Loader"

The following command creates a RAM disk additional options entry:

    bcdedit /create {ramdiskoptions} /d "Ramdisk options"

The following command creates a new operating system boot entry:

    bcdedit /create /d "Windows Vista" /application osloader

The following command creates a new debugger settings entry:

    bcdedit /create {dbgsettings} /d "Debugger Settings"

C:\Windows\system32>

• MANDATORY: Mark the new BCD entry as bootable, and specify the pathname of the PBR file.

C:\Windows\system32>bcdedit /set {05a763ce-d81b-11db-b3ec-000000000000} device boot
The operation completed successfully.

C:\Windows\system32>bcdedit /set {05a763ce-d81b-11db-b3ec-000000000000} path \openbsd.pbr
The operation completed successfully.

C:\Windows\system32>

Note the absolute pathname of the imported PBR file. Do not add a drive letter as it is assumed that the file is placed in the system partition. bcdedit will not complain about an explicit drive specification, but the boot manager will balk later claiming it cannot resolve the designated pathname.

• SUPPLEMENTARY: Further information on the set option can be found at the following:

C:\Windows\system32>bcdedit /? set

This command sets an entry option value in the boot configuration data store.

bcdedit [/store <filename>] /set [{<id>}] <datatype> <value>

    <filename>  Specifies the store to be used. If this option is not
                specified, the system store is used. For more information,
                run "bcdedit /? store".

    <id>        Specifies the identifier of the entry to be modified.  If not
                specified, {current} is used. For more information about
                identifiers, run "bcdedit /? ID".

    <datatype>  Specifies the option data type that will be created or
                modified. Run "bcdedit /? TYPES" for more information about
                data types.

    <value>     Specifies the value that should be assigned to the option. The
                format of <value> depends on the data type specified. Run
                "bcdedit /? FORMATS" for more information about data formats.

Examples:

The following command sets the application device to the partition C: for the
specified operating system entry:

    bcdedit /set {cbd971bf-b7b8-4885-951a-fa03044f5d71} device partition=C:

The following command sets the application path to
\windows\system32\winload.exe for the specified operating system entry:

    bcdedit /set {cbd971bf-b7b8-4885-951a-fa03044f5d71} path
        \windows\system32\winload.exe

The following command sets the NX policy to OptIn for the current operating
system boot entry.

    bcdedit /set nx optin

C:\Windows\system32>

Now is the time to deal with the cosmetics of what the boot manager displays. bcdedit only provides for inserting at the beginning (/addfirst) or end (/addlast) of the list. If there are more than two operating systems, repeated /displayorder commands can be used to bubble the entries to their desired ordering.

• SUPPLEMENTARY: Specify the position of the new entry:

C:\Windows\system32>bcdedit /displayorder {05a763ce-d81b-11db-b3ec-000000000000} /addfirst
The operation completed successfully.

C:\Windows\system32>

• SUPPLEMENTARY: Further help for /displayorder can be viewed by the following command.

C:\Windows\system32>bcdedit /? displayorder

This command sets the display order to be used by the boot manager.

bcdedit /displayorder <id> [...] [ /addfirst | /addlast | /remove ]

    <id> [...]      Specifies a list of identifiers that make up the
                    display order.  At least one identifier must be specified
                    and they must be separated by spaces.  For more information
                    about identifiers, run "bcdedit /? ID".

    /addfirst       Adds the specified entry identifier to the top of
                    the display order.  If this switch is specified, only a
                    single entry identifier may be specified.  If the specified
                    identifier is already in the list, it will be moved to the
                    top of the list.

    /addlast        Adds the specified entry identifier to the end of
                    the display order.  If this switch is specified, only a
                    single entry identifier may be specified.  If the specified
                    identifier is already in the list, it is moved to the
                    end of the list.

    /remove         Removes the specified entry identifier from the
                    display order.  If this switch is specified, only a single
                    entry identifier may be specified.  If the identifier is
                    not in the list then the operation has no effect. If
                    the last entry is being removed, then the display order
                    value is deleted from the boot manager entry.

Examples:

The following command sets two OS entries and the NTLDR based OS loader in
the boot manager display order:

    bcdedit /displayorder {802d5e32-0784-11da-bd33-000476eba25f}
        {cbd971bf-b7b8-4885-951a-fa03044f5d71} {ntldr}

The following command adds the specified OS entry to the end of the boot
manager display order:

    bcdedit /displayorder {802d5e32-0784-11da-bd33-000476eba25f} /addlast

C:\Windows\system32>

Note in the command above the new entry is specified to be listed first. One would naturally think this would be the default operating system to be booted (no active selection made at boot time then boots a predetermined OS...), but this is not the case. Specifying the default OS booted requires yet another command.

• SUPPLEMENTARY: Change the default OS booted to the new boot manager entry.

C:\Windows\system32>bcdedit /default {05a763ce-d81b-11db-b3ec-000000000000}
The operation completed successfully.

C:\Windows\system32>

• SUPPLEMENTARY: Help for the default option results in the following information:

C:\Windows\system32>bcdedit /? default

This command sets the default entry that the boot manager will use when the
timeout expires.

bcdedit /default <id>

    <id>    Specifies the identifier of the boot entry to be used as the
            default when the time-out expires. For information about
            identifiers, run "bcdedit /? ID".

Examples:

The following command sets the specified entry as the default boot manager
entry:

    bcdedit /default {cbd971bf-b7b8-4885-951a-fa03044f5d71}

The following command sets the NTLDR based OS loader as the default
entry:

    bcdedit /default {ntldr}

C:\Windows\system32>

Finally, the boot manager's timeout value (which also can be changed in the System applet...) can be changed through bcdedit.

• SUPPLEMENTARY: Change the timeout value (If no OS selection is made after this prescribed time lapses, boot the default OS.) of the default OS.

C:\Windows\system32>bcdedit /timeout 10
The operation completed successfully.

C:\Windows\system32>

• SUPPLEMENTARY: More information on this command follows:

C:\Windows\system32>bcdedit /? timeout

This command sets the time to wait, in seconds, before the boot manager selects
a default entry. For information about setting the default entry, run
"bcdedit /? default".

bcdedit /timeout <timeout>

    <timeout>   Specifies the time to wait, in seconds, before the boot manager
                selects a default entry.

Example:

The following command sets the boot manager <timeout> to 30 seconds:

    bcdedit /timeout 30

C:\Windows\system32>

The result of all changes can be seen by reissuing the bare bcdedit command:

C:\Windows\system32>bcdedit

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=C:
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {default}
resumeobject            {f4bad82f-d5dc-11db-b83c-fff6129dfa33}
displayorder            {default}
                        {current}
toolsdisplayorder       {memdiag}
timeout                 10
customactions           0x10000ba000001
                        0x54000001
custom:54000001         {572bcd55-ffa7-11d9-aae0-0007e994107d}

Real-mode Boot Sector
---------------------
identifier              {default}
device                  boot
path                    \openbsd.pbr
description             OpenBSD/i386 4.5

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Microsoft Windows Vista
locale                  en-US
inherit                 {bootloadersettings}
osdevice                partition=C:
systemroot              \Windows
resumeobject            {f4bad82f-d5dc-11db-b83c-fff6129dfa33}
nx                      OptIn

C:\Windows\system32>

In summary, multibooting OpenBSD through Vista isn't significantly more difficult than earlier versions of Windows. The biggest issue is grasping enough of bcdedit's capabilities to form a working boot manager configuration.

Questions and/or comments are welcomed.

[Carpetsmoker]

bcdedit is truly a cryptic and difficult command-line tool, some time ago I needed to copy a Vista boot entry and add some debug flags -- I could not get the job done with bcdedit.
I had to resort to a GUI tool, EasyBCD

As a slightly related note, I noticed that the FreeBSD bootloader can boot Vista, I used the bootloader from CURRENT, not sure if the one from 6/7 is ``Vista Ready''.

To truly run bcdedit with Administrator credentials requires cmd.exe also be explicitly run with Administrator credentials. Right click on the Command Prompt icon (Start | All Programs | Accessories | Command Prompt), or open the Start window and type cmd. When the search facility shows the application's icon, right click it and select Run as administrator from the local menu.

Going to the run box (The `search' box in the start menu doubles as the run dialog) and pressing CTRL/ALT/ENTER will accomplish the same effect.
Note that does not work with Win+R, do'h!

[argv]

let's say you have vista and you shrink your ntfs partition and install BSD. you've got Vista on 1st partition and BSD on 2nd partition.

rather than a commercial product you might use a free linux live cd with GNU parted (or the gui Gparted), i.e. the ntfsresize utility, to shrink your ntfs partition.

parted has a 'set' command which is very useful for multibooting. alas, there's no parted for BSD (yet), it's linux only. but BSD's fdisk has the -a switch.

how it's done: while you're in linux via the live cd, from the command line you set a boot flag (0x80) on one of the partitions. here we set it to partition 2. this way we will boot to BSD.

Code:

(parted)set 2 boot on

when you reboot, the OS that boots is the one with the boot flag, the one marked as "Active": the 2nd partition. your BSD partition.

if you set the boot flag on your Vista NTFS partition (partition 1) then the system will reboot to Vista. simple.


Code:

(parted)set 1 boot on

or (if you are in BSD)

fdisk -a and follow the instructions


what do you do while you're in Vista and you want to set boot flags? to boot to BSD. are there windows equivalents of GNU parted or BSD's fdisk?

not that i know of. bcdedit is a "boot manager" (as is "grub"), which is something different. these "managers" aim to boot OS's by acting as a go-between, taking control before letting the OS's native boot loader do its job. do we need a go-between?

parted and fdisk aim to edit partitions which is what switching the boot flag involves- a very small hex edit.

i found a small utility called plppart32 on the plop (system recovery) linux site. easier to use than bcdedit? have a look. it requires just one more line than parted to set the next reboot. while in Vista we can set the boot flag on 2nd partition (BSD) like this

Code:

plppart32 -d 0 -p 2 -b 0x80 # set boot flag on 2nd slice
plppart32 -d 0 -p 1 -b 0 # remove boot flag from 1st slice

in sum the boot flag is all that needs to be manipulated to choose an OS to boot from

hence you can

[just in case] save a copy of your windows MBR (tar'd or zipped)

[just in case] keep a linux systemrescuecd on hand

use a tool like GNU parted in linux, or fdisk in BSD, and use a tool like plpprt32 in Vista to make the simple hex edit to set the boot flag.

simple and easy. let each OS use its own boot loader, with no go-betweens.

[ocicat]

Given that Microsoft made Windows 7 Release Candidate freely available to the public last week:

http://www.microsoft.com/windows/win.../download.aspx

...I was curious to see if anything had changed with respect to multibooting OpenBSD. This time, I was interested in following up using a recent snapshot of OpenBSD-current.

For more information on installing the Release Candidate, see the above link. For installing OpenBSD, see Section 4 of the FAQ:

http://openbsd.org/faq/faq4.html

The important thing to remember when installing OpenBSD after any version of Windows is to make sure that the question "Do you want to use the entire disk?" is answered no. Answering yes to this question overwrites the MBR which will make reclaiming Windows very difficult if not impossible.

Also note that this message chronicles a new installation of both operating systems. Supposedly, the BCD database from a Vista installation can be migrated when upgrading to Windows 7, but I chose to start fresh on both fronts.

User Access Control is still present in Windows 7, & running bcdedit with elevated Administrator rights is still required. What has (minimally) changed is how to invoke bcdedit correctly. Two means found are:

• Go to the Start menu, & type cmd in the search edit box. Instead of pressing Enter, use Ctrl-Shift-Enter to start Command Prompt with the needed credentials.
• In Vista, I pinned the Command Prompt icon to the taskbar given that I frequently exercise functionality from the shell prompt. Right clicking on this pinned icon would display a local menu which offered the choice of running Command Prompt as Administrator. In the Windows 7 RC, this choice is no longer part of the locally generated menu. The choice is still available through right-clicking on the Command Prompt icon found under Start | All Programs | Accessories. Not earth shattering, but mildly irritating when not knowing how to elevate privileges when it is needed.

The bcdedit recipe provided earlier also has to be amended. Upon first executing bcdedit, the following output can be seen in Windows 7 RC:

C:\Windows\system32>bcdedit

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume1
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {0154a86c-3d41-11de-bd67-a7060316bbb1}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {0154a86e-3d41-11de-bd67-a7060316bbb1}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {0154a86c-3d41-11de-bd67-a7060316bbb1}
nx                      OptIn

C:\Windows\system32>

From the earlier discussion, it would appear that all that is needed to configure the BCD database is the following three commands:

C:\Windows\system32>bcdedit /create /d "OpenBSD/i386 4.5-current" /application bootsector
The entry {0154a872-3d41-11de-bd67-a7060316bbb1} was successfully created.

C:\Windows\system32>bcdedit /set  {0154a872-3d41-11de-bd67-a7060316bbb1} device boot
The operation completed successfully.

C:\Windows\system32>bcdedit /set  {0154a872-3d41-11de-bd67-a7060316bbb1} path \openbsd.pbr
The operation completed successfully.

C:\Windows\system32>

A tell-tale sign that this is insufficient is seen by reissuing the bcdedit command afterwards with no arguments. The output is the same as above. Nothing appears to be added to the database, & if the system is rebooted, booting proceeds directly into Windows 7.

One might guess (which I did...) that something else is needed to trigger database insertion. Perhaps specifying where the entry is to appear in the boot menu is necessary:

C:\Windows\system32>bcdedit /displayorder  {0154a872-3d41-11de-bd67-7060316bbb1 } /addlast
The operation completed successfully.

C:\Windows\system32>

Re-entering bcdedit with no arguments looks encouraging:

C:\Windows\system32>bcdedit

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume1
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {0154a86c-3d41-11de-bd67-a7060316bbb1}
displayorder            {current}
                        {0154a874-3d41-11de-bd67-a7060316bbb1}
toolsdisplayorder       {memdiag}
timeout                 30

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {0154a86e-3d41-11de-bd67-a7060316bbb1}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {0154a86c-3d41-11de-bd67-a7060316bbb1}
nx                      OptIn

Real-mode Boot Sector
---------------------
identifier              {0154a872-3d41-11de-bd67-a7060316bbb1}
device                  boot
path                    \openbsd.pbr
description             OpenBSD/i386 4.5-current

C:\Windows\system32>

...as a new section on a real-mode boot sector has been added to the database output. Rebooting does display Microsoft's boot manager, but upon selecting the OpenBSD entry, I was greeted by an error message beginning with:

Windows failed to start.  A recent hardware or software change might be the cause.
...
     file:  \openbsd.pbr
    status: 0xc000000f

The selected entry could not be loaded because the application is missing or corrupt.

Spelunking about raised questions about the whether the boot manager actually understood where the PBR file resided. Vista simply needed it to simply exist in the system volume, however, I found references pointing out that Windows Server 2008 allowed different versions of Windows to be found all over the disk. Eventually, I found the following command which specifies the exact partition where the PBR can be found:

C:\Windows\system32>bcdedit /set  {0154a872-3d41-11de-bd67-a7060316bbb1} device partition=c:
The operation completed successfully.

C:\Windows\system32>

Now, the database output looks like:

C:\Windows\system32>bcdedit

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume1
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {0154a86c-3d41-11de-bd67-a7060316bbb1}
displayorder            {current}
                        {0154a872-3d41-11de-bd67-a7060316bbb1}
toolsdisplayorder       {memdiag}
timeout                 30

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {0154a86e-3d41-11de-bd67-a7060316bbb1}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {0154a86c-3d41-11de-bd67-a7060316bbb1}
nx                      OptIn

Real-mode Boot Sector
---------------------
identifier              {0154a872-3d41-11de-bd67-a7060316bbb1}
device                  partition=C:
path                    \openbsd.pbr
description             OpenBSD/i386 4.5-current

C:\Windows\system32>

...& the boot manager now allows me to boot into whichever operating system I prefer.

None of this is complicated, but troubleshooting required some knowledge of where to find Microsoft-specific information, & perhaps this lengthy explanation will help others successfully configure a multibooting environment of these two operating systems.

FWIW.

[fbsduser]

AFAIK, EasyBCD have a new version which is compatible with malware v7.

[argv]

This is an excerpt from the OpenBSD faq4:

Setting active partitions

This is probably the most overlooked, and yet, sometimes the best solution
for multibooting. Simply set the active partition in whatever OS you are
currently using to be the one you want to boot by default when you next
boot. Virtually every OS offers a program to do this; OpenBSD's is
[162]fdisk(8), similar named programs are in Windows 9x and DOS, and many
other operating systems. This can be highly desirable for OSs or systems
which take a long time to shut down and reboot -- you can set it and start
the reboot process, then walk away, grab a cup of coffee, and come back to
the system booted the way you want it -- no waiting for the Magic Moment


I am 100% in agreement with this. Let each operating system boot *with its own boot loader*. Simple and easy. We do not need boot managers. We can multiboot by simply changing the boot flag.

Alas, Windows does not have an equivalent to GNU Parted or BSD fdisk.

To my knowledge, there is no utility in Windows that will simply change the boot flag.

If one tries to change a boot flag with the Windows diskpart.exe utility (which can "set" a primary partition as "active"), it will write an entire Microsoft-style MBR. That's more than switching a boot flag, and it's not what we want for multibooting.

plppart32.exe is the best Win32 utility I have found for switching the boot flag. It's just too bad Microsoft will not include one of their own with their OS.

[vermaden]

For short time I thought that I came to wrong forum.

[IdOp]

That is definitely a technique one should know about, but I think the key word is it's "sometimes the best solution". For me, I don't always know what OS will be booted next, and it would also be easy to forget to make a change. I suppose one could always boot a DOS floppy with fdisk on it, change the active partition, and reboot.

[Marrea]

I stumbled upon this forum while searching the Internet for information about using BCD to dual boot Windows 7 and Linux and have to say it is the most comprehensive set of instructions I have managed to find yet, so should like to compliment ocicat on his extremely well set out guide. I am fairly experienced in using boot.ini to dual/multi boot Windows XP and Linux on a single hard drive but have still to get my head round the new BCD, especially with the added complication of a second hard drive as I now have.

I hope I may be allowed to post here. Although I am using Linux rather than OpenBSD the principles are surely pretty much the same (identical?) and therefore my queries hopefully will be of interest and relevance to OpenBSD users.

My situation is as follows.

I have two separate hard drives. My main C: drive contains Windows 7 Home Premium 64 bit, which came pre-installed with the computer. The second hard drive was originally empty.

The C: drive has two partitions, shown in Windows Disk Management as follows:
1. System Reserved, 100 MB NTFS, Healthy (System, Active, Primary Partition)
2. (C:), 232.79 GB (NTFS), Healthy (Boot, Page File, Crash Dump, Primary Partition)

The second hard drive now has two partitions, which I created using Windows Disk Management, prior to installing Ubuntu 10.04 64 bit as follows:
1. /dev/sdb1, Linux root partition, Ext4, 230.88 GB
2. /dev/sdb2, Linux swap partition, 2.00 GB

I placed Ubuntu’s Grub on its root partition. I then took a copy of the Linux bootsector, which I called linux.bin.

My first problem was knowing where on Windows to place the copy of the Linux bootsector. I have read elsewhere that it needs to be in the same location as the bootmgr file. Unfortunately I am not quite sure where bootmgr is on my system. A Windows search for bootmgr shows nothing. (And, yes, I do have all the various options ticked to (i) show hidden files, folders and drives, (ii) show protected system operating files, (iii) when searching non-indexed locations include system directories.) If I use Windows Explorer to do a manual search, there is no bootmgr in the root C: drive. However in C:\Windows\Boot\EFI\en-US\ there is a file called bootmgr.efi.mui, along with bootmgfw.efi.mui and memtest.efi.mui. I am not sure whether this efi file is the bootmgr file. The only other place I can think it might be is in the 100 MB System Reserved partition but, if so, I have no idea how one would copy a file into that partition. So I simply copied the Linux bootsector to the Windows root C: drive and hoped for the best.

Next I edited BCD, but first taking the precaution of doing a backup:

C:\Windows\system32>bcdedit /export "C:\BCDBackup"
The operation completed successfully.

and then proceeded to follow ocicat’s instructions as follows:

C:\Windows\system32>bcdedit /create /d "Ubuntu 10.04" /application bootsector
The entry {66a21b2f-62f1-11df-9194-d9f24e40b78f} was successfully created.

C:\Windows\system32>bcdedit /set {66a21b2f-62f1-11df-9194-d9f24e40b78f} device boot
The operation completed successfully.

C:\Windows\system32>bcdedit /set {66a21b2f-62f1-11df-9194-d9f24e40b78f} device partition=c:
The operation completed successfully.

C:\Windows\system32>bcdedit /displayorder {66a21b2f-62f1-11df-9194-d9f24e40b78f} /addlast
The operation completed successfully.

bcdedit then showed:

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume1
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {66a21b2b-62f1-11df-9194-d9f24e40b78f}
displayorder            {current}
                        {66a21b2f-62f1-11df-9194-d9f24e40b78f}
toolsdisplayorder       {memdiag}
timeout                 30

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {66a21b2d-62f1-11df-9194-d9f24e40b78f}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {66a21b2b-62f1-11df-9194-d9f24e40b78f}
nx                      OptIn

Real-mode Boot Sector
---------------------
identifier              {66a21b2f-62f1-11df-9194-d9f24e40b78f}
device                  partition=C:
path                    \linux.bin
description             Ubuntu 10.04

However, on reboot when selecting the Ubuntu 10.04 entry from the Windows boot menu all that happened was I was taken to a black screen with a flashing white cursor in the top left hand corner.

So my queries are:

1. Have I copied the Linux bootsector to the right location on Windows?
2. Does the black screen with the flashing cursor indicate that my bcdedit commands were correct but there is instead a problem with Ubuntu’s Grub which is preventing it booting and that is where I need to investigate?

[Marrea]

An update on my previous post

I have now managed to ascertain that bootmgr is indeed in the 100 MB System Reserved partition. I hadn’t realised that, even though the Windows installation does not give this partition a drive letter, in order to view the contents in Windows Explorer and copy files to it all you have to do is go into Disk Management and assign a drive letter to it there. I therefore assigned the letter R to the partition, deleted the Ubuntu menu entry I had previously created, moved linux.bin to the root of the R partition, and ran a new set of bcdedit commands as follows:

C:\Windows\system32>bcdedit /create /d "Ubuntu 10.04" /application bootsector
The entry {66a21b30-62f1-11df-9194-d9f24e40b78f} was successfully created.

C:\Windows\system32>bcdedit /set {66a21b30-62f1-11df-9194-d9f24e40b78f} device boot
The operation completed successfully.

C:\Windows\system32>bcdedit /set {66a21b30-62f1-11df-9194-d9f24e40b78f} path \linux.bin
The operation completed successfully.

C:\Windows\system32>bcdedit /set {66a21b30-62f1-11df-9194-d9f24e40b78f} device partition=r:
The operation completed successfully.

C:\Windows\system32>bcdedit /displayorder {66a21b30-62f1-11df-9194-d9f24e40b78f} /addlast
The operation completed successfully.

Running bcdedit now gives the following:

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=R:
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {66a21b2b-62f1-11df-9194-d9f24e40b78f}
displayorder            {current}
                        {66a21b30-62f1-11df-9194-d9f24e40b78f}
toolsdisplayorder       {memdiag}
timeout                 30

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {66a21b2d-62f1-11df-9194-d9f24e40b78f}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {66a21b2b-62f1-11df-9194-d9f24e40b78f}
nx                      OptIn

Real-mode Boot Sector
---------------------
identifier              {66a21b30-62f1-11df-9194-d9f24e40b78f}
device                  partition=R:
path                    \linux.bin
description             Ubuntu 10.04

I can still boot into Windows OK but selecting the Ubuntu entry in the Windows boot menu takes me to a black screen with a flashing white cursor just as it did before. I don’t know if it is because Ubuntu is on a separate hard drive from Windows which is causing the problem, whether something in Ubuntu’s Grub needs editing, or whether I have not carried out the bcdedit commands properly.

[BSDfan666]

If Linux is on a separate drive, why not just go into your BIOS and select the device? people come up with far to elaborate multiboot environments.

[ocicat]

Originally Posted by Marrea

I can still boot into Windows OK but selecting the Ubuntu entry in the Windows boot menu takes me to a black screen with a flashing white cursor just as it did before.

This is the symptom you should be focusing upon.

The solution I provided was specific to a single disk environment. In the NT 4.0 days, the ARC notation for drives allowed for multiple drives in a system using boot.ini. A quick look through the sources I consulted to figure out the single disk environment with bcdedit does not mention multiple disks. I suspect the information is out there, but I have not found it. I also don't have a two disk system to experiment anyways.

My recommendation to you is three-fold:

• Search through Microsoft's TechNet for information related to booting from multiple disks. MSDN or Microsoft's support site should be checked as well.
• Ask specifically on Microsoft's free support forums how to use bcdedit to boot multiple versions of Windows on multiple disks. I would also recommend not mentioning non-Microsoft operating systems as this may decrease anyone's motivation to help you.
• You may want to look into using Grub as the boot manager instead of Microsoft's. I vaguely recall reading where Grub can manage multiple disks, but I remember nothing more, nor where I saw this information.
  
  Secondarily, attempting to use Microsoft's boot manager on one drive & Grub on the other sounds disastrous. Use one or the other.

[Marrea]

BSDfan666 and ocicat

Many thanks for your replies. I thought I’d just give a little background.

For the last five years I have been successfully running a Windows XP/various flavours of Linux multiboot single hard drive computer. I currently have eight different Linux distros on it, and my primary bootloader is Windows boot.ini. With each new Linux installation I always put Grub on the Linux root partition, copy the bootsector across to the Windows root C: drive, add an entry in boot.ini and away I go. Nice and simple. Never any problems booting.

I do not like using Grub as my primary bootloader on any machine which also runs Windows. Once you let Grub take over the MBR it can - not always I admit, but quite often in my experience - cause problems. Not drastic, there is usually a way out, but all the same it can be fiddly and take time to fix when you suddenly find you can’t get into Windows or one or more of the distros because Grub has decided to go AWOL. However, I do have a couple of laptops which only run Linux (one of them dual boots two Linuxes) and there of course naturally I use Grub which by and large behaves itself. I must confess I definitely think Linux is much better not co-existing on the same machine alongside Windows.

Anyway, I was in the market for a more up-to-date desktop computer and while I was about it I thought I might as well take the opportunity to move to 64 bit. I have read frequently that in a dual boot situation it is a good idea to install Linux completely separately from Windows on a second hard drive. Unfortunately the articles have then never gone on to explain in detail how in fact you go about the procedure. Not to be dissuaded, I decided that my new computer would have two hard drives and I would have a shot at booting Linux off the second one. I also wanted to try and follow my usual practice of using the Windows bootloader to boot Linux. I did not want to use Grub, nor did I want to install a third party program such as EasyBCD, which as far as I am concerned is an unnecessary extra layer. I don’t believe that EasyBCD can do anything which can’t be done natively using the bcdedit commands, the only problem being of course finding out what those commands are!!

Originally Posted by BSDfan666

If Linux is on a separate drive, why not just go into your BIOS and select the device? people come up with far to elaborate multiboot environments.

BSDfan666
I always knew that it was possible to go into the BIOS and change the boot order permanently (until such time that is as you go back in and change it again) and had thought about this as an option originally but discounted it as being a slightly untidy method. However, what I hadn’t appreciated until yesterday after reading your comment and doing some further research is that some BIOSes allow you to hit a key at startup, which takes you to a screen listing your various boot devices and you can simply click on the one you want to boot into at that particular time, ie you don’t have to alter the boot order at all. I dragged out my motherboard manual last night and was delighted to see that my particular BIOS does have this facility.

So what I have done today is boot into Ubuntu using the live installation CD, done a chroot and moved Grub to the MBR of the second hard drive (during installation I had placed it on the root partition). I have left the first hard drive as the first boot device so normally the computer will boot straight into Windows 7 but when I want to use Ubuntu all I have to do is hit F8 at start up, select the second hard drive and off it goes to Grub and boots. I really wish I had been aware of this feature before. We live and learn.

Originally Posted by ocicat

A quick look through the sources I consulted to figure out the single disk environment with bcdedit does not mention multiple disks. I suspect the information is out there, but I have not found it.

ocicat
Yes, this has been my experience too. I cannot believe it can’t be done but so far I have had no success whatsoever.

Thank you for your three recommendations. As you will see from my comments to BSDfan66 above I have managed to solve my immediate problem of not being able to get into Ubuntu. However I am still interested in pursuing the inner workings of BCD and intend doing some more digging around and will certainly explore the avenues you have suggested.

Once again, thanks to both of you for your interest.