Re: Can Grub start Windows XP from "other" partition

[Ulf Zibis]

Hi Felix,

Am 21.11.2012 01:51, schrieb Felix Miata:
> On 2012-11-21 00:17 (GMT+0100) Ulf Zibis composed:
>
> > as I had forgotten, that I'm not subscribed to this list, I missed
> > observing the archive
> > <http://lists.gnu.org/archive/html/help-grub/2012-11/msg00048.html>
> > earlier. So please cc me while answering, e.g. by "Reply all".

Thanks for ccing me. But now I'm wondering, that your message is no visible in 
the archive.

> > On 2012-11-17 01:10 (GMT+0100) Ulf Zibis composed:
> > > On 2012-11-16 19:50 (GMT-0500) Felix Miata composed:
> > > Windows primary partitions cannot be "moved" except via sophisticated 
> > > understanding
> > >  and working knowledge of partitioning and the Windows registry.
>
> > Some time ago I was able to manually hide partition 1 and flag partition 2 for 
> > boot. In that case,
> > the "old" Windows was moved from primary partition 1 to primary partition 2. IIRC then 
> > the "old"
> > Windows booted properly without any registry change. In MBR I set:
> > 1BE: 80 -> 00
> > 1C2: 07 -> 17
> > 1CE: 00 -> 80
> > (This hack should not work, if the "old" Windows is moved into a logical partition in the 
> > extended area.)
>
> Why do you consider this changing of type and active a "hack"? ....

Because the partition table is changed statically, and partition 1 then is inaccessible from Windows 
on partition 2.
But I'm also fine with you, not considering it a "hack" :-)

> > IIRC, the boot manager, distributed with the old commercial Powerquest 
> > Partition Manager, used
> > exactly this technique to manage multi-boot on multiple Windows installations.
>
> Partition Magic's original releases included the IBM Boot Manager originally created by IBM for 
> OS/2. Partition Magic was created by OS/2 developers, was later bought by Powerquest, after which 
> support for OS/2 partitions was eventually dropped. About that time IBM BM was replaced by 
> Powerquest's proprietary boot manager. Automatic hiding and unhiding of primary partitions was and 
> remains and IBM BM feature.

Thanks for your details.

> > I would be happy, if Grub 2 could somehow do the same, and revert the change 
> > when booting from
> > another partition.
>
> Grub Legacy can do the very same partition type modifications at boot time. I doubt this 
> capability has been dropped from Grub2. I don't use Grub2, and install no bootloader during 
> installation of non-*buntu distros that do not offer to install Grub Legacy.

Can you point me to the paragraph in Grub Legacy docs, where this is described? This would ease me 
to possibly find that feature in Grub 2.

> >  This would necessitate to delete the Thinkpad Recovery partition or install 
> Linux
> > to a logical partition.
> > So still preferentially I would like Grub 2 to boot the new Windows 
> > installation from primary
> > partition 1 and the "old" Windows installation from any logical partition, but 
> > having the
> > systemdrive named as C: in both cases.
>
> As I previously wrote, to move a Windows primary to a logical takes a high level of expertise in 
> partitioning and registry. You won't catch me trying it. Better to make an image of the old 
> installation, and restore it if and when you actually need to boot it. If all you really want is 
> to preserve some files it contains, copying its content to a logical will suffice.

There are several old SW development configurations installed which I have to start again from time 
to time to compare when running stuck in my new installation. But this old installation is little 
broken, slow and overloaded by much old stuff like several mobile phone synch software over the 
years. So I've decided to set up a new Windows installation. Yes, just for the files it would be 
enough to move it to a non-runnable partition. When I come to the goal, that all configurations on 
the new installation will work as expected, then I can delete the old one.

> Two different primaries, each to act as C: when unhidden, is doable, but for the #2 Windows 
> installation to work the way you want requires you set the appropriate primary active and the 
> older hidden prior to installing.

Yes thanks, I know. In my case I first rescued the old Windows installation by help of CloneZilla, 
then first I deleted it before setting up the new Windows installation. Now I can restore the old 
one back to an other partition and have to find a way to make it runnable without corrupting the new 
one. The hidden-"hack" should work, but I would be more happy to find a more smart solution, best by 
help of Grub 2, preferably in a logical partition.

> Otherwise its installer may set the wrong one active and make it C: for the new installation. Its 
> installer seems perfectly happy to install more than one of itself to the same primary, given 
> enough space to do so.
>
> > I remember that I had read a tutorial about "duplicating Windows" to 2 
> > partitions for the purpose to
> > have a working installation and a test installation to try out dangerous things 
> > without corrupting
> > the first. I'm pretty sure, that the 2nd one was created by just copying the 
> > 1st, and if booted into
> > the 2nd, partition 1 appeared as D:.
> > Unfortunately I do not find this tutorial again by Google.

Do you have an idea, how this could have been possible, or do you know about a 
doc which may help me?

> > > Windows needs a primary to be C:, but it needn't be "installed" to C:.
>
> > In other words, Windows needs the NTloader, boot.ini etc. in the first 
> > Windows-visible-native-typed
> > partition which is always named as C:. If Windows itself is "installed" in any 
> > other other
> > partition, it would be named different, e.g. D:, E: ... right?
>
> Yes.

But how does it work, if there are 2 Windows installations with 2 NTloaders?
If Windows can only be booted by the NTloader from the 1st partition, how can Grub tell it to boot 
the Windows installation from the 2nd partition?


> If the plan is to delete to reclaim space from the old C: to allocate to a native Linux partition, 
> the original C: could be deleted, a new smaller one created in its place, and a repair 
> installation for the logical installation performed. If all you want is the old installation to go 
> away, you need only delete the files and directories that make up that installation from a Linux 
> or other type of maintenance boot, such as Hirens.

You mean to leave NTLoader, boot.ini etc. in C:, shrink it to some MB and run the new installation 
in e.g. D: in perpetuity? Well, that would work, but waste a "valuable" primary for ever and smells 
little dirty.

> >   > If you now have Grub on the MBR, the Windows installation will overwrite it 
> > with standard PC MBR
> > code. Before starting another Windows installation if you install Grub to your 
> > Ubuntu / partition,
> > then either of Windows or Linux can chainload the other via the standard MBR 
> > code Windows will
> > install, as spelled out on http://fm.no-ip.com/PC/install-doz-after.html which 
> > should help
> > understanding multiboot with more than one Windows as well as with Linux.
>
> > Do I understand right, that here Grub 2 can chainload Windows via the hda1, 
> > even if hda3 is the
> > "active" partition?
>
> Assuming Grub2 can do what Grub Legacy can do, and as long as hda3 is a native Linux filesystem 
> supported by Grub, then yes. Grub won't load Windows directly. That's NTLDR's job started via the 
> Grub chainload process.

Aha!
But if there are 2 Windows installations on a system, both listed in Grub's start menu, each has 
it's own NTLDR + boot.ini with only 1 default entry, how can Grub manage to chainload the right 
NTLDR, or instruct the NTLDR in the 1st partition to boot the Windows installation in the 2nd partition?
If I have understood right, Grub can boot Linux from any arbitrary partition, but in case of Windows 
it should fallback to the BIOS which boots the Windows installation from the "active" partition, 
which can only be one of the two.

Or ist it like this? :
Grub can start *any* NTLDR regardless of the "activeness" of it's enclosing partition. In case of 
the NTLDR of the 2nd Windows-visible-native-typed partition it will boot the 2nd Windows partition, 
but "see" the 1st Windows partition as C: and the 2nd as D:, which is the big problem here if it was 
originally installed on C:

-Ulf