Bug 753801

Summary: Windows 7 built-in backup tool does not work when booted via grub2
Product: [Fedora] Fedora Reporter: Thomas Müller <thomas>
Component: grub2Assignee: Peter Jones <pjones>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 16CC: dennis, mads, pjones
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-25 10:44:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Output of os-prober
none
grub2.cfg created by grub2-mkconfig which results in reported Win7 error
none
patched grub2.cfg which results in Win7 working fine none

Description Thomas Müller 2011-11-14 14:33:14 UTC
Description of problem:
The backup tool of Windows 7 always aborts with a "File not found" error, when Windows 7 was booted via (unpatched) grub2. If Windows 7 is booted via its own boot loader (or patched grub, see below) everything works fine.


Version-Release number of selected component (if applicable):
grub2-1.99-12.fc16.x86_64


How reproducible:
Happens always (at least on my system)


Actual results:
Windows 7 does not work correctly (backup tool fails)


Expected results:
Windows 7 should work correctly


Additional info:
The hard drive layout is as follows:
/dev/sda1:  Windows XP
/dev/sda2:  Windows 7
/dev/sdb:   Fedora 16

MBR of /dev/sda contains the boot loader of Windows 7.
MBR of /dev/sdb contains grub2.

If I tell the BIOS to boot from /dev/sdb and then select Windows 7 in grub2, Windows 7 boots up just fine. However, the backup tool always aborts with the afore mentioned error.
If I tell the BIOS to boot directly from /dev/sda, the backup tool works as it should.

It appears that Windows 7 gets confused by the BIOS drive ordering or something like that.
If I explicitly add "drivemap -s (hd0) ${root}" to the Windows 7 menuentry of grub2 everything works fine again even when booted via grub2.

Interestingly, this is automatically added by grub2 to all chainloader menuentries *except* for Windows Vista, Windows 7 and Windows 2008.
Is there a specific reason, not to use that on these systems?

Comment 1 Mads Kiilerich 2011-11-17 21:52:06 UTC
Please attach your grub.cfg and the output of 'os-prober'.

Comment 2 Thomas Müller 2011-11-19 10:15:45 UTC
Created attachment 534557 [details]
Output of os-prober

Comment 3 Thomas Müller 2011-11-19 10:17:53 UTC
Created attachment 534558 [details]
grub2.cfg created by grub2-mkconfig which results in reported Win7 error

Comment 4 Thomas Müller 2011-11-19 10:18:35 UTC
Created attachment 534559 [details]
patched grub2.cfg which results in Win7 working fine

Comment 5 Mads Kiilerich 2011-11-20 00:19:24 UTC
So both XP and Win7 basically works out of the box?

Win7 backup only starts working if you add _both_ of
	drivemap -s (hd0) ${root}
	parttool ${root} boot+
?

Why has boot+ been added to XP as well? Do you see the same problem on XP - and do this line fix it?

Does it all work without boot+ if you make the partitions bootable with fdisk?

How did you install Fedora? Did it remove the boot flag from the windows partitions or did something else do it?

(Yes, the logic in /etc/grub.d/30_os-prober do for some reason intentionally leave out the drivemap line for Win7.)

Comment 6 Thomas Müller 2011-11-20 11:55:39 UTC
Sorry for the confusion with boot+, it's just to "please" Windows...

I don't remember the exact details, but when this setup was originally created several years ago, I had some problems when Windows was installed or booted to a partition that was not marked active/bootable. It seems to insist that the active partition is always accessible as "C:\", even if Windows itself is installed to another partition.
As I wanted to keep the two Windows installations as separated as possible, both Systems were installed and are booted with their particular partition marked active to make sure the installation partition is always mounted as "C:\".

Toggling the active/bootable partition with fdisk instead of using boot+ works as well, it is just a bit inconvenient.

If I just concentrate on Windows 7 and the problem with the backup-tool, boot+ does not make any difference once the correct partition is marked active.
So
 drivemap -s (hd0) ${root}
 parttool ${root} boot+
as well as just
 drivemap -s (hd0) ${root}
both work, while using just the boot+ line or none of them at all boots up Windows 7, but results in the backup-tool not working properly.

Fedora was installed using Fedora-16-x86_64-netinst.iso and it did not touch the Windows installations or partitions in any way.
Until is was replaced by grub2 during the installation of Fedora 16, grub was the default bootloader. It also was (manually) configured to appropriately toggle the bootable flag and map devices when booting WinXP and Win7, which worked fine for several years now.

Comment 7 Mads Kiilerich 2011-11-20 17:34:54 UTC
As far as I can see there are two issues:

Windows doesn't like it when the ordering and numbering of the hard drives changes. So don't do that, or request a bugfix from the vendor of that software.

The backup software has further restrictions to the boot setup. If you want to use that software then create your setup in such a way that it works - or request a bugfix from the vendor of that software.

It is just great if you can work around these issues with grub2, but I really don't see any grub2 issue here.

Comment 8 Thomas Müller 2011-11-20 20:38:27 UTC
Yes, Windows is a bit stupid when accessing its drives and partitions and yes, it is very nice that grub2 is able to work around it.

My "issue" with grub2 is, why the drivemap command is automatically used for Windows XP and older, but not for Windows Vista and newer.

Is there a specific reason for this (e.g. does it trigger another issue within Windows?) or did someone just notice that it also boots up without it?
If it is the second case it might make sense to just always use the drivemap command when booting Windows... not only when booting older ones.

Comment 9 Mads Kiilerich 2011-11-20 20:46:22 UTC
I guess never windows versions can handle being installed on secondary disk drives, and that use of this workaround for these windows versions thus in general just would add another source of errors.

That question is however not related to the packaging for Fedora, so you could try to investigate it upstream.

Comment 10 Thomas Müller 2011-11-25 10:44:59 UTC
(In reply to comment #9)
> That question is however not related to the packaging for Fedora
That's obviously true, but I would guess that also applies to the vast majority of bugs reported against Fedora in this Bugzilla ;)

However, as this only affects another proprietary OS (and even then presumably only in a very specific setup), I can understand that there is not much interest in pursuing this further... especially since there is a workaround.