AmigaOS 3.2 crash when booting up

[guybrush]

Using a 64 GB card, with one partition used for WB (500 mb), and 2x30 GB partitions for extras.



Prepped the card on the Amiga1200, installed the OS booting from 3.1 roms, but after the second reboot after the loadmodule, I get the software error blinking message; and the machine reboot.


So far had no luck getting 3.2 running on my 1200 with Blizzard 1230 MK4; it boot fine using the modules1200 adf disk, it boots fine using the installer 3.2 disk, to the point where I can install the whole OS fine but it won't boot in 3.2.


I tried on UAE and it works fine; so the installation is fine.

After a bit of investigation, I found what makes it crash: If I cold boot the 1200; and boot directly from the CF card, it does give me the software error and does not load WB; but if I boot using the module disk, and after the first reboot I remove the module disk, it does boot fine from the hard disk. At this point I think there is something going on with the installer then; it does the same no matter what card size and partition size I use; so the issue is neither the partition size nor how big the CF card is.

I also tried with and without libs for the 030 card and it does the same exact thing. The cold start seems to be the issue; if I reset the computer but I keep it on, the WB load just fine. Any help on the subject about how to fix this would be really appreciated... I can use the boot disk for now but it is not really ideal.

[indigolemon]

Try adding

NOMEMFKICK REVERSE

to the end of the LoadModule line in your startup-sequence.

[thomas]

Where is the HDD connected to, IDE or SCSI?

If IDE, how did you set MaxTransfer for the partitions? As you first boot with Kick 3.1, MaxTransfer does matter.

[guybrush]

Originally Posted by indigolemon

Try adding

NOMEMFKICK REVERSE

to the end of the LoadModule line in your startup-sequence.

Thanks, tried to add those 2 commands to loadmodule line but it is still crashing

[guybrush]

Originally Posted by thomas

Where is the HDD connected to, IDE or SCSI?

If IDE, how did you set MaxTransfer for the partitions? As you first boot with Kick 3.1, MaxTransfer does matter.

The drive is connected to a standard IDE adapter; I tried 2 different adapters and the result is the same.


Oh, I didn't set MaxTransfer when I created the partitions :O Although why would it work if I use the modules disk first? I can give it a try though. Can I change the MaxTransfer value on an existing drive or do I need to delete the partitions and re-create them?

[thomas]

Originally Posted by guybrush

Although why would it work if I use the modules disk first?

Because the Modules disk updates scsi.device and the updated scsi.device does not have the MaxTransfer issue.

Can I change the MaxTransfer value on an existing drive or do I need to delete the partitions and re-create them?

You can change it. But whether it helps depends on how you installed the OS. If you installed the OS in WinUAE or on the A1200 with the updated scsi.device, then all files probably have been written ok and changing MaxTransfer cures the issue.

But if you installed the OS on the A1200 with only Kick 3.1, then files have been corrupted during writing and changing MaxTransfer does not fix anything. In this case you have to re-install the OS (or at least copy all files bigger than 128K from the installation media again).

BTW, you can emulate the MaxTransfer issue in WinUAE if you change the controller to IDE and the mode to "ATA2+ Strict".

[guybrush]

Originally Posted by thomas

Because the Modules disk updates scsi.device and the updated scsi.device does not have the MaxTransfer issue.

You can change it. But whether it helps depends on how you installed the OS. If you installed the OS in WinUAE or on the A1200 with the updated scsi.device, then all files probably have been written ok and changing MaxTransfer cures the issue.

But if you installed the OS on the A1200 with only Kick 3.1, then files have been corrupted during writing and changing MaxTransfer does not fix anything. In this case you have to re-install the OS (or at least copy all files bigger than 128K from the installation media again).

BTW, you can emulate the MaxTransfer issue in WinUAE if you change the controller to IDE and the mode to "ATA2+ Strict".

I see; I just tried to change the max tranfer rate to 0x1FE00 on DH0 but it didn't make a difference after rebooting; so I guess I need to try reinstalling the OS. I had nothing on it anyway so no big deal.


What would be the correct order of events?


- On the real amiga I load module disk to have 3.2 ROM; then I use HDTools to create only the WB partition of 500 MB, leaving the rest of the drive empty; the DH0 partition is set to default file system and with 0x1FE00 max transfer rate.
- I reboot using the installer disk (so I am loading from 3.1 ROM and not 3.2); then I format DH0 and install 3.2 on it.

- reboot from HD; that should loadmodule for 3.2 and on subsequent reboot, start 3.2 without the software error.



Would that be the correct order of events?

[guybrush]

Good news, it works now!

I just re-installed everything using the correct max transfer rate value before install the OS and now it is working fine. Thanks for your help!

[thomas]

Originally Posted by guybrush

