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:
Code:
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:
Code:
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:
Code:
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:
Code:
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:
Code:
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:
Code:
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:
Code:
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.