Resource.library v44 missing in fresh OS3.9 installation

[Firestone]

Hi everyone...

I remember this error when fiddling around back in the days with the installation of OS3.9. The system boots fine, but when it comes to starting AmiDock from WBstartup, it will throw the following error:

Cannot open "resource.library", version 44
Unable to run "Amidock".

Some background:
This installation was done by mounting the cdrom in OS3.1 and fresh installation was done from there on a empty partition.
The system was not booted from the emergency disk which I believe is the key to this issue if I remember correctly.

Can anyone remember what caused this problem to happen? There must be something that doesn't get copied because the system is still in 3.1 when the installation is done....

.....hmm.... and now i suddenly noticed that "C:version" displays:

Kickstart 40.68, Workbench 45.1

I guess that the rom update was not loaded...?

[Firestone]

Strange..... been doing some experiments tonight to see if I can recreate the problem in WinUAE....

...and it works just fine in Winuae installing from the same source on empty partition. OS3.9 boots just fine and does not complain about resource.library as stated above.

The real system I'm trying to do the same on is an A3000 with Cyberstorm 060 MKII.

[zipper]

My first install on a real system did have the same error. I found out that something in Classes and Gadgets was missing as I compared with the CD. Odd...

[Firestone]

Originally Posted by zipper

My first install on a real system did have the same error. I found out that something in Classes and Gadgets was missing as I compared with the CD. Odd...

Yeah, you're right. It's a few gadgets + datatypes.library that is the problem here.
Really strange, I tried to copy one at a time to see which ones trigged the error.

These files need to be copied again from the cd, although all files are identical. Same date, same size:

Libs/datatypes.library
classes/gadgets/layout.gadget
classes/gadgets/chooser.gadget
classes/gadgets/speedbar.gadget

For all I know, the rest of them could be a problem too, but these are enough to get Amidock to launch again, and for Prefs-programs to start.....
Strangest thing in the world.....

[Firestone]

All right, now I'm getting somewhere.

I've done some more experiments around this strange problem.
It has always been a strange thing with the OS3.9 installation, even back in the days when it was new.

It occured to me that the only difference between me copying the same files over again from the CD into Sys:classes is that I'm doing the copy-operation either the copy shell command or in Dopus5.

All replaced files have the same date, same size and so on, so there really shouldn't be a difference.

So I decided to try running the installationscript with a different "Installer".
The icon on the OS3.9 cd refers to the installer in progdir:c/installer (or c/installer in the icon).

So I switched it with just "Installer" to run it from the current enviroment. In this case I used the 3.2 Installer.
It will fail to compile the script because the OS3.9 installer got some functions as far as I can se that's not present in 3.2.
So I removed all the things it complained about. Mostly "(back)", "(trace)" and "(retrace)".

Installer was now able to run the script. And after installation was done, I gave the machine a cold reboot into OS3.9.
And guess what, now it freakin works out of the box without copying those gadgets one more time.

I looked again in the Installer-script, and all it does is using the build in "copyfiles" function of installer.
If a clean install is selected, all contents of the Workbench3.5/-drawer is copied to the destination first, and then the contents of Workbench3.9/
The last one will overwrite old versions from 3.5 as intended.

So the question remains, is this a bug only in the copy-routine in the 3.9 Installer-program itself?
As it worked fine in an emulated environment, I guess the only difference is the CPU which is a 68060 in the A3000, and a 68020 in WinUAE.
...and yeah of course, I was emulating an A1200 with IDE, and not internal SCSI if that matters...

[Daedalus]

I've never had that issue with the 3.9 installer, but I have always installed using the boot floppy (as required by the installation instructions). This avoids other issues that can come from directly installing from a non-3.9 environment, such as incorrectly copied icons for some system components. The emergency disk doesn't provide those classes, but I think it's entirely possible that the issue stems from the direct installation, possibly a mismatch of the 3.9 installer utility and the non-3.9 environment it was run in.

[Firestone]

Probably yes.

Can you share the details with your experiences with incorrectly copied items? What's that about?

[thomas]

There is serious lack of information in this thread.

What is the hardware configuration?
What kind of HDD is used and where is it connected to?
Where is the CD drive connected to?
Which software is used to access the drive in 3.1?
How are buffers, Mask, MaxTranfer, BufMemType set for each partition and the CD drive?
If SCSI is used, how is the bus terminated?
Is DMA used or not?
Is Reselection enabled or not?
Synchronous or Asynchronous?
Are the 060 libs installed properly?

3.2 is made for 68000 CPUs, 3.9 requires a 020. The 020 optimisations might cause trouble on higher CPUs if the CPU libs are missing.

I doubt that there is a copy bug in the 3.9 Installer. I rather suppose that it uses larger buffers which triggers a malfunction of your hardware.

And of course it matters that you don't configure the emulator accurately.

[Daedalus]

Originally Posted by Firestone

Can you share the details with your experiences with incorrectly copied items? What's that about?

The installation process makes use of features of certain 3.9 libraries that don't exist on a 3.1 setup for example, and can't be loaded once the OS has booted. The icon library is used for copying icons for example, and if you install without booting from the emergency disk, you'll often end up with some icons that are missing the extra colours or otherwise corrupted.

But have a look at thomas' points above - it's very easy for an emulated setup to differ from real hardware even though the settings mostly match.