- I reboot using the installer disk (so I am loading from 3.1 ROM and not 3.2);

It doesn't work like that. The Modules disk installs resident modules in memory. They don't go away by a reboot. You have to switch power off to remove 3.2 modules from memory.

But the sequence you used was still correct. Boot from the Modules disk, then boot from the Install disk with 3.2 modules still im memory. There is also a "Sys to Install" script on the modules disk which saves you the reboot (if you have two floppy drives. With only one drive you have more work swapping floppies than it lasts to reboot.)

[guybrush]

Originally Posted by thomas

It doesn't work like that. The Modules disk installs resident modules in memory. They don't go away by a reboot. You have to switch power off to remove 3.2 modules from memory.

But the sequence you used was still correct. Boot from the Modules disk, then boot from the Install disk with 3.2 modules still im memory. There is also a "Sys to Install" script on the modules disk which saves you the reboot (if you have two floppy drives. With only one drive you have more work swapping floppies than it lasts to reboot.)

Thanks for your help; it was related to data transfer I guess. After re-installing everything (for the 7th time...never installed an OS so much as 3.2); now everything works.


Cheers!

[Radical]

I have a similar issue (A4000, 3.1, OS3.2). When I clone my working setup to slave hard drives they report as NDOS when set to master on the Amiga, but read normally under winuae. Thoughts?

[thomas]

File system missing on the cloned drive?

[Leon Besson]

Same size drives cloned to? Can the cloned drives be seen under HDToolBox? What is the original Filesystem used?

[Kin Hell]

Originally Posted by Radical

I have a similar issue (A4000, 3.1, OS3.2). When I clone my working setup to slave hard drives they report as NDOS when set to master on the Amiga, but read normally under winuae. Thoughts?

Just a thought.....

IDE IDC Headers on the A4KD cable?

Extrapolating a little, when the HD's Jumper is set to Master or Slave, it has to be on the correct IDC Header.

Iirc, the first IDC Header is Slave & the second is Master. (Could be the other way around....it's been a while now....)

Not entirely sure WinUAE emulates this requirement of the A4KD's cable.

You can find the original Filesystem used by checking the L: directory and or HDToolBox at the time of cloning.

[thomas]

Originally Posted by Kin Hell

Just a thought.....
Extrapolating a little, when the HD's Jumper is set to Master or Slave, it has to be on the correct IDC Header.

No, that's not true. If you correctly jumper Master and Slave on the devices, then you can connect them anywhere.

Only if you set the jumpers to Cable Select, then the position on the cable defines whether the device is Master or Slave. Master is at the end of the cable, Slave in the middle.

You can find the original Filesystem used by checking the L: directory

That's not true, either. HDToolbox tries to read L:FastFileSystem once in the beginning. But you can add, delete or update file systems later. Once you leave HDToolbox there is no reference to the L directory any more. Especially during the boot process, when partitions are mounted, it does not matter at all what is contained in the L directory.

or HDToolBox at the time of cloning.

That's the only place to check the file system version. At any time.

[Radical]

Filesystem present. ffs 47.4. If I cold boot with Modules disk Loadmodule aborts (drive validating). Reset then brings the system up. Thought to try it my 8gb CF card. Works 100%. This suggests a race condition issue to me. Thomas?

[thomas]

I guess you didn't look at the right place or for the right attribute. You have to look at the Add/Update section in HDToolbox and check the identifier. The id has to match the one of the partition. The id for long file names is 444f5307.

[Kin Hell]

Originally Posted by thomas

No, that's not true. If you correctly jumper Master and Slave on the devices, then you can connect them anywhere.

Only if you set the jumpers to Cable Select, then the position on the cable defines whether the device is Master or Slave. Master is at the end of the cable, Slave in the middle.



That's not true, either. HDToolbox tries to read L:FastFileSystem once in the beginning. But you can add, delete or update file systems later. Once you leave HDToolbox there is no reference to the L directory any more. Especially during the boot process, when partitions are mounted, it does not matter at all what is contained in the L directory.




That's the only place to check the file system version. At any time.

At least I got one right eh!

Joking aside, I do recall seeing HD's on IDE not working as a pair. Maybe it was with a 4-way header on it & my loathsomeness to install IDE-Fix. - The AK4D should have had SCSI anyhow.

Was just a thought but all the same, thanks for the refresh.

@ Radical

Good Luck fella.

[Radical]

Thanks Thomas! Changed the identifier from 444F5303 to 444F5307. This wasn't mentioned in the documentation as far as I know..

[Kin Hell]

Originally Posted by Radical

Thanks Thomas! Changed the identifier from 444F5303 to 444F5307. This wasn't mentioned in the documentation as far as I know..

So changing the Identifier resolved everything for you, yes?