bugGNU GRUB - Bugs: bug #46763, allow multibooting of windows-xp...


You are not allowed to post comments on this tracker with your current authentication level.

bug #46763: allow multibooting of windows-xp 32bit or lower on >2TB discs

Submitter:  Piotr Sawuk <piotr5>
Submitted:  Sun 27 Dec 2015 03:10:25 PM UTC
Category:  Disk & Partition Severity:  Major
Priority:  3 - Low Item Group:  Feature Request
Status:  None Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Open Release:  other
Release:  Reproducibility:  Every Time
Planned Release:  2.03+

Mon 28 Dec 2015 01:07:24 PM UTC, comment #4: 

sorry, couldn't find any tool capable of moving protective-partition after the extended one (since they are fixated to a position). I moved it after the windows-xp drive though, and windows fails with "root>\system32\hal.dll" missing or broken. I'm not going to reinstall windows in that configuration though and neither will other users with a similar problem. you are right though, such a problem can be solved by gptsync, some website wrote extensively about that. however, as that website said: this wont work if you want extended mbr-partitions! according to my tests gptsync does get me through the missing dll problem, but then I lose several partitions, in theory. in practice however, during booting windows crashes with bsod or rather reboots immediately because of the changed partition table.

before using grub I merely switched between mbr blocks, one for booting windows and another for linux. this works nicely but had no boot-menu. I hoped grub could change that, but current versions don't offer access to mbr partitions when gpt is active. any attempts to change that resulted in empty partition-table from the point of view of grub.

I agree, my gpt.patch is not needed for general purposes and isn't well-thought-through. however, primary partitions are scarce, one for gpt, one for booting dos (which has very strict position-requirements) and one for booting windows-xp and similar (which because of bios has another set of position requirements to be bootable). in the end these 3 partitions will all be located about the first 40GB. if I want anything more than that I need a 4th partition and therefore have no space left for a boot-partition to be visible in windows. so for me dropping extended partitions is no option if I want to keep up compatibility with dos. the title says multibooting windows-xp and older! why do you think anybody would want that? it's because otherwise some programs we paid for wont work! I happen to have a machine which when cache is disabled can run old dos programs without changing them. isn't grub the right tool for that?

as for my hardware, you are right it isn't able to use the 3TB drive, I needed an adapter to plug the sata drive into my parallell-ata slot. bios does offer lba, but on factory-settings it's disabled. as I said, it was my decision to give 1/4 of disc to windows, I didn't need to limit myself here. but maybe others do. more exactly, I suppose I'm lucky my drive does inform bios it has 1023/63/254 at max in C/H/S (or has the adapter done that?) instead of simply refusing to work without extended read. don't know if the bios software would be capable to handle that.

the thought to put grub on my dos-partition did occur to me. unfortunately grub documentation does not cover how to put core-img into space that isn't start of a partition, and how to add gpt emulation into that mix. alternatively I could use blocklists (also not well documented, likely for a good reason), but I prefer to defrag it every now and then to improve the drive's magnetic charge, and of course I really don't want to give everybody write-access to my linux kernels and boot-configuration.

I really am not claiming my gpt.patch should be included in grub, that I only say of the other patches. it is one possibility to solve the problem of limited number of primary partitions. alternatively grub could handle its own sub-partition inside of the protective gpt partition. what partition type to use there though? the beginning of that partition is taken for gpt, so any sub-partition table would need to be located only at the end to ensure upwards-compatibility with gpt. you have any suggestions? or maybe allow a block-list to be mounted as a partition within grub?

to summarize: the problem to solve for this bug is booting of multiple windows versions on old hardware with huge discs, and to give them additional large partitions for storage. and all that should be managed from linux located beyond the reach of old dos/windows, beyond 2TB. as we likely agree, the problem is solved with the 2 patches, without the gpt.patch, as soon as config-creation has the sufficient interface. for doing that you need the ability to disable gpt, without grub losing the ability to read the partitions. you see any alternative solutions than my patches? I definitely wont help with user-interface till my patches are included or an alternative solution is found...

Piotr Sawuk <piotr5>
Mon 28 Dec 2015 07:50:16 AM UTC, comment #3: 

> it ends at 1565550314 since this is 1023/63/254 in C/H/S

Your BIOS supports 3TB disk but does not support Extended Read (LBA based)? May wonders never cease ...

> windows-xp refuses to work if the first partition is a protected one for gpt

Does it work if you put protective partition as the last one?

Anyway, I do not see any need for patches.

Ensure that both MSDOS and GPT labels have the same partition number for GRUB prefix and use prefix that does not include partition type, like


This will be found using both labels.

And you need not even modify grub-install for that, you can configure your Linux to install GRBU on partition (or do not install bootsector at all) and create tiny image that multiboots GRUB directly from (hd0,1)/boot/grub/i386-pc.

If you have any questions how to implement it, please use help-grub@gnu.org.

Andrei Borzenkov <arvidjaar>
Group Member
Sun 27 Dec 2015 09:48:34 PM UTC, comment #2: 

first off, gptsync by design wont work with extended mbr-partitions. the parent-partition must encompass all its sub-partitions, and therefore no gpt-partition can hold the extended mbr-entry while at the same time the individual extended sub-partitions are mirrorred on gpt. this could "easily" be changed  by extending gptsync to management of actual extended mbr. less intuitive but slightly easier to implement is to detect extended partitions while they're being attatched to mbr by gptsync and altering the partition-size accordingly. but neither of these solutions really is of much use for the ordinary user.

