[cyberchicken]

something similar to what jmkay03 was reporting (it seems he has not solved anyway)

in a few words: I run xpc and sometimes my image wont boot (into vmware v4.05 bild 6030)
i get this error: CDBOOT: can't find NTLDR
and then tries to boot the hd.

grasp your chair cause i'm gonna tell you something really weird.

the problem arises since I was writing a little wrapper for xpc (sstream sp1, run remove, run xpc, write image)
The problem is NOT the operation I was going to add because I stripped them all just to be sure. I left only directory clearing and copying. Only this! Read on.
I wont tell all the test i had to do to pinpoint the problem, but now I'm fairly sure to be able to reproduce the problem.

a note: I used a little prog named cdcheck to perform file and directory comparison.

My xpc ini for this test:

[XPCREATE]
;XPSOURCE=D:
XPSOURCE=source

DOCABS=NO
DOSATA=NO
DOSVCPACK=YES
DRIVERDIR=$OEM$\$1\DRIVERS

OVERWRITEOEM=YES
SILENTINSTALL=YES

DOISO=YES
XPISO=XPCREATE.ISO

BOOTIMGFILE=BOOT\XPCTBOOT.BIN
;BOOTIMGFILE=BOOT\mybootdisk4.ima

DOCD=NO
CDBURNER=E:
CDERASE=NO
CDSPEED=MAX

DELTEMP=YES
DELISOS=NO
DELROOT=NO

EXITQUIET=NO

note XPSOURCE=source where "source" is a folder in xpc branch (this has always worked)
also to do my stuff i needed ANOTHER source: wxpcorp_en which holds all the file from a win xp corp cd

now (numbering starts from 4 because of some preceding tests):
source is empty

-copy by hand (windows explorer) wxpcorp_en to source (source4)

-run xpc (produces cdroot4 and iso4)

-iso4 works!


del /kseqxyz source\*.*
md /s source\i386
(4nt commands, these works, I checked, I mean, source gets emptied and i386 gets created!)

