Re: Mounting ULTRIX CDROMs on Linux
On 2021-07-26 9:34 a.m., Maciej W. Rozycki via cctalk wrote: > On Fri, 21 May 2021, Maciej W. Rozycki wrote: > >> ISTR upstreaming some fixes to Linux UFS support 20+ years ago to address >> this very problem (IIRC OSF/1 or Digital Unix CD-ROMs were also UFS, and I >> had a need to access them under Linux for some reason) and with them in >> place I thought the loop device hack was not needed anymore. >> >> Perhaps my memory tricks me or something has since regressed though, e.g. >> due to changes in the block layer, so I'll try to remember to see what's >> happened here when I get to my Ultrix CDs when I'm in my remote lab next >> time. It's not a feature that's used on a regular basis after all, so any >> regression can be long-lived. > > I remembered right. An old Linux 2.4.26 kernel binary mounts a UFS CD > here using the old IDE hardware driver just fine with no need for block > size translation via the loop device: > > # mount -t ufs -o ro,ufstype=old /dev/hdc /mnt/cdrom > # mount | grep ufs > /dev/hdc on /mnt/cdrom type ufs (ro,ufstype=old) > # uname -a > Linux (none) 2.4.26 #8 SMP Sat Aug 14 21:00:06 CEST 2004 i586 unknown unknown > GNU/Linux > # > > Not anymore with Linux 2.6.18 or anything newer: > > # mount -t ufs -o ro,ufstype=old /dev/hdc /mnt/cdrom > mount: wrong fs type, bad option, bad superblock on /dev/hdc, >or too many mounted file systems > # dmesg | tail -n 1 > UFS: failed to set blocksize > # mount -t ufs -o loop,ro,ufstype=old /dev/hdc /mnt/cdrom > # mount | grep ufs > /dev/hdc on /mnt/cdrom type ufs (ro,loop=/dev/loop0,ufstype=old) > # uname -a > Linux (none) 2.6.18 #9 SMP Sun Nov 26 18:31:10 GMT 2017 i586 unknown unknown > GNU/Linux > # > > So we do have a regression here, sigh. Thanks for the analysis. I would have speculated that the difference was in the SCSI CD-ROM driver for /dev/sr* devices since those are what are used in modern Linux distributions. But your results quite clearly show that's not the case. It also shows just how long ago the change happened. Very interesting.
Re: Mounting ULTRIX CDROMs on Linux
On Fri, 21 May 2021, Maciej W. Rozycki wrote: > ISTR upstreaming some fixes to Linux UFS support 20+ years ago to address > this very problem (IIRC OSF/1 or Digital Unix CD-ROMs were also UFS, and I > had a need to access them under Linux for some reason) and with them in > place I thought the loop device hack was not needed anymore. > > Perhaps my memory tricks me or something has since regressed though, e.g. > due to changes in the block layer, so I'll try to remember to see what's > happened here when I get to my Ultrix CDs when I'm in my remote lab next > time. It's not a feature that's used on a regular basis after all, so any > regression can be long-lived. I remembered right. An old Linux 2.4.26 kernel binary mounts a UFS CD here using the old IDE hardware driver just fine with no need for block size translation via the loop device: # mount -t ufs -o ro,ufstype=old /dev/hdc /mnt/cdrom # mount | grep ufs /dev/hdc on /mnt/cdrom type ufs (ro,ufstype=old) # uname -a Linux (none) 2.4.26 #8 SMP Sat Aug 14 21:00:06 CEST 2004 i586 unknown unknown GNU/Linux # Not anymore with Linux 2.6.18 or anything newer: # mount -t ufs -o ro,ufstype=old /dev/hdc /mnt/cdrom mount: wrong fs type, bad option, bad superblock on /dev/hdc, or too many mounted file systems # dmesg | tail -n 1 UFS: failed to set blocksize # mount -t ufs -o loop,ro,ufstype=old /dev/hdc /mnt/cdrom # mount | grep ufs /dev/hdc on /mnt/cdrom type ufs (ro,loop=/dev/loop0,ufstype=old) # uname -a Linux (none) 2.6.18 #9 SMP Sun Nov 26 18:31:10 GMT 2017 i586 unknown unknown GNU/Linux # So we do have a regression here, sigh. I'll see what I can do about it, but it'll have to wait a bit as I won't have local lab access for a while and I dare not leaving a CD in the drive while I am away. Maciej
Re: Mounting ULTRIX CDROMs on Linux
On 2021-05-20 4:49 p.m., Antonio Carlini via cctalk wrote: > > Great, thanks for that. I would probably have never guessed that I > needed loop. I'm glad it worked. I still find it illogical to loop mount a device, but it works. I never would have figured it out on my own either. I don't remember who taught me that trick so I can't give credit where it is due.
Re: Mounting ULTRIX CDROMs on Linux
On 2021-05-20 5:05 p.m., Jonathan Stone via cctalk wrote: > > What does one have to do (Linux, MacOS, *BSD) to write such an image > to the CD with 512-byte blocks, so it can be read by a DEC boot-ROM? There's nothing special needed to write the disk -- just burn it the way you would any other ISO image. It is the filesystem contained in that disk image that determines block size.
Re: Mounting ULTRIX CDROMs on Linux
On Thu, 20 May 2021, Christian Groessler via cctalk wrote: > IIRC I had burned the Ultrix CD "normally" (means without fiddling with block > size, so not 512), but changed the block size to 512 for booting it. IIRC #2, > burning was done on another drive, not the Plextor. CD-ROM medium format has been standardised and what I guess the 512-byte sector size jumper only does is logical translation of sector addressing to fulfil weird OS requirements. So that will not affect burning (unless you burn on a weird OS, which I guess does not support it anyway). ISTR upstreaming some fixes to Linux UFS support 20+ years ago to address this very problem (IIRC OSF/1 or Digital Unix CD-ROMs were also UFS, and I had a need to access them under Linux for some reason) and with them in place I thought the loop device hack was not needed anymore. Perhaps my memory tricks me or something has since regressed though, e.g. due to changes in the block layer, so I'll try to remember to see what's happened here when I get to my Ultrix CDs when I'm in my remote lab next time. It's not a feature that's used on a regular basis after all, so any regression can be long-lived. Maciej
Re: Mounting ULTRIX CDROMs on Linux
More top-post alert! :-) IIRC I had burned the Ultrix CD "normally" (means without fiddling with block size, so not 512), but changed the block size to 512 for booting it. IIRC #2, burning was done on another drive, not the Plextor. regards, chris On 5/20/21 11:26 PM, Jonathan Stone wrote: [[ apologies for top-post: Y! issue ]] I know that to be bootable on DECstation/VAX/early Alpha, CD-ROMs needs to be jumpered to 512-byte blocks. Like RRD4x. Does the burning CD write need to be jumpered to 512-bytes? Or can one write on a "normal" CD burner, then read on a 512-byte-block CD-ROM ? If the former, I guess I'll have to find an old, 512-byte-block jumperable SCSI CD burner. On Thursday, May 20, 2021, 02:15:39 PM PDT, Christian Groessler via cctalk wrote: On 5/20/21 11:05 PM, Jonathan Stone via cctalk wrote: > MacOS (Mojave) can mount an image read from a 512-byte UFS CD. > > What does one have to do (Linux, MacOS, *BSD) to write such an image to the CD with 512-byte blocks, so it can be read by a DEC boot-ROM? I think that's a property of the CD drive, not the disk itself. I've got a Plextor CD writer which can be jumpered between 2048 and 512 byte blocks. I was able to boot the Ultrix installation CD (MIPS) on a DECServer. regards, chris
Re: Mounting ULTRIX CDROMs on Linux
[[ apologies for top-post: Y! issue ]] I know that to be bootable on DECstation/VAX/early Alpha, CD-ROMs needs to be jumpered to 512-byte blocks. Like RRD4x. Does the burning CD write need to be jumpered to 512-bytes? Or can one write on a "normal" CD burner, then read on a 512-byte-block CD-ROM ? If the former, I guess I'll have to find an old, 512-byte-block jumperable SCSI CD burner. On Thursday, May 20, 2021, 02:15:39 PM PDT, Christian Groessler via cctalk wrote: On 5/20/21 11:05 PM, Jonathan Stone via cctalk wrote: > MacOS (Mojave) can mount an image read from a 512-byte UFS CD. > > What does one have to do (Linux, MacOS, *BSD) to write such an image to the > CD with 512-byte blocks, so it can be read by a DEC boot-ROM? I think that's a property of the CD drive, not the disk itself. I've got a Plextor CD writer which can be jumpered between 2048 and 512 byte blocks. I was able to boot the Ultrix installation CD (MIPS) on a DECServer. regards, chris
Re: Mounting ULTRIX CDROMs on Linux
On 5/20/21 11:05 PM, Jonathan Stone via cctalk wrote: MacOS (Mojave) can mount an image read from a 512-byte UFS CD. What does one have to do (Linux, MacOS, *BSD) to write such an image to the CD with 512-byte blocks, so it can be read by a DEC boot-ROM? I think that's a property of the CD drive, not the disk itself. I've got a Plextor CD writer which can be jumpered between 2048 and 512 byte blocks. I was able to boot the Ultrix installation CD (MIPS) on a DECServer. regards, chris
Re: Mounting ULTRIX CDROMs on Linux
MacOS (Mojave) can mount an image read from a 512-byte UFS CD. What does one have to do (Linux, MacOS, *BSD) to write such an image to the CD with 512-byte blocks, so it can be read by a DEC boot-ROM?
Re: Mounting ULTRIX CDROMs on Linux
On 20/05/2021 21:11, John-Paul Stewart via cctalk wrote: Setting ufstype=sun will indeed work for loopback mounting Ultrix CD images. With physical CDs, the Linux CD-ROM driver expects the filesystem to use 2048 byte blocks but the UFS CDs have 512 byte blocks. So you'll also have to add "loop" to the options: sudo mount -t ufs -o ro,ufstype=sun,loop /dev/sr1 /tmp/mount That will mount the physical CD using a loopback device so you can access the 512 byte per block filesystem. (FWIW, I learned that trick with IRIX EFS CDs, which have the same problem.) We have a winner: $ ls /tmp/mount/decw_book/ bookbrowser d3b0aa70.decw_book d3knaa23.decw_book d3s1aa97.decw_book d5e5aaa8.decw_book dh87zaa1.decw_bookshelf dt59aaa8.decw_book BRM410 d3b0aa71.decw_book d3knaa24.decw_book d3s1aaa1.decw_book d5e5aaa9.decw_book dhqdaa11.decw_book dt59aaa9.decw_book BRV410 d3b0aa72.decw_book d3knaa25.decw_book d3s1aaa2.decw_book d5e5zaa2.decw_bookshelf dhu3aaa3.decw_book dt59zaa1.decw_bookshelf d296aaa1.decw_book d3b0aa73.decw_book d3knaa26.decw_book d3s1aaa3.decw_book d8dlaaa1.decw_book dhu3aaa4.decw_book dt59zaa2.decw_bookshelf d296aaa2.decw_book d3b0aaa1.decw_book d3knaa27.decw_book d3s1aaa4.decw_book d8dlaaa6.decw_book dhu3zaa2.decw_bookshelf dt59zaa3.decw_bookshelf ... Great, thanks for that. I would probably have never guessed that I needed loop. Antonio -- Antonio Carlini anto...@acarlini.com
Re: Mounting ULTRIX CDROMs on Linux
On Thu, May 20, 2021 at 04:11:18PM -0400, John-Paul Stewart via cctalk wrote: > On 2021-05-20 4:01 p.m., Warner Losh via cctalk wrote: > > On Thu, May 20, 2021 at 1:56 PM Antonio Carlini via cctalk < > > cctalk@classiccmp.org> wrote: > > > >> I'm running Linux Mint (an ubuntu derivative) and I want to mount ULTRIX > >> CDROM discs to see what I can see. > >> > >> (I'm eventually going to image these, but I presume that will "just > >> work" with dd or ddrescue). > >> > >> They are supposed to be UFS format (according to the net) and that > >> usually means you have to tell mount exactly which option to use (as not > >> all UFS implementations are compatible). > >> > >> I've tried (all the options I can find) and failed: > >> > >> $ sudo mount -t ufs -o ufstype=44bsd /dev/sr1 /tmp/mount > > > > 44bsd is likely too new. ufstype=old or =sunos or =sun might work. > > Setting ufstype=sun will indeed work for loopback mounting Ultrix CD images. > > With physical CDs, the Linux CD-ROM driver expects the filesystem to use > 2048 byte blocks but the UFS CDs have 512 byte blocks. So you'll also > have to add "loop" to the options: > > sudo mount -t ufs -o ro,ufstype=sun,loop /dev/sr1 /tmp/mount > > That will mount the physical CD using a loopback device so you can > access the 512 byte per block filesystem. (FWIW, I learned that trick > with IRIX EFS CDs, which have the same problem.) Wow! I never expected to learn something new about mounting CDs tonight :-) Thanks! -- Malte Dehling
Re: Mounting ULTRIX CDROMs on Linux
On 2021-05-20 4:01 p.m., Warner Losh via cctalk wrote: > On Thu, May 20, 2021 at 1:56 PM Antonio Carlini via cctalk < > cctalk@classiccmp.org> wrote: > >> I'm running Linux Mint (an ubuntu derivative) and I want to mount ULTRIX >> CDROM discs to see what I can see. >> >> (I'm eventually going to image these, but I presume that will "just >> work" with dd or ddrescue). >> >> They are supposed to be UFS format (according to the net) and that >> usually means you have to tell mount exactly which option to use (as not >> all UFS implementations are compatible). >> >> I've tried (all the options I can find) and failed: >> >> $ sudo mount -t ufs -o ufstype=44bsd /dev/sr1 /tmp/mount > > 44bsd is likely too new. ufstype=old or =sunos or =sun might work. Setting ufstype=sun will indeed work for loopback mounting Ultrix CD images. With physical CDs, the Linux CD-ROM driver expects the filesystem to use 2048 byte blocks but the UFS CDs have 512 byte blocks. So you'll also have to add "loop" to the options: sudo mount -t ufs -o ro,ufstype=sun,loop /dev/sr1 /tmp/mount That will mount the physical CD using a loopback device so you can access the 512 byte per block filesystem. (FWIW, I learned that trick with IRIX EFS CDs, which have the same problem.)
Re: Mounting ULTRIX CDROMs on Linux
On Thu, May 20, 2021 at 02:01:21PM -0600, Warner Losh via cctalk wrote: > On Thu, May 20, 2021 at 1:56 PM Antonio Carlini via cctalk < > cctalk@classiccmp.org> wrote: > > > I'm running Linux Mint (an ubuntu derivative) and I want to mount ULTRIX > > CDROM discs to see what I can see. > > > > (I'm eventually going to image these, but I presume that will "just > > work" with dd or ddrescue). > > > > They are supposed to be UFS format (according to the net) and that > > usually means you have to tell mount exactly which option to use (as not > > all UFS implementations are compatible). > > > > > > I've tried (all the options I can find) and failed: > > > > > > $ sudo mount -t ufs -o ufstype=44bsd /dev/sr1 /tmp/mount > > > > 44bsd is likely too new. ufstype=old or =sunos or =sun might work. I just tried on an Ultrix 4.5 ISO and I was able to mount it with ufstype=old or without a ufstype option. Cheers, Malte -- Malte Dehling
Re: Mounting ULTRIX CDROMs on Linux
Ultrix UFS is 4.2SD plus some big fixes. It's definitely pre-4.3BSD. So 44BSD won't work. I hit fsck errors anytime I mounted Ultrix FFS read-write with (very early NetBSD). You may be better off if you can try with *BSD. OSF1/Digital Unix/Tru64 has a newer FFS, definitely 4.3BSD or newer -- perhaps 4.4-Lite? -- but I've never tried it with Ultrix media. On Thursday, May 20, 2021, 01:00:51 PM PDT, Antonio Carlini via cctech wrote: I'm running Linux Mint (an ubuntu derivative) and I want to mount ULTRIX CDROM discs to see what I can see. (I'm eventually going to image these, but I presume that will "just work" with dd or ddrescue). They are supposed to be UFS format (according to the net) and that usually means you have to tell mount exactly which option to use (as not all UFS implementations are compatible). I've tried (all the options I can find) and failed: $ sudo mount -t ufs -o ufstype=44bsd /dev/sr1 /tmp/mount mount: /tmp/mount: wrong fs type, bad option, bad superblock on /dev/sr1, missing codepage or helper program, or other error. The CDROM would appear to be readable 9and I've tried a few anyway): $ sudo file -s /dev/sr1 /dev/sr1: Unix Fast File system [v1] (little-endian), last mounted on /UPS_MOUNT_TAR_SOURCE, last written at Wed Sep 28 16:27:45 1994, clean flag 30, number of blocks 243648, number of data blocks 233295, number of cylinder groups 38, block size 8192, fragment size 1024, minimum percentage of free blocks 10, rotational delay 0ms, disk rotational speed 60rps, TIME optimization A later Digital Unix CDROM behaves the same way with mount and reports this with file: $ sudo file -s /dev/sr1 /dev/sr1: Unix Fast File system [v1] (little-endian), last mounted on /kits/tmp/gendisk17665/mnt, last written at Wed Nov 20 13:38:02 1996, clean flag 3, number of blocks 151168, number of data blocks 150383, number of cylinder groups 24, block size 8192, fragment size 1024, minimum percentage of free blocks 0, rotational delay 0ms, disk rotational speed 60rps, SPACE optimization I also have a few OSF/1 CDROMs, which I assume are also the same format. Any ideas? I can't be the first person to try to do this ... Antonio -- Antonio Carlini anto...@acarlini.com
Re: Mounting ULTRIX CDROMs on Linux
On Thu, May 20, 2021 at 1:56 PM Antonio Carlini via cctalk < cctalk@classiccmp.org> wrote: > I'm running Linux Mint (an ubuntu derivative) and I want to mount ULTRIX > CDROM discs to see what I can see. > > (I'm eventually going to image these, but I presume that will "just > work" with dd or ddrescue). > > They are supposed to be UFS format (according to the net) and that > usually means you have to tell mount exactly which option to use (as not > all UFS implementations are compatible). > > > I've tried (all the options I can find) and failed: > > > $ sudo mount -t ufs -o ufstype=44bsd /dev/sr1 /tmp/mount > 44bsd is likely too new. ufstype=old or =sunos or =sun might work. Warner > mount: /tmp/mount: wrong fs type, bad option, bad superblock on > /dev/sr1, missing codepage or helper program, or other error. > > > The CDROM would appear to be readable 9and I've tried a few anyway): > > $ sudo file -s /dev/sr1 > /dev/sr1: Unix Fast File system [v1] (little-endian), last mounted on > /UPS_MOUNT_TAR_SOURCE, last written at Wed Sep 28 16:27:45 1994, clean > flag 30, number of blocks 243648, number of data blocks 233295, number > of cylinder groups 38, block size 8192, fragment size 1024, minimum > percentage of free blocks 10, rotational delay 0ms, disk rotational > speed 60rps, TIME optimization > > > A later Digital Unix CDROM behaves the same way with mount and reports > this with file: > > $ sudo file -s /dev/sr1 > /dev/sr1: Unix Fast File system [v1] (little-endian), last mounted on > /kits/tmp/gendisk17665/mnt, last written at Wed Nov 20 13:38:02 1996, > clean flag 3, number of blocks 151168, number of data blocks 150383, > number of cylinder groups 24, block size 8192, fragment size 1024, > minimum percentage of free blocks 0, rotational delay 0ms, disk > rotational speed 60rps, SPACE optimization > > > I also have a few OSF/1 CDROMs, which I assume are also the same format. > > > Any ideas? I can't be the first person to try to do this ... > > > Antonio > > > > -- > Antonio Carlini > anto...@acarlini.com > >
