Setup hangs copying files

[Nixie]

I downloaded the latest stable release of ReactOS and burned it to a CD-RW. Tried to install it in the following machine:
Pentium III 500 MHz, 128 Mb SDRAM, videocard S3 TrioDX, harddisk 2.3 Gb Maxtor.
It boots fine from CD, creates and formats the partition and then hangs when it shoud be copying files. Usually hangs at the first or second file but one try reached ext2fs.sys
I think the problem is someting around DMA or modes used to access the harddisk. Does it change or enable some mode or DMA setting when it starts to copy files? Would it be hard to provide some option to avoid this?

I tried many BIOS settings without any help. Particularly tried to enforce PIO modes but apparently the software overrides this.
Windows 98 installs and runs perfectly in this machine, but if the harddisk DMA checkbox is enabled in the device manager upon restart it is disabled, which means it does not support DMA.
On the other hand tried to install Puppylinux and it suffers the same problem, Gparted gets stuck accessing the hard disk. Probably the same problem.

Thanks for reading

[Dave3434]

the hard disk may have a bad sector it happen to me once.

[swight]

top suggestion I can think of is to try the latest trunk build. The last stable release is very old(think it was released in February) and many issues have been fixed since its release such as newer UniATA drivers which fix many hard drive related issues. From what I have heard the trunk is nearly stable enough for a release.

Another option is try to acquire the latest UniATA drivers and install them on the copy that you have. Others here would be more suited to guide you through the process if necessary. I know there have been forum posts on it but I don't want to direct you to outdated information.

There is also a trick involving renaming a file or two that may help though I don't know if that trick still applies or is necessary. There should be forum posts about it if you want to research it.

Sorry I can't be more helpful. I watch certain subsections of the forums fairly closely but other sections and communication methods not so much so I can't count on my information being up to date if it hasn't been talked about recently in the forums I watch. Hopefully this will get you started or help someone help you if required.

[EmuandCo]

did you install on ext2 or fat? only fat will work.

[DOSGuy]

The last stable release is very old(think it was released in February) and many issues have been fixed since its release such as newer UniATA drivers which fix many hard drive related issues.

And also cause some new ones. It's been impossible to get into the first stage of installation in Bochs 2.6 ever since UniATA was updated to 41b5 in r56870. The many updates to UniATA since then still haven't fixed it.

[Nixie]

Thanks for all the replies. I downloaded the latest Trunk build.
It still gets stuck at the start of file copy, with this new version an error message pops just before it hangs: Setup could not create install directories. ENTER=Reboot computer.
But ENTER does not reboot the computer, seems hung.

I am formatting as FAT. I am curious as to why it creates and formats partitions successfuly and then cannot write files to the disk. Does it change some access method or hard disk setting?

[DOSGuy]

Bochs reports the system rapidly switching between PIO and DMA mode several hundred times during installation. I would guess "yes" to the access mode changing.

[Nixie]

Thanks, I was suspecting that.
It would be safer to stick with PIO mode during install, I wonder why DMA is used at all. If I remember correctly (I may be wrong of course) PIO is faster for a dedicated task such as the install. The only advantage of DMA is when multitasking is used, where the CPU is free for other tasks while the copy runs in background.
To put an example MS WIndows 95 and 98 do not do any DMA until you tell it to try. It is a safe way.

[DOSGuy]

DMA was indeed off by default until Windows XP. My best guess is that the developers wanted to free up the CPU from having to handle all of those reads and writes, which can create significant overhead on an older computer.

The bigger question is why it keeps switching. I just found something I had never noticed before: it's only the CD-ROM drive that switches between MDMA and PIO. The primary master (the hard drive) goes to MDMA2 and stays that way. It's the primary slave (the CD-ROM) that keeps switching back and forth, filling my Bochs console with:

ata-0-1: set transfer mode to MDMA1
ata-0-1: set transfer mode to PIO
ata-0-1: set transfer mode to MDMA1
ata-0-1: set transfer mode to PIO

Great googly moogly! I can get into installation if I move the CD-ROM to secondary master! Apparently UniATA 41b5 introduced a problem to the primary slave. Interestingly, every time I move up or down the language list on the first screen, the ata1-0 device switches to MDMA1 and then back to PIO.

[PurpleGurl]

Maybe these issues should be taken up with the Uni-ATA guy.

[DOSGuy]

That was amazing! For the first time since r56869, I was able to complete installation of ReactOS in Bochs! All I had to do was move the CD-ROM drive to the secondary master.

Of course, ROS still crashes right after the logo screen due to PnP being turned on in VBE from r56112. That can be overcome by choosing VGA for the video setting during installation. Great googly moogly ROS is ugly in 16-color mode.

It's starting to seem like a good idea for ROS to assume VGA and search for VBE capability when it searches for devices. Windows stopped asking users to identify their video hardware after Windows 3.1, and assumed a 640x480x16c display until installation was complete. It should also probably assume that you don't have DMA unless you tell it that you do, or it can detect the capability.


Aww crap! Now the setup program shuts down as soon as I tell it to install Wine Gecko. It started in r57672, but I'm not sure why those changes should have that effect. If I click Cancel, setup resumes, but if I say Install, the setup program shuts down and I'm left with an empty desktop.

In the meantime, I've filed bugs CORE-6773 and CORE-6774 regarding the VBE and UniATA issues. Perhaps the latter will help to resolve your problems.

Sorry to hijack your thread, but it's possible that UniATA is causing some of your problems. Is your CD-ROM on the primary or secondary IDE channel? If it's on the primary and you have a second IDE cable, try moving it to the secondary channel. If that doesn't help, also consider trying r56869 to see if UniATA 41b5 is your problem.

[Nixie]

The CDROM was connected as primary slave and the hard disk as primary master. I have connected the CDROM as secondary master and it keeps getting stuck at the copy.
Sometimes instead of the error message it displays the progress bar and the first file to copy (acpi.sys) and sits there.

By the way the motherboard string is i440ZX-P2-99 and hard disk is Maxtor 82559A4.

[DOSGuy]

Just to be sure, when you moved the CD-ROM to the secondary channel, did you also change the jumper setting to master? I'm not sure the secondary slave would be discovered without a master, but it doesn't hurt to ask.

[Nixie]

Yes. Actually to do minimal messing inside the computer I unplugged the IDE interface from the CDROM and connected another CDROM with another IDE cable to the free secondary IDE socket. This CDROM is set to master.
The BIOS summary at boot shows how it is detecting devices:
Primary master: LBA,Mode 4, 2559MB
Primary slave: None
Secondary master: CDROM,Mode 4
Secondary slave: None

I also did this way to discard any possible read error that the older CD drive in this PC could have reading a CD-RW.

In the meantime with this configuration I retried to install Puppy linux and this time succeeded.