[rescue] SGI Indy revival

[Steve Hatle]

Indy's are 50 pin SCSI, right?

You might explore using a current gen BlueSCSI device in initiator mode 
to copy the drive to an SD card image.

That should give you a bootable copy of the drive, unless IRIX does 
something really odd with the bootblocks or the drive formatting.

I've not seen anyone do this specifically with SGI disks, but I know it 
works in the Mac world as well as synths and other devices that use SCSI.

Much easier to make copies of the disk image for backup, and you can run 
the Indy off the BlueSCSI for a faster and quieter experience.

Steve

> Mouse via rescue <mailto:rescue at sunhelp.org>
> March 22, 2026 at 9:49 PM
>> I am hoping to show an Indy [...] make sure it is fully backed up
>> first, [...]
>> Here is the process I'm thinking, and I'd like feedback on it.
>> 1) Boot into single user mode.
>> 2) Connect a second disk and EFS format it.
>> 3) Use tar to backup the first disk  piped to tar extract on pointed
>> at the new disk.
>> 3b) tar -cpofv - -C / . | tar -xpof - -C /newdisk
>> I'm a little uncertain if it will then end up trying to recursively
>> stuff as it is written to /newdisk.
> Probably.  Many tars have no way to say "archive this directory but
> don't include this subdirectory thereof".  Mine does.  Sometimes I've
> used it.  Other times I've used other tactics.  For example, in some
> cases I've created a new partition on the old disk that exactly
> overlaps the partition I want to copy, mounted that new partition
> read-only, and copied out of it.  (Of course, this works only if the
> old partition is also read-only, as writing to the filesystem via one
> mount while reading from the other is a recipe for fireworks.)  This
> depends on a whole bunch of things, things which may or may not be true
> of Irix (I don't know it well enough to say).  I do it only on NetBSD,
> on which it's possible to create a partition in the live system without
> creating it on the disk.
>
> I would offer the thought that, for some purposes, it would be better
> for the new disk to be enough bigger than the old that you can make an
> image of the whole (old) drive on the backup drive.  It would be
> something like
>
> 3) Use dd to copy the first disk onto the second:
>
> dd if=/dev/WHATEVER bs=65536 of=/newdisk/olddisk.img
>
> (65536 can be pretty much any multiple of 512 in that general range.
> Too small and the per-syscall penalty becomes a performance killer; too
> large and lack of parallelism becomes a performance killer.  Among my
> tools is one that forks, using memory shared between the processes for
> very fast transfer of data, with one process reading and the other
> writing, to get faster copies in cases like this.)
>
> However, given what you said below, it sounds as though you want the
> new disk to be bootable.  What I've sketched above won't give you that.
> See below.
>
>> 4) turn off, unplug, swap the scsi ID on the new disk to the old one
>> and disconnect the old one.
> If you want to be able to do this with a direct disk image, you need to
> copy to the new disk directly instead of to a file in a filesystem on
> the new disk.  Use the new disk device in the of= clause above for
> that.
>
> Some OSes will be just fine with a filesystem-level copy such as your
> tar would create.  I don't recall enough Irix to know whether it is
> one.  But if your new disk is larger than the old, or (even better) is
> exactly the same size, then a dd-style copy from the old disk to the
> new stands a decent chance of giving you a running system.
>
> If you go with a filesystem-level copy, there may be bootblocks or some
> such that needs copying separately.  I don't think I ever knew Irix
> well enough to know whether it had sny such.
>
> If you don't need the new disk to be bootable per se, but just want to
> be able to restore, then you could put the old disk and the new disk on
> a machine with a boring but well-known OS, like a BSD or Linux, and use
> its filesystem and my modified step 3 above.  Then, if you need to
> restore, just put them both on the same OS again and redo the dd,
> except swapping if= and of=, to write the image back onto the disk.
>
> /~\ The ASCII				  Mouse
> \ / Ribbon Campaign
>   X  Against HTML		mouse at rodents-montreal.org
> / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
>
> _______________________________________________
> rescue list - http://sunhelp.org/mailman/listinfo/rescue_sunhelp.org
> Joshua Boyd via rescue <mailto:rescue at sunhelp.org>
> March 22, 2026 at 9:03 PM
> I am hoping to show an Indy in the retro room at a conference next 
> weekend, but I'd like to make sure it is fully backed up first, which 
> I should have already done anyway.  At the moment surprisingly 
> everything works.
>
> There are two areas of concern.  This machine has licensed software on 
> it, so in addition to backing up the disk, I want to back up the 
> identity of the machine so that if need be it can be restored to a 
> different one or after the NVRAM is someday replaced.  For identity, 
> do I just need to back up the eaddr?
>
> Virtually all of my Irix experience is with Irix 6.4 then Irix 6.5, so 
> I want to be a little sure of things here before diving in.  
> Previously I would have taken the disk out and DD'd it but currently I 
> don't have any other machines with SCSI running, and would prefer not 
> to have to set that up to get this backed up. Here is the process I'm 
> thinking, and I'd like feedback on it.
>
> 1) Boot into single user mode.
>
> 2) Connect a second disk and EFS format it.
>
> 3) Use tar to backup the first disk  piped to tar extract on pointed 
> at the new disk.
>
> 3b) tar -cpofv - -C / . | tar -xpof - -C /newdisk
>
> I'm a little uncertain if it will then end up trying to recursively 
> stuff as it is written to /newdisk. I know that 5.3's doesn't support 
> --exclude.  It does support -X though.
>
> 4) turn off, unplug, swap the scsi ID on the new disk to the old one 
> and disconnect the old one.
>
> 5) success?
>
>
>
>
>
> _______________________________________________
> rescue list - http://sunhelp.org/mailman/listinfo/rescue_sunhelp.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sunhelp.org/pipermail/rescue_sunhelp.org/attachments/20260323/b7b14540/attachment-0001.html>