Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

Make a proper Dual Boot

- - - - -

  • Please log in to reply
37 replies to this topic

#1
Dogway

Dogway

    Advanced Member

  • Member
  • PipPipPip
  • 391 posts
  • Joined 24-December 11
  • OS:XP Pro x86
  • Country: Country Flag
I was very lost because this is the first time I do this. I already have a dual boot but managed by windows.
I installed first XP x86 on first partition of first disc, that is C:, and later XP x64 on the second partition of the first disc, designated as J:.
Now for me that is a problem, is it possible to convert that J: to C:? And then make those partitions not see each other?
I went reading a bit and figured out I need a boot manager, then wondered which out of the many should I choose, finally decided that GRUB 2 could be a safe bet, but I don't find information about it, all I see involves Linux which I'm not interested. If ultimately it is not possible to convert J: to C:, it's not a big deal either, I can reinstall XP x64 in the second partition from scratch, but I'd like to keep C: untouched by all means.

Any help is welcome. Thanks!


How to remove advertisement from MSFN

#2
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,287 posts
  • Joined 14-September 05
  • OS:none specified
  • Country: Country Flag
I'll suggest NOT "Grub" but Grub4DOS (NOT the same thing). It's very easy to set up.
Download -
http://sourceforge.n...jects/grub4dos/
Tutorial -
http://diddy.boot-la...os/Grub4dos.htm

Two items used - "GRLDR" and "MENU.LST" in the C-drive. The tricky part IF you want to install BOTH to a (quote)C-Drive(unquote) is that you will have to TOTALLY hide the FIRST install so the SECOND install will "think" it's installing to "C"...

For that initial "trick" you MIGHT be able to use PTEDIT32 found here -
ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities
I'm making a "guess" that as long as it's in the "Active/Boot" state that it will boot in spite of the fact that it's "temporarily hidden". :unsure: You could make a basic LiveXP and place the program on the CD "just in case".

In any case, read the Tutorials thoroughly.... Flip/Flop the HDD Designations for each Boot. You can "cheat" and rename GRLDR<->NTLDR so the BootPart goes to NTGRLDR first and use MENU.LST to control the Booting/Hiding-unhiding.

Edited by submix8c, 20 April 2013 - 09:28 AM.

Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#3
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,287 posts
  • Joined 14-September 05
  • OS:none specified
  • Country: Country Flag
1 - Place GRLDR in ROOT of C-Drive
2 - Rename NTLDR to NTLDR.BIN
3 - Rename GRLDR to NTLDR
4 - Put the following in a file named MENU.LST in ROOT of C-Drive
color white/blue  black/light-gray
timeout 20
default 0

[[hook1]]
title Microsoft Windows XP Professional x86
unhide (hd0,0)
hide (hd0,1)
chainloader /NTLDR.BIN

[[hook2]]
title Microsoft Windows XP Professional x64
unhide (hd0,1)
hide (hd0,0)
root (hd0,1)
chainloader +1

[[hook3]]
title Reboot
reboot
title Shutdown
halt
You can STILL boot the x86 at this point. Your problem now is only to get the x64 into the second partition.

Edited by submix8c, 19 April 2013 - 10:02 PM.

Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#4
Dogway

Dogway

    Advanced Member

  • Member
  • PipPipPip
  • 391 posts
  • Joined 24-December 11
  • OS:XP Pro x86
  • Country: Country Flag
I don't have problems in using Grub4DOS, but why not GRUB 2? it's much newer and probably a bit easier to use.

The "hiding the partition" trick, I heard it from a video in youtube but for other reasons (not override boot loader from one OS to another). I know how to do that, the guy used gparted from a live CD so no risk there, if that's ok.

The part I'm 100% lost is about the boot manager, I will be full read on the tuto and videos when you confirm me I can't use GRUB 2.

#5
Dogway

Dogway

    Advanced Member

  • Member
  • PipPipPip
  • 391 posts
  • Joined 24-December 11
  • OS:XP Pro x86
  • Country: Country Flag
Don't I need gparted with that MENU.LST?
For simplicity I omitted that I have also an EISA partition on first disk, it's the first partition, XP x86 second, XP x64 third.
I'd need to change that, right?:

[[hook1]]
title Microsoft Windows XP Professional x86
unhide (hd0,1)
hide (hd0,2)
chainloader /NTLDR.BIN

[[hook2]]
title Microsoft Windows XP Professional x64
unhide (hd0,2)
hide (hd0,1)
root (hd0,2)
chainloader +1

Then what, reboot and reinstall XP x64? is that all?

Edited by Dogway, 19 April 2013 - 10:11 PM.


#6
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,287 posts
  • Joined 14-September 05
  • OS:none specified
  • Country: Country Flag
GRUB-2 is Linux. Grub4DOS is designed specifically for Microsoft, hence EASIER...
https://wiki.ubuntu.com/Grub2

GRUB 2 is the default boot loader and manager for Ubuntu...


Edited by submix8c, 20 April 2013 - 09:28 AM.

Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#7
Dogway

Dogway

    Advanced Member

  • Member
  • PipPipPip
  • 391 posts
  • Joined 24-December 11
  • OS:XP Pro x86
  • Country: Country Flag
