• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

sharing disk images between ZuluSCSI/BlueSCSI and modern Mac

LaPorta

Well-known member
Two things:

Thanks @bigmessowires for figuring that out, that was something holding me back from getting a BlueSCSI and the like because I was afraid of having to mess with command line stuff.

Second…can some enterprising soul take these hfsutil things and build a GUI for it? :p.
 

joevt

Well-known member
For Old World Macs, the HFS+ partition is wrapped in an HFS wrapper. To deal with these, I boot a Parallels VM into Mac OS X Leopard or Snow Leopard. iPartition 3.1.3 works well with HFS wrappers (allows creating HFS wrappers and resizing).
The old Mac OS X versions are useful for mounting and converting DiskCopy 6 images and HFS partitions and HFS wrappers.

For modern macOS, you can mount HFS disk images and partitions by installing MacFUSE and fusehfs.

DiskWarrior.app in modern macOS does not preserve HFS wrappers.
 

LaPorta

Well-known member
The only issue I learned with MacFuse/FuseHFS is that, sadly, it doesn’t work with REAL disks, only images.
 

cheesestraws

Well-known member
I do try to avoid condescending software.

It may sound silly, but something about the tone of homebrew's documentation, error messages, and especially its insistence that everyone has the ability to upgrade to the newest macos all the time really rubs me up the wrong way.
 

Phipli

Well-known member
It may sound silly, but something about the tone of homebrew's documentation, error messages, and especially its insistence that everyone has the ability to upgrade to the newest macos all the time really rubs me up the wrong way.
Like how Ubuntu decided that nobody should be allowed to use Python 2, and started uninstalling it at every update, even though I had toolsets that I didn't have the skill or time to migrate?

That made me so angry. It was so arrogant and... Un-Linux. Linux is meant to be choice and freedom, even if to make poor decisions.
 

CC_333

Well-known member
macports is a good alternative that is less opinionated and condescending than homebrew, generally
It may sound silly, but something about the tone of homebrew's documentation, error messages, and especially its insistence that everyone has the ability to upgrade to the newest macos all the time really rubs me up the wrong way.
Yes, I've noticed that an increasing amount of software in general is being very presumptuous with regard to a user's desire or capability to upgrade all the time or, for another example, whether they actually want to buy a subscription and activate online.

Like how Ubuntu decided that nobody should be allowed to use Python 2, and started uninstalling it at every update, even though I had toolsets that I didn't have the skill or time to migrate?

That made me so angry. It was so arrogant and... Un-Linux. Linux is meant to be choice and freedom, even if to make poor decisions.
Un-Linux indeed! I gave up on Ubuntu years ago because all those little niggling things just kept piling up. On their own, they're not too bad and are usually manageable, but there were so many of them, and it would be so nontrivial to undo it, that once done, it ceases to be Ubuntu, so why not just run something else that's free of all the annoyances instead? I initially went with Ubuntu because it was relatively open and contained a well rounded assortment of packages that basically make it ready to go out of the ISO. I also liked it because its parent distro, Debian Linux, is very open and quite versatile (plus a number of Debian packages could be installed onto Ubuntu with some effort).

Since they started mucking about with the UI and making it so minimalist that it's almost unusable for anything but the most basic things, I gave up on it and just went with Debian proper, since, as already mentioned, it's still (and will hopefully remain) very open.

My second favorite is Fedora, since it was one of the first distros I got into (waaay back in 2004 when it was known as Fedora Core), but I don't always like to be on the bleeding edge because you can never tell what might break. Plus I kind of like the way apt and dpkg works versus, what is it, yum and rpm?

