RaSCSI internal setup having boot image corruption on power off

[caver01]

My setup: Mac SE/30, 8mb. RaSCSI setup internally using RPi Zero W, only physical device on SCSI cable. Powered using molex 5v to USB connected to RaSCSI board.

I am curious if others are running into this problem:
Using the November release image on a 16gb SD card, I am successfully booting from the System 7.5.3 drive image. I have also setup a 2-gig drive, initialized and formatted with FWB Hard Disk Toolkit, or Lido—I have used them both.

So, after configuring the system the way I like by disabling printer extensions, or pulling out CDEVs for Powerbook that don’t apply to the SE, etc. I shutdown for the night. Because the RaSCSI is internal, it is powered from the mac itself. I shut of with the power switch on the back of the mac, which of course, turns off the Pi.

On three different occasions, my boot drive is corrupted when I turn the computer back on. The mack goes through the memory test, Flashing ? disk icon becomes a happy mac, but only for a split second before the mac resets and starts over. This repeats forever.

I can attach a fresh boot drive and re-initiialize/reformat the one causing the looping restarts. Rebuilding the disk from scratch makes it work again.

SO, the Pi SD card is not getting corrupted but the boot image definitely is when I power off the mac.Is anyone else seeing this? Am I supposed to hit the web interface and shutdown the pi before I power off the mac?

 

[cheesestraws]

Am I supposed to hit the web interface and shutdown the pi before I power off the mac?

I believe you need to, yes.

 

[MacKilRoy]

I believe you need to, yes.

Oh wow! That’s interesting. I’ve looked into RaSCSI but that requirement seems really strange for a user device (although I can see it as needed because of corruption issues).

I wonder if somehow it would be possible to build a circuit that had capacitors on it, and when it detected a power off, it properly powered off the Pi.

Otherwise, you must log into the Pi using another machine to power off the Pi, then power off the computer quickly (to avoid the drive being disconnected from the Mac and causing more corruption issues)? To me that’s a deal breaker on that device.

 

[dochilli]

Perhaps it may be better to use a BlueSCSI?

 

[caver01]

Getting a BlueSCSI in the mean time. The odd part to me is the longstanding risk of SD card corruption without proper pi shutdown is NOT what I am observing. If it were that well-documented issue, I would have a non-bootable Pi. That is not the case here. It is merely corrupting the drive image that is attached.

 

[caver01]

Another observation—even though the Mac cannot boot from the image once this happens, it CAN still mount that image, transfer files from it and so on. It just doesn’t boot from it anymore.

 

[caver01]

To me that’s a deal breaker on that device.

To be fair, used as an external drive, you would be running your own power cable to it, so maybe people are not seeing this happen in those situations—mac turns off but the RaSCSI is still on.

 

[cheesestraws]

It is merely corrupting the drive image that is attached.

I've had a situation before where the last few writes before the machine powers down being lost makes the disc unbootable. What happens if you re-bless the system folder on the drive?

 

[caver01]

What happens if you re-bless the system folder on the drive?

I wondered that myself. Tonight, I did an experiment. I detached my 2gig that will no longer boot, attached the RaSCSI 7.5.3 boot image. Let it boot up. Then, re-attached the 2gig and the bootstrap drive. Ran Lido from the bootstrap and did an UPDATE of the disk driver. Shutdown, then detached everything but the 2gig. . . RESTART and bam, booted right up.

This has me wondering if the powerdown is simply corrupting the disk driver.

I need to do more tests, but it would be nice if someone else could repeat my findings. Two things invalidate any conclusions I can draw so far:
1. I also detached the Daynaport. I have had that device attached both times the boot drive was corrupted. I am not running the network (yet) but it is a factor, and when I was just able to make my corrupted drive work again, I realized I also detached the daynaport. So, that device could be a factor for all I know.
2. Before I updated the driver again on the 2gig drive just now, I did go into the system folder and double-clicked the System file to see if it was corrupted. It opened up fine, so I cannot say for sure, but I thought I read doing this can “blass” that system folder. Maybe I am wrong. Anyway, if true, maybe it was blessing the folder that did the trick.

