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

[Piotr Sawuk]

Follow-up Comment #4, bug #46763 (project grub):

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>system32hal.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...

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?46763>

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/