HDDs gone missing

Iznougoud · 01 December 2009, 00:55

I decided, in obvious conflict with my better judgement, to update SFS on my HDDs. Being cautious, I started off with the second partition (since it's empty) on my 4.2Gb SCSI HDD, added the new SFS filesystem, and removed the old, via HDToolbox.

When I rebooted the entire HDD was gone. Entirely gone. Can't be found via HDToolbox, not listed in early startup - it is as if it never existed. Along with it went the 19Gb IDE-HDD, which isn't all that strange, since the IDE HDD is connected to the controller of the X-Surf-board.

Now, I can understand the filesystem, or RDB, being, well - fucked up, but I should at least be able to access the HDD at hardware levels. I hate to admit it, but I'm lost.

The setup (changes made in HDToolbox were written to HD1):

A2000, with a phase 5 2040ERC accelerator.

4.2Gb HDD (2060scsi.device), HD0: 1Gb HD1: 3.2Gb.

19Gb IDE (xsurf.device), HD2: 19Gb

Help is not only welcome, it's desperately needed.

thomas · 01 December 2009, 09:36

Are you sure you run HDToolbox correctly ? You need to tell it to look at 2060scsi.device, either via tooltypes (when run from Workbench) or via command line option.

If you cannot get the drive to be seen in HDToolbox, then you are really lost.

Nevertheless, which version of SFS did you have before and which version did you use to update ? Why did you add the new and remove the old, you could have choosen to update the old ? When adding the new, did you remember to change the identifier from 43465300 to 53465300 ?

Iznougoud · 01 December 2009, 12:58

I'm quite confident I've run HDToolbox correctly. Still, this would indicate a hardware error rather than a filesystem mishap, and I would consider it odd that this would coincide with my messing with the filesystem.

All my Amiga HDDs being unavailable, I'm not sure of the version number of the SFS I was upgrading to, it did require the identifier 0x33465300 though, and this identifier was found by HDToolbox.

I did upgrade from version 1.236. That I know. The new version would most likely be 1.277. Howevere, of that I'm not sure, at the time of writing.

thomas · 01 December 2009, 13:55

The question is if you have any spare parts you can use to test what caused the breakdown. Do you have another SCSI drive with which you can test if the SCSI controller still works ? Do you have another SCSI controller with which you can test the drive ?

In order to access the IDE drive you need the XSurfIDE driver in the Expansion drawer of the Workbench disk. It is loaded by the Binddrivers command in startup-sequence.
You can get it from there: http://icomp.de/t/bin/xsurfide.lha

Iznougoud · 01 December 2009, 14:10

You're quite right. And I've dug out a couple of SCSI-HDDs this morning, I'll run tests with them later this afternoon.

Doesn't look good though. HDToolbox won't list 2060scsi.device at all. The bright side, is that it doesn't list any device. Of any sort. Which might indicate something other than my Blizzard-board/SCSI-controller being at fault. And as I said, it would be one heck of a coincidence..

Still. I messed around with the second partition (DH1), provided the hardware is functional, would there be reason to suspect that DH0 has gone to meet it's maker as well? I'd really hate to rebuild that partition. Almost as much as I hate making backups

thomas · 01 December 2009, 16:34

Quote:

Still. I messed around with the second partition (DH1), provided the hardware is functional, provided the hardware is functional, would there be reason to suspect that DH0 has gone to meet it's maker as well?

Well, perhaps the step from 1.236 to 1.277 was a bit too far to be done without a backup. 1.236 is not even mentioned in the change log any more. I know for sure that there was one version step which was irreversible (i.e. made a change to the file system structure which is incompatible to older versions). It may well be that there is another version step which needs reformatting of the partition.

And of course changing the SFS code which is stored in the RDB affects all partitions which are formatted with SFS, not only DH1.

Iznougoud · 01 December 2009, 17:08

From the looks of it, the changes have been global. Found myself an ancient install of AOS3.9 on another SCSI-disk, which does find the partitions via HDToolbox - and they both are set to SFS 1.277.

Ah well.. Suppose I have a couple of weeks of rebuilding the workbench to look forward to. Any advice on that, given that I'm starting from scratch? After all, I might as well make the most of it, and if possible further optimize the system. I honestly can't recall all the patches and changes that have been made over the years..

thomas · 01 December 2009, 17:15

You should first try to revert back to 1.236 and see if the partitions magically appear again. Then make a backup.

chiark · 01 December 2009, 17:25

This is reminding me of something with a CSA Magnum 40/4 which I never got to the bottom of: I had to use the CSA tool to prep the drive, even though it supports RDB. I can take a hard disk prepared on the CSA Magnum and use it on any device, but I cannot take a disk prepped on any other device and have it recognised...

If I try to boot with a disk that hasn't been prepped by the CSA software, the csascsi.device driver isn't loaded (so without binddrivers and csascsi.device in the expansion drawer, it won't be found).

It sounds a bit familiar, that's all

Is there a specific tool you can use for the 2060?

(as an aside, I still can't work out what the CSA software is writing to the RDB or disk so that is recognised successfully!)

thomas · 01 December 2009, 17:54

Quote:

Is there a specific tool you can use for the 2060?

There is SCSIConfig on the Phase5 SCSI Disk. But it does nothing specific except that it should find all drives on Phase5 controllers without changing tooltypes or the like.

The SCSI disk is available here: http://powerup.amigaworld.de/index.php?lang=en&page=13

The disk also contains UnitControl which could be helpful in your case. It can configure the SCSI controller and cause it to rescan devices.

Quote:

I still can't work out what the CSA software is writing to the RDB or disk so that is recognised successfully!

The RDB can store drive initialization code. This feature is sometimes used to load driver updates.

Jope · 01 December 2009, 18:05

It could also store something before the RDB, like the ICD AdIDE does. The RDB doesn't have to begin at block 0. (Thomas naturally knows this, but for the benefit of the others. :-)

Iznougoud · 01 December 2009, 18:47

After some serious messing around, I've managed to access the files on DH0, and I am in the process of copying them to another HDD right now. For some unknown reason, both partitions were set to SFS 1.277, and I now seem to have managed to switch back to 1.13 (which is the correct version number).

Question is what to do now - other than introducing regular backups. Should I reformat the entire drive with SFS 1.277, or should I stay with FFS, at least on the boot partition, given that it's not that big, and use SFS 1.277 on the 20Gb IDE drive only (which I haven't started to mess with yet, and I will - obviously - backup the data before I do that). Then again, maybe SFS 1.13 is sufficient. After all, it worked fine until I started to "improve" things.

chiark · 01 December 2009, 20:29

Jope, Thomas, thanks for the info: I didn't see the drive initialisation bit in the RDB!

Glad you've recovered your data iznougoud

thomas · 01 December 2009, 20:51

Quote:

I now seem to have managed to switch back to 1.13 (which is the correct version number).

This version is really old, more than 11 years. Many changes have been done since. Of course this version is not compatible to later versions. Even the programmer has changed. The last version made by John Hendrikx was 1.84 which is already 10 years old, too. After that Jörg Strohmayer continued development.

IMHO you should make the big step and upgrade. At least to 1.84, better to 1.279.

But remember that changing SFS to a higher version on one harddrive will affect all partitions on all harddrives which are formatted with SFS. So you need to backup *everything* before you start, not only one partition.

Iznougoud · 01 December 2009, 21:18

Hopefully I've learned my lesson. And I intend to backup, and wipe the HDD. The backup, however, will be stored on an FFS-formatted HDD - just in case. As a matter of fact, after what I've been through - upgrading isn't more work than simply restoring, so I guess it's all for the best.

And before I forget it, thanks for all your help

chiark · 02 December 2009, 08:30

It's also worth backing up to a PC whilst the disk is out: just use WinUAE to either make an image of the real disk or copy everything to a mounted directory...

Jope · 02 December 2009, 14:48

Remember to use clone if using the normal cli copy command.

Iznougoud · 03 December 2009, 20:24

Given I don't have SCSI in my PC, I'll consider archiving sys: and transfer it via LAN instead...

01 December 2009, 00:55	#1
Iznougoud Quite the odd one Join Date: Sep 2007 Location: Sweden Posts: 180	HDDs gone missing I decided, in obvious conflict with my better judgement, to update SFS on my HDDs. Being cautious, I started off with the second partition (since it's empty) on my 4.2Gb SCSI HDD, added the new SFS filesystem, and removed the old, via HDToolbox. When I rebooted the entire HDD was gone. Entirely gone. Can't be found via HDToolbox, not listed in early startup - it is as if it never existed. Along with it went the 19Gb IDE-HDD, which isn't all that strange, since the IDE HDD is connected to the controller of the X-Surf-board. Now, I can understand the filesystem, or RDB, being, well - fucked up, but I should at least be able to access the HDD at hardware levels. I hate to admit it, but I'm lost. The setup (changes made in HDToolbox were written to HD1): A2000, with a phase 5 2040ERC accelerator. 4.2Gb HDD (2060scsi.device), HD0: 1Gb HD1: 3.2Gb. 19Gb IDE (xsurf.device), HD2: 19Gb Help is not only welcome, it's desperately needed.

01 December 2009, 21:18	#15
Iznougoud Quite the odd one Join Date: Sep 2007 Location: Sweden Posts: 180	Hopefully I've learned my lesson. And I intend to backup, and wipe the HDD. The backup, however, will be stored on an FFS-formatted HDD - just in case. As a matter of fact, after what I've been through - upgrading isn't more work than simply restoring, so I guess it's all for the best. And before I forget it, thanks for all your help Last edited by Iznougoud; 02 December 2009 at 07:54. Reason: Deleted a question which wasn't relevant anymore.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
What am I missing here?	illy5603	support.WinUAE	4	12 August 2008 13:58
Formatting / Wiping Amiga HDDs...	AliasXZ	New to Emulation or Amiga scene	10	27 January 2008 01:52
Why is it missing ?	-Rob-	Coders. General	61	22 August 2006 08:24
Amiga and 'new age' HDDs	kas1e	support.Hardware	6	12 October 2005 23:59
Am i missing something here ?!?!	THX1138	MarketPlace	9	16 December 2003 13:45

01 December 2009, 09:36	#2
thomas Registered User Join Date: Jan 2002 Location: Germany Posts: 6,985	Are you sure you run HDToolbox correctly ? You need to tell it to look at 2060scsi.device, either via tooltypes (when run from Workbench) or via command line option. If you cannot get the drive to be seen in HDToolbox, then you are really lost. Nevertheless, which version of SFS did you have before and which version did you use to update ? Why did you add the new and remove the old, you could have choosen to update the old ? When adding the new, did you remember to change the identifier from 43465300 to 53465300 ?

01 December 2009, 12:58	#3
Iznougoud Quite the odd one Join Date: Sep 2007 Location: Sweden Posts: 180	I'm quite confident I've run HDToolbox correctly. Still, this would indicate a hardware error rather than a filesystem mishap, and I would consider it odd that this would coincide with my messing with the filesystem. All my Amiga HDDs being unavailable, I'm not sure of the version number of the SFS I was upgrading to, it did require the identifier 0x33465300 though, and this identifier was found by HDToolbox. I did upgrade from version 1.236. That I know. The new version would most likely be 1.277. Howevere, of that I'm not sure, at the time of writing.

01 December 2009, 13:55	#4
thomas Registered User Join Date: Jan 2002 Location: Germany Posts: 6,985	The question is if you have any spare parts you can use to test what caused the breakdown. Do you have another SCSI drive with which you can test if the SCSI controller still works ? Do you have another SCSI controller with which you can test the drive ? In order to access the IDE drive you need the XSurfIDE driver in the Expansion drawer of the Workbench disk. It is loaded by the Binddrivers command in startup-sequence. You can get it from there: http://icomp.de/t/bin/xsurfide.lha

01 December 2009, 14:10	#5
Iznougoud Quite the odd one Join Date: Sep 2007 Location: Sweden Posts: 180	You're quite right. And I've dug out a couple of SCSI-HDDs this morning, I'll run tests with them later this afternoon. Doesn't look good though. HDToolbox won't list 2060scsi.device at all. The bright side, is that it doesn't list any device. Of any sort. Which might indicate something other than my Blizzard-board/SCSI-controller being at fault. And as I said, it would be one heck of a coincidence.. Still. I messed around with the second partition (DH1), provided the hardware is functional, would there be reason to suspect that DH0 has gone to meet it's maker as well? I'd really hate to rebuild that partition. Almost as much as I hate making backups

01 December 2009, 17:08	#7
Iznougoud Quite the odd one Join Date: Sep 2007 Location: Sweden Posts: 180	From the looks of it, the changes have been global. Found myself an ancient install of AOS3.9 on another SCSI-disk, which does find the partitions via HDToolbox - and they both are set to SFS 1.277. Ah well.. Suppose I have a couple of weeks of rebuilding the workbench to look forward to. Any advice on that, given that I'm starting from scratch? After all, I might as well make the most of it, and if possible further optimize the system. I honestly can't recall all the patches and changes that have been made over the years..

01 December 2009, 17:15	#8
thomas Registered User Join Date: Jan 2002 Location: Germany Posts: 6,985	You should first try to revert back to 1.236 and see if the partitions magically appear again. Then make a backup.

01 December 2009, 17:25	#9
chiark Needs a life Join Date: Jan 2008 Location: England Posts: 1,707	This is reminding me of something with a CSA Magnum 40/4 which I never got to the bottom of: I had to use the CSA tool to prep the drive, even though it supports RDB. I can take a hard disk prepared on the CSA Magnum and use it on any device, but I cannot take a disk prepped on any other device and have it recognised... If I try to boot with a disk that hasn't been prepped by the CSA software, the csascsi.device driver isn't loaded (so without binddrivers and csascsi.device in the expansion drawer, it won't be found). It sounds a bit familiar, that's all Is there a specific tool you can use for the 2060? (as an aside, I still can't work out what the CSA software is writing to the RDB or disk so that is recognised successfully!)

01 December 2009, 18:05	#11
Jope - Join Date: Jul 2003 Location: Helsinki / Finland Age: 43 Posts: 9,861	It could also store something before the RDB, like the ICD AdIDE does. The RDB doesn't have to begin at block 0. (Thomas naturally knows this, but for the benefit of the others. :-)

01 December 2009, 18:47	#12
Iznougoud Quite the odd one Join Date: Sep 2007 Location: Sweden Posts: 180	After some serious messing around, I've managed to access the files on DH0, and I am in the process of copying them to another HDD right now. For some unknown reason, both partitions were set to SFS 1.277, and I now seem to have managed to switch back to 1.13 (which is the correct version number). Question is what to do now - other than introducing regular backups. Should I reformat the entire drive with SFS 1.277, or should I stay with FFS, at least on the boot partition, given that it's not that big, and use SFS 1.277 on the 20Gb IDE drive only (which I haven't started to mess with yet, and I will - obviously - backup the data before I do that). Then again, maybe SFS 1.13 is sufficient. After all, it worked fine until I started to "improve" things.

01 December 2009, 20:29	#13
chiark Needs a life Join Date: Jan 2008 Location: England Posts: 1,707	Jope, Thomas, thanks for the info: I didn't see the drive initialisation bit in the RDB! Glad you've recovered your data iznougoud

02 December 2009, 08:30	#16
chiark Needs a life Join Date: Jan 2008 Location: England Posts: 1,707	It's also worth backing up to a PC whilst the disk is out: just use WinUAE to either make an image of the real disk or copy everything to a mounted directory...

02 December 2009, 14:48	#17
Jope - Join Date: Jul 2003 Location: Helsinki / Finland Age: 43 Posts: 9,861	Remember to use clone if using the normal cli copy command.

03 December 2009, 20:24	#18
Iznougoud Quite the odd one Join Date: Sep 2007 Location: Sweden Posts: 180	Given I don't have SCSI in my PC, I'll consider archiving sys: and transfer it via LAN instead...

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)