All,

We're a software development house that is constantly burning CD's and shipping them out to our clients. We're using Fedora Core 3 (kernel: 2.6.9-1.667) as the distribution, mkisofs to generate an iso, cdrecord to burn the iso to our Yamaha CRW-F1S drive and then automount to mount /dev/scd0 to /mnt/cdrw so a diff can be run comparing the files on the CD to the files in our software directory.

Everything works up until the automount and diff to verify the files. It gives the following error:

Now verifying the contents of the CD
diff: /mnt/cdrw: No such file or directory

If i try to cd /mnt/cdrw it I get:

-bash: cd: /mnt/cdrw: No such file or directory

Now if i 'eject /dev/scd0 ; eject -t /dev/scd0' and then cd /mnt/cdrw, it works.

Here are some notable messages in the log file:

Mar 3 10:10:05 mrhanky kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>>
Mar 3 10:10:05 mrhanky kernel: scsi0:0:5:0: Device is active, asserting ATN
Mar 3 10:10:05 mrhanky kernel: Recovery SCB completes
Mar 3 10:10:05 mrhanky kernel: Recovery code sleeping
Mar 3 10:10:05 mrhanky kernel: Recovery code awake
Mar 3 10:10:05 mrhanky kernel: aic7xxx_abort returns 0x2002
Mar 3 10:10:05 mrhanky kernel: attempt to access beyond end of device
Mar 3 10:10:05 mrhanky kernel: sr0: rw=0, want=68, limit=4
Mar 3 10:10:05 mrhanky kernel: isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16
Mar 3 10:10:18 mrhanky kernel: attempt to access beyond end of device
Mar 3 10:10:18 mrhanky kernel: sr0: rw=0, want=68, limit=4
Mar 3 10:10:18 mrhanky kernel: isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16
Mar 3 10:10:18 mrhanky automount[20146]: >> mount: wrong fs type, bad option, bad superblock on /dev/scd0,
Mar 3 10:10:18 mrhanky automount[20146]: >> or too many mounted file systems
Mar 3 10:10:18 mrhanky automount[20146]: mount(generic): failed to mount /dev/scd0 (type iso9660) on /mnt/cdrw

Looks like the most notable of the above is the "attempt to access beyond end of device" error. Does anyone know what causes this or how it can be remedied without having to use an eject ; eject -t?

TIA,

-JP

"Now if i 'eject /dev/scd0 ; eject -t /dev/scd0' and then cd /mnt/cdrw, it works."

I used to have a Philips CD-RW that had the same problem. The problem was a hardware design flaw where if I burned a CD and then my software issued a hardware reset command to the CD-RW the reset did not work correctly. So after I burned a CD I always did a manual eject and a manual tray close which would then allow the next software reset command to work correctly.

If this is your problem then I would advise you to get rid of automount and then set up a script which does eject, eject -t, mount, cd, and diff

--------------------------
Steve Stites

Currently i do have the 'eject ; eject -t' in place, but it used to work flawlessly on an old redhat 7.1 install we were using on a different box with different hardware (same cdrw and scsi card, different proc, memory, etc..)

I'd really like to tell the individual who will be using this that he just has to deal with it, but unfortunatley he won't accept that as an answer since it used to work on the old redhat 7.1 install. I even went as far as formatting and installing redhat 7.1 on his box and it still didn't work the way it does in the other box. Perhaps there is some conflict between the cdrw and his machine architecture whereas that conflict doesn't exist when the cdrw is setup on the previous working machine?

I know this seems pretty ridiculous considering an eject works around the issue, but apparently the whole 4 seconds it takes to 'eject ; eject -t' is just too precious to this individual and he doesn't want to have to deal with that.

Anymore help or suggestions would be great, or if anyone needs more information from me, such as the architecture of the current machine vs. the old machine.

Thanks!

-JP