A yak shave with SGI's EFS
blog.pizzabox.computerGood to see some folks using my 'irixboot' utility in the wild. Looks like it worked!
Also, the whole process by which the Development CD image is extracted could have been easily handled by irixboot and you can use irixboot as a 'dist' install source within the already-installed OS.
It's always great randomly coming across something you wrote in the past, isn't it? Even if it's only a small blog post.
A couple of years ago I got Octane2 and went through similar ordeal (new OS and a bunch of other fun things). SGIs and IRIX are a lot of fun, especially for us that saw those only at workplace or in adverts 'back in the day' (they were a highway robbery back then).
There's one advice from a friend here. If you ever want to use Octane2 on your desktop, let me warn you that it sounds like a jet engine. Not practical at all. Now I know why we kept only O2s on desktops and Octanes were in 'server room' when we did work on them.
> SGIs and IRIX are a lot of fun, especially for us that saw those only at workplace or in adverts 'back in the day'
Back when I was in high school SGI brought their truck[1] full of all their toys to our school for the students to tour. That was a good day. I'll never forget the refrigerator-sized Onyx2 running a 3D flight simulator across three displays.
Pretty much weighs as much as a jet engine, too.
j/k, of course, but it's clearly the heaviest desktop system I've ever seen.
Definitely heavy as a neutron star! TBH, the coolest looking one (to me at least) is/was Indigo 2. Both green and purple one! They ARE more manageable.
As an indigo^2 user: holy shit they were trinitron heavy, too. But the internals of that case were [stunningly beautiful](http://www.futuretech.blinkenlights.nl/i2/i2open.jpg).
All SGI hardware was beautiful inside (pun not intended). Source: was SGI employee for some years.
I have a late-model Indigo2. They're definitely a lot heavier than they look. The later models also suffer from being a bit of a "bridge" machine. Newer CPU and graphics paired with older SCSI, Memory, and Networking.
On the bright side, the Octane2 is one of the few SGI machines new enough to support graphics hardware with DVI ports.
It does support it, but the DCD card has always been expensive/rare. Also requires V10/V12 graphics, which are almost as expensive/rare.
Every Fuel has standard DVI, although Fuels have other drawbacks
I still had that 13w3 to something (might've even been a VGA), even though graphics was maxed out.
Very fun read. There is something really enjoyable about stories of people solving the problem at hand in the most straightforward way possible, even when that means digging into all kinds of low-level details that are usually abstracted away for us.
I had a SGI Indy as my desktop machine in the mid-90s. It was a really awesome system at the time and I still miss it. A couple of random things that I remember:
- The 'lp' account (for the printing system) was not protected by a password on IRIX installs for the longest time. You could telnet in and exploit df(1) [1] and you'd have root. I obtained shells on a number of SGIs around the 'net in this manner back in the day. Good times!
- The author mentioned not being able to run EZSetup over an X11 session. As I recall, many of the graphical system utilities SGI's proprietary framework, which used some proprietary extensions that would not render over vanilla X11. The only way you could run them was from another SGI (using X11 forwarding) or from the local console. I'll bet this is why EZSetup never ran for you.
So much fun. I'm alllllmost tempted to go looking for an Indy on eBay. :)
Not too bad. I was expecting the first shaving step to be about the OS media requiring 520 byte sectors and thus needing a "fancier" CD writer/reader. Maybe that was Sun, not SGI?
I think the whole 512 byte sector CD-ROM thing was common to all the 90's-era "Real UNIX" machines. They generally all wanted to treat CDs like a hard drive, for booting purposes. (PCs, on the other hand, did a different weird hack where they'd embed a floppy image at the state of the CD and the BIOS knew how to handle that.)
AFAIK, the "El Torito" standard, so named for the restaurant where ppl. from IBM & Phoenix BIOS hashed out how to do it...
Yeah, you're right, they wanted 512 instead of 2048 bytes per sector to use the CD as a HD. But I think that at least one of the Unix vendors shipped the install media as 520 byte sectors, with 512 bytes of data and 8 bytes of checksum. In order to duplicate the discs, you needed to own a writer that was fancier than average (i.e. a SCSI unit, not an IDE one).
I keep a DEC RRD-40 drive (with its weird pre-caddy disc holder thing) around for the purpose of booting old DECstations. Not sure if it used 520B sectors though. I think I have the manual .. somewhere.
You might be thinking of OS/400 aka IBM i, which indeed uses 520 byte sectors. Sun used 512.
Yeah, I know about OS/400 using the extra bytes on hard drives for the pointer tags (not a checksum), but what I had in mind were data CDs, whose canonical sector size was 2048.
I'm pretty sure it was apple who used 520 byte sectors, first on floppies, but also on Earl hard drives too
While interesting, a yak shave is where you go off on a long excursion to solve a problem that helps you solve the real problem. This, on the other hand, is just having a hobby. Calling it yak shaving doesn't seem appropriate.
The long excursion might be seen as implementing all that code to do EFS-to-TAR. (Rather than figure out how to compile a Linux kernel module, or run an old version of Linux on something.)
If I was trying to do this project, I'd just do what it took to get an EFS-supporting OS up and running, expose via NFS, and be done with it.
You must be fun at parties.