No I don't want to argue, your quote doesn't state it doesn't work outside Linux, I also went to wikipedia and didn't read anything about it, that's why I asked you why I can't use GRUB 2. I will use what's more convenient and does the job.

Does your MENU.LST avoid the need of gparted?

Edited by Dogway, 19 April 2013 - 10:36 PM.


#8
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,287 posts
  • Joined 14-September 05
  • OS:none specified
  • Country: Country Flag
GPARTED = Move/Resize.

I installed first XP x86 on first partition of first disc, that is C:, and later XP x64 on the second partition of the first disc, designated as J:.

Two predefined so GPARTED is out of play.

GRUB2 and Linux/Windows - https://wiki.archlin...index.php/GRUB2

Edited by submix8c, 20 April 2013 - 09:27 AM.

Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#9
Dogway

Dogway

    Advanced Member

  • Member
  • PipPipPip
  • 391 posts
  • Joined 24-December 11
  • OS:XP Pro x86
  • Country: Country Flag
duplicated

Edited by Dogway, 21 April 2013 - 10:32 AM.


#10
Dogway

Dogway

    Advanced Member

  • Member
  • PipPipPip
  • 391 posts
  • Joined 24-December 11
  • OS:XP Pro x86
  • Country: Country Flag
I should ask then if with the MENU.LST file, do I still need PTEDIT32 as suggested?

Also I don't know if renaming ntldr to ntldr.bin, and naming grldr to ntldr is legit, sfc can detect and replace it back or lead to some troubles, or not? Shouldn't I install grub4dos with the grub installer or bootice first?

Also if I were to load NTLDR.BIN (upper case?) I would need to edit my boot.ini to only one entry, so I avoid the XP boot manager from popping up. XP x64 would load from the grub4dos boot manager (namely grldr named as ntldr by the "chainloader +1" call), is that right?


edit: finally found the holy page that explains mostly everything. There is one thing still, they explain how to hide boot partitions from each other, but I bet they will still be named after consecutive letters because OS install is done prior to GRUB4DOS, just as my current situation.

Edited by Dogway, 20 April 2013 - 12:41 AM.


#11
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,463 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
Ok, let's start again from scratch.

The grub4dos is NOT anymore on sourceforge (since YEARS).

The current release is here:
http://code.google.c.../downloads/list

ALWAYS use, unless specifically told to use a specific version, LAST one marked as "Featured", right now:
grub4dos-0.4.5c-2013-03-03
http://code.google.c...-03.7z&can=2&q=

There is NO NEED to rename anything to anything else :realmad: , on the contrary it is STRONGLY ADVISED to NEVER do that.

grub4dos is MORE flexible than GRUB (legacy) and GRUB (GRUB2) because it has been designed with features that both the original GRUB and the unneededly made complex GRUB2 completely miss.

But to simply dual boot two XP's there is NO need for using any third party bootloader/bootmanager, the NTDLR is enough.

The real issue here is:

Now for me that is a problem, is it possible to convert that J: to C:?

The quick answer is NO.
The long answer being, YES, it is possible but the procedure is so long, complex and prone to errors that it is NOT a smart approach.
Reinstalling from scratch is highly advised, really.

And then make those partitions not see each other?

Yes, it is possible.
Ideally you should have three partitions, (one for the boot files NTLDR/BOOT:INI/NTDETECT.COM) and two one for each XP, but it is doable even with your current setup.

You need to re-install the second instance of XP, however AND have a "separate" booting media (ideally a PE).

The key is the file migrate.inf, that you will find in \$WIN_NT$.~BT\ after running the first part of the setup, see:
http://www.911cd.net...showtopic=19663
the file is used to "migrate" ;) the current drive lettering (from the first XP install) to the second (new) one.
You need to edit it so that in the "new" install the first partition (the one with the XP 32 bit install) is NOT assigned to C: and INSTEAD the second partition (the one to which you are going to install the XP64) will get it. (in practice you will simply need to invert the drive letters, your migrate.inf will have two entries).

This way the C: letter will be assigned in the XP64 install to the second partition where the XP64 is installed to and the "other" letter will be assigned to the first one.
Later you can remove the drive letter from the "other" partition from each of the two XP's from Disk Management.
The issue here will be that to edit (if needed) BOOT.INI from the XP64 install, you will need to assign a drive letter to the first partition in order to access it.

The above is the "difficult way", if we are allowed to use grub4dos - at least for the mere install phase - it would be much simpler, as we can use it to hide the first partition (and thus there will be no need to edit migrate.inf).

The approach sketched by submix8c (set aside the renaming of grldr) is valid but it is "permanent", and at every other boot you will be setting/unsetting data in the MBR, something very like it can be used only during the install, and later provide a "normal" NTLDR choice between the two XP's.

Let me know which way you prefer, ask for directions BEFORE doing things.

jaclaz

#12
Dogway

Dogway

    Advanced Member

  • Member
  • PipPipPip
  • 391 posts
  • Joined 24-December 11
  • OS:XP Pro x86
  • Country: Country Flag
