Re: RFE: Grub should provide option to swap partition order

[Ulf Zibis]

Hi Vladimir,

thanks for your response.

As I'm not subscribed to this list, please CC me while answering, e.g. by "Reply all".


Am 01.02.2013 08:02, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:

On 29.01.2013 22:56, Ulf Zibis wrote:

Now I've found a possibility to have 2 WinXP installations, both
originally installed on "C:", alternatively running on one disk.
As I still was unable to boot a Windows by Grub from a logical partition
(only NTLDR can do that, but in my case resolves incompatible drive
letter), I copied my old Windows XP partition from sda1 to sda2. A fresh
new Windows XP installation was installed to sda1.

First I tried this:
http://www.gnu.org/software/grub/manual/grub.html#DOS_002fWindows

It works for to boot the Windows installation on sda1, but it dosn't
work for the one on sda2 (~ 10 seconds after WinXP boot screen I got a
blue-screen).

So the only thing I found out, that works, is to swap the order of those
partitions in the partition table (print from sfdisk):
         Device Boot Start     End   #cyls    #blocks   Id  System
      /dev/sda1   *      0+   3038    3039-  24410736    7 HPFS/NTFS/exFAT
      /dev/sda2      16418   19456    3039   24410767+   7 HPFS/NTFS/exFAT
      /dev/sda3       3039    5390    2352   18892440   83  Linux
      ....
exchange/toggle with:
      /dev/sda1      16418   19456    3039   24410767+   7 HPFS/NTFS/exFAT
      /dev/sda2   *      0+   3038    3039-  24410736    7 HPFS/NTFS/exFAT
      /dev/sda3       3039    5390    2352   18892440   83  Linux
      ....

Unfortunately grub can't do that until now, so hereby I suggest an
additional option e.g.:

      parttool (hd0,1) swap-order (hd0,2)

The option should include swapping the volume-IDs in the menu entries in
grub.cfg as well, so they would again match correctly.

Windows doesn't care much about partition numbers other than in
boot.ini.

Exactly, and that's the problem, I have to deal with here.
Partition numbers in boot.ini refer to there counterparts in the partition table, but nut to the physical order on the disk.

For better understanding I define:

physical(1): start=       63, size= 48821472, Id= 7, bootable
physical(2): start= 48821535, size= 37784880, Id=83
physical(3): start= 86606541, size= 69625584, Id= 7, logical
physical(4): start=156232188, size= 10490382, Id= 7, logical
physical(5): start=166722633, size= 72469152, Id= 7, logical
physical(6): start=239191785, size= 73384920, Id= 7

NTLDR(1): Windows boot loader, located on physical(1):
NTLDR(2): Windows boot loader, located on physical(6):
NTLDR(3): Windows boot loader, located on physical(3):

BOOT.INI(1): BOOT.INI, located on physical(1):
BOOT.INI(2): BOOT.INI, located on physical(6):
BOOT.INI(3): BOOT.INI, located on physical(3):

Windows(1): Windows installation, located on physical(1):
Windows(2): Windows installation, located on physical(6):
Windows(3): Windows installation, located on physical(3):

partition(1) aka sda1: physical(x), where 1st entry in partition table points to
partition(2) aka sda2: physical(x), where 2nd entry in partition table points to
partition(6) aka sda7: physical(3)

This is the Windows part of my grub.cfg:
### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Microsoft Windows XP Professional (auf /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-chain-32B430C4B4308BFB' {
    insmod part_msdos
    insmod ntfs
    set root='hd0,msdos1'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  32B430C4B4308BFB
    else
      search --no-floppy --fs-uuid --set=root 32B430C4B4308BFB
    fi
    drivemap -s (hd0) ${root}
    chainloader +1
}
menuentry 'Microsoft Windows XP Professional (auf /dev/sda2)' --class windows --class os $menuentry_id_option 'osprober-chain-FE14AE0A14ADC64D' {
    insmod part_msdos
    insmod ntfs
    set root='hd0,msdos2'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2  FE14AE0A14ADC64D
    else
      search --no-floppy --fs-uuid --set=root FE14AE0A14ADC64D
    fi
    drivemap -s (hd0) ${root}
    chainloader +1
}
menuentry 'Microsoft Windows XP Professional (auf /dev/sda7)' --class windows --class os $menuentry_id_option 'osprober-chain-FE14AE0A14ADC64D' {
    insmod part_msdos
    insmod ntfs
    set root='hd0,msdos7'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7  FE14AE0A14ADC64D
    else
      search --no-floppy --fs-uuid --set=root FE14AE0A14ADC64D
    fi
    drivemap -s (hd0) ${root}
    chainloader +1
}
### END /etc/grub.d/30_os-prober ###