Oh, and talk about arrogant: Micro$soft has been doing this with Windows 10 for YEARS now (installing by force updates — that users can't opt out of without a bunch of rigamarole — which undo customizations and optimizations and reset many personalization settings to their defaults; perhaps some of this has been fixed more recently, but as I've somehow managed to not use 10 virtually never, I wouldn't know).

I do try to avoid condescending software.
As do I.

c
 

LaPorta

Well-known member
I know I’m alone here in a community of Uber computer enthusiasts, but like CC said, there’s an unfriendly attitude in general. Times were past 20 years ago, every new Mac OS X software that came out, be it utilities, arcade emulators, you name it, all had nice GUI interfaces built for them. I need that sort of thing because I don’t have time to learn arcane command line jargon and such…I’ve got a more than full time job and a family. These days, every Utility is a command line tool that no one can be bothered to make user friendly. I don’t know why that is.
 

joshc

Well-known member
Times were past 20 years ago, every new Mac OS X software that came out, be it utilities, arcade emulators, you name it, all had nice GUI interfaces built for them. I need that sort of thing because I don’t have time to learn arcane command line jargon and such…I’ve got a more than full time job and a family. These days, every Utility is a command line tool that no one can be bothered to make user friendly. I don’t know why that is.
Have you got some specific examples of things that had nice GUIs that don't anymore?

For a lot of tasks, the command line is no slower or more complicated than using a GUI. In a lot of ways, a command line saves time, and a lot of tasks can be scripted.
 

LaPorta

Well-known member
That is if you have time to learn commands or make scripts. Some examples are the hfsutil that everyone talks about, as well as dd. It’s not that they had a GUI to begin with, it’s that they likely never will. I suppose I bemoan the fact that Disk Utility did much of what the command line still does before it was stripped out.

Not necessarily the same thing, another gripe I’ve got is people not building their projects. In the past, everything could be downloaded in a nice zip or StuffIt archive, complete with application, instructions, read me, etc. Today it’s more “just compile the source.” For me it’s a headache because some library is always missing or I don’t do it correctly somehow…why can’t they just compile and post the application for download thenselves?

I know I’m some sort of “grew up on Mac OS” old fart :p
 

joshc

Well-known member
dd is an interesting example because it's probably one of the easier commands to use. For most use cases, you would be doing

Code:
dd if=/dev/INPUT-DEVICE-HERE of=/dev/OUTPUT-DEVICE-HERE

and you get the devices to pass in from
Code:
diskutil list
in macOS.

Command line programs tend to be better documented than GUI wrappers, and much more feature-full and flexible.

But you seem to have already made your mind up - so I guess it's just something I won't ever understand.
 

LaPorta

Well-known member
dd is an interesting example because it's probably one of the easier commands to use. For most use cases, you would be doing

Code:
dd if=/dev/INPUT-DEVICE-HERE of=/dev/OUTPUT-DEVICE-HERE

and you get the devices to pass in from
Code:
diskutil list
in macOS.

Command line programs tend to be better documented than GUI wrappers, and much more feature-full and flexible.

But you seem to have already made your mind up - so I guess it's just something I won't ever understand.

I can definitely give it a go and see what I can do, I appreciate your input @joshc, not to mention your willingness to help!

I suppose what it is is that is what I like about our old Macs in general: complete lack of any text based anything. I know I’m in the minority. What would you suggest, however, as your go-to reference to use dd?
 

JT737

Well-known member
I've seen hints that it's possible to configure Zulu SCSI in passthrough mode, where it essentially operates like SCSI2SD and uses the whole SD card at a raw level, which might be one solution. But I'm not sure how to enable that or how to configure the SCSI ID in that configuration.
This. My default way to install an OS on a SCSI2SD drive was first to format the card using an application such as Lido 7, and then simply treat the drive like a regular hard drive and install an OS from either a CD-ROM or the install files from another hard drive (all of this is done using classic hardware).

However, I have yet to have any luck doing this with the Zulu SCSI/Blue SCSI.
 

LaPorta

Well-known member
I’m fairly unique. I’ve done that sort of thing on my SCSI2SD macs that have neither Ethernet nor CDs. I format the SD card for use in the SCSI2SD with a floppy startup disk, then pop it out and put the card in an SD reader on a 10.4/OS 9 G4 or something and then just drag and drop everything, including the System.
 

bigmessowires

Well-known member
It's interesting how much difference it makes for a SCSI emulator to use a file on the SD card instead of the whole SD card. SCSI2SD was basically impossible to use unless you already had a working boot disk or a second vintage Mac you could use to format the SCSI2SD and install a System, or were comfortable mucking about with low-level tools and raw devices. With file-based emulation you can just download a ready-made device image and copy it to the SD card, just like you'd copy your family vacation photos. It's easy. Configuration is done through a simple text file, so there's no need for a separate configuration program like SCSI2SD-util either. It's just tons better, all around. I proposed file-based emulation to Michael McMaster around 10 years ago when he first introduced SCSI2SD, but I guess I wasn't very persuasive about its merits.
 

JT737

Well-known member
@bigmessowires -It seems easy, I just haven't had much luck. I guess it's kind of funny that to me, the older SCSI2SD was easier for me to work with....but then again, I have all of the vintage equipment to do it! What can I say, I like doing things the hard way.....at least, that's the way my life seems to always work :cool:

I actually haven't played with my Zulu SCSI or Bluepill SCSI for a bit, but I will try it again. Maybe this time I'll actually get it to work.

I mean, I'm pretty sure I'm doing it right.....download an image, install it on a (HFS formatted) sd card, then plop the sd card into the Zulu drive. It should just work.......
 

bigmessowires

Well-known member
You're trying to do SCSI2SD-style emulation where the whole SD card is the device, or file-based emulation where a file is the device? Unless you have a specific use case in mind that requires SCSI2SD-style emulation, I think file-based emulation is a whole lot easier.

1. Format the SD card as exFAT (with Master Boot Record partition, if prompted)
2. Download a ready-made device image like this one: https://archive.org/details/macpack-20211212
3. Copy the device image to the SD card (you may need to rename the file something like HD5.hda)
4. Insert the SD card in the Zulu SCSI and boot your computer
5. If it doesn't work, remove the SD card and open the file zululog.txt to see what went wrong
 

joshc

Well-known member
However, I have yet to have any luck doing this with the Zulu SCSI/Blue SCSI.
Why? It's not really any different, once you have a file on the SD card with a driver. Tools such as Disk Jockey can create one for you, the Mac will recognise it as a hard drive and then you can format it on the Mac as normal and then install whatever you want on it via whatever method you want.

 

Phipli

Well-known member
I guess it's kind of funny that to me, the older SCSI2SD was easier for me to work with....but then again, I have all of the vintage equipment to do it!
I'm in the same boat. I like the SCSI2SD setup. There were lots of issues with older BlueSCSIs, so I never got one. I anticipate that things have got better, but given I have a good retro setup, just setting a SCSI2SD as a disk and then doing all the formatting and installation on a retro machine suits me just fine. It's the same as we've always done. It's just a hard disk.
IMG_20210310_122118.jpg
Why? It's not really any different, once you have a file on the SD card with a driver. Tools such as Disk Jockey can create one for you, the Mac will recognise it as a hard drive and then you can format it on the Mac as normal and then install whatever you want on it via whatever method you want.
I would use one if I had one, and have helped many people set them up, but I would argue that the process you just described is... quite a bit more complex than setting up a SCSI2SD.
 

robin-fo

Well-known member
I guess it's kind of funny that to me, the older SCSI2SD was easier for me to work with....but then again, I have all of the vintage equipment to do it!
I agree.. The approach used with BlueSCSI and ZuluSCSI is ideal to set up a new machine, but to use it permanently inside the Mac I‘d rather have a single SCSI ID (set by jumpers), a single disk (whole SD card, no wrapper filesystem) and standard Molex connector for power (leave termination power for others to use). In other words, a drop-in SSD replacement for a single SCSI HD, what none of the current solutions exactly are.
 
Top