-copy with "xcopy /q /s wxpcorp_en\*.* source\" (source5)
(xcopy is from windows' right? I have it in my windows folder)

-run xpc (produces cdroot5 and iso5)

-iso5 DOESN'T works! HELL!

if I compare source4 and source5 they seems to be identical

BUT
if I compare CDROOT4 and CDROOT5 i get:

error;compare;content mismatch (99% match) (code: 62);C:\Jobs\THE BOOTDISK\XPCREATE\CDROOT4\I386\SVCPACK.IN_ <-> C:\Jobs\THE BOOTDISK\XPCREATE\CDROOT5\i386\SVCPACK.IN_
error;compare;content mismatch (99% match) (code: 62);C:\Jobs\THE BOOTDISK\XPCREATE\CDROOT4\I386\SVCPACK\DOTNETFX.EXE <-> C:\Jobs\THE BOOTDISK\XPCREATE\CDROOT5\i386\SVCPACK\DOTNETFX.EXE
error;compare;content mismatch (99% match) (code: 62);C:\Jobs\THE BOOTDISK\XPCREATE\CDROOT4\I386\SVCPACK\MDAC.EXE <-> C:\Jobs\THE BOOTDISK\XPCREATE\CDROOT5\i386\SVCPAC

I didn't dig into those file, but I thought that xpc should be deterministic, right?

Also, obviously iso#4 and iso#5 are slightly different (but same size)

I attach the log from the "5" test which was supposed to work just like the others and does not.

Just to be clear, the only difference between the two test is the copying with explorer or the copy with xcopy /q/s

please help me out of hell


edit:
You cannot upload this type of file
I can't post the log cab!?

[cyberchicken]

I'm very very sad
i threw away 5 fine days of my life for a stupid thing
and btw this board has too few sad smilies

md /s source\i386

this was the problem
and needless to say, GM was right as always: always use original ms disc!

well what's the difference between my folder and the disc?
i386 is written lowercase
LOWERCASE!!!! S%%%T

just to be clear: ms software sucks
if I'd be judging the os by its installer I'd rather throw it away... and I would be right.

Anyway:

EVERY "SYSTEM" FOLDER (probably files too) ON THE CD HAS TO BE UPPERCASE

did anyone ever read such a thing on a doc?

I have discovered also aother things that I think should be incorporated in the unattended guide, but I'll write a post when I've reordered my notes.
Thank you.

PS please GM I'm very down, give me a pat on the back

[Alanoll]

here's your pat on the back.

i dunno, but did you ever realize that the disk was mastered under ISO 9660 specs? Under such specs, everythign should be 8.3 filenames and uppercase. Just so you know.

Only thing that would change that would be to use the Joliet format or UDF.

[GreenMachine]

Yes, cyberchicken, I, too, sympathize for you. Especially when the solution is so simple ... I should have got the tip when I saw your code in lower case. I always write DOS code in UPPER, use 8.3, and often use XCOPY with the option to rename to NT4 names. There is also the option to create the ISO with other programs, that may (or may not) have better luck.

[cyberchicken]

Thank you friends

Quote

i dunno, but did you ever realize that the disk was mastered under ISO 9660 specs? Under such specs, everythign should be 8.3 filenames and uppercase.  Just so you know.

I knew! When I burn my $oem$ in my image i get:

WARNING: This image contains filenames and/or directory names that are
         NOT COMPATIBLE with Windows NT 3.51.  If compatibility with
         Windows NT 3.51 is required, use the -nt switch rather than
         the -n switch.

for the files I have in it.
So I felt safe when I left out $oem$ and received no warning.

Quote

I always write DOS code in UPPER, use 8.3, and often use XCOPY with the option to rename to NT4 names. There is also the option to create the ISO with other programs, that may (or may not) have better luck.

Let me point that if we were working in DOS we woudn't have any long or lower case filname
Anyway I always worked with the 4dos/4nt shell and never had a case-related problem. Cmd is somehow terra incognita for me.

Quote

often use XCOPY with the option to rename to NT4 names.

which one? /n?


Anyway, now the CDIMAGE is working and I'll keep on testing.

BTW GM did you notice the strange behaviour of the latest patch? I had to move it to the RunOnceEx stub

[GreenMachine]

Actually, the problem is not in CDIMAGE, rather in the TXTSETUP OS, which cannot find the files from the tables. That same CD shows everything fine in Windows. It is a delicate balance, and I have it the way I want it to work for me. There are other ways ...

I only have 8.3 UPPER names ... It was just so long before I found out that something else existed, that I can't manage to right my ways.

Yes, the /N switch. Run the files through that once, and you can be sure to never have a problem!

What strange hotfix? I use the Current hotfixes list on the XPCREATE web site. Does one of those not work for you as listed?

[cyberchicken]

Quote

Actually, the problem is not in CDIMAGE, rather in the TXTSETUP OS, which cannot find the files from the tables. That same CD shows everything fine in Windows.

Are you sure? I thought that joliet worked like fat32 about lfn, overalying secondary directory listings (hidden to non caring sw) that holds long and cased filenames. Therefore sfn should be always iso9660 compliant. Thus CDIMAGE would be the culprit. But I have no hard data on this topic.

Quote

What strange hotfix? I use the Current hotfixes list on the XPCREATE web site. Does one of those not work for you as listed?

Last wednesday was released Q840374
It's listed under type1 but actually has new rubbishy options.
It has many disturbing "features": leaves rubbish temp directory in the root
if you use the option to sstream it ina distribution it fills i386 (pardon, I386) with a couple dozen language folders
if i put it in hf1 xpc runs fine (same language folders) but then durin the install the ms java vm stops saying that it "should not be installed if there's not aready ms jvm" and, just to finish, the boot hangs

nice little hotfix

[GreenMachine]

Oh, that hotfix.

The "rubbishy options". XPCREATE sill uses the standard method for this: it is backwards compatible. As for the "/integrate" switch, I do not use it, as XPCREATE does a cleaner integration.

Yes, it does make a mess. Fortunatly, only XPCREATE sees it, as GreenMachine never needs to look at the results (after testing).

As for MSJVM, I test it with SP1 with MSJAVAWU.EXE, the MSJVM update, and SP1A without. I have not yet tried SP1A, and the baliktad MSJVM "package". Nor have I experienced any boot hangs.

[BeenThereB4]

Just made an XPcreate CD with all the current patches per GreenMachine's list. All is fine!

[GreenMachine]

Now THAT'S what I like to hear!

Might just have to close and pin this one ...

[cyberchicken]

Quote

Yes, it does make a mess. Fortunatly, only XPCREATE sees it, as GreenMachine never needs to look at the results (after testing).

If you don't mind I'll put it in runonceex.

Quote

As for MSJVM, I test it with SP1 with MSJAVAWU.EXE, the MSJVM update,

That's my setting too, and with KB840374.EXE the MSJAVAWU.EXE gets me that warning. Bah.

BTW Please can you lead me to the postings about REMOVE together with XPC?
Thank you

[GreenMachine]

cyberchicken, on May 17 2004, 11:56 AM, said:

... If you don't mind I'll put it in runonceex. ...

I don't mind!

Strange about KB840374.EXE and MSJAVAWU.EXE. I don't see that at all. And KB840374 only updates the Help Center ...

I do not understand. What do you mean "REMOVE and XPCREATE"? If you are refering to the various methods of REMOVING files from the XP Source, I cannot help you there: never tried it.

[cyberchicken]

Quote

Strange about KB840374.EXE and MSJAVAWU.EXE. I don't see that at all. And KB840374 only updates the Help Center ...

Retried, now it works. It must have been sthing else.

Quote

I do not understand. What do you mean "REMOVE and XPCREATE"? If you are refering to the various methods of REMOVING files from the XP Source, I cannot help you there: never tried it.

I saw a thread about jdeboeck's REMOVE and XPC, but can't find it anymore (too generic keywords). My question was REMOVE before or after? I thought that someone, possibly you, had replied.
Anyway as always... I'll do my tests

[GreenMachine]

I think Alanoll has the most experience here. Also, that thread you were talking about seems to have been bumped up.

Tests, tests and more tests. Don't forget to post your results, for the next guy.