fact is, my use-case is a prepared mirroring of gpt to mbr, and I want to keep it. additionally to that upgraded windows-xp refuses to work if the first partition is a protected one for gpt, I must un-protect it first. I didn't manage to get it to work and nowhere on the net I found a solution. but if I turn off gpt then the boot-partition is gone and I can't load any modules nor do there exist any partitions at all. that's what my patches fixed. what's still missing for this bug is support in config-creation, and be it a command-line option. and actual distinction between OS requiring gpt or mbr partitions would be nice too...

if you say gptsync is sufficient, try it out! somehow I doubt it even works without my patches. and even if it does, the mbr.patch is needed along with the gpt-hybrid.patch to actually alter msdos1 from 0xee to 0x6e for windows-xp. well, I didn't try to swap protective mbr entry with some other partition, so maybe that would have worked. (i.e. maybe internally windos-xp omits a number if partition-type is 0xee and therefore my boot.ini was faulty.) as someone else complained here, changing boot.ini doesn't help, the partition table must be returned to the state where windows was installed or else windows probably wont boot.

and the 3rd point where my patches are needed is to change the active flag while booting from gpt partitions. old windows uses that flag to determine what is drive c:, so when installing multiple windows versions you need my mbr.patch!

also there is the point of interface-flexibility. fact is gpt and mbr are two partition tables for the same disc. this should be reflected in code. gpt is what grub should use by default, but the other possibility should be up to the user. IMHO gpt is an ugly hack, so its standard shouldn't be obeyed that strictly. hence the gpt.patch for making use of gpt even if it doesn't exist according to mbr! the OS should obey standards, not the boot-loader...

Piotr Sawuk <piotr5>
Sun 27 Dec 2015 03:29:21 PM UTC, comment #1: 

Why isn't already present  feature gptsync sufficient for this usecase?

Vladimir Serbinenko <phcoder>
Group administrator
Sun 27 Dec 2015 03:10:25 PM UTC, original submission:  

well, duh, the single feature many people were looking for needs to be mentioned in the feature-requests for grub too. officially the answer is that it isn't possible to run windows-xp 32bit or lower on such drives, and that's correct. however, when multibooting, you can put another os on the part which isn't accessible by mbr. in windows you'll see much less than 3TB and additionally maybe many boot-partitions visible in gpt will be invisible in mbr as they are hidden under the protective partition. in a way this provides some sort of safety since those parts of another OS wont be easily accessible form malware.

I should mention my situation: old amd-athlon-xp 32bit, with bios and no efi. after partitioning the 3TB disc I installed windows-xp. all these old windows versions and the linux boot partition must end before sector 80769024 or bios will refuse to boot, so  that's the exact sector where my mbr extended partition starts. it ends at 1565550314 since this is 1023/63/254 in C/H/S. I suppose with the right bios config I could have given more space to windows than those 750GB, but I really don't want some mess-up in bios to make the system unbootable. linux is installed after that. I found these values through experimentation, for your bios and disc and partition-table they might differ.

what I did to successfully create multiboot between gpt and mbr is altering the sourcecode of grub. linux is gentoo with sys-boot/grub-2.02_beta2-r7 and I put the following 3 patches in /etc/portage/patches/sys-boot/grub/

msdos.patch allows for part_msdos to detect the mbr even when a protective partition indicates gpt presence.

gpt.patch I need to read the boot-partition grub is installed in even when there is no protective partition in mbr. in linux I have installed /boot/ on a gpt partition hidden under the protective mbr-entry. haven't tested yet how grub will react when there is a disc without any gpt installed, with only mbr partitions. TODO: compare gpt with its copy at the end of the disc if it exists...

gpt-hybrid.patch I need to use the grub-install and similar tools for writing core.img since with above changes grub believes there are 2 partition tables, mbr and gpt. so I use gpt by default. although I'm not sure: does the pointer to mbr then need to be saved or is it stored elsewhere already? for future compability I'm rescuing it anyway...

after applying these patches and re-compiling and installing of the new grub on my boot partition, I also altered the grub.cfg file. at every linux menuentry I added:

insmod part_msdos
parttool (hd0,msdos1) type=0xee

and in windows-xp menuentry I do the same with "type=0x6e". (I suppose hiding and unhiding would work too.) beware that on a flash disc you'd probably better save the wear-off by actually checking if this will perform any change at all...

Piotr Sawuk <piotr5>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #35864:  msdos.patch added by piotr5 (1KiB - text/x-patch)
file #35865:  gpt.patch added by piotr5 (834B - text/x-patch)
file #35866:  gpt-hybrid.patch added by piotr5 (962B - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by arvidjaar (Posted a comment)
  • -email is unavailable- added by phcoder (Posted a comment)
  • -email is unavailable- added by piotr5 (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-10-11 phcoder Priority5 - Normal 3 - Low
    2016-03-02 phcoder Planned ReleaseNone 2.03+
    2015-12-27 piotr5 Attached File- Added msdos.patch, #35864
        Attached File- Added gpt.patch, #35865
        Attached File- Added gpt-hybrid.patch, #35866

    Back to the top

    Powered by Savane 3.13-0159.
    Corresponding source code