I can confirm this problem, explain the root cause, and confirm the fix. Steps to reproduce problem: 1. Obtain a Windows 7 install (I used Windows 7 Professional) 2. Install a second drive with higher boot priority in the BIOS 3. Install Ubuntu (I tested with 12.04.1 and 12.10) on the second drive. *Drive*, not merely partition. 4. Boot into the new "Windows 7 (loader)" grub entry 5. Attempt to hibernate via the shutdown menu (the following are optional information gathering steps) 6. Attempt to hibernate via running "poweroff /h" in an Administrator cmd window 7. Attempt to list BCD values via running "bcdedit /enum" in an Administrator cmd window 8. Look at the boot configuration in System Properties -> Advanced -> Startup and Recovery.
Expected results: 5. Machine enters hibernate 6. Machine enters hibernate 7. Printout of Windows boot loader options and available Windows 7 installations 8. Fields in the panel filled out with appropriate values (such as "Windows 7 Professional" and a timeout of "10") and editable. Actual results: 5. Screen blanks, computer locks (the "need a password" variety, not a freeze), does not hibernate 6. Same as 5, but you see the error "The system cannot find the file specified.(2)" 7. Error message "The boot configuration data store could not be opened. The system cannot find the file specified." 8. All fields are blank and you are unable to set them. I spent multiple hours tracking down why this occurred, and attempting to bash the Windows 7 Boot Configuration Data system into accepting being on the second drive. I even went so far as to completely erase and recreate the entire BCD descriptor. It works fine for booting, but not for hibernation -- and by extension, Hybrid Sleep, meaning that Windows 7 sleep functionality is broken on many installs. The source of this particular issue is that hibernation in Windows 7 is done in part by modifying the BCD to point to the hibernation file, similar to when calling "bcdedit" to edit boot entries, but Windows 7 *only* looks for the BCD on the boot device. Specifically, it only looks at the primary partition on the boot device that has the bootable flag set, and "boot device" in this context means the first hard disk in the BIOS ordering (i.e. drive 0x80 in BIOS-speak). I scoured technet looking for any way to modify this behavior and came up short, finding only an "until next reboot" solution for EFI devices. I actually had grub on both drives at one point in my tests, and I could boot into Windows 7 using either by changing the boot order in my BIOS. Whenever I booted from the different drive than windows, I coulnd't hibernate or access any of the BCD information using any of steps 5, 6, 7, or 8 above. I *could* manually specify the BCD with the bcdedit tool using its "/store" parameter to explicitly specify the BCD store file, successfully altering parameters for subsequent boots, but anything that was supposed to operate on the "current" BCD store would fail. After determining that it was in fact related to BIOS boot order, I tried setting grub to swap the bios identifiers using the "drivemap" declaration in grub.cfg, which worked perfectly to resolve all the described issues. It looks like someone beat me to writing a bug report, though, so I'm adding this here. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1055880 Title: 30_os-prober does not add drivemap for Windows 7 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1055880/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
