Unable to format/write to ZuluSCSI v6.4 Emulated Drive -
zthart - 09-02-2024
Hey folks, apologies if this is better suited for the main IRIX thread, but I am a beginner and I feel like the answer here is probably a misunderstanding on my part, so this felt the thread to post in.
I recently got my hands on an Indy (badged as an R5000 machine but it seems to have an R4600 - there's some other pretty clear evidence this thing has had some parts moved around by a previous owner) that I'm trying to get cleaned up and usable. It
did come with a hard drive, and with the drive installed the machine will boot to the multi-user login screen. I do not know any credentials, including the root creds to try and boot into single-user mode, and I suspect the person I bought this from has no clue either. I've got some context clues as to where this machine was last used in any contemporary sense, and I'm betting the person I bought the machine from found it several yard/estate/liquidation sales removed.
I bought a ZuluSCSI v6.4 (Not a "base" ZuluSCSI or RP2040 variant, this seems to be the successor to the SCSI2SD v6 - no DIP switches, configured via a utility) that I would like to get working with the machine, and am using
LOVE to handle installation over my network.
What works:
- LOVE is running on another machine on my network just fine
- I can boot the Indy into the PROM command monitor (had to remove the password jumper)
- With my current ZuluSCSI configuration (which may be suspect), the output of `hinv` shows one SCSI device at scsi(0)disk(1)
- The ZuluSCSI configuration has the drive at SCSI id 1, start sector 0, enough sectors to show as 4GiB (4GiB/512Bytes)
- I've set the ZuluSCSI to SCSI 2, and enabled Parity
- I have no other devices enabled
- I have no hardware SCSI devices connected
- I'm able to launch `fx` to attempt to format the drive to prepare for an installation
- `fx` starts and reports that the volume header is not valid - this makes sense, there's nothing on the drive yet
- If I check the results of the partition table generated by default, I see that it seems to detect the correct number of blocks as configured earlier for the ZuluSCSI
At this point, though, I'm stuck. If I try to format the drive using the `[a]uto` option, I get a bunch of errors as output, notably "fx/auto: Warning: can't write volume header on disk", and "fx/auto: Warning: can't write sgilabel"
I've done as much googling and searching of these forums as I can stand, and have come across a really frustrating array of results. I see things saying "ZuluSCSI is plug and play", as well as "ZuluSCSI is not plug and play", I've quickly realized that a lot of the results on this and other forums are for the "base" version of the ZuluSCSI card, and suggest I need to create files on the SD card to represent my disk images. However, my understanding of the ZuluSCSI v6.4 card is that it is writing data at a lower level to the SD card. Searching for stuff around the older SCSI2SD cards does result in some indication that i need to "partition" the SD card, but I don't see how that helps me here. `fx` is
trying to partition the card and seems to get the fake drive dimensions correct, at least in regards to number of sectors.
I have tried (just for the sake of trying) to partition the SD card on another system using fdisk and creating a new SGI table, matching the sector layout to what ZuluSCSI expects. This does get rid of the volume header warning when starting fx (not when trying to run the auto format) - but again, this makes sense - I put it there myself so of course this time it finds one. However, if I try and start installing software at this point, I get errors about missing swap partitions because fdisk only creates the volhdr and volume partitions. So if I go
back to `fx` to try and stick partitions in there using `[r]epartition`, I yet again get my errors about writing the header/sgilabel.
Whatever, at this point `fx` is not my friend. I take the SD card, go back to fdisk, duplicate the default table that `fx` creates using fdisk, write the table to my SD card, boot the machine back up, try and start installing software, and at this point I already pretty much knew what it was going to say in the back of my mind:
Code:
Write error 21: read only filesystem
I've tried a couple SD cards to try and rule that out (I've also triple checked the silly little lock slider on the full-size SD cards), and the results are consistent on each. Am I missing some obvious step of this process? I'm clearly able to write to the SD card directly on other machines, given that `fdisk` was able to partition the card even though `fx` was not. Could there be a problem with my ZuluSCSI card? Has anyone had any luck installing IRIX onto a ZuluSCSI v6.4 (or even SCSI2SD v6 - they seem to be largely compatible)?
RE: Unable to format/write to ZuluSCSI v6.4 Emulated Drive -
weblacky - 09-02-2024
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.
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. Your PC will not intrinsically be able to read the contents of these virtual Drive files. So expect that you’ll be able to copy, delete, or create these files using your standard PC, but that doesn’t mean that the PC will be able to crack open these image files and read individual files from a specially formatted SGI Drive image! An analogy might be that the formatted SD drive is like a basket and the virtual Drive files are like eggs, you can add or delete or copy as many eggs as you want (up to the SCSI bus address limits), but you may not be able to crack the egg open and look at the contents inside. They may require to be read by the original machine that formatted them for them to make any sense. So do not assume that you can use them for data transfer from your SGI Indy to your PC by simply reading the virtual Drive file on your PC. It won’t work, as a PC has no knowledge of how to read an SGI formatted drive and file system.
3. To ensure that you’re formatting your SD card correctly there is an official formatting utility from the SD card association available from their website for Mac and Windows. But you can certainly try using the standard format in your computer, please use exFAT as the preferred file system.
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.
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. For an emulated drive please re-create or keep a copy of the empty zeroed Drive file between FX partitioning attempts. You’ll likely find it easier to keep copying over an empty drive image to the SD card than to keep reworking old file system, and partitioning attempts if you’re just starting out.
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.
Try these suggestions first and then get back to us.
RE: Unable to format/write to ZuluSCSI v6.4 Emulated Drive -
zthart - 09-02-2024
(09-02-2024, 02:27 PM)weblacky Wrote: 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.
Quote: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.
Quote: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.
Quote: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.
Quote: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.
RE: Unable to format/write to ZuluSCSI v6.4 Emulated Drive -
weblacky - 09-02-2024
Alright then, in the link I posted above one of those users (Callahan :
https://forums.irixnet.org/thread-880-post-6295.html#pid6295) mentions that he himself had a custom config for his v6. Did you happen to try his configuration in your ZuluSCSI?
https://github.com/callahan-44/sgivfo/blob/master/callahansSCSI2SDv6_Indy.xml
Thanks!
RE: Unable to format/write to ZuluSCSI v6.4 Emulated Drive -
zthart - 09-02-2024
(09-02-2024, 06:38 PM)weblacky Wrote: Alright then, in the link I posted above one of those users (Callahan : https://forums.irixnet.org/thread-880-post-6295.html#pid6295) mentions that he himself had a custom config for his v6. Did you happen to try his configuration in your ZuluSCSI?
https://github.com/callahan-44/sgivfo/blob/master/callahansSCSI2SDv6_Indy.xml
Thanks!
I did try this at one point, yes. The config utility for the ZuluSCSI v6 and the older config utility for the SCSI2SD v6 do differ very slightly in the set of fields they give you to configure per device. Notably, the ZuluSCSI v6 util does not allow you to set the Sectors per Track or Heads per Cylinder settings - From what I've noticed by showing the drive details via `fx` these are always 63/255 respectively when using the ZuluSCSI v6 util.
I've tried:
- Copying the config settings available in the new util from the linked config by hand (specifically, the startup delay and latching setting)
- Loading the config in the new util from disk and applying it to the ZuluSCSI (thus setting all the disk properties including size)
- Writing the config for the ZuluSCSI v6 using an older SCSI2SD util
None of these have resulted in anything other than the same write errors. Each time `fx` seems to recognize the configured drive dimensions though.
RE: Unable to format/write to ZuluSCSI v6.4 Emulated Drive -
weblacky - 09-02-2024
Well the only thing I can think of, never seeing the special utility and not knowing all the options, is you didn't happen to enable any Termination inside the ZuluSCSI board?
I assume that you have a normal functioning Indy workstation with its normal passive terminator on its internal ribbon cable. There should be zero reason to enable any form of termination on the ZuluSCSI board, if used internally.
I don't recall you mentioning this in your previous posts so I would just say please remove all forms of termination on the ZuluSCSI, if present.
Double termination at one end will not function correctly as the resistance values will not be correct.
RE: Unable to format/write to ZuluSCSI v6.4 Emulated Drive -
zthart - 09-02-2024
There are termination settings in the utility, but you are correct - I have a terminator at the end of my internal ribbon cable and have had the termination options in the ZuluSCSI utility disabled - I did try enabling them just to see, it did not cause any new errors, but it did not resolve the write errors.
Appreciate all the suggestions, I will keep poking at this, I know the ZuluSCSI creator has been on these forums, but I may also reach out via email to them to see if they've got any thoughts.
RE: Unable to format/write to ZuluSCSI v6.4 Emulated Drive -
Shiunbird - 09-03-2024
Have you tried setting it via zuluscsi.ini?
I have been using one with a HP 712 and a mac, I keep a few image files in a 32GB exfat SD, and it is all good.
I have SCSI ID 3 and 4 for my HP 712 and I can quickly pop the SD into my computer, change the ini file and have the mac image be SCSI ID 3.
The HP 712 has a picky setup, I followed the tips here:
https://blog.pizzabox.computer/posts/hp712-nextstep-part-1/
and just adapted the instructions for the zuluscsi, no problem.
So try hand-massaging the settings as you need and writing to img files. If you keep stuck, let me know and I will pop it out of the 712 and I can share my ini file.
RE: Unable to format/write to ZuluSCSI v6.4 Emulated Drive -
legodude - 09-03-2024
The original poster seems to be using a ZuluSCSI 6.4, which is a descendant of the V6 device. Doesn't that need to be set up using the app?
Zuluscsi.ini is used for the RP2040 device.
OP, is there a reason you are using the 6.4 vs the RP2040 version? I only have experience with the RP2040, but set up has been largely painless across a variety of machines.
Also, I forgot to link this:
https://blog.pizzabox.computer/posts/getting-an-indy-desktop/
RE: Unable to format/write to ZuluSCSI v6.4 Emulated Drive -
weblacky - 09-03-2024
He is using the app.