Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


Sign in to follow this  
xpman

OEMFilesPath for CD installs

Recommended Posts

I have been at this problem for the last couple of years, never gave it a high priority, though. During this time, I only focused on CD installs, I have little to no clue about RIS. Still, it has always been bugging me, and with Win6x around I finally want to close my gaps around Win5x.

deploy.chm says about this, among other things:

Specify the path to the folder containing the \$OEM$ folder without including "\$OEM$" in the path. UNC paths are also not supported.

What is *not* there:

- any mention of relative or absolute paths

- any mention of a difference between CD or RIS installs, setup.exe and winnt32.exe

The following posting has several intersting points in it (http://www.msfn.org/board/oem-single-direc...hl=oemfilespath)

- it claims that UNC paths work for RIS installs

- it quotes a Microsoft engineering saying that for CD installs you have to specific a drive letter (and thus an absolute path, I guess)

Well, I finally got my answer from MS. Erik (SBST - System Builder Support Team) told me in order to specify a location that's not through the network, I have to give a drive letter. So, I'd have to specify D:\Setup\Preinstal and make sure that there was only one HDD and one optical drive. I may still do it, but I'm not sure if it's worth the hassle. We'll see.

This posting (http://www.msfn.org/board/oemfilespath-t19810.html) claims success by placing the $OEM$ folder in the CD root and using OemFilesPath="$oem$" or OemFilesPath="..\$oem$".

After reading these (any many more postings), I tried the following setup:

- Windows XP Pro SP3 (I used the SP3 setupldr.bin for the multiboot, just to be sure)

- $OEM$ is located in the CD root

- I have one partition (and some free space) on the HDD, the primary partition is called C: in txtmode setup

- I tried d:\, d:\$OEM$, \$OEM$, \ as OemFilesPath (presuming that the CD drive would be D:)

Still, I have not had any luck. Setup only copies the files from txtsetup.sif and then reboots. The $OEM$ files are not copied. With all the postings around, I expected to actually find a "solved" anywhere, but no such luck. Then again, in the multi-boot forum, there are only 5 total hits for "OemFilesPath".

I truly hope that this is a trivial one for someone who has had success.

Share this post


Link to post
Share on other sites

deploy.chm says about this, among other things:
Specify the path to the folder containing the \$OEM$ folder without including "\$OEM$" in the path. UNC paths are also not supported.

What is *not* there:

- any mention of relative or absolute paths

- any mention of a difference between CD or RIS installs, setup.exe and winnt32.exe

Yes, deploy.chm dosn't refer to a multi boot cd.

Setup only copies the files from txtsetup.sif and then reboots. The $OEM$ files are not copied.
Setup dosn't search at root, hence the files are not copied.

Nonetheless, the relative path OemFilesPath="..\$oem$" may work.

File copy and OemFilesPath are two different cases.

If you like a non default copy path, you have to copy the files yourself.

Add a command at unattended mode.

With all the postings around, I expected to actually find a "solved" anywhere
Flyakite suggest $oem$ beside I386, not in root.

Why do you use $OEM$ at root? Is there any special reason?

What's the general request?

Share this post


Link to post
Share on other sites
Specify the path to the folder containing the \$OEM$ folder without including "\$OEM$" in the path. UNC paths are also not supported.

What is *not* there:

- any mention of relative or absolute paths

- any mention of a difference between CD or RIS installs, setup.exe and winnt32.exe

The way I read that, it means if your $OEM$ folder is at D:\$OEM$, you only need to specify "D:" (was not in your list of failed tries) without the "\$OEM$" like this

OemFilesPath=D:

or maybe like spoiled said try.

OemFilesPath=%source%

During this time, I only focused on CD installs, I have little to no clue about RIS.
Your verbiage is misleading. Are you having trouble with a network based RIS install, or are you trying to create a multi-boot DVD. Makes a difference. Edited by MrJinje

Share this post


Link to post
Share on other sites

Thanks for all the replies. Please let me clarify some things:

1. I am doing only a CD install. I only mentioned RIS to say "please do not give me RIS-solutions - I cannot use them".

2. I only put the $OEM$ folder at the root because some postings said that this worked for them (compared to putting it into some subfolder).

3. My motivation for not having it beside the I386 is simply the multi-boot scenario: I want to share the $OEM$ folder space-efficiently between several Win5 editions. Also the reason why I decided to post in the multi-boot, not the unattended forum; I see little need to move the folder if you have just a single OS.

Regarding some of the new suggestions:

1. I tried OemFilesPath=D: (no success, I actually had tried ="D:\")

2. I tried OemFilesPath=%source% (which was not exactly the suggestion, I still presume that $OEM$ must be left out; I also thought there was no such variable during any install phase)

So I still have no success, just some more questions:

1. Should the quotation marks make any difference?

2. Does the trailing back-slash matter in paths?

3. Is there actually a variable pointing to the setup source? I never saw this. (would be nice to have setupsourcedir as a full absolute path)

(I somewhere read that this line does e.g. not work when you add a comment after it, so I suspect anything now.)

And maybe I misunderstood something:

File copy and OemFilesPath are two different cases.
In my experience, if you enable preinstallation, txtsetup copies the entire $OEM$ folder after copying the files specified in txtsetup.sif. So the bar remains at 100% for as long as that takes. So with no files being copied in my case, I take that as a sign that the folder redirection does not work. Am I maybe wrong about this? Will using OemFilesPath make the copying unnecessary and the setup process will simply look at that new path? And would this be the reason that an absolute path must be specified?

So when I say "not working", I mean that I do not see the $OEM$ folder being copied as it usually is. Am I expecting something wrong?

My general request is to see a working solution from anyone that uses this variable for CD installs.

EDIT: I just let one install run through using OemFilesPath=D: - and cmdlines.txt in $OEM$ was not executed, although the CD drive is D: after the installation.

Edited by xpman

Share this post


Link to post
Share on other sites

Tried at XP SP3 again:

Directories

$OEM$

XP01\$OEM$

XP01\I386

[Data]
MsDosInitiated=No
[Unattended]
UnattendSwitch=Yes
OemFilesPath = ..
;OemFilesPath = ..\
;OemFilesPath = ..\$OEM$
;OemFilesPath = $OEM$
;OemFilesPath = D:\
;OemFilesPath =\\.\D:\

\$OEM$\cmdlines.txt is ignored, contrary XP01\$OEM$\cmdlines.txt is processed.

Does OemFilesPath work at "MsDosInitiated=Yes" only?

3. My motivation for not having it beside the I386 is simply the multi-boot scenario: I want to share the $OEM$ folder space-efficiently between several Win5 editions.
At multboot: add the $OEM$ files once to CD but add several links to the same file.

Optimize the layout at CD: duplicate files are once at CD.

Or create a junction to $OEM$ at hard disk first.

Create the ISO image next.

Or create one $OEM$ at hard disk. And create several $OEM$ at ISO image application.

Share this post


Link to post
Share on other sites

Thanks for the suggestions.

Does OemFilesPath work at "MsDosInitiated=Yes" only?

Not according to all the documentation, but it could well be since you'd use this in network install scenarios (if I am not mistaken). Since this is not what I am after, I never tried it, though.

At multboot: add the $OEM$ files once to CD but add several links to the same file.

Optimize the layout at CD: duplicate files are once at CD.

Or create a junction to $OEM$ at hard disk first.

Create the ISO image next.

Or create one $OEM$ at hard disk. And create several $OEM$ at ISO image application.

On hard disk, I only have one $OEM$ directory, I think it will probably depend on the burning tool if it makes anything useful from this. Currently, I am using Nero, but that is quite unintelligent regarding junctions or adding the same folder twice. For mkisofs, the manual only mentions hard links, but not junctions. I must say I never really used mkisofs or cdimage.

Share this post


Link to post
Share on other sites

I used in the meantime

[Unattended]
UnattendSwitch=Yes
OemPreInstall = Yes
OemFilesPath = \!OEM!\

There is both a \$OEM$\cmdlines.txt and \!OEM!\cmdlines.txt.

\!OEM!\cmdlines.txt is not processed.

Instead \$OEM$\cmdlines.txt is processed.

Still no solution for OEMFilesPath for CD installs.

On hard disk, I only have one $OEM$ directory
Using one $OEM$ at hard disk and create several $OEM$ at ISO image application:

use mkisofs -graft-points: connect one $OEM$ directory from HD to different directories at CD.

Several directories are added at CD, but files themself are added once to CD.

A basic -graft-points example

mkisofs -o image.iso -graft-points /XP01/$OEM$=$OEM$ /XP02/$OEM$=$OEM$ /XP03/$OEM$=$OEM$ .

If you need further examples, name your added windows versions and used directories.

Share this post


Link to post
Share on other sites

cdob, first of all, thanks for all your help!

I think by now it appears safe to say that the OEMFilesPath does not work with CD installs. It just seems strange to me that in all the years nobody has really had and pursued this problem.

Anyway, it took me a while to get started with mkisofs.exe (which I am using under Windows but from a makefile within msys, so half of the time I am struggling with the right escape sequences). Graft-points are working, but the $OEM$ folders take up individual space. The man page for mkisofs only mentions space reductions when inodes are cached (which apparently cannot be done under Windows), but nothing about the same for graft-points.

Share this post


Link to post
Share on other sites
which I am using under Windows but from a makefile within msys
Msys/mingw dosn't provide inodes.
The man page for mkisofs only mentions space reductions when inodes are cached (which apparently cannot be done under Windows)
Cygwin provide inodes at windows. I'm using a cygwin compiled mkisofs.

http://cdrecord.berlios.de/

http://www.student.tugraz.at/thomas.plank/

Trust the newest available version.

Share this post


Link to post
Share on other sites

Thanks for the links! I actually had recently downloaded what I thought to be a current version of the cdrtools (with the described success). Now using the 2.01.01a75, graft-points behaves "intelligently" and only causes the data to be stored once (saving about 800MB).

I had started reading about cygwin and inodes, my first impression was that I am generally out of luck on Windows. So I am glad to hear that it should still work. For the OEM folders, I do have a solution, of course. The only thing now might be identical files between XP SP3 and 2K03 - if there are any. Was the reference to cygwin and inodes just a hint or does this save you considerable space?

The latest version of the tools now also comes with a man with useful information on file priorities; I still think some occasional problems I have with the DVD come from boot files being at the wrong position. What puts me off a bit trying this option is the fact that all files have to be individually listed in the sort_file; I would have hope to at least be able to specify directories, too, e.g. for the 4-letter Windows boot folders.

Again, a big thanks to you, cdob!

Share this post


Link to post
Share on other sites
Now using the 2.01.01a75, graft-points behaves "intelligently"
Did you add cygwin1.dll, that's the main difference. There are inodes now.
For the OEM folders, I do have a solution, of course. The only thing now might be identical files between XP SP3 and 2K03 - if there are any.
Yes, be careful about differences XP SP3 and 2K03.
Was the reference to cygwin and inodes just a hint or does this save you considerable space?
Cygwin inodes support hard links too.

I've several XP versions at hard disk, identical files are hard linked.

This save considerable space at hard disk.

And builded a multi boot cd, files are added once only.

The latest version of the tools now also comes with a man with useful information on file priorities

There is a readme.sort at source code too. Requirements are strange at first glance, but make sense.

ftp://ftp.berlios.de/pub/cdrecord/alpha/

I still think some occasional problems I have with the DVD come from boot files being at the wrong position.
Setupldr.bin and ntldr access first 4gb of media.

Textmode boot files and XP asms directory has to be within first 4gb of media.

What puts me off a bit trying this option is the fact that all files have to be individually listed in the sort_file; I would have hope to at least be able to specify directories, too, e.g. for the 4-letter Windows boot folders.
You may specify directories and wildcards.

Example, ISO source files are at current directory .

./boot.catalog 10000
./bootsect 9990
./WIN* 9978
./AMD64/* 1100
./AMD64/SYSTEM32 9000
./AMD64/COMPDATA 20
./AMD64/LANG 1000
./AMD64/WINNTUPG 100
./I386/* 1100
./I386/SYSTEM32 9000
./I386/COMPDATA 20
./I386/LANG 1000
./I386/WIN9XMIG 100
./I386/WIN9XUPG 100
./I386/WINNTUPG 100
./DOCS -1000
./DOTNETFX -1000

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...