Patrick J. LoPresti wrote:

Jordan Share <[EMAIL PROTECTED]> writes:


A couple of bugs:

First, some of the directories under "os" have long filenames.  This
is fine with the dos boot disk, presumably because it mangles them the
same for winnt as it does for install.pl.

Under linux, though, the initial installer gets told to copy files
from "win2kServer", which doesn't work in dosemu.


Rename the directories to use shorter names. :-)

We can probably fix this by implementing name-mangling ourselves,
using the mangled names in the portions of the install which are run
by DOS.  Maybe just doit.bat.

This strikes me as a fair bit of work for only moderate gain.  Feel
like opening a formal bug tracking ticket?

I don't mind using shorter names, but maybe the master script should give a warning if it finds directories with long filenames? Also, you may want to change the docs that say (paraphrased) "it doesn't matter what the directories are named, since install.pl scans the actual content of the directories".


Another problem I'm running into is when it tries to copy my driver
files over.

I am getting the error:

Setup was unable to copy the following file:

IA32

o press ENTER to retry the copy operation
[ etc. ]

I did a find in the os directory and this is the only hit:
./win2ksp4/I386/$oem$/$1/drivers/shuttle/LAN/Windows/Drivers/IA32


The exact same directory works when copied from DOS?

Yes. As I said in a different reply, the entire "os" tree is symlinked from the (working) production tree.


And the failure happens on all of your machines, or only with the 160G
disk you mention below?

I have only tried it on the 160gig machine at this point. I'll have to find another box to try the beta stuff on.


Can you put a tarred copy of drivers/shuttle someplace where I can
download it?  I would like to try to reproduce this myself.

I tarred and bzipped up the entire $oem$ tree, and put it at: http://waken.krotus.com/~jshare/oemtree.tbz

It's 16megs, but I figure this way you'll have everything. :)

IA32 is the only one it complains about. Perhaps it is too deep?


Perhaps. FreeDOS bug, maybe.


When it first detects the drive (a 160gig drive), I get various errors
in the style of:
Odd.  C/H/S does not multiply out to 312581808.

Setting C/H/S for hda to 19457/255/63...done.


This is not really an error; I get something similar on a couple of
machines.  It just means the total drive size is not an integral
number of cylinders, where a "cylinder" is 512 bytes times H times S.
The cylinder count is not terribly important; it is the head and
sector counts that matter.


The boot output is:
hda: ST3160021A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 1024KiB
hda: 312581808 sectors (160041 MB) w/2048KiB Cache, CHS=19457/255/63,


These CHS values and drive size agree with ours, which I suppose is
good.


UDMA(100)
 hda: hda1

These CHS values do not correspond to what the BIOS thinks the drive
is.


We query the BIOS for the "legacy" geometry (H and S only), and then
compute C from those plus the drive size.  If you change your BIOS
setting, you should see the values we report change as well.

How was your BIOS set to when you performed this test?

I had it set to LBA for this one.


Here's the BIOS settings, and what it ends up with for C/H/S with each
of them:

CHS -- 65535/16/255


With H/S of 16/255, the drive is too big to fit even with the cylinder
count maxed out.  So they max out the cylinder count, which makes
sense.


LBA -- 16643/255/63


This is just wrong.  16643*255*63*512 == 136G, not 160.  Hm...  That
does pretty much agree with CHS == 65535/16/255.  I wonder what is
going on here.


Large -- 4095/240/255


No idea where this is coming from.


Auto -- 65535/16/255 (same as CHS)


This might be related to the next problem...

----
Finally, (after skipping the copy of IA32), It reboots and I end up with:
Setup cannot find the temporary installation files.

The hard drive on which Setup placed temporary files is not
currently available to Windows 2000.  You may need a
...
[ snip ]


Questions:

Does this system install OK when you use the DOS boot disk?

Yes, I can use the "production" (3.5) unattended install with no problem.


Have you tried using this hard drive (or any >137G drive) in a
different computer?

I can't recall any specific times when I have done that. It is possible; we have a lot of different kinds of machines around here.


But I can't be sure.

Did you change the BIOS settings between the initial boot and the
execution of Windows Setup?  (Unlikely, but I had to ask...)

Nope.


Did you allow Unattended to partition the drive automatically?

Yes.


I still do not see what is going on.  The initial partition should be
a 4G FAT partition.  Even if our cylinder count is too large, we
should be fine.

Ok, this is starting to be weird. Now I'm getting all kinds of very strange behaviour.


Here's what I've done after the previous mail:
* Started a reinstall from "production" 3.5 unattended.
* Let it run partway, just to verify that it was working (it ran past the point where it expands the partition and converts to NTFS)
* Then rebooted and tried to install from the "unbeta" 4.2pre2.
* Now I get wacky errors when I try to use the unbeta:


Proceed with Format (YES/NO)? yes
# *** Formatting 2000 Mbytes as FAT16. ***Safe QuickFormatting (trying to save UnFormat data)
Drive_IO( command=READ sector=0 count=1 ) [FAT12/16] [drive C*]Critical error encountered while using DOS disk driverDOS driver error (hex): 01Description: unknown unit for driverProgram terminated.


A:\>xcopy /s /e /y Y:\ C:\
Unable to create directory C:\NETINST
0 file(s) copied

(it then kicks off the winnt.exe, which dies, for obvious reasons).

I'm starting to wonder if the drive is being partitioned at all by the unbeta.

Next, I reboot and partition under dos.  Hmm, that's weird, I get:
fdisk_cmds = fdisk /clear 1;fdisk /prio:2000;fdisk /activate:1

ABOUT TO PARTITION THE FIRST HARD DRIVE!
WARNING: This operation erases the disk!
Are you sure[Y,N]?Y

Re-checking partition table...no change. Continuing.

So, the dos fdisk thinks that after it issued the command shown above (we tweaked the install script to show fdisk commands when we were setting up "multiboot" machines), there was no change to the partition table.

Previously, when I've repartitioned under linux, it "calls IOCTL" to reread the partition table (or something). Is that happening with the unbeta?

This is starting to get long. I'll send this mail, and then a subsequent one dealing with these partitioning issues.

Two things you might try.

First, experiment with different BIOS settings (LARGE/LBA/CHS).  Each
time you change, be sure to allow Unattended to replace the partition
table, though.

I have tried all the bios settings, and none of them work.


Second, try partitioning the disk under DOS, then booting to Linux and
choosing "do nothing" for the partitioning step.  If that works, we
can debug from there.

I will give this one a shot.


Jordan


------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ unattended-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unattended-devel

Reply via email to