If I select the 1st Windows entry from Grub menu, BOOT.INI(1) is in effect, and the Windows(1) installation is bootet, according the default entry in BOOT.INI(1).
If I select the 2nd Windows entry from Grub menu, I can see, that BOOT.INI(2) is in effect (as the only difference between BOOT.INI(1) and the 2 others is, that on the latter there is an additional Recovery Console entry, and I did a little edit, to distinguish the 3), but finally the Windows(1) installation is bootet, according the default entry in BOOT.INI(2).
If I select the 3rd Windows entry from Grub menu, I can see, that BOOT.INI(3) is in effect, but finally the Windows(1) installation is bootet, according the default entry in BOOT.INI(3). This is very surprising, as I ever thought, Windows bootloader should reside on a primary partition to be executable.

If I add this line to any BOOT.INI:
       multi(0)disk(0)rdisk(0)partition(2)\WINDOWS ...
I am presented Windows boot menu.
If I choose the 1st entry, the Windows(1) installation is bootet successfully.
If I choose the 2nd entry, the Windows(2) installation starts booting but after some time it crashes. I interpret the reason, that partition(1) still is seen as C:, partition(2) (system volume of Windows(2)) is seen as D:, and relative paths were correctly resolved to D:, but absolute (C:)-paths were resolved to C:, which is not the valid system volume in this case.
At worst it appears Windows(2) to work correctly, but Windows(1) becomes corrupted as cause of write actions from Windows(2).

HOW TO SOLVE THIS PROBLEM without
- tweak registry from Windows(2), which requires expert knowledge and special tools to tweak it offline?
- manually swap the physical(1,2) in the partition table entries order and run update-grub after?
(in the latter case, the 2nd and 3rd Windows entry in grub.cfg could be deleted, as superfluous)

IF YOU DON'T KNOW A SOLUTION, please consider my RFE !!!

It only cares about which partition has boot flag

AFAIK (I have proofed it on my machine), Windows itself doesn't care about the boot flag, only Windows generic MBR code does (which BTW is no more present after Grub is installed in MBR). The boot flag determines, which Windows boot loader becomes loaded and executed.
If the boot flag is set on the partition(2)=sda2, in case of original Windows generic MBR code, the Windows boot loader NTLDR(2) becomes loaded and executed. It parses the BOOT.INI(2) from same partition(2) and according it's default value or the manual choice, the Windows boot manager boots one of those Windows kernels, regardless, which of those partitions is marked bootable:
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS ...
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS ...

If Grub is in the MBR, boot flag seem to have no effect, as seen above.

 (you did add parttool hd0,X boot+ to the entries, right?)

It was nowhere set from update-grub.
(But all Windows partitions were added from update-grub, even those, which can't be bootable, as they were on logical partitions.)

Yes, I tried to add parttool hd0,X boot+ to the entries, but this didn't make any difference.
If I select the 2nd Windows entry from Grub menu, I can see, that in any case BOOT.INI(2) is in effect (as the only difference between both is, that on BOOT.INI(2) there is an additional Recovery Console entry), but finally the Windows installation from partition(1) is bootet, according the default entry in BOOT.INI(2).

and partition start sector as recorded in registry

I have no idea, what you mean by that. In which registry and where, a start sector should be recorded?

> Try reading http://support.microsoft.com/kb/289022
I know that, but funny, there is an error on that page. For
    multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Professional" /fastdetect
    multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows 2000 Professional" /fastdetect
it states "This is a BOOT.INI with an earlier installation of Windows 2000 ..."
IMHO, it is vice versa, except they mean, that the earlier Win2000 was installed to partition (2) from the beginning, which seems quite weird for a beginners demonstrating example.


-Ulf