Mounting ULTRIX CDROMs on Linux

Maciej W. Rozycki macro at
Mon Jul 26 08:34:44 CDT 2021

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.


More information about the cctech mailing list