The below from nekochan is helpful, but WRONG! Corrections follow. file order is: sa mr descriptor .IDB file the rest of the files are in the reverse order of the AWK command listed in the below instructions! do NOT use a PC to write these w/dd unless you use the "swab" option. do NOT use distcp to write these from IRIX (at least IRIX 6.5, dunno about others) as it WILL add the header to the descriptor, making it unusable for installation on different OS versions. From nekochan.net: ------------------------------ Let's assume you read back the IRIX 3.3.2 "EOE1" QIC150 tape on IRIX 5.3. You have: Code: total 50912 -rw-r--r-- 1 janjaap users 16384 2009-10-29 10:11 eoe1 -rw-r--r-- 1 janjaap users 196608 2009-10-29 10:11 eoe1.idb -rw-r--r-- 1 janjaap users 2621440 2009-10-29 10:11 eoe1.man -rw-r--r-- 1 janjaap users 32768000 2009-10-29 10:11 eoe1.sw -rw-r--r-- 1 janjaap users 16384 2009-10-29 10:11 mr -rw-r--r-- 1 janjaap users 16515072 2009-10-29 10:11 sa The file of interest is the product descriptor file, the one without extension. This is the one 'mangled' when copied in by distcp. Code: hexdump -C eoe1 00000000 70 64 30 30 31 56 35 33 30 50 30 30 00 07 c4 00 |pd001V530P00....| 00000010 01 07 c3 00 06 00 04 65 6f 65 31 00 2b 34 44 31 |.......eoe1.+4D1| 00000020 2d 33 2e 33 20 45 78 65 63 75 74 69 6f 6e 20 4f |-3.3 Execution O| 00000030 6e 6c 79 20 45 6e 76 69 72 6f 6e 6d 65 6e 74 20 |nly Environment | 00000040 28 70 61 72 74 20 31 29 00 00 26 67 04 ae 00 2b |(part 1)..&g...+| 00000050 34 44 31 2d 33 2e 33 20 45 78 65 63 75 74 69 6f |4D1-3.3 Executio| 00000060 6e 20 4f 6e 6c 79 20 45 6e 76 69 72 6f 6e 6d 65 |n Only Environme| 00000070 6e 74 20 28 70 61 72 74 20 31 29 00 02 08 00 00 |nt (part 1).....| ... Look back to my previous post in this thread and you will recognize the 'pd001V530P00' identifier identifying this as an IRIX 5.3 software distribution, even though it is a 3.3 dist and now the IRIX 3.3 installer won't know how to handle it anymore. If this were e.g. an IRIX 4.0.5 dist, you would have to edit the product descriptor. IRIX 3.3 doesn't have this prepended at all, though, so we have to cut it off. Maybe you have a hex editor which can do it, otherwise 'dd' can do this for you. So: Code: mv eoe1 eoe1.orig dd if=eoe1.orig of=eoe1 bs=13 skip=1 Code: hexdump -C eoe1 00000000 07 c4 00 01 07 c3 00 06 00 04 65 6f 65 31 00 2b |..........eoe1.+| 00000010 34 44 31 2d 33 2e 33 20 45 78 65 63 75 74 69 6f |4D1-3.3 Executio| 00000020 6e 20 4f 6e 6c 79 20 45 6e 76 69 72 6f 6e 6d 65 |n Only Environme| 00000030 6e 74 20 28 70 61 72 74 20 31 29 00 00 26 67 04 |nt (part 1)..&g.| 00000040 ae 00 2b 34 44 31 2d 33 2e 33 20 45 78 65 63 75 |..+4D1-3.3 Execu| 00000050 74 69 6f 6e 20 4f 6e 6c 79 20 45 6e 76 69 72 6f |tion Only Enviro| 00000060 6e 6d 65 6e 74 20 28 70 61 72 74 20 31 29 00 02 |nment (part 1)..| 00000070 08 00 00 03 6d 61 6e 00 2a 45 78 65 63 75 74 69 |....man.*Executi| ... Tada: now the IRIX 3.3.2 will happily read this dist and install it. Problem solved. If you want to create an IRIX 3.3 distribution tape on IRIX 5.3 rest assured: distcp only mangles tapes when it copies them in, not when it copies them out to tape. Now some fun facts :) Fun fact #1 The sizes of all files in the original listing are multiples of 16K. The files on an IRIX CD aren't. If you create a distribution tape from a CD and read it back, files become multiples of 16K. Even the product descriptor file with the extra 13 bytes is still a multiple of 16K, not 16K + 13. The files are padded with 0x00 to the next multiple of 16K. Fun fact #2 You can actually read back a tape without distcp, using 'dd', e.g. Code: mt reten mt rewind dd if=/dev/nrtape of=file1 bs=16K dd if=/dev/nrtape of=file2 bs=16K dd if=/dev/nrtape of=file3 bs=16K dd if=/dev/nrtape of=file4 bs=16K dd if=/dev/nrtape of=file5 bs=16K ... (at some point 'dd' will complain there is nothing on the tape anymore and return a file of zero length) I use a block size of 16K here: as seen above all files are multiples of 16K and at e.g. 512 bytes block size the tape doesn't stream properly and this is bad for the drive and the tapes. Restoring this to a workable distribution is tedious, but possible: 'file1' is always 'mr'. It is always 16K of zeroes 'file2' is always 'sa'. Unless this tape contains installation tools (a miniroot) this file is also 16K of zeroes. 'file3'' is the product descriptor of the first software distribution. Use hex editor to derive it's name 'file4' is the IDB file. The rest are the distribution files, in the order they are in the IDB file, e.g. Code: cat eoe.idb | awk '{ print $7 }' | sort | uniq eoe1.man.relnotes eoe1.man.unix eoe1.sw.unix except all 'man' subsystems are in one file, etc. So, in this case: 'file5' is eoe1.man 'file6' is eoe1.sw Usually there's only one product per tape, if there are more it's rinse and repeat (minus the 'mr' and 'sa') If you restore a tape this way, nothing is mangled regardless of the IRIX version used! You can also use this to recover a corrupted tape, or at least parts of it. Otherwise I wouldn't use this because it is so elaborate. Fun fact #3 You can write distribution tapes with 'dd' too. Write to '/dev/nrtape', otherwise you will keep overwriting file #1 Fun fact #4 If you are a perfectionist (like me), you may have noticed the files in the listing are dated to the time they were restored from tape. But the original date and time are buried in the product descriptor. If you run 'showprods' on it, you can find it back: Code: showprods -f . -u: Distribution: . product eoe1 id "4D1-3.3 Execution Only Environment (part 1)" # product format 6, created Sat Jun 2 02:13:34 1990 image man # (eoe1.man) id "Execution Only Environment 1 documentation" version 1005000065 order 15 # format 2 ... Therefore we can date these files: Code: total 50912 -r--r--r-- 1 janjaap user 16384 Jun 2 1990 eoe1 -r--r--r-- 1 janjaap user 196608 Jun 2 1990 eoe1.idb -r--r--r-- 1 janjaap user 2621440 Jun 2 1990 eoe1.man -r--r--r-- 1 janjaap user 32768000 Jun 2 1990 eoe1.sw -r--r--r-- 1 janjaap user 16384 Jun 2 1990 mr -r--r--r-- 1 janjaap user 16515072 Jun 2 1990 sa Fun fact #5 We've established that IRIX 4.0 - 6.5 prepend a 'pd001VxxxPyy' identifier. But this wasn't the first time they did this. An IRIX 3.3 product descriptor starts with these 8 bytes: Code: 07 c4 00 01 07 c3 00 06 An IRIX 3.2 software distribution file starts with Code: 07 c3 00 06 In other words: IRIX 3.3 updated the distribution format and prepended 0x07c40001 to make this recognizable. I can only assume IRIX 3.3 distcp mangles IRIX 3.2 tapes in a similar way that later releases do :( Fun fact #6 IRIX 3.x software distributions are not compressed, unlike 4.0 and later. I think the last 'inst' program capable of unpacking (reading) IRIX 3.3 software distributions was 5.3. You might be able to unpack it by hand but this is extremely tedious, better fire up an older IRIX system. Fun fact #7 While a recent IRIX cannot unpack an IRIX 3.3 software dist, it can still read the product descriptor (Fun fact #4). But even this capability is lost with the even more ancient IRIX 3.2 format. However, if you prepend the four magic 07 c4 00 01 bytes, even IRIX 6.5 can parse this format again :) Fun fact #8 If you got this far, you have restored a software distribution, but don't have a QIC150 tapedrive (or tapes) then you must netboot. You have to extract the standalone files from the 'sa' file first: Code: mkboottape -l -f sa Filename Size sash.IP4 180896 sash.IP5 194512 sash.IP6 200384 sash.IP7 194512 sash.IP9 194512 sash.R2300 151792 mr 12599296 fx.IP4 289168 fx.IP5 302800 fx.IP6 330736 fx.R2300 260064 ide.IP4 290320 ide.IP5 810096 ide.IP6 500096 Extract the relevant files (-x) and off you go. Which brings us back to the original topic of this thread :) I think this sums up most of my knowledge of ancient IRIX tape archeology and restoration. Let's hope it helps to preserve some of this old material. To anybody who still has some of these old cartridge tapes: they are still readable after nearly 20 years. But I think you'd better image them now because they're not going to last forever.