Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: Michele31415 on September 09, 2021, 08:33:40 PM
-
In attempting to restore my hard disk fs3: from a USB stick to the SCSI2HD on my A2000, it somehow became unbootable. I can still boot from floppy and the hard disk appears on the WB 3.1 screen and I can see all the restored files there but it won't boot.
So if I say "install fs3:" will that erase all the files I copied from the USB stick? I'm asking because it took over two hours to do the copy the first time, mostly because every 10 files or so I got a pop-up saying "bad sector" on the USB stick (but then it worked fine after selecting Retry). I'd rather not have to go through that again. It would be nice if Install wrote a boot block and nothing else.
-
It should not work but don't even try it. Install writes a bootblock to a floppy disk or thelike. HDs have RDBs, so you would not make it bootable with this.
-
Oh! Well that's really good to know - I'm glad I asked first. So is there any way to install an OS on a hard disk without affecting the files already on the disk?
-
There a several steps to this. First you have to find out why (if) it doesn't boot. The OS files could still be present but maybe your machine catched a virus or something.
We don't have enough informations about your system atm to diagnose this problem.
-
it won't boot
That's a rather bad description of the problem.
A harddisk partition is marked bootable in the partition table (using HDToolbox or the like). It does not need a boot block. And it will boot no matter if there are files on it or not. If there are no files, you get an empty DOS prompt.
So you should have a closer look where it gets stuck. If you see the insert-disk screen, check with HDToolbox if the partition is marked bootable.
If you get an empty DOS prompt although you think all the right files are installed, check with HDToolbox if there are multiple partitions marked as bootable and if the one you want to boot from has the highest priority.
If you get a DOS prompt with an error message, tell us what the message is.
If it ends with an empty screen with only the "Workbench screen" bar and no icons, boot from floppy, edit startup-sequence of the harddisk and remove the EndCLI command at the end. Then reboot from harddisk and look for error messages.
If something else happens, tell us.
-
You're absolutely right. Here is hopefully a better description. I have a 1 GB disk defined as LUN 0 and named FS3: on my 16 GB SD card in my SCSI2HD connected to a GVP HC+8 SCSI contyroller. There's also a 2 GB hard disk and a CD-ROM on the same SCSI daisy chain.
Originally, I booted 3.1 from floppy and installed 3.1 on FS3:. That worked fine. If I just powered up the machine, it booted directly to OS 3.1 on FS3:. Then I reloaded my backup of the original FS3: hard drive from a USB stick onto the new SCSI2SD FS3: by saying "copy <usb-name> FS3: all". Took about two hours.
Now when I try to boot from the SCSI2SD, the disk activity LED flashes around for a few seconds as usual but then all activity stops and I see nothing but a light gray screen. If I try to reboot using CTL-A-A, I get more disk activity and then the red error box with "Software failure. Press left mouse button to continue. Error: 0000 0008 Task: 00212DA0". At this point I have to power-cycle the machine to even be able to boot from my 3.1 floppy. That works, and an FS3: drawer icon appears on the workbench screen and I can access all the files there.
HDToolBox said there are "no drives in system". The window for the drives was empty and all the buttons below were grayed out except for Help and Exit. So I changed scsi.device to gvpscsi.device in the icon's info. Now it shows the drives on the SCSI2HD. But how do I tell if it thinks they're bootable?
If I try to boot FS3: using the "boot with no startup-sequence" option from the preboot diagnostic screen, it just goes to the ROM OS screen.
One other possibly relevant point - the USB backup was a 3.9 OS.
-
Originally, I booted 3.1 from floppy and installed 3.1 on FS3:. That worked fine. If I just powered up the machine, it booted directly to OS 3.1 on FS3:.
So there's nothing wrong with partitions and boot blocks and so on.
Then I reloaded my backup of the original FS3: hard drive from a USB stick onto the new SCSI2SD FS3: by saying "copy <usb-name> FS3: all". Took about two hours.
Now when I try to boot from the SCSI2SD, the disk activity LED flashes around for a few seconds as usual but then all activity stops and I see nothing but a light gray screen. If I try to reboot using CTL-A-A, I get more disk activity and then the red error box with "Software failure. Press left mouse button to continue. Error: 0000 0008 Task: 00212DA0".
It's rather with the files you copy to the disk.
How much do you trust that backup if it gives you "bad block" errors all over the place? Are you confident that the files are not corrupted?
Was this backup made from the same machine you try to restore it to? With the same CPU, the same RAM, the same expansions and the same harddisks?
If I try to boot FS3: using the "boot with no startup-sequence" option from the preboot diagnostic screen, it just goes to the ROM OS screen.
What do you mean by "ROM OS screen"? This one: http://www.gregdonner.org/workbench/images/wb_31k.gif ?
Do you say, you can enter the early startup menu, see your FS3 partition there, click on boot or boot without startup-sequence and then it tells you there is no harddisk any more?
One other possibly relevant point - the USB backup was a 3.9 OS.
Yes, that's relevant. OS 3.9 has a set of modules which they call ROM update. These modules are loaded after power-on and then activated by an immediate reboot. That second boot (and all subsequent reboots) can behave completely different than the first one because of this ROM update.
And IMHO what you describe about software failure after Ctrl-A-A sounds just like that.
-
By ROM OS screen I mean the window that says "AmigaDOS ROM Operating System" and just has a "1>" prompt on it.
I can't say for certain the USB stick files are OK. I do know that I was able to read that stick on my PC without any errors. I checked a random sample of files that I copied to the new FS3: and they looked OK. But clearly, that copy operation trashed the OS, either due to some bad files or because the backup was OS 3.9 and the OS on FS3: was 3.1.
So I decided to format one of my unused disks on the SCSI2SD and copied FS3: to that as a backup. Then I tried reinstalling 3.1 on FS3:. It said it worked OK but when I rebooted, it threw all sorts of errors like "Unable to find Sound", "Unable to find SCSI LUN 6" and "Volume not registered", and then went to the Software Error screen.
At this point I decided it wasn't worth trying to recover this drive. I just reformatted it and will do a clean OS 3.1 install from floppy on it, then install AmiCDFS from floppy. That will let me read the OS 3.9 CD and do that upgrade. Then I can selectively copy back the non-system directories from my copy of FS3:
UPDATE:
As long as I was reformatting I decided to increase the size of FS3: from 1 GB to 4 GB using UDToolbox. Then I started the Format operation. The disk activity light started flickering and all looked good. But I just checked again - the LED is still flickering but it's been three hours and the progress bar is still stuck on zero. Does it really take this long to format a big SD disk or is something else wrong now?
-
Never do a full format. Quick format is sufficient.
Also making the boot partition larger than 2GB can cause severe problems.
-
Oh *DUH*! I knew that but somehow ended up clicking on Format instead of Quick Format. Quick format worked just fine (and quickly). The new disk shows up as 2 GB. I loaded WB 3.1 from floppy, rebooted and all was still good. I installed ASimCDFS from floppy and then ran the OS 3.9 Installer from CD. It said it completed successfully and that I should reboot.
But when I did - we're back to the "Software error" in a red box again. I don't get it - this is the same machine as the original install. The only difference is that I now have the GVP HC+8 SCSI controller and a SCSI2SD instead of the A2091 and an actual Quantum hard drive.
I was able to reboot using the 3.9 Emergency Rescue Disk but it's not clear what to do next. Running info shows that it thinks DH0: (what I'm calling FS3:) is "not a DOS disk".
I'm wondering - since a clean 3.9 install from CD fails the same way as my attempted USB backup restore (which contains 3.9) maybe something else is going on here, like the GVP controller. I know it uses its own gvpscsi.device instead of scsi.device. Could that be why this isn't working?
-
There’s a bug in these newish OS releases (OS 3.1.4 and I suppose this so called “Workbench 3.2” too) that if you select more than one NDOS partition and pick “format” from the menu, the “quick format” is only available in one of the format windows that pops up, in the others it is grayed out. Maybe that happened to you?
-
But when I did - we're back to the "Software error" in a red box again. I don't get it - this is the same machine as the original install. The only difference is that I now have the GVP HC+8 SCSI controller and a SCSI2SD instead of the A2091 and an actual Quantum hard drive.
Seems like we'll have to go into details now.
Can you please run this program and add the report as an attachment here: https://thomas-rapp.homepage.t-online.de/downloads/hddreport.lha
After that edit Startup-Sequence of FS3. Add
set echo on
as the very first line. Save it and reboot. Try to see which command is executed last when the Software Error appears.
-
No, it was just operator error. I saw both the Format and Quick Format buttons and somehow wasn't thinking that Quick Format was the one I wanted. No harm done though. I canceled the unending Format, did it over again with a Quick Format and that worked OK.
-
Can you please run this program and add the report as an attachment here: https://thomas-rapp.homepage.t-online.de/downloads/hddreport.lha
After that edit Startup-Sequence of FS3. Add
set echo on
Thanks - got it! The problem right now is that there is no FS3: anymore. When I boot from the OS 3.9 emergency disk, FS3's icon doesn't even appear on the WB screen. I have to go to HDToolbox to find it (SCSI address 0). Should I reformat it and load OS 3.1 back on it and then run your program? (I may not be able to get to this today though - I have a bunch of errands to run).
-
When I boot from the OS 3.9 emergency disk, FS3's icon doesn't even appear on the WB screen.
This seems to match the other symptoms. What if you boot from the 3.1 Workbench disk?
I have to go to HDToolbox to find it (SCSI address 0).
But the partition is still there?
Should I reformat it and load OS 3.1 back on it and then run your program?
No, that's not necessary. If HDToolbox finds the partition, then HDDReport should find it, too. Just run it.
As a first try to fix the issue, boot from a floppy disk from where you see the FS3 drive (WB 3.1 probably), go to the Devs folder of FS3 and rename the file AmigaOS ROM Update to something else.
-
Holy moly, Thomas - you're a genius! I renamed that file, removed the OS 3.1 floppy, did a CTL-A-A reboot and hey presto, it booted right into FS3: running OS 3.9! I've been pulling my hair out over this for a week now. Problem solved. Thank you so much!
-
It's not really a solution but rather a workaround. By renaming the ROM update file you actually deactivated one half of OS 3.9. The better solution would have been to investigate which part of the ROM update causes the software error and exclude it explicitly.
There might still be an issue with your system, you just don't notice any more.
-
...
So if I say "install fs3:" will that erase all the files I copied from the USB stick?
The "Install" command (all the versions which shipped with Workbench 1.x, 2.x, 3.x and also 4.x) is safe to use with storage devices which aren't df0, df1, df2 or df3. The "worst" that could happen is that the "Install" command will complain with the somewhat unspecific error message "object is of the wrong type" (what is that "object"? it's the device you wanted to install a boot block on) or just printing the command template ("Usage: INSTALL [DRIVE] {DF0:|DF1:|DF2:|DF3:} [NOBOOT][CHECK]") again.
The "Install" command versions which shipped with Workbench versions 1.x, 2.x, 3.1, 3.5 and 3.9) are restricted to df0-df9 and (2.x onwards) cc0-cc9 (for the Amiga 600 and Amiga 1200). If you had unwisely picked any of these storage device names for your USB stick partition name, then strange things would have happened. These "Install" command versions make assumptions about the storage device driver (df0-df9 will give you "trackdisk.device" and cc0-cc9 will give you "carddisk.device").
Things are a little bit different for the "Install" commands which shipped with AmigaOS 4.x, 3.1.4, 3.1.4.1 and 3.2. The 3.2 and 4.x versions will do their utmost to verify that the storage device to install a boot block on makes sense. For example, any floppy disk drive is configured to feature two reserved blocks at the very beginning of the storage medium which are not available for file system use, and the disk covers the entire storage medium (i.e. the "df0:" device configuration includes both the very first and very last cylinder of the medium: this is never true for the partitions defined by an Amiga RDB block created by HDToolbox, etc.). These are the basic criteria for a storage device which could make use of a boot block: the boot block goes into these two reserved blocks (there must be enough room for at least 1024 bytes of floppy disk boot block code) and should not accidentally damage any data stored there. Otherwise you might end up knocking out the partition, etc. information stored in an Amiga RDB block which defines the layout and properties of all the partitions on the storage medium, and then some.
What about the 3.1.4 and 3.1.4.1 versions then? Just like the 4.x and 3.2 versions they allow you to use the "Install" command with storage devices other than df0-df0 and cc0-cc1 and figure out the correct storage device driver for the respective device (e.g. it determines that df0 is associated with trackdisk.device unit 0 instead of assuming that df0 must correspond to trackdisk.device unit 0). Unlike the 4.x and 3.2 versions, however, they are less paranoid when it comes to check if the storage device should have a boot block installed on it. Also, the 4.x and 3.2 versions really verify if the boot block found on such a storage device features a correct checksum (none of the other versions ever did that).
That's the (perhaps overly) long explanation ;) You should be unable to destroy your hard disk or USB stick partitions using the "Install" command, but you should not need to use the "Install" command on these either if you have already used HDToolbox (or a more capable and less quirky/brittle such partitioning tool) to set up a storage device. The "Install" command is really just for storage devices which the Amiga operating system considers special (such as df0-df9 and cc0-cc9). For all other storage devices there would be a hard disk controller such as for the IDE or SCSI hardware in the Amiga 4000T which upon system startup looks for Amiga RDB partitioning information on its connected devices.
-
It's not really a solution but rather a workaround. By renaming the ROM update file you actually deactivated one half of OS 3.9. The better solution would have been to investigate which part of the ROM update causes the software error and exclude it explicitly.
There might still be an issue with your system, you just don't notice any more.
Oh? Bummer then. Which half? Is there a way to figure that out? In playing around with it yesterday, I'm having trouble getting my x-surf 3 card to connect to the net. I also can't find the screensaver icon that's supposed to be in Prefs.
-
The "Install" command (all the versions which shipped with Workbench 1.x, 2.x, 3.x and also 4.x) is safe to use with storage devices which aren't df0, df1, df2 or df3. The "worst" that could happen is that the "Install" command will complain with the somewhat unspecific error message "object is of the wrong type" (what is that "object"? it's the device you wanted to install a boot block on) or just printing the command template ("Usage: INSTALL [DRIVE] {DF0:|DF1:|DF2:|DF3:} [NOBOOT][CHECK]") again.
...
Thank you for taking the time to write such a comprehensive explanation of this command. This post ought to be made a sticky for future reference.
-
I also can't find the screensaver icon that's supposed to be in Prefs.
Maybe because it’s not supposed to be there.
-
@Michele31415
Perhaps you are confusing this with the Blanker commodity. Found in SYS:Tools/Commodities.
-
I also can't find the screensaver icon that's supposed to be in Prefs.
Maybe because it’s not supposed to be there.
Isn't this?
https://wiki.amigaos.net/wiki/AmigaOS_Manual:_Workbench_Preferences#ScreenBlanker_Editor
-
No, that is OS4.
-
Blanker is in Tools/Commodities.
-
Blanker is in Tools/Commodities.
Thanks. That's what I was looking for. It wasn't mentioned in any of the search results I got.
-
No, that is OS4.
I see. I guess I was confused because I followed a search result there and there was no mention of it being for OS 4 on that page. You have to go back to the Main page and then read halfway down before finding a single reference to "4.0" there. So can I upgrade from 3.9 to 4.0? I seem to recall reading somewhere that 3.9 was the end of the line for the A2000.
-
No, that is OS4.
So can I upgrade from 3.9 to 4.0? I seem to recall reading somewhere that 3.9 was the end of the line for the A2000.
No, you cannot upgrade - OS4.0 (and upwards, latest is 4.1FE update 2 - "final edition") is for PowerPC systems.
I won't comment on what is end of line for the A2000, it depends on who you ask - 3.9 is one option, 3.2 is another option, many would argue that it really is 3.1.
-
Instead of calling anything "end of line", at least this can be said:
3.1 was the last version with involvement from the "original" Commodore.
Then Haage & Partners (read: developers working for ...) made 3.5 and 3.9 based on 3.1. Some of the sources of those components were owned by the contributors and were not put back into the official AmigaOS repository, while others were.
Then Hyperion (read: same same ...) made 4.x, which, as Kolla writes, is now at 4.1 Final Edition Update 2 plus a few smaller updates. 4.x is a fully ported (and further developed) version for PowerPC machines aka NG Amigas and won't work on 68k machines.
Then, for classic Amigas/68k, some other developers made 3.1.4 and 3.2 based on 3.1 plus some 68k reimplementations of some of the 4.x parts as well as some other improvements (I haven't tried it, so others may be better at describing it). Hyperion also marketed these.
So 3.5/3.9 may be an end of one line, but other lines have taken over the various needs of transportation (to stay in the terminology).
I think that's about it?
Best regards,
Niels
-
Then, for classic Amigas/68k, some other developers made 3.1.4 and 3.2 based on 3.1 plus some 68k reimplementations of some of the 4.x parts as well as some other improvements
For 3.1.4, they weren’t “other developers”, they were pretty much the same ones that also worked on 3.5 and 3.9, most of the key components also came from 3.9 just as much as from 3.1 directly, only a few came via 4.x. The only missing 3.9 components were all the ReAction classes and resource.library, and software relying on these, essentially all OS3.9 Reaction based prefs programs. Oh, and HDToolBox (and hdwrench.library) by Joan Dow. With 3.2 ReAction classes and various other components/features were ported/reimplemented back from OS 4.x, and some developers replaced in the process. Noteworthy is that key developer and one if the two original initiative takers of 3.1.4 and arguably the most influential OS 3.2 developer (you know who), left the OS team long before its release, and is now seen arguing with some of the current developers (the usual very opinionated suspects) over certain choices done for the OS 3.2 release. So I would argue that the REAL end-of-line OS release for A2000 (and the other 68k systems) is currently on the hard drive of ThoR :)
And this brings us back to what Amiga is REALLY about - drama! - arguing, whining, bickering, blaming, entitlement, huge egos, besserwissers, splitting, forking, hacking, patching… :)
-
For 3.1.4, they weren’t “other developers”, they were pretty much the same ones that also worked on 3.5 and 3.9,
Agreed, and thanks for the correction. I did actually plan to formulate this differently, but got distracted and forgot.
What I thought about was that some of the developers closest to H&P, not least Jochen Becher, took part in the "dead end", if it was, where their sources never went into the OS repository (for good or bad reasons, not my place to judge). Therefore those modules weren't available as parts/basis for neither 4.x nor 3.1.4/3.2.
most of the key components also came from 3.9 just as much as from 3.1 directly, only a few came via 4.x. The only missing 3.9 components were all the ReAction classes and resource.library, and software relying on these, essentially all OS3.9 Reaction based prefs programs.
Thanks for that clarification too - as I wrote, I haven't used these later 3.x releases or been as close to their creation as I have been to the others.
Oh, and HDToolBox (and hdwrench.library) by Joan Dow.
Joanne, actually (sorry for nitpicking :-)). But she left already after 3.5, IIRC.
So I would argue that the REAL end-of-line OS release for A2000 (and the other 68k systems) is currently on the hard drive of ThoR :)
Oh dear, sounds like a sad, but recognizable story ...
And this brings us back to what Amiga is REALLY about - drama! - arguing, whining, bickering, blaming, entitlement, huge egos, besserwissers, splitting, forking, hacking, patching… :)
Indeed. Wish all that negative energy could be reversed and put to better use.
Best regards,
Niels