ok, I see, what you suggest is to interrupt the installation (when the Windows performs the first reboot after copying files) and boot from a Live CD, look for migrate, change letters, reboot and finish install of XP x64?
Here I will want to set x86 drive letter C: as a far letter, X: for example, so it doesn't displace my other known drive letters, D: (Data), E:, etc For my current XP x86 I don't care, second partition (where x64 will be installed) is already T:. Then I hide them, with disk management? is it possible?
I also didn't correctly understand your last sentence about boot.ini, mmm no I think I do, if I were to edit BOOT.INI isn't enough to boot to x86 and change it? I'm not very concerned about that I think.

Tell me if I missed something, actually I want the method that is less risky, about difficulty I funnily find this last one easier although (despite not being as straightforward). I think the risk here is to not miss the first reboot, otherwise the XP install continues.
For the grub4dos way I need to know more things I'd need to ask, specially for the menu.lst file, commands like norootverify, makeactive, etc
I'll do what you suggest me to.

Thanks for help.

Edited by Dogway, 20 April 2013 - 05:51 AM.


#13
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,463 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

ok, I see, what you suggest is to interrupt the installation (when the Windows performs the first reboot after copying files) and boot from a Live CD, look for migrate, change letters, reboot and finish install of XP x64?

Yep.

Here I will want to set x86 drive letter C: as a far letter, X: for example, so it doesn't displace my other known drive letters, D: (Data), E:, etc For my current XP x86 I don't care, second partition (where x64 will be installed) is already T:. Then I hide them, with disk management? is it possible?
I also didn't correctly understand your last sentence about boot.ini, mmm no I think I do, if I were to edit BOOT.INI isn't enough to boot to x86 and change it? I'm not very concerned about that I think.

Yes, but you need some background.
Drive letter is a "residual" of DOS, NT based systems do not really-really use drive letters (though 99.99% of programs running in them do use them).
I know it sounds "crazy" apparently, but that is how it works.
Boot.ini uses ARC paths (and knows nothing about drive letters), this is why a typical entry in it is like:
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
i.e. a partition/volume is accessed by it's address, in the above first partition (1) on first disk (0).
Then NT boots and the same volume is seen (in disk management or diskpart) in a similar way, the actual NT name will be \Device\Harddisk0\Partition1 or \Device\HarddiskVolume1 or \Device\Harddisk0\DR0 or , you can use the nice Sysinternals program Winobj:
http://technet.micro...s/bb896657.aspx
and also an GUID is assigned to it (try running the MOUNTVOL command), like \??\Volume{83092730-6bfc-11df-b90c-806d6172696f}.
then a drive letter is assigned to it (i.e. the Volume is mounted to a drive letter).
If there are no related settings in the Registry (namely in HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices ) the letter assignment is automatic (following a given set of Rules, first non-hidden primary on first disk is given C:, etc.) OR you can choose to NOT assign a drive letter (i.e. the Volume is NOT mounted) OR you can use INSTEAD of a drive letter (on NTFS only) a mountpoint see:
http://technet.micro...y/cc938934.aspx

So, the idea is not to "hide" the partition(s) but simply to NOT mount the "other" volume on each of the two installs.
The easiest is to use migrate.inf during setup to have it mount to a "different from C:" drive letter, let's say U:, and later, once install is complete, de-assign the drive letter from the volume.
The reference I made was about the impossibility of accessing the BOOT.INI (as the only item that may need to be edited) on the non-mounted volume, but it is only a matter of temporarily mounting it in order to do the editing.

Tell me if I missed something, actually I want the method that is less risky, about difficulty I funnily find this last one easier although (despite not being as straightforward). I think the risk here is to not miss the first reboot, otherwise the XP install continues.

Yes, but actually in the worse case you will have re-installed to the "same, wrong" drive letter, nothing catastrophical.
I gave you the "complex" way in order to see what you thought about it.
The key question here is if you have a working PE of some kind and you are familiar with it in order to do the editing of the migrate.inf.
Booting a grub4dos (from say a USB stick) and simply hiding the first partition (second in your case) before installing the XP 64 is far easier.
The only issue with this approach might be if the second partition (third in your case) is not a primary one but a volume inside extended.

For the grub4dos way I need to know more things I'd need to ask, specially for the menu.lst file, commands like norootverify, makeactive, etc

Well, as a matter of fact what most people fail to realize is that a menu.lst is correspondent to a batch file, i.e. it is a way to repeat a set of commands at will, in this case you need not a menu.lst, you simply want to run a few grub4dos commands on the command line.
Think at grub4dos like you would think at DOS: it is a (minimal) Operating System with a set of commands available.
Think at menu.lst like you would think at DOS' Autoexec.bat and Config.sys, a set of commands (and choices) that will execute when booting the OS.
The grub4dos guide by diddy:
http://diddy.boot-la...os/Grub4dos.htm
details enough most of the basic usage of the tool (though since the time it was written a number of new features were added to grub4dos).
You need to read just these pages:
http://diddy.boot-la...iles/basics.htm
http://diddy.boot-la...s/files/cli.htm
and something about disk swapping:
http://diddy.boot-la...es/map.htm#swap
and learn about three commands:
http://diddy.boot-la...mmands.htm#hide
http://diddy.boot-la...ands.htm#unhide
http://diddy.boot-la....htm#makeactive

I'll do what you suggest me to.

