[zthart]

There are a lot of things going on here and I’ll only comment on a few:

Make sure you’ve read through this first: https://forums.irixnet.org/thread-880.html

Then….

1. Make sure you’re running the latest ZuluSCSI firmware from GitHub.com.

I have come across that thread in trying to resolve my issue - I don't know that the OP there is experiencing the same nature of issue I am. Their solution seems to have come down to one of: update their SCSI2SD firmware, pick a better SD card, or use a SCSI terminator on their external SCSI port.

I don't currently have a terminator for the external port. I've bought one online a few weeks ago and it's in the mail somewhere, perhaps that's begging for issues, but as mentioned using the spinning drive I got with the machine, everything works well enough without the external terminator to get to the multi-user prompt. If all that's needed to fix my problem is the terminator then that'll certainly be an easy fix, but it's odd that it manifested itself for the user in that other thread as SCSI bus errors after formatting their drive, whereas I'm getting disk operation errors just attempting to format it.

I am currently running the latest firmware from the ZuluSCSI v6 firmware repo on github - I will point out that this is distinct and separate from the "base" ZuluSCSI firmware at the separate ZuluSCSI/ZuluSCSI-firmware repo. The SD card I'm using is one I bought from the maker of the ZuluSCSI board at the time I bought the board. One hopes they are sending compatible SD cards out with their own product.

2. Stop trying to use the bare SD card as your virtual drive, all ZuluSCSI should be able to be used in raw SD mode or in file mode. It’s much more normal to properly format your SD card in your PC and then create image files for each of the virtual SCSI drives you want. For example, if you wanted a 4 GB virtual SCSI drive on ID1 you need to create a 4 GB file on the SD card for it to read, it’s a bad idea to treat the raw SD card as the actual drive the Indy will see. So the file would be named hd1.img on otherwise normally formatted SD card that your Mac or PC can read. To be extremely clear on this the SD card is formatted exFAT, it will contain one or more image files that you need to create.

I did come across instructions formatting the card as exFAT/FAT32 and creating image files to be exposed to the system. I tried this to no avail. From what I gather, the ZuluSCSI v6.4 is a newer card that is meant to behave much more like the SCSI2SD v6, and appears to behave differently to the ZuluSCSI v1.2 or ZuluSCSI RP2040. The firmware repo for the v6 variant does not indicate in it's README any of the details about creating blank images, whereas the firmware repo for the ZuluSCSI v1.2/RP2040 does include all of the details about creating images on an exFAT drive. Trying this again now as a sanity check, I've:

1. Formatted the entire SD card as exFAT on a modern host using the SD Association's formatter tool, deselecting "Quick format" as mentioned in that thread
2. Created a blank image file `hd1.img` via `dd if=/dev/zero of=<path-to-sd>/hd1.img bs=512 count=8388608` (clearly I am able to write data to the card)
3. Inserted the card back into the ZuluSCSI v6, re-configured with the same settings from the util
4. Re-insert the ZuluSCSI into my machine, booted into the command monitor. `hinv` again shows me just the one scsi device I'm expecting
5. Running `fx` again warns about the invalid volume header, which at this point is expected, the img file is a bunch of zeroes
6. ignoring the auto mode - (this was included in the guide for LOVE, which is why I mentioned it), if I just go in to the label util and try and sync the default partitions to the device, or repartition the drive, I get the same errors. "Can't write volume header on disk", and "Can't write sgilabel". No progress.

Frankly it seems that regardless of configuration, I cannot get fx to write any data to the ZuluSCSI, even though it appears to recognize the emulated drive and it's dimensions.

4. if you’re current raw emulation is showing up as ID1 then why would you set it for ID2? File name normally overrules the manual setting.

Apologies, this may have been unclear in my first post - I've configured the card to work in SCSI2 mode, with a device at SCSI ID 1.

5. Don’t ever use the AUTO option in FX. It doesn’t do what you think it does and it definitely won’t work on an emulated drive. The AUTO option runs the low level SCSI format on a drive before partition. That’s not something you ever want to do normally. Please just use the create disk label command and create a root drive.

Mentioned this a bit previously, I was following the guide linked in the LOVE post on how to get things started which recommends using the auto option. Skipping anything to do with auto and just ensuring that `fx` has created a valid set of partitions, I've done this (both using an exFAT formatted card with a .img file named correctly and with a card manually partitioned using fdisk):

• Run `fx`, choose "label" > "create" > "all" > "sync" (get aforementioned errors at this step)
  
• Run `fx`, choose "repartition" > "rootdrive" > xfs > yes (get aforementioned errors at this step)
  

If at this point I try to exit fx, I get a prompt noting there are unwritten changes. If I say yes to write these changes I get the same set of errors before the program terminates and I'm back at the maintenance screen for the Indy.

6. Ensure that you can read and write to your SD card and that you have not accidentally engaged the lock tab on it as the adapter will respect the lock tab. Also the link given above talks about proper SD card classes and speeds. Please make sure that you’re adhering to that advice when choosing an SD card.

As mentioned in my post, I've checked several times over that I haven't accidentally engaged the lock tab. The SD card was purchased at the same time through the creator for the ZuluSCSI as an add on to the order. It's a SanDisk Class 10/UHS 1, which based on the thread seems like it should work just fine. Unless the lock tab is being slid into the locked position by the SD card slot on the ZuluSCSI and then perfectly moved back to the unlocked position when the card is removed, there shouldn't be any lock tab related issues.