View Single Post
  #4   (View Single Post)  
Old 10th May 2009
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 3,277
Default

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.
Reply With Quote