Re: /etc/fstab (swap and cdrom)

[Marcus Watts <mdw_(_at_)_umich_(_dot_)_edu>]

Andre Nathan <andre_(_at_)_v2r_(_dot_)_com_(_dot_)_br> and others wrote:
...
> > > /dev/cd0a  /cdrom  cd9660  ro,noauto  0  0
> > > mount /cdrom says: unknown special file or filesystem
> > >
> > > If i do it with mount_cd9660 it works fine.
> 
> > this is weird. it works fine here on i386. double-check the line. see
> > if there isn't an extra whitespace somewhere. or maybe there  is 
> > something special about cdroms on sparc arch.
> 
> I had to use 
> 
> /dev/cd0a  /cdrom/  cd9660  ro,noauto  0  0
> 
> (notice the slash after /cdrom/) to make it work in my box (i386). Same
> for floppy.
...

Here's my fstab on a ultra sparc64 machine (running a later 3.1 copy):
	/dev/sd0a / ffs rw 1 1
	/dev/sd0d /var ffs rw 1 2
	/dev/sd0e /usr ffs rw 1 2
	/dev/sd0f /home ffs rw 1 2
	/dev/sd0g /usr/X11R6 ffs rw 1 2
	/dev/cd0a /cdrom cd9660 ro,noauto 0 0
	/proc /proc procfs rw 0 0
	/dev/sd1d /x ffs rw 1 2
Note: no trailing / on directories.

The logic that parses fstab entries is in
	/usr/src/lib/libc/gen/fstab.c
it's not the most pretty, but the only really alarming thing I see is
that it uses "strtok".  That should indeed accept multiple spaces or
tabs indiscriminantly as field delimiters, so that's ok.  It is also
vulnerable to various forms of unpleasant interaction with other
callers of strtok, and that's not so good.  That may not the problem here,
but it's something to consider (probably library code should in
general be at least using strtok_r instead.)

Actually, I'm a bit surprised the above works -- I would have
expected to see
	/dev/cd0c /cdrom cd9660 ro,noauto 0 0
instead -- that's what I have on my laptop.  Partition "c" should
always map the whole thing.  Evidently the default "you don't have
a disk label" code in the kernel makes partition "a" look the same
as "c", for cdroms.

It would be very interesting to see the results of:
	disklabel /dev/cd0c
for cases where it fails on people.  Here's what I got for a random CD
I found in my office (which has a zero'd block 0):
	# /dev/cd0a:
	type: SCSI
	disk: SOLARIS_2_3_AB  
	label:                 
	flags: removable
	bytes/sector: 512
	sectors/track: 100
	tracks/cylinder: 1
	sectors/cylinder: 100
	cylinders: 2283
	total sectors: 228224
	rpm: 300
	interleave: 1
	trackskew: 0
	cylinderskew: 0
	headswitch: 0           # microseconds
	track-to-track seek: 0  # microseconds
	drivedata: 0 

	3 partitions:
	#        size   offset    fstype   [fsize bsize   cpg]
	  a:   228224        0   ISO9660                        # (Cyl.    0 - 2282*)
	  c:   228224        0   ISO9660                        # (Cyl.    0 - 2282*)
	disklabel: warning, partition a: size % cylinder-size != 0
	disklabel: warning, partition c: size % cylinder-size != 0

The OpenBSD sparc64 bootable CD is going to look different than
this typical case; it's actually got a label, and *both* an
ISO9660 filesystem, *and* UFS.  Normally it shouldn't matter
if you use cd0a or cd0c - but for that one disk, it would matter.

For people who still have problems after all this, it would be
very interesting to see the results of "ktrace/kdump", both for the
successful case, and for the failing case -- and of course the
output for diskabel too for the same cd.

					-Marcus Watts