9 replies to this topic

[CapnM]

Well, I've been successfully using Grub4Dos on flash drives, learning just enough to be dangerous, and becoming bewildered by the scattered information available

Now I want to attack a WinXP box, multibooting WinXP, Win7, and a few test OSs / instances of Windows.

Here's how I'm thinking of setting up my system drive (data drives are separate):

A tiny primary partition just for Grub4Dos

Two primary partitions for WinXP/Win7

An extended + logical partitions for additional instances of WinXP, etc

Is this likely the least troublesome way to set it up so I can swap drive images in and out as I mess about?

In order to keep WinXP/Win7 happy I understand I should hide all the other system drive partitions with Grub4Dos menu.lst commmands when I boot, and delete the key(s) [HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices] before saving images - thus Winxx should recreate it's drive table, with itself in C:, on bootup.

Does that make sense? I'm hoping someone will redirect me if I'm going the wrong way here.
I'm afraid this is too easy to be true .... and I'm missing something big.

If the above is actually the right way to go -- what's the easiest way to maintain menu.lst? I don't think I can have its partition visible from another OS (without screwing up that OSs drive assignments) - does that mean I have to install an OS + text editor with it in p0?

Finally - If I do manage to confuse WinXPs drive assignments - what's the best way to recover? Same question -Win7?

thanks

[was_jaclaz]

It seems to me like you are overcautious.

grldr and menu.lst can be in ANY partition, even a hidden one, one of the ADVANTAGES of grub4dos is exactly that it won't need a dedicated partition.

NT based systems use "assigned drive lettering", thus, once you have installed them properly, they won't be "mixed up easily.

The usual advice I give, that usually is completely ignored , is to NEVER have two SAME drives have two DIFFERENT drive letters under two DIFFERENT Operating Systems.

Before or later, you will be booted in one OS, think that you want to delete a file on (say) D:\ Volume, do that, to later find that you thought wou were bootend in another OS, and deleted the file from the wrong volume.

Of course you can have a multiboot-setting in which only one Volume is visible to the OS, but that will create you a problem when you have to exchange Data between two OS/Volumes.

Particularly, all NT based systems, including XP and Windows 7 are DESIGNED to be run flawlessly from Logical Volumes inside Extended partition, so, it makes no or little sense to use two primary partitions for them, all you normally need is a (and it can be very small) Primary partition to hold the system boot files (i.e. NTLDR-BOOT.INI-NTDETECT.COM and BOOTMGR-boot/BCD).

The above approach can be considered slightly safer for a number of reasons:
http://www.msfn.org/...964-page-6.html

Moreover if the small Primary partition is FAT, you can use practically everything to edit it's contents, including menu.lst and Boot.ini.

The least you fiddle with [HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices], the more likely is that you won't find yourself with an unbootable system, Windows "wants" to find the files it needs on the volume (drive letter) it was installed to, deleting the whole [HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices] is NOT advised. (until you really know what you are doing).




jaclaz

[CapnM]

My reason for putting Grub4Dos in its own partition is to segregate it from the OS partitions.

I want each OS to believe it is in the C: volume, which is why I think I must hide the Grub4Dos partition.