[Firestone]

Originally Posted by thomas

There is serious lack of information in this thread.

What is the hardware configuration?
What kind of HDD is used and where is it connected to?
Where is the CD drive connected to?
Which software is used to access the drive in 3.1?
How are buffers, Mask, MaxTranfer, BufMemType set for each partition and the CD drive?
If SCSI is used, how is the bus terminated?
Is DMA used or not?
Is Reselection enabled or not?
Synchronous or Asynchronous?
Are the 060 libs installed properly?

You're right thomas, sorry about that.

The system I'm doing these experiments on is an
Amiga 3000
Cyberstorm MKII 060/50Mhz with 144MB fastram (16+128)
AmigaNET ethernet board
Cybervision 64

Using the internal scsi-interface with SCSI2SD v5.

Target partition for installation is formatted with FFS 47.4 (previously PFS3 AIO 18.5, same result anyway)

30 buffers, mask: 0x7FFFFFFE, MaxTransfer 0xFFFFFF

There is no CD drive in this system. The contents of the CD has been moved over from another Amiga with a CD drive.

But you seem to have solved the copy issue where files had to be copied again. It was in fact the 060 libs.
The 3.1 system that was a plain install in this experiment, did only contain the original 68040.library from the 3.1 disk set.

I repeated the same thing now only with the newest 68040(dummy).library and 68060.library installed, and did the installation again.
This time everything went fine. No complains about missing resource.library, no problems with classes or gadgets. So this was probably the most important difference between the UAE-installation I compared with which was a 020-system, and this 060 system.

Of course, as Daedalus said, the problems with the icons occured because I didn't boot from the emergency disk. Icons are missing colors.

So I created the emergency disk, and just added an assign to "AmigaOS3.9" to the drawer the installationfiles are stored in startup-sequence on the emergency disk, and the disk boots fine into 3.9 "Notfall boot".
The installation program automatically copied the 040/060 libs over to the emergency disk.

Tried to install again from there as a fresh install over OS3.x or empty HD, and it worked fine. Icons are fine, everything works again. (booted from emergency boot disk).

A little background for this experiment, is that I'm trying to find the quickest way to do a fresh install of 3.9 from to an empty HD.
But I've learned now, that this needs to happen when the OS3.9 environment has been started first..... at least if it's going to happen through the original installer-script.

I guess the problem with icons happens because the tool "Iconpos" in the installer requires the 3.9 icon.library.
Icons will also loose it's colors if you in a 3.1 environment tries to change some tooltypes of the icon and save it again as far as I could see.

Thanks both of you for your tips! Cheers!

[thomas]

Originally Posted by Firestone

I'm trying to find the quickest way to do a fresh install of 3.9

All you need is on the CD. The emergency disk is only needed to access the CD.

If you can access the contents of the CD by another way, you can as well use a script with Assign and Execute commands to move the boot process over to the CD (in the end that's what the emergency disk does, too)

It's important that 3.9 (or 3.5) is already active when you start the actual installation. But how you get there does not matter.


Another fast (quick and dirty) method to install OS 3.9 is to skip the installation and just copy the contents of the Emergency-Boot directory to the harddrive. Then find and copy the installer's startup-seqence to the HDD's S directory and copy other needed files like the 060 libs.

[Firestone]

Thanks again thomas. Very helpful as always!

[Leon Besson]

Something to note here;

MaxTransfer 0xFFFFFF

Have you tried MaxTransfer 0x1fe00

Sometimes the maxtransfer can cause corruptions.

Have had something similar in the past when installing 3.9 with an 060. Find you have to have 68060.Libs in Libs: directory or it’s no dice Bromigo! And you get the error you describe with AmiDock.

[Daedalus]

Originally Posted by Leon Besson

Have you tried MaxTransfer 0x1fe00

The MaxTransfer workaround isn't needed in this case (A3000 SCSI).

[Leon Besson]

Originally Posted by Daedalus

The MaxTransfer workaround isn't needed in this case (A3000 SCSI).

Does this work for all SCSI controllers? Only asking as I tried this mask before with a Blizzard 603+ with NCR SCSI controller and I couldn’t get anything to boot with it unless I used 1FE00 maxtransfer

[daxb]

Don't confuse MaxTransfer and Mask.

[Leon Besson]

Originally Posted by daxb

Don't confuse MaxTransfer and Mask.

Ja mein Hier!

I got served! Mangs!

[thomas]

The smallest SCSI command is READ(6). It has an 8-bit length field, just like IDE, so it could suffer from a MaxTransfer issue at 128 KB. But it also has a 21-bit LBA which limits the disk size to 1GB.

The next bigger SCSI command is READ(10). It has a 16-bit length field and a 32-bit LBA, so the MaxTransfer limit is 32 MB and the maximum disk size is 2 TB.

All with 512 bytes per sector.

This means, every SCSI driver which can deal with disks larger than 1 GB does not have a real issue with MaxTransfer.

[BarryB]

Strangely, my AmiDock in WinUAE on an installed OS3.9 has just thrown up this error too!!

Turned out a Polish program 'Mentor' I was testing overwrote C:assign with an older version so the ADD option of assign was not recognised and threw up loads of 'Bad Args' messages as well as the 'cannot open resource.library' message!

Replacing assign with the one from the Workbench 3.5 folder on the OS3.9 CD fixed it