More tests needed of course, to eliminate extenuating circumstances. It would be nice to know if any developers have seen this problem and understand the root-cause.

 

[caver01]

I did a test last night. First, I was easily able to “corrupt” two system 7.5.3 boot disk images by turning off the power while the images were attached. One was the boot drive, another was simply attached. This happens at the “RESTART” screen, to be clear. I am not arbitrarily hitting the power switch while looking at a booted desktop.

The test basically requires that I setup ANOTHER image that is clean, boot from that, attach the broken image and mount using a SCSI utility.

Testing whether double-clicking the System file is enough to fix the image and make it boot again.

RESULTS:
On one image, I double clicked the System file after mounting it and the file opens up revealing items inside etc. Closed everything down, Shutdown, detached all drives, attached this one. RESTART and it boots. So, in this case, touching the system was enough to bless that drive and make it boot again.

The second image was not as easy. For this one, double-clicking System resulted in an error ”Cannot Open file”. This was concerning, so I tried step 2 which was to Update the disk driver using Lido. After a restart like above, this drive was still not bootable. Re-transferring System Folder may have been the next step to try, but I was pretty surprised to see two variations of this issue—one was easily recoverable, the other more sinister. Both were mountable, but with one containing an unopenable System file I am concerned about data loss.

I don’t know if this testing is useful for anyone. It does make me concerned about using RaSCSI internally. Given my MacSE/30 is otherwise working great, I have no reason to suspect my situation is unique, but my system did have hardware issues at one point (as most of us running SE/30s can probably attest). Mine had video issues solved by replacing UE8 chip, reseating the ROM SIMM. I also had a broken D31 data bus line from the SCSI chip—so it is possible there is something happening at power-off on my mac that is unique, but I can’t suggest what that might be. I‘d feel better about my tests if another RaSCSI user could produce similar results. Am I on an island here with a unique situation? Is my RaSCSIS acting strangely? Is my Mac still broken?

 

[caver01]

I've had a situation before where the last few writes before the machine powers down being lost makes the disc unbootable. What happens if you re-bless the system folder on the drive?

Had another thought on this, @cheesestraws. When an SE/30 shuts down, it actually doesn’t do a soft power down. It goes to the black-background “RESTART” dialog with power still keeping the HDD etc. alive. I would expect any pending writes to be handled by then, no?

 

[nottomhanks]

I've had the BlueSCSI go AWOL after restarting with the SE/30 and the Portable. No explanation whatsoever.

 

[caver01]

I am starting to think I still have a hardware issue with the SE30 I have been restoring. I know I took voltage measurements before, but this system has been evolving over the past year as I have worked on different parts.

SO, I setup BlueSCSI. It worked fine, but now at shutdown I am getting a Bus Error instead of the black background RESTART screen. I also tried putting my RaSCSI on a different Pi and used the external cabling connector. This did not work at all—does not boot. It recognizes the drive, I get a happy mac, but then it goes back to the gray background and restarts (not back to blank with chime). This is how it has behaved when I corrupt an image.

SO, my external SCSI is not working, and when I put it back on the 50-pin, the same RaSCSI config boots Ok. I decided to start checking for resistance on the data lines between the SCSI chip and the 50-pin header, as that was something I had not verified and something TechKnight ran into a while back. Anyway it all checks out. Then I thought maybe I need to look at term power again. I took voltage reading on the 50-pin and got 4.6v, but the external was only like 1.2! Correct me if I am wrong, but this should be 5v on both, right?

I am surprised these are so different, to begin with, but it does explain why external was not working at all, while internal is maybe just barely working with low term power? I would invite comments for things to check on the logic board, but I also just ordered a recap kit for the analog board and the PSU, which was overdue anyway.

 

[landoGriffin]

You might be running into this issue: https://github.com/akuker/RASCSI/issues/335

RaSCSI might not write the emulated drive contents to the SD card until the RaSCSI process is shut down.

 

[caver01]

Thanks for the update. I posted some comments on that issue just now. Write cacheing is almost certainly what is going on here. i also just finished recapping my analog board and PSU, so that will add more confidence in the results.