For example, I anticipate taking an OS volume image from another (similar hardware) box, messing with it, possibly sending it back changed.
(I know there can be hiccups moving windows from machine to machine - that's an unrelated issue)

And, in agreement with your advice, my data volumes (on other drives) should maintain their assignments across OSs.

So, yes, I'm looking at having only one volume (on hd0) visible to an OS - I'd actually prefer not to be able to exchange data between OS volumes, just between data volumes.

Particularly, all NT based systems, including XP and Windows 7 are DESIGNED to be run flawlessly from Logical Volumes inside Extended partition, so, it makes no or little sense to use two primary partitions for them, all you normally need is a (and it can be very small) Primary partition to hold the system boot files (i.e. NTLDR-BOOT.INI-NTDETECT.COM and BOOTMGR-boot/BCD).

Ah! Good to know. I trusted Linux would be fine in logical volumes, wasn't sure about Windows.
So just one small primary for Grub4Dos. No need for another primary. Windows boot files will stay on their OS's logical volumes.
Right?

I'm still stuck with circumventing "assigned drive lettering" --is there a better way than just deleting [HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices]?

It seems like that should work as long as I'm happy with the drives in default (hardware) order, no gap letters.

Does a logical volume on hd0 get assigned before a primary on hd1? I seem to recall early Windows assigning all the primaries before the logical volumes -- but I could easily be mistaken.

Thanks

[was_jaclaz]

Ah! Good to know. I trusted Linux would be fine in logical volumes, wasn't sure about Windows.
So just one small primary for Grub4Dos. No need for another primary. Windows boot files will stay on their OS's logical volumes.
Right?

If you use grub4dos to bypass bootsectors, yes, if you want to directly boot the bootsector on logical volumes you need to "fix" them:
http://www.goodells.net/multiboot/
http://www.goodells....boot/ptedit.htm

I'm still stuck with circumventing "assigned drive lettering" --is there a better way than just deleting [HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices]?

What I am failing to explain properly is that YOU SHOULD NOT delete the whole key.
You should either choose:

• to leave drive lettering as Windows makes it (of course we are talking about the System volumes)
• to assign a drive letter through migrate.inf or othe method at install

once letters are assigned, you should leave them alone.

It seems like that should work as long as I'm happy with the drives in default (hardware) order, no gap letters.

Yes, but if you start hiding paritions you will soon find yourself in a mess.

Does a logical volume on hd0 get assigned before a primary on hd1? I seem to recall early Windows assigning all the primaries before the logical volumes -- but I could easily be mistaken.

It's not so straightforward read this:
http://www.msfn.org/...nt-t109717.html
and links given in it.
Remember that DOS uses a slightly different assignment order AND that the use of "strange" filesystems may mess things even more.

A rather complex approach that may however be of interest to you is this one:
http://www.boot-land...?...ic=7138&hl=




jaclaz

[CapnM]

What I am failing to explain properly is that YOU SHOULD NOT delete the whole key.

You are explaining, I'm just not quite ready to listen -- yet

How's this?

hd0,0 small active hidden primary partition for Grub4Dos
hd0,1 extended partition
hd0,2 - hd0,n WinXP/Win7 system volumes to be C:
hd1,0, hd2,0 data drives D:, E:

Now I take an image from a simple hd0,0=C:, hd1,0=D: system
(With the whole key deleted)
Put the image in say, hd0,3
hide all other volumes on hd0
Grub4Dos chains to ntldr/bootmgr in hd0,3

Hopefully, Win boots up assigning C: to the system volume, D:=hd1,0, etc

It seems as though this should work.

One possible problem - I'm still not sure what happens to drive assignments when the only unhidden volume on hd0 is a logical volume (the system volume). Maybe I'm back to:

hd0,0 small active hidden primary partition for Grub4Dos
hd0,1 primary for Winxx system
hd0,2 primary for Winxx system
hd0,4 etc logical for Winxx system
where I use the primary partitions for swapping OSs in and out, the logical volumes for more permanent installs

Or maybe I shouldn't try to quick swap OSs here, but use virtual machines for that ..... but this seemed like it could be much simpler ....

Thanks again, I know I'm being either stubborn or dense

[was_jaclaz]

Put the image in say, hd0,3

What do you mean by "put the image"?

Copy the image file to a file on the volume?

Or "restore" the image to the volume?

I guess the latter,

Hopefully, Win boots up assigning C: to the system volume, D:=hd1,0, etc

It seems as though this should work.

and yes, it may work.

Please note that there is no need to have the partition with grub4dos primary and expecially NOT active (cannot say what happens to the NT drive lettering sequence if only a hidden active primary is found )
Take into account also that if you have NO primary (visible ) partition on first hard disk, you CANNOT have any primary on 2nd, 3rd, etc, hard disks as the C:\ will be assigned to the first Primary found across ALL hard disks (starting from the first).

Re-read this:
http://www.dewassoc....riveletters.htm

Though I would be really curious what is the actual final goal and where these images come from, as besides the drive letter assignment you will have (both several and severe) problems with actual drivers/hardware detection, etc. if the images come from different machines.



jaclaz

[dog]

Don't let Jaclaz convert you with his seditious logical whispers, primary is the way to go
Historically his side had the advantage of numbers, as the good primary warriors were limited to a quartet, while the evil logical army could spread widely... But with the grub4dos partnew command, we can even the odds with extra Sneaky Ones^TM
I keep grub4dos on a cd as a boot manager, makes things easier to recover after the inevitable accident...
The partnew lines below are for a 120GB disk with wierd geometry, except for the 1184MB one, and are set up to match the way xpsp3 setupldr partitions things.

color grey/black white/bluedefault 0fallback 1timeout 10title (hd0)+1rootnoverify (hd0)chainloader (hd0)+1title wipe PBR then /I386/SETUPLDR.BINdd if=(cd)/512zero of=(hd0) bs=512 count=1 seek=63find --set-root /I386/SETUPLDR.BINchainloader /I386/SETUPLDR.BINtitle (hd0,0)+1chainloader (hd0,0)+1rootnoverify (hd0)title dd ms440 (hd0)dd if=(cd)/ms440 of=(hd0) bs=440 count=1title dd if=(cd)/512zero of=(hd0) bs=512 count=1dd if=(cd)/512zero of=(hd0) bs=512 count=1title dd if=(cd)/512zero of=(hd0) bs=512 count=1 seek=63dd if=(cd)/512zero of=(hd0) bs=512 count=1 seek=63title sig ffffffff (hd0)dd if=(cd)/ff of=(hd0) bs=1 seek=440dd if=(cd)/ff of=(hd0) bs=1 seek=441dd if=(cd)/ff of=(hd0) bs=1 seek=442dd if=(cd)/ff of=(hd0) bs=1 seek=443title partnew --active (hd0,0) 1 0x07 0-20GBpartnew --active (hd0,0) 0x07 63 41942817title partnew --active (hd0,0) 1 0x07 2425748 = 1184MBpartnew --active (hd0,0) 0x07 63 2425748title partnew --active (hd0,0) 1 0x07 2434257 = 1189MBpartnew --active (hd0,0) 0x07 63 2434257title partnew (hd0,0) 0 0 0partnew (hd0,0) 0 0 0title partnew --active (hd0,0) 2 0x07 20-40GBpartnew --active (hd0,0) 0x07 41942880 41942880title partnew --active (hd0,1) 2 0x07 20-40GBpartnew --active (hd0,1) 0x07 41942880 41942880title partnew (hd0,1) 0 0 0partnew (hd0,1) 0 0 0title partnew --active (hd0,0) 3 0x07 40-60GBpartnew --active (hd0,0) 0x07 83885760 41942880 title partnew --active (hd0,0) 4 0x83 60-80GBpartnew --active (hd0,0) 0x83 125828640 41942880 title partnew --active (hd0,0) 5 0x83 80-100GBpartnew --active (hd0,0) 0x83 167771520 41942880 title partnew --active (hd0,0) 6 0x07 100-110GBpartnew --active (hd0,0) 0x07 209714400 20971440

[was_jaclaz]

But with the grub4dos partnew command, we can even the odds with extra Sneaky Ones^TM

Really?

A rather complex approach that may however be of interest to you is this one:
http://www.boot-land...?...ic=7138&hl=

jaclaz

[CapnM]

Please note that there is no need to have the partition with grub4dos primary and expecially NOT active (cannot say what happens to the NT drive lettering sequence if only a hidden active primary is found dubbio.gif)

Whoops - I think you just saved me from a basic mistake.
So back to basics - having installed grldr.mbr to the mbr, active partitions are irrelevant, grldr.mbr knows where to look for grldr, so my Grub4Dos partition could be primary or logical, hidden or not Not sure how that would help me, but good to remember. I suppose it does give me the option of three (not just two) primary partitions for OSs. Not sure that's useful either

I may even end up putting Grub4Dos (or at least menu.lst) on a data drive. hmmm....
I think a plan is falling together now...

Take into account also that if you have NO primary (visible unsure.gif) partition on first hard disk, you CANNOT have any primary on 2nd, 3rd, etc, hard disks as the C:\ will be assigned to the first Primary found across ALL hard disks (starting from the first).

I was wondering if that might not be the case.

So combining my ideas &what Goodell said in the link you provided.
At any given time I will have one unhidden volume (could be primary or logical) on hd0, to be assigned C:
I restore an OS image to that volume - having deleted the mounted devices key before imaging.
If it is a logical volume, in order to convince Winxx to assign it C: I boot once with hd1,0 etc (D:, etc) hidden so it is the only unhidden volume on the machine. Then I can unhide the data drive partitions. Winxx will remember the drive assignment and live happily ever after.
If it is a primary partition the extra step of hiding/unhiding the data drives is unneeded.

Do you see any other pitfalls I need to be saved from?
I think I'm ready to try this when I have some fritter time available in a few days.
Many thanks!

Though I would be really curious what is the actual final goal and where these images come from, as besides the drive letter assignment you will have (both several and severe) problems with actual drivers/hardware detection, etc. if the images come from different machines.

The images come from substantially similar hardware, or some times, same hardware, different time. Drivers haven't been a problem. Virtual machines consumed so much fritter time it was easier to just physically swap in a drive. This looks even easier. (If it works).

[Karl1982]

I multiboot WinXP and Win7 both at home and at work without any registry editing. I assume from your post you understand the concept of MBR vs bootsector, correct?

If you were to play this game Microsoft's way, you would install each OS in order from oldest to newest using only primary partitions for them. Each one rewrites the MBR, makes its own partition active, and adds a line to its own boot loader to boot the previous OS. That's the easiest way to start. Then once you're done, you just blow out the MBR with grub4dos anyway.

If you also want to install Ubuntu, you can install it at any point during this (because it plays nice). My preferred method is on the last screen before it starts installing, there are some advanced options where you can tell it where to install its version of GRUB. By default it installs to MBR. If you tell it to install to its own partition's bootsector, rather than MBR, then all you have to do is chainload that partition. As the Ubuntu OS updates, it will update its copy of grub with new settings without stepping on any of your other stuff. Essentially what happens there is you boot to grub4dos, which then chainloads Ubuntu's GRUB (you get another boot menu), and then you can boot Ubuntu. You can also edit Ubuntu's GRUB to fall back to grub4dos on the MBR. It's nice.

After you install the first OS, I recommend you go ahead and boot to grub4dos from a flash drive or something, open the command line, and hide its partition. That way when you install the second OS, you don't have it trying to add entries to boot.ini or bootmgr for the first one, and ntldr or bootmgr will just boot straight into its OS. Plus that just guarantees it will make no attempt to tamper with the OS that's already in place. Keeps it nice and clean.

If you have a partition for file storage to share between the OSes, that's a fine place to put grldr and menu.lst so you can edit it as needed regardless of what you booted into.

The way I do this is configure my menu.lst to hide the partitions of other OSes so they can't see each other. Each one thinks it's drive C, and although it's aware of another partition, it makes no attempt to read it if it's marked as hidden. So say for example you had WinXP installed in (hd0,0) and Win7 installed in (hd0,1) and a shared file storage partition on (hd0,2). My menu.lst entry to boot WinXP would look something like this (and keep in mind there are a number of ways to approach it):

title Windows XP

unhide (hd0,0)

hide (hd0,1)

unhide (hd0,2)

root (hd0,0)

makeactive

chainloader +1

One last piece of advice: If Win7 makes its little 100MB partition for its boot files, keep in mind you need to chainload that, rather than where it's actually installed. And I hide/unhide them both.