Thanks for help.

You are welcome.
If I were you I would boot from a USB stick with grub4dos on it (an easy way to create one is using RMPREPUSB: http://www.rmprepusb.com/ ), then issue these commands:

map (hd0) (hd1)
map (hd1) (hd0)
map --hook
root (hd0, 1)
ls

first three lines "restore" the disk order as if you hadn't booted from USB, the ls should show the contents of your current XP 32 partitions, it is just a check to make sure that device/partition numbers are correct.
Then:

root (hd0,2)
ls

this should list the contents of the partition on which you are going to install the XP 64.
You should (from the XP 32) delete the contents of this partition and make on it a "tag file", deleting the contents is needed because otherwise the XP install will probably use the current "wrong" drive letters from the XP 64 Registry and making on it a file like "thisis_64_bit_part.txt" is just a way to make sure that partition is the "right" one.
Then:

makeactive (hd0,2)
hide (hd0,1)

i.e. make active the third partition and hide the second one.
Then reboot and install the XP 64 "normally".
Once done that simply unhide the second partition, either booting to grub4dos and:

map (hd0) (hd1)
map (hd1) (hd0)
map --hook
unhide (hd0,1)

or by using *any* Windows tool oriented to managing partition tables/MBR, the mentioned PTEDIT32 would do, but also any disk editor will do as well or any other tool you are more familiar with.
When you reboot you will still have the XP64 only actually booting, this time the XP32 partition (since it is non-hidden) will get a drive letter, up to you if you want to change it or remove it alltogether in Disk Management.
Now you need to edit the BOOT.INI (on the XP64 partition) to add an entry for the XP32 partition.
This way the "main" bootmanager will be the one on the third partition.

If you want to use instead the one on the second partition you need to make that active instead (and add to the BOOT.INI on the second partition an entry for the XP64 install).
This is IMHO the less risky because you have handy a tool (the USB stick with grub4dos) with which one can fix any and all issues that may arise.

BEFORE doing any of the above, obviously, it is strongly recommended that you make a backup of the MBR "as is" (which BTW, since you have a partition that is - incorrectly - identiifed as EISA by disk management and that is a Recovery partition of some kind, is VITAL since besides the DATA also likely contains a non-standard MBR CODE allowing the access to the recovery parittion).

jaclaz

#14
Dogway

Dogway

    Advanced Member

  • Member
  • PipPipPip
  • 391 posts
  • Joined 24-December 11
  • OS:XP Pro x86
  • Country: Country Flag
I will answer you in detail later when I got some time, but wanted to a quick feedback before it. I forgot to say I have a working BartPE I made a few months ago. I tested it this morning and it works (explore files etc).
What I tried to test a few days ago was booting windows from USB (in order to install a nlited OS with integrated RAID drivers), I couldn't make it work, I also used it to install the drivers at F6 previously, tested with 2 USBs and BIOS didn't like any.
I have for these things instead a CD-RW, and a DVD-RW I bought a few days ago that currently has burned this mod of my unattended XP x64 with the integrated RAID drivers, this one I will use.

I read also earlier today all the pages from grub4dos, skipped the few pages that had nothing to do with my case.
I'll read your help throughly and ask later.
My hard disk is as follows:

- EISA
- x86
- x64
- Unpartitioned 8Mb (doesn't show in disk management)

Edited by Dogway, 20 April 2013 - 09:12 AM.


#15
Andromeda43

Andromeda43

    Retired PC Tech.

  • Member
  • PipPipPipPipPipPip
  • 1,018 posts
  • Joined 14-August 05
  • OS:XP Pro x86
  • Country: Country Flag
After reading most of the posts here, I have just one suggestion, based on 30+ years of my own PC experience and some very bad experience with Dual Booting, on a single Hard Drive.

I take a line from the railroad industry, "never the trains shall meet". And in my own PC I change that slightly to read, "never the OS's shall meet".

It's a fairly well known fact, that if one OS can see another OS, it will try to "fix" it. I don't remember the details now, but XP and Windows 7 seemed to mess with one another. One would erase the restore points created by the other. (or something like that)

So now I have XP, Windows 7 and Windows 8 all installed on separate hard drives, all set up to run on my main desktop PC, but never all connected to run at the same time. I only power up the drive, with the OS, that I want to run at any one time. The other drives remain UN-Powered so there is absolutely NO freakin' way that one OS can interfere with another OS.

If I want to take one OS-Drive out and use it elsewhere or reformat it and put on a different OS, there is absolutely NO way that's going to interfere with my main OS.

I know this flies in the face, of all the explanations given here.....but that's just my own take on the problem of dual booting.

Happy Computing!
B)
A person with experience is never at the mercy of a person with an argument.

#16
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,463 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
What I care to stress about is that NO such thing as an EISA partition exists (if not in the perverted mind of the good MS guys) since something like 25 years (and actually never existed as a "standard").

EISA is (was) an update/extension to the ISA bus:
http://en.wikipedia....rd_Architecture

On some machines equipped with that bus, a "hidden" partition containing the configuration utilities was created.

This partition had a partition ID of 12 which has NEVER been tagged (if not by the good MS guys) as EISA, as a matter of fact everyone know (knew) it as the Compaq Diagnostics partition:
http://web.archive.o...rimus/id233.cfm
http://www.ctyme.com/intr/rb-2270.htm
(Compaq was one of the "Gang of nine") because it was the firm that at the time made the first machines and particularly the first "commonly used" machines based on this bus.

The bus soon faded into oblivion, and was replaced by faster buses, such as VESA and later PCI.

But there was a precedent of a "hidden" partiion with id 12 that has been later used extensively by Compaq itself and later by other manufacturers (including Intel and IBM to name a couple) for Recovery or Diagnostics use, see:
http://www.win.tue.n...on_types-1.html

Microsoft NT based systems - trying possibly to be smart - tag in Disk Management the ID 12 partition as EISA instead of "unknown".

A partition ID that means "nothing" in the sense that it DOES NOT IDentify a particular filesystem as it can contain everything and the contrary of everything should not be tagged with something that actually does not exist (and possibly NEVER existed), IMNSHO.

Dell's Recovery partitions normally have a partition ID of DE, see:
http://www.goodells.net/dellrestore/
http://www.goodells.net/dellutility/
if XP tags a DE partition as "EISA" it is twice wrong :w00t: (and no, that doesn't make it a right :no: ).

jaclaz

Edited by jaclaz, 20 April 2013 - 11:31 AM.


#17
Ponch

Ponch

    MSFN Junkie

  • Patrons
  • 3,275 posts
  • Joined 23-November 05
  • OS:none specified
  • Country: Country Flag

It's a fairly well known fact, that if one OS can see another OS, it will try to "fix". I don't remember the details now, but XP and Windows 7 seemed to mess with one another.

There is no mention of a Windows 7 here, and there are simple workaround for your well known fact, that's what the OP is asking about . Saying "I don't believe in dual boot because it scares me" is not helping much, is it ? :unsure:
There are lots of ways of dual booting two XP on a same HDD, the basic is to understand what you do at first. Maybe try on an other blank HDD with OS you can mistakenly loose. Then you'll see how you can get them back up. Not much is lost until you format the wrong partition.
What I do is install both OSs, setting there own partition as active during install, then install Ranish Partition/Boot Manager that lets me choose at boot what partition becomes active and so what OS (always on C:) is booted. One C: becomes E: in the alternative scenario. My data partition (logical) remains D: in both cases. I never had a problem that I couldn't fix in 2 minutes.
Now Ranish is an old horse and I'm not sure how big a HDD it would support.

#18
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,463 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
@Ponch
Here we have a "third" factor which is the Recovery partition.
Until the exact nature (and booting/accessing mechanism) of it is ascertained, changing the MBR CODE is NOT a suitable solution :ph34r: , hence the suggestion to use a selection mechanism outside and beyond the MBR.

Risks connected to overwriting the MBR code (in the case it uses a proprietary solution like the mentioned "Softthinks") are detailed here:
http://www.msfn.org/...d-not-be-found/

JFYI, among the "self contained in the MBR only" bootmanagers, the current state of the art is (and it is since years) MBLDR:
http://reboot.pro/to...is-named-mbldr/

@androemda43
Only to counterbalance your report, I have run for several years a multiboot PC with:
  • DOS (6.22)
  • Windows 98 SE
  • Windows 2000 (actually TWO installs of it)
  • Windows XP
without a single itch/issue/problem whatever (and each OS - within it's filesystem/addressing limits - could "see" the other installs).

Certainly the multi-boot setup was accurately planned, and it is very possible that Windows 7 may have issues with XP, but I do have a couple system where there is Windows 7 installed as "main" system AND there is an XP "service" partition (and each can see the other) where I have had not (yet) any issue whatsoever, time will tell.
I have run for years double boot XP+XP and never had a single issue, so unless you know for sure that there is some issues for XP32+XP64, your recommendation of preventing them to "see the other" seems overcautious (and in any case Dogway is going to have them NOT "see the other").

jaclaz

#19
Dogway

Dogway

    Advanced Member

  • Member
  • PipPipPip
  • 391 posts
  • Joined 24-December 11
  • OS:XP Pro x86
  • Country: Country Flag
Ok, I got some time. It's a bit hard to grasp, but let's see.
First, thank for explanation on the "EISA" partition, guess it shouldn't be called like that, but still, it applies as a partition right? so I assume partition orders don't change.

-Since I will be booting grub4dos from CD I guess I can skip the first code block (hd maps).
-So to start, I delete everything on my x64 partition, that is T:, and put inside a "tag file" (what file?).

-make x64 partition (third partition, right?) the root partition with:
root(hd0,2)
ls


-make the partition active (as in C:), while hiding current C: (my second partition after Dell diagnostic tools partition)
makeactive (hd0,2)
hide (hd0,1)


-reboot, and install XP x64 (I guess that at this stage on the Windows Install blue console x86 partition will be now hidden, true?), let it do the unattended, etc. reboot and load again grub4dos from CD to unhide XP x86 partition, make it active (default OS) by typing:

unhide (hd0,1)
makeactive (hd0,1)


-reboot again, it will boot into the only available OS at the moment that is XP x86. Change boot.ini to allow XP x64 to be accessed through default XP boot manager. Hide T: partition (C: on the XP x64 install) from Disk Management. Hide x86 partition from x64 OS as well.

FINISH


Well, correct my process if something is wrong. Also I have many questions:
1. what tag file do I place onto the empty third (x64) partition?
2. Can't I hide each other partitions by using the hide commands? or is it because
3. in the end we are not installing grub4dos right?, but only using them as an indirect way of managing the migrate file from the command line. And the reason for that is due to -> an unusual "recovery partition", which I called EISA, and contains the "Dell Diagnostic Tools" (this is actually a Precision 690 Workstation), so not recommended to rewrite MBR with grub4dos.
4. I would ask you then, how to hide them with disk management?, but I don't think that's too critical to know by now (probably well documented around?), more importantly, how to backup MBR? This should be the very first thing to do, true?


You are a master, have all the variables covered. Let me know if you need any info on my system.
edit: I access the Diagnostic Tools by pressing F12 at the very start of the boot process, in the same panel I am to press F2 to enter BIOS. Later it takes me to a similar panel to that of F8 with certain entries (Boot from each disk, load from CD, Reboot, Recovery, Diagnostics, etc) Youtube link

Posted Image

Edited by Dogway, 21 April 2013 - 10:42 AM.


#20
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,798 posts
  • Joined 12-May 07
  • OS:none specified
  • Country: Country Flag
Carefully re-read jaclaz's instructions, taking notes if it will help you.

As to the tag file, he said:

[...] making on it a file like "thisis_64_bit_part.txt" is just a way to make sure that partition is the "right" one.


So make a txt file "thisis_64_bit_part.txt" with anything in it that you want. The purpose of it, as I understand it, is so that you can easily do a "ls" command, the grub4dos version of "dir" I believe, to confirm that you are in the right partition so you don't overwrite something you didn't mean to.

As to how to hide partitions using Disk Manager, he said:

So, the idea is not to "hide" the partition(s) but simply to NOT mount the "other" volume on each of the two installs.
The easiest is to use migrate.inf during setup to have it mount to a "different from C:" drive letter, let's say U:, and later, once install is complete, de-assign the drive letter from the volume.


meaning that in Disk Manager that you simply "de-assign the drive letter from the volume" and it will then be hidden, if I understood correctly.

Cheers and Regards

Posted Image


#21
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,463 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

-Since I will be booting grub4dos from CD I guess I can skip the first code block (hd maps).

Yes :thumbup , this is needed only if you boot form a hd-like device, such as a USB stick or external hard disk.

To the numbered points:
1. *any* file, the idea is just to have a file that you can see with the ls command (in order to make sure that you are on the "right partition". I suggested a (can be an empty file or a text file containing something like "Hello peeps! :)") named "thisis_64_bit_part.txt" but you can use any.
I guess an explanation needs to be made.
You are used to see partitions on the disk through Disk Management which shows them as a graphical map of the hard disk, i.e. representing them as a "stripe" with the beginning of the disk on the left and the end on the disk on the right, and with the various partitions represented in the order they occupy on the hard disk.
I will try to be more clear, the "first" partition in disk manager is the partition the occupies the first part of the disk (leftmost), "second" is the one to the right of it, etc, etc.
BUT a number of other addressing methods for partitions use NOT their position on disk but INSTEAD the position of the corresponding entry in the partition table.
The partition table has 4 "slots" or "entries" for writing partition address data (let's for the moment set aside Extended partition and Volumes inside it).
These entries are numbered, in grub4dos:
#0 is first partition entry
#1 is second partition entry
#2 is third partition entry
#3 is fourth partition entry
it is perfectly possible (and happens more often than not, and especially when a "Recovery" partition is involved in the setup) that a partition entry does NOT correspond to the order in which it is placed on disk.
Example, your "Recovery partition" may well be written to partition entry #0 BUT being placed at the END of the disk, OR, in one of the changes made in the past on the disk partitioning, entry #1 could be empty.
So a sensible thing to do (better be safe than sorry) is to check which partition corresponds to a given partition entry.
In grub4dos making a given partition (in the sense of the partition whose address data is written to a given partiion entry) root and then check which files are on it with ls is a quick way to make sure that you are dealing with the "intended" partition.

2. I am not sure to get the "meaning" of the question, right now, from what you report you have three partitions:
  • the Recovery partition (which is already hidden, otherwise your first - 32 bit - XP install would have NOT gotten the C: drive letter)
  • the partition (non hidden) where you have already the XP 32 bit installed (that you need to hide when installing the XP 64 bit)
  • the partition (non hidden) where you are going to install the XP 64 bit (that needs to remain non hidden in order to install to it)

3. Yes and no.
NO, as a matter of fact we are going to use grub4dos simply as a MBR partitiion table editing tool, you can do the same booting from a DOS floppy with (say) MBRwizard, or from a PE and using MBRFIX or *any* disk editor. grub4dos is simply more handy as it is easily bootable (from CD/DVD in your case), has NTFS read access, has direct (and IMHO simple/linear syntax) MBR partition table access.
YES, the idea is to NOT touch the MBR (i.e. NOT writing the grldr.mbr to the MBR AND following few sectors) because this may cause the impossibility to boot again the Recovery partition.
The "enhancement" (let's call it "difference" ;)) with the solution proposed by submix8c :thumbup is that in his solution grub4dos (still NOT installed, but called/invoked through the renaming of the files approach) the grub4dos becomes a "permanent" part of the booting sequence, whilst in the one I proposed grub4dos is just a tool to manage the MBR partition entries at install time.
If something is not really-really needed I find it better to NOT make it a key step of booting "forever", though nothing prevents from (as an eaxample) haveing grub4dos as a "third option" in the BOOT.INI.

I am FIERCELY against the concept of the RENAMING of the files (still better be safe than sorry) before or later it could happen that because of you, or a stupid windows update or anyway *somehow* the NTLDR file (which is a grldr under false name) is overwritten (or that some stupid software checks that NTLDR is actually the real NTLDR or whatever) creates an unbootable system or some other "damage" (additionally the renaming of the grldr may cause issues in more recent grub4dos builds)
The original idea of renaming was by spacesurfer:
http://www.911cd.net...showtopic=18031
but later it was (hopefully) "bettered" by this:
http://reboot.pro/to...-alpha-release/
i.e. by changing the filename invoked by the bootsector, so that files kept their original names.

4. There is NO provision in Disk Management to hide/unhide partitions AFAIK. Why do you think there are so many "third party" tools to manage the MBR? :unsure:
You will find tens of (wrong :ph34r: ) references about Diskpart being capable of hiding partitions, while most the connected commands are about assigning or removing the assignment of a drive letter to a volume, example:
http://forum.thewind...g-diskpart.html

There is however a way is to set a given ID to a partition, this is a RIGHT example:
http://defaultreason...-with-diskpart/
Basically (at least for MS "recognized" parition ID's) any partition ID that begins with 1 means that it is a hidden partition of the type ID-10, like:
16 is a hidden partition ID 06
17 is a hidden partition ID 07
etc.

About backing up the MBR, we are before a doubt.
To backup ONLY the MBR the easiest would be a GUI tool, such as HDhacker:
http://dimio.altervista.org/eng/
the MBR is the first sector of the \\.\PhysicalDriven (n is the same as DISK #-1 in disk management or diskpart, i.e. first disk is \\.\Physicaldrive0, second disk is \\.\PhysicalDrive1, etc)
BUT in your case we don't know whether the "Recovery partition booting mechanism" relies on:
  • the MBR only
  • the MBR and *some* hidden sectors
  • the MBR and all (normally 62) hidden sectors, i.e. first 63 sectors
  • none of the above and the code is in the BIOS
To be on the safe side I would backup:
  • only the MBR
  • the whole first head (63 sectors)
  • the whole set of hidden sectors (if not 63)

using a command line tool like dsfo (part ot the dsfok toolkit):
http://members.ozema...eezip/freeware/
the corresponding commands would be (choose the "right" n, for the first two :
dsfo \\.\PhysicalDriven 0 512 C:\mymbr.bin
dsfo \\.\PhysicalDriven 0 32256 C:\myhid.bin
for the third one you need to check how many hidden sectors you have (normally in a disk partitioned under XP is 63, but if it has been partitioned in Vista :ph34r: or later this number maybe different, normally 2048)
To check them quickly you can use the partition editor here (dtidata partition repair tool):
http://www.dtidata.c...tion_repair.htm
http://www.dtidata.c...repair_tool.exe
99.99% you will have a partition with "Rel Sectors" (i.e. "hidden sectors" or "sectors before" or LBA offset of partition) of 63, in the 0.01% in which this does not happen, you will need to multiply it by 512, example for 2048 sectors 2048*512=1048576 and thus:
dsfo \\.\PhysicalDriven 0 1048576 C:\myhidall.bin

Take your time digesting the info, maybe I pushed too much in a single post....

jaclaz

#22
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,287 posts
  • Joined 14-September 05
  • OS:none specified
  • Country: Country Flag
I HAVE to chime in! ( sorry - :blushing: )

Please bear in mind the difference between "Utility Partition" and "Recovery Partition". They may or may not be the same partition. It has yet to be ascertained if the second truly exists in order to (e.g.) "Restore To Factor" (from some sort of Images) -AND- are one and the same.

AFAICR, just the Partition Type is necessary for the BIOS (the F-whatever key) to boot to it, with or without the MBR code. I'll be glad to prove that "theory" with my Dell if you wish, but I DO believe I did that with my Brother's Dimension 4600 using it as a LiveXP/Recovery Solution (from the BBS Selection). How ODD that it was a Clean Install/Setup and used the Standard XP MBR, only having Type=DE in the first Partition (the Second as the "Standard" Type=07 Bootable) and WORKED.

Don't confuse the two or the ABSOLUTE necessity of the MBR code to access it. It may ONLY be needed IF Recovery is possible. :unsure: Easy enough for the OP to prove by backing up the Sector(s), using the MBRfix to "replace" it, then attempting to Boot to it via the BIOS Selection. IF it works, then the MBR has absolutely nothing to do with anything and IF there is absolutely NO Recover To Factory available then it becomes a moot point, not so? ;) (You can ALWAYS put the Original MBR back.)

I shall now again bow out...

Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#23
Dogway

Dogway

    Advanced Member

  • Member
  • PipPipPip
  • 391 posts
  • Joined 24-December 11
  • OS:XP Pro x86
  • Country: Country Flag
I was referencing a line of this post
"Later you can remove the drive letter from the "other" partition from each of the two XP's from Disk Management."

What is this for, "hide" my partition, unmount it?
What should I do then, the above Disk Management procedure, or the Disk Part one by setting a +10 new ID? I remember having issues with DiskPart on XP before, being unable to format a drive with custom block size.

I will backup the recovery partition right away in those explained 3 ways, but to clear things up yesterday I made a video of my system booting that you might have missed.

edit: I access the Diagnostic Tools by pressing F12 at the very start of the boot process, in the same panel I am to press F2 to enter BIOS. Later it takes me to a similar panel to that of F8 with certain entries (Boot from each disk, load from CD, Reboot, Recovery, Diagnostics, etc) Youtube link

Posted Image

I made it so you could tell me exactly if what I have is a recovery partition or a Utilities partition (I read that Utilities normally go first, and recovery last in partition order).
And in case that's not enough to know, ask you how can I know it (what exactly to backup, if any). FYI my system came installed with XP x64, if that helps.

Either way, I'm gonna backup those three meanwhile, so rather than "what to backup", "what to delete" (or replace, when a fix is called)
edit: backed up the MBR, and whole first head. Rel sectors showed 63, so only backed up those two.


submixc8: Is it risky to test that what you say? I already have the backups, anyway I will follow jaclaz guidelines in case there's a better way to know what kind of partition/booting mechanism I have.

Edited by Dogway, 22 April 2013 - 12:28 AM.


#24
Ponch

Ponch

    MSFN Junkie

  • Patrons
  • 3,275 posts
  • Joined 23-November 05
  • OS:none specified
  • Country: Country Flag

Please bear in mind the difference between "Utility Partition" and "Recovery Partition". They may or may not be the same partition. It has yet to be ascertained if the second truly exists in order to (e.g.) "Restore To Factor" (from some sort of Images) -AND- are one and the same.

AFAICR, just the Partition Type is necessary for the BIOS (the F-whatever key) to boot to it, with or without the MBR code. I'll be glad to prove that "theory" with my Dell if you wish, but I DO believe I did that with my Brother's Dimension 4600 using it as a LiveXP/Recovery Solution (from the BBS Selection). How ODD that it was a Clean Install/Setup and used the Standard XP MBR, only having Type=DE in the first Partition (the Second as the "Standard" Type=07 Bootable) and WORKED.

I'm pretty sure I moved a Dell Diagnostic partition to the end of a disk two years ago and it was still working. Also keep in mind that Dell keeps changing the way they arrange their stuffs.That PC had 4 primary partitions out of the box. Thank you Dell.

#25
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,463 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
There were TWO points I was trying to make:
  • there may be n different ways the "recovery" or "service" partition is booted
  • there are (at least) THREE different ways to avoid automatic drive lettering

#1:
Ponch just confirmed what was hinted before and partially documented on mentioned Dan Goodel's pages, DELL (which BTW has historically and gerically a "quirk" for introducing changes in almost *anything* from BIOSes to XP install disks, and generally adopting NON-standard solutions) the "DE" partition can contain everything and the contrary of everything.
As well the video does not in any way provide means to know (for sure) the exact mechanism that is used to boot to the "DE" partition, the F2 may cause a jump to a routine fully embedded in the BIOS, chainload a "special" DELL MBR passing to it a "switch" parameter, chainload directly another sector on the hard disk, there are many possibilities.
Not knowing exactly the specific way the specific machine uses, backing up everything is logical, since it costs nothing (in terms of money) and very little (in terms of time).

#2:
The generic problem is the following:
How is it possible to avoid that a partition or volume is auto-mounted and/or that drive letters are automatically assigned to it?
Normaly an XP will autoassign drive letters along an algorithm that is detailed here:
http://www.msfn.org/...ers/page__st__7
but for what is needed here is VERY simple:
First Primary partition on first hard disk drive gets letter C:

There are at least THREE different ways to avoid that:
  • (ONLY valid at Setup) use a migrate.inf to force the assignment of another letter to that partition (and force the C: to the other partition)
  • (valid BOTH at setup and during "normal" operation) hide the First Primary partition in the MBR partition table, this way NO letter will be assigned to it.
  • (ONLY valid during "normal" operation) force the unmount of the partition and/or assign to it NO drive letter

#1 is the most complex and thus more prone to error
#2 is the most simple BUT in the case of a dual boot needs a third party boot manager capable of hiding/unhiding partitions
#3 is simple and needs NOT the use of a third party boiotmanager BUT cannot be used at setup (actually during setup this aproach is the same as #1 and needs a migrate.inf)

The idea is to use the #2 (simpler) during setup and #3 (simple and needing not third party tools) during "normal operation".
One of the possible ways to do #2, i.e. hide the partition (in the MBR) through the use of grub4dos has been given, you can use any other tool to do the same.
Once the XP is installed, you unhide the partition (again any suitable tool can be used) and implement #3 by using Disk Management or Diskpart (or a direct Registry editing, whatever suits you).


jaclaz




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users