Multipartition USB disk

I have an idea to have a particular multiboot situation with Grub or Syslinux on a USB flash drive.

There would be multiple partitions on the flash drive, with one partition having Windows XP installer, another having Windows 7 installer, another with YUMI for linux distributions, another for Hiren. 

Can the Windows boot sector (or whatever it is called) on the CD/DVD, be used on the PBR rather than the MBR?

When one selects the partition one wants to boot into, from the Grub menu, then by a series of Grub commands:

1) one would set the default partition Grub would boot into after an X second timeout ( see https://www.gnu.org/...avedefault.html )

2) one would set the first partition on the USB flash drive (so Windows installer can find it's files) through Grub commands ( see http://www.rmprepusb...ls/multipartufd )

 

Possible?

 

Not that it's impossible or too difficult, but why all the mess?

WinSetupFromUSB and Easy2boot can handle just about any mix of sources in a single partition, why would you need to go into way more complicated setup with multiple partitions on a removable drive?

 

Because I want to keep the files of different Windows installers from mixing all together: it makes it easier to use folder comparison programs.

Because I don't want the files in an ISO.  I have to keep recreating an ISO for no particular reason.

 

When you decide to edit contents of the disk, you'd have to switch visible partition to Windows as well. Of course a filter driver or flipping the removable bit so Windows works with a fixed disk and all partitions is a way around, but again, is it really worth, unless you have something else in mind?

 

I am already using the driver that shows all the partitions on the flash drive.  Why not have this driver?  It appears to be superior.

 

From http://www.winsetupfromusb.com/faq/

"" 6. Are customized Windows sources supported?

Generally speaking- yes. Due to the numerous ways to customize XP for example, it’s hard to test every kind of customization, hence severely modified sources may not install properly. In case of NT6 (Vista and above) customized source, as long as updates or hotfixes are integrated into install.wim and using postsetup.cmd script, which seeks for files on the system drive, rather than the source DVD, there should be no issues. ""

 

I have this in setupcomplete.cmd:

FOR %%i IN (C D E F G H I J K L N M O P Q R S T U V W X Y Z) DO IF EXIST %%i:\$oem$\UnattendedOOBE.xml SET DVDRoot=%%i

 

ilko, on 14 Feb 2014, said:

Not a perfect world...

Manufacturer has some basic guidelines, $OEM$ goes to <DVD>(USB)\sources\$OEM$. Setup, in PE phase, copies contents to destination drive. First reboot. $OEM$ is not needed and used any more, nor should be other folders/files on the DVD/USB. Custom scripts search their things in the already copied contents of $OEM$ to the destination drive, not on the DVD/USB. Nothing is broken, everyone is happy, there are some rules followed.

Of course, there are sources which are customized in a different way with different needs. One may not want to copy OEM content to the destination drive for some reason, shared OEM folder for several sources, big sized contents, place it elsewhere as in your case and explicitly search for it etc.  Can such sources be easily added programatically in a multiboot scenario?

Unfortunately there has to be some trade off, a little user intervention and understanding what is what and how it works, second boot from USB, no multiboot, or some other limitation.

 

Thanks.  I changed that part of my install method to copy contents to the drive (via $oem$ folders), and invoke from there, instead of the flash drive.  Later I delete what was copied over.  Now my custom windows installer is compatible with WinSetupFromUSB, and probably a lot of other multi-boot utilities.

 

For now I will live with having to create and copy an ISO every time I make a small change, rather than copying a couple small files over

...or I may go with Rufus for one OS per USB flash drive

...or I may go with Rufus in combination with multiple partitions, LOL.

 

Update: Found out another drawback to using $oem$ folders as opposed to "FOR %%i IN (C D E F G H I ...".  For mbr multipartitioned drives (destination for the Windows install), the drive letters are different during the first stage and the last stage of the Windows install.  [primary1] [primary2] [primary3] [extended [logical-data]]

 

This is deal breaker, so I am again wanting to multi-partition a flash drive for the different OS installers.  Any tips on how to set up Grub, etc?

Edited by mraeryceos, 19 February 2014 - 11:45 AM.

Put grub4dos MBR, grldr and menu.lst go to the first partition for example.

Each entry in menu.lst uses Steve's script to change the visible partition to the desired one, root to it and chainload bootmgr in it.

Create default entry, which swaps HD order and chainloads MBR of the first internal disk. This is for unattended setups, if the second boot happens to be from USB again.

Copy contents of each source to the corresponding partition, there is no need of external tools.

 

If you need UEFI support, I am not sure how it would behave, would it ignore the hidden/not first partitions.

 

 

Update: Found out another drawback to using $oem$ folders as opposed to "FOR %%i IN (C D E F G H I ...".  For mbr multipartitioned drives (destination for the Windows install), the drive letters are different during the first stage and the last stage of the Windows install.  [primary1] [primary2] [primary3] [extended [logical-data]]

How does that affect you? Do custom script in PE phase interfere with custom script in last phase, sharing location?

Why wouldn't FOR %%i still pick up whatever you need, even though the drive letter has changed?

 

You better post all the custom scripts you have.

There is no custom script in the PE phase.  $oem$ folders are copied over in the PE phase.  This is standard Windows installer behavior.

 

[primary1] [primary2] [primary3] [extended [logical-data]]

I want to install Windows to partition 2.  I "hide" partition1, and partition3 doesn't matter because it is EXT2.  Hiding partition1 helps the logical partition be the letter D, when the system is up and running.  However, the $oem$ folder "D" gets copied to primary2.

I have instead been using FOR %%i instead, and then using an xcopy command to move files to the logical partition.  For reasons I do not understand, FOR %%i does not work if the medium is the USB flash drive (unless I'm using RUFUS, which is badass).

 

note: I am using the driver that shows all the partitions on the USB flash drive, in the system I use for development, not streamlined into the windows installer.  I could streamline the driver, as I think FOR %%i might then work?  Although with this driver, if the flash drive is treated as another hard drive (just guessing), I run into drive letter assignment issues (because I need drive D to be the logical partition.  see The reason I want to do this, is that the user profiles are moved to the D: drive, via the Windows registry.

 

I haven't even started to think what the solution would be for UEFI!  Is there a way to make Windows not be stupid, and understand partitions rather than drive letters?

Edited by mraeryceos, 19 February 2014 - 08:41 PM.

There is no custom script in the PE phase.  $oem$ folders are copied over in the PE phase.  This is standard Windows installer behavior.

 

Surely this is standard behaviour, no need to mention.

You say drive letters change during PE and the other phases without explaining why and how that affects you. If there is no custom script during PE phase, why would you care about drive letters in PE phase at all?

 

 

[primary1] [primary2] [primary3] [extended [logical-data]]

I want to install Windows to partition 2.  I "hide" partition1, and partition3 doesn't matter because it is EXT2.  Hiding partition1 helps the logical partition be the letter D, when the system is up and running.  However, the $oem$ folder "D" gets copied to primary2.

This is weird. Did partition 2 get D letter indeed? Setup log files might give more clues what's happening.

You do need to post your custom scripts and $OEM$ folder structure as requested. There might be an error or something you are overlooking. Besides, it's much easier to look at them and find out what the intentions are, rather than keep asking you questions over and over to get clear picture of what you are doing.

 

 

I have instead been using FOR %%i instead, and then using an xcopy command to move files to the logical partition.  For reasons I do not understand, FOR %%i does not work if the medium is the USB flash drive (unless I'm using RUFUS, which is badass).

Ditto, post your scripts, unless they are secret ones.

No clue why Rufus would help with FOR %%i search, posting them might help in clearing things up.

 

 

note: I am using the driver that shows all the partitions on the USB flash drive, in the system I use for development, not streamlined into the windows installer.  I could streamline the driver, as I think FOR %%i might then work?  Although with this driver, if the flash drive is treated as another hard drive (just guessing), I run into drive letter assignment issues (because I need drive D to be the logical partition.  see The reason I want to do this, is that the user profiles are moved to the D: drive, via the Windows registry.

Since the USB stick will have primary partition on a fixed disk, it will get priority over logical partitions when assigning drive letters.
 

 

 Is there a way to make Windows not be stupid, and understand partitions rather than drive letters?

You can try mnt.exe

Usage: mnt.exe [-u | -z] [<drive>: [<Device>]]
Examples: mnt.exe J: \Dosdevices\C:\DOS
          mnt.exe K: \Device\Harddisk0\Partition1
          mnt.exe -u L: (deletes current definition of L:)
          mnt.exe -z M: (deletes all definitions of M:

You'd be interested in

mnt.exe K: \Device\Harddisk0\Partition1

 

and when you finish

 

mnt.exe -z M: (deletes all definitions of M:)

 

Surely this is standard behaviour, no need to mention.

You say drive letters change during PE and the other phases without explaining why and how that affects you. If there is no custom script during PE phase, why would you care about drive letters in PE phase at all?

 

I wrote: "the $oem$ folder "D" gets copied to primary2."

See: http://unattended.ms...xp/view/web/18/ " drive_letter - Represents the root of a particular volume on the system (e.g., \$OEM$\C represents the C: drive) and contains any files that WinXP Setup should copy to this partition during installation. "

I haven't read the rest of your post.  Get back to you later.

Edited by mraeryceos, 20 February 2014 - 12:41 AM.

c:\windows\panther\setupact.log, shows $oem$ folders were copied without issue, to D:\.  And since I find the files on partition2, it can only be Windows intended behavior.

 

I have conflicting motivations.  While I want to solve this, I don't want to make it easier for people to be able to install Windows.  I would rather people choose Linux.  I'm so tired of Windows crap, like this for example.  So anyway, my install method works, but I don't want to reveal all the scripts.  I want to focus on creating a multi-boot environment so that people can choose to boot into Linux as an alternate to Windows, and this I am more than willing to reveal.  It would be helpful if I could have all the OS on one flash drive (with files accessible for easy editing -> not in an ISO), but I can live without that.

 

edit: While the installation is happening, during winpe stage, diskpart's "list volume" shows D is assigned to the logical partition!  I see my files were copied to the D partition!  Oh!  The previous time, I created the NTFS partitions with an older partitioning software, and perhaps the NTFS version was not sufficient for Windows Installer to want to use it for anything.  The previous time I formatted the C partition with the Windows installer, but may not have reformatted the D partition to the newer NTFS version.

Edited by mraeryceos, 20 February 2014 - 03:38 AM.

I have instead been using FOR %%i instead, and then using an xcopy command to move files to the logical partition.  For reasons I do not understand, FOR %%i does not work if the medium is the USB flash drive (unless I'm using RUFUS, which is badass).

Ditto, post your scripts, unless they are secret ones.

No clue why Rufus would help with FOR %%i search, posting them might help in clearing things up.

Maybe because Rufus doesn't put the files in an ISO?

Or because it's unclear what are you currently using and which of your troubles apply to which method used in the past, just scattered thoughts and results, which are quite hard to follow, despite all the willingness to be helped with your issues.

Sorry I try to explain the best I can, believe it or not.  I appreciate your altruism!

 

Maybe creating an ISO every time isn't such a bad idea, as I can keep track of my changes for when something goes wrong.  I will continue to use WinSetupFromUSB for now.

Two complaints:

WinSetupFromUSB is really really slow installing XP, compared to Rufus (even though Rufus is on a slower flash drive).  I've heard complaints in other forums about this.

WinSetupFromUSB uses ISOs, so installers and boot disks can't reliably access their files needed from the USB drive.  For example, Hiren's Boot CD could not load the custom menu, unless I inserted the Hiren CD simultaneous to the USB flash drive.

 

So I would still like to figure out a way to use a multipartitioned USB flash drive as an alternative.  Or just use Rufus and buy more flash drives  :-/

 

So, ilko, if you don't mind, I would like input from others, since you are not interested in using multiple partitions.

Edited by mraeryceos, 08 March 2014 - 01:33 AM.

I'd first clear up your misunderstandings and yet again wrong conclusions based mostly on lack of information and for some reason, which is still unclear to me why, negative attitude since the starting point.

 

WinSetupFromUSB is really really slow installing XP, compared to Rufus (even though Rufus is on a slower flash drive).  I've heard complaints in other forums about this.

 

In later versions FAT32 is used by default for UEFI compatibility if option to auto format is used as it is. And XP Setup could be horribly slow when launched that way on FAT32. Ask Microsoft what they had done to the poor FAT32 driver.

Some speed tests:

http://www.msfn.org/...d-on-usb-stick/

 

FAQ:

www.winsetupfromusb.com/faq/#faq13

 

If XP setup was used with WinSetupFromUSB on FAT32 and Rufus on NTFS, then results will be different for sure. Compare apples with apples.

Your only escape with FAT32 is to install it from grub4dos emulated CD and Firadisk/WinVBlock drivers as Easy2Boot and recent YUMI versions do.

 

WinSetupFromUSB uses ISOs, so installers and boot disks can't reliably access their files needed from the USB drive.  For example, Hiren's Boot CD could not load the custom menu, unless I inserted the Hiren CD simultaneous to the USB flash drive.

 

Hiren Cd is not supported in any way since it's warez, the rest is just yet another wrong generalization. Good luck putting contents of multiple ISOs in the same partition with overlapping files and folders...

 

So, ilko, if you don't mind, I would like input from others, since you are not interested in using multiple partitions.

 

Others are not prohibited to write in here, besides, you haven't yet noticed or simply ignored the ideas already put in post #2 about multiple partitions, ideas which have nothing to do with WinSetupFromUSB...

 

Duh, seriously, why all the negativism...

Yes, you have made it clear that you do not want a multi-partitioned USB drive.  Thanks for clarifying this, yet again.

I miss Wonko! LOL

I miss Wonko! LOL

 
But Wonko is here.
Only he is limiting his contributions to factual statements and highlighting self-evident truths.
 
Factual statements:
Last time I counted them (and limiting to the tools developed and posted on reboot.pro, 911cd.net and msfn.org) there were no less than 5 fully or mostly automated methods:

• Wimb's  USB_MultiBoot.cmd
• Ilko's WinSetupFromUSB (actually two of them a "legacy" one and the current one which uses a different approach)
• Wimb's U_XP_SET and connected tools
• Akeo's Rufus
• Steve6375's Easy2boot

ALL of them pretty well documented, and no less than 5 complete tutorials or manual methods using flat files, .iso or .img in virtual disks, pre-booting to another OS, etc., etc.:
http://www.msfn.org/...ndows-from-usb/
to which we may add the nice, though possibly less-known, Galapo's OfflineSysPrep approach: 
http://www.911cd.net...hp?showforum=43
and a number of tools to help in the process, among which I would mention JFX's Winntsetup:
http://www.msfn.org/...winntsetup-v33/
 
Unlike the good ol' times :
http://www.msfn.org/...l-from-usb-key/
there are now lot of choices, an incredible amount of related knowledge/info on the matter, and most if not all of these are public.
 
Self-evident truths:
All the mentioned (and non-mentioned) developers and contributors, while belonging mainly to the "evil" windows world, disclosed all (or the most relevant parts) of their methods/tools publicly, discussed them, adapted them interactively with final users and other contributors, all with the scope of making it easier to install Windows from USB or more generally explore new, strange ways to deal with the final scope which is "making Windows install from USB or other media easier or more convenient".
 
Set aside the evident whining , it is "queer" that someone belonging to the "good" Linux world would actually make this statement, and in any case the scope seems very different:
 

While I want to solve this, I don't want to make it easier for people to be able to install Windows.  I would rather people choose Linux.  I'm so tired of Windows crap, like this for example.  So anyway, my install method works, but I don't want to reveal all the scripts.  I want to focus on creating a multi-boot environment so that people can choose to boot into Linux as an alternate to Windows, and this I am more than willing to reveal.

 
 

 
Wonko

It's true I DON'T WANT TO REVEAL ALL THE SCRIPTS.  I DON'T WANT TO MAKE WINDOWS EASIER TO INSTALL.  Ok, now we got that out of the way.  I am free to talk about Windows XP.  China, and the rest of the world, is having trouble with 7, not XP.

 

This morning, I tried to re-install XP on my HP DV8000 CTO laptop (last time I used a Macbook Pro, circa late 2006, and Rufus did fine).  This time, Windows Setup via Rufus couldn't find itself on the USB drive (I used the same OS I sent you, Akeo), as in, Windows Setup asked for the CD, because it said that I was using the upgrade version.  I then tried WinSetupFromUSB, and proceeded with the installation, but got a black screen on reboot.  I reformatted the partition, and tried again with a CD, but got the same black screen.

 

I forgot to back up the MBR, but fortunately, Boot Doctor (from Gparted on Hiren) was able to recover the MBR after I pointed it to the Crunchbang partition.

 

XP is nlited, and has most of the driverpacks.  Wait... I remember adding some files.  Maybe that threw off the Rufus install.  The root of the XP Setup now has:

WIN51
WIN51IP
WIN51IP.SP1
WIN51IP.SP2
WIN51IP.SP3
WIN51IS.SP1
WINXP.PRO

I thought more was better.  I am not home now.  I will try again removing the extra "marker" files I added.

 

However, I don't think this has anything to do with the black screen I got from the CD and WinSetupFromUSB, though I could be wrong.  Oh... I also used the SP3 kernel on SP2 source.  This works if I switch the kernel on an already installed system, but maybe the installer doesn't like it.  I will check when I get home.

 

...I need some plain method to work, before I consider trying multiple partitions.

Edited by mraeryceos, 08 March 2014 - 05:36 PM.

But Wonko is here.



Wonko

Hey Wonko! I thought you quit.. glad thats not the case. I was reading this thread (that is apparently a continuation from somewhere) and Ilko's posts started to remind me of a certain sane one! LOL somebodies gotta keep things straight around here.. actualy, Ilko is doing a pretty good job with it here.

but dont limit yourself too much Wonko because that tends to limit me and all the others including the lurkers who learn so much from you here.


mraeryceos, sorry to intrude on your thread like this. hope you get it worked out. if so I hope you will reconsider and Care to Share.