GNU 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: |
Piotr Sawuk <piotr5> |
Mon 28 Dec 2015 07:50:16 AM UTC, comment #3:
|
Andrei Borzenkov <arvidjaar>![]() |
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.
|
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>![]() |
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.
|
Piotr Sawuk <piotr5> |
Depends on the following items: None found
Items that depend on this one: None found
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 | Priority | 5 - Normal | ![]() |
3 - Low |
2016-03-02 | phcoder | Planned Release | None | ![]() |
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 |
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...