Bug 79126

I can't even get the mkisofs command line given to work. Could you provide the exact 
commands needed to build a multi-session CD image from scratch with no CD in any 
drive...?

You will need to burn a CD to do this, if you haven't already got one in a 'partly burnt' state that you can use. Full details, for starting from scratch, as follows:

1. Create the image for the first session:

   # mkisofs -r -gui -J -o cdimage.raw <file_list>
   
   where <file_list> is a space-separated list of files 
   (omit the angle brackets!) - use any files you happen 
   to have lying around - to put in the first session.
   
2. It will be possible to mount this image and see the
   files on it:
   
   # mkdir cdimage
   # mount -t iso9660 -o ro,loop=/dev/loop0 cdimage.raw cdimage
   # ls -l cdimage
   
   # umount cdimage
   
3. Place a blank CD in the drive (assumed to be SCSI 
   device 0,0 for this example) and burn the image
   onto it. First:
   
   # cdrecord -scanbus
   
   and see the output to check whether your CD is 0,0
   or some other device - if some other, adjust the
   following instructions to suit - also change the
   'speed' option to suit your CD writer if need be;
   then:
   
   # cdrecord -multi -v speed=16 dev=0,0 cdimage.raw
   
4. If desired, check the contents of the CD (you may
   need to eject and reload the CD for this to work):

   # mount /dev/scd0 /mnt/cdrom
   
   (adjust the above as necessary for your configuration)
   
   # ls -l /mnt/cdrom
   
5. Read the 'multi-session' info for the first session
   off the CD (again, you may need to eject and reload 
   the CD to make this command work):
   
   # cdrecord -msinfo dev=0,0
   
   (change the device number in the above if need be).
   
   The multi-session info should be two numbers separated
   by a comma, e.g. '1234,5678'.
   
6. With the CD still loaded in the drive, create the 
   image for the second session:
   
   # mkisofs -r -gui -J -o cdimage.raw -C 1234,5678 -M 0,0 <file_list_2>
   
   (substitute your own multi-session info, obtained
    at step 5, for '1234,5678' and also change '-M 0,0',
    if need be, to use the correct SCSI device number.
    <file_list_2> is a space-separated list of files,
    which should *not* be the same files that you used
    in the first session).
   
7. Now try mounting the image of the second session:

   # mkdir cdimage
   # mount -t iso9660 -o ro,loop=/dev/loop0 cdimage.raw cdimage

   This is the point at which I get the 'not a directory' 
   failure.
   
8. Create a dummy file and try mounting the second
   session to it, e.g.:
   
   # cat > temp
   (whatever)
   ^D
   
   # mount -t iso9660 -o ro,loop=/dev/loop0 cdimage.raw temp
   
   This will appear to have succeeded! However, any attempt
   to access 'temp' - either as a file or as a directory -
   will fail. I found I was unable even to dismount it and
   got various error messages at system close-down.

I don't have a CD burner I can use for testing.

From your description, it seems likely there is a bug, but without an easy way to reproduce 
it, I can't get to fixing it. Also based on your description, it sounds like it might actually be a 
kernel problem rather than util-linux - might want to move the bug there if that is correct.

My apologies, I hadn't appreciated that you might have no access to a CD writer.
   
Do you have access to the web? If so you could try the following:
   
Download <URL:http://www.rstonehouse.co.uk/mount/cdimage.raw>
   
Then follow the previous instructions, starting at step 7.

This is a specially constructed image and rather small (I have hardware limitations too - like a slow dial-up connection!) but it does illustrate the problem.

Regarding your second point, that it might be a kernel bug - by all means feel free to reclassify it, if you think fit.

I noticed that the iso9660 fstype takes a 'session=N' mount option (according to mount.8). 
Does specifying this do the trick?

No, already tried '--session=N' and various other things - see 'Additional info' section of original report.

Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/