force unmounting of CDROM

From Chady Kassouf

Answered By: Thomas Adam, Mike Martin, Karl-Heinz Herrmann

Hello Answer Gang,

I backed up most of my files on CD-Rs that later on appeared to be of very low quality, now none of my CD-ROM of CD-Writer drives manage to read from them, but that's not where the problem is.

[Thomas] As long as you have (hopefully) learnt from the exercise, that's all the matters

The fact that mounting a CDROM in linux locks the drive is making a problem with these CDs.

[Thomas] How so? The whole idea of locking the drive is to do with the way the mount command works.

OK, the CDs are bad, there's no way to read them, but there's the problem of not being able to unmount them, linux will just keep on trying to chew on the bad CD, and killing `cp' will not make it give up. `umount' will either hang forever waiting for system to finish reading from the drive, or it will return but the drive will not be released. same thing will happen with `eject'

[Thomas] If you're trying to umount a /cdrom that is currently being read/write to, then what you should do is:

ps waxf

to see the upper program that is being called below "mount /cdrom", and do:

kill -9 $(pidof <program_name>)

(rude, I know). Then you'll be able to do:

umount /cdrom

I'm using RedHat 7.3, and the guilty drives are a TEAC 40X CDROM and an HP 8200Plus CD-Writer.

[Thomas] What you're describing here is not really a problem with the hardware per se but merely a gripe with the way the kernel and mount mounts a cdrom drive. Locking the drive is there to prevent the FS from screwing up, and allowing a clean change of disks via umount.

It's good to note that while rebooting the machine, init will try to unmount the filesystems but will fail on the drive that's stuck trying to read, `umount2' will kick in and retry for three times before finally giving up and letting the reboot continue.

[Thomas] Umounting drives is done for a reason. I suspect the reason why you cannot unmount /cdrom is due to Zombie processes clogging up your kernel buffer, and the kernel doesn't realised that these have effectively stopped. Usually, I have found in situations like this that a lengthy wait of 30 mins or so, does allow the kernel time to flush itself, and the locked drive is then accessible via an 'eject'.

fuser mount /cdrom

will also help you ascertain this information, as well as the classic:

ps wax

My question is twofold; first, is there a way to tell linux to give up reading and force unmounting a CDROM drive without having to use the safety pin and, hence, lose access to the drive, OR reboot he machine?

[Thomas] Yes, there is. I have done this on some severe occassions. The first thing I would try is to:

umount -f /cdrom

The "-f" flag says to mount to force umounting of it. If that does not work, then edit "/etc/mtab" and remove the entry pertaining to your cdrom drive. In case you are wondering, "/etc/fstab" holds information about drives that can and might be mounted, and "/etc/mtab" is there as a state file for those drives that are currently mounted. Editing the file in this instance is perhaps a good idea.

If you find that this is happening to you on each and every mount, try doing something like:

mount -n /cdrom

which will tell mount NOT to write to /etc/mtab. Typically I have used this on drives whereby "/" has been mounted ro, but I cannot see why it wont work here.

Second, anyone happened to have a similar situation? or might that be a hardware problem?

[Thomas] Reading my answer here will not doubt confirm that I have had experience in this sort of thing. I doubt this is hardware related, but it could be. I would need to know more information about which aspects of your cdrw work/don't work in order to help you further.

[K.-H.] Better use some of the suggestions by Thomas but it seems cdrecord does not care for the "lock" state of a CD. If you issue:

cdrecord -eject

it will simply eject the CD -- regardless if it's locked or mounted. In the best case the kernel recognises the media is gone and the errors given back to "cp" causes all concerned processes to stop. Then a umount should also be possible. Worst case you get a kernel panic for a "damaged" filesystem on the now nonexistant CD (didn't happen here, mostly it's recovering gracefully).

[MikeM] final issue could be a process called fam locking the drive - sometimes if you kill fam, you can then umount the drive.

[Thomas] Indeed, Mike. I had considered this, but then I realised that FAM isn't always loaded on some machines.

FAM (File Alteration Monitor), is also debian package and an absolute cow to compile. It is not distro specific, no. It is used to monitor directory/file changes, so I can see how it might be used in this instance but it is unlikely.

I tried all the options presented by the kind people in this list, the only one that worked though was the cdrecord -eject although it took about 3 minutes to succeed. Thanx for K.H for the solution.

I was able to capture the error that was printed out after a file copy in KDE started to choke:

scsi0: ERROR on channel 0, id 0, lun 0, CDB: Request Sense 00 00 00 40 00
Info fld=0x1a4f7, Current sd0b:00: sense key Medium Error
Additional sense indicates No seek complete
 I/O error: dev 0b:00, sector 431068

[K.-H.] read error from the CD, "Medium error" as you already assumed in your original mail. Probably nothing to save anymore. I too had some CD's which came through the file comparison right after burning. Some time later they gave me plenty of read errors. In my case the read attempts at some point broke off but as I tried to get as much data back as possible I made the reading process to try harder.

Meet the Gang   1   2   3   4   5   6   7   8