SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
It mounts as write protected because if you're just viewing a CD, you're probably not gonna be writing anything to it, and in most cases you can't (normal CDs, CD-Rs, etc.). If you wanna burn stuff to a cd, unmount it and use a program like cdrecord to burn stuff onto it, the read-only part won't matter.
Thanks for your reply. I installed k3b by compiling the source (k3b-0.9). I ran k3bsetup to configure k3b and then ran k3b. I got the following message.
"cdrdao 1.1.7 does not support ATAPI
The configured version of cdrdao does not support writing to ATAPI devices without SCSI emulation and there is at least one writer in your system not configured to use SCSI emulation.
Solution: The best and recommended solution is to enable ide-scsi (SCSI emulation) for all writer devices. This way you won't have any problems. Or you install (or select as the default) a more recent version of cdrdao.
No support for ATAPI with cdrdao
You will not be able to use all your reading devices as copy sources since there is at least one not configured to use SCSI emulation and your system does not support ATAPI with cdrdao.
Solution: The best and recommended solution is to enable ide-scsi (SCSI emulation) for all writer devices. This way you won't have any problems."
I believe other users have asked how to enable scsi emulation and the responses on this board have shown how to modify lilo.conf to enable scsi emulation. However I boot Slackware from a floppy, without LILO. In this situation how can I enable scsi emulation for my cd burner?
i've problem with this too.
as i know, you can activate it in rc.modules, find the section modprobe ide-scsi and uncomment it.
i haven't tried it since i wondering if i must use ide-scsi emulation ? what is the different between using atapi and ide-scsi ? which one is better ?
You generally need to enable SCSI emulation to burn discs. There is no particular advantage or disadvantage to it other than this.
You can load the modules for ide-scsi from rc.modules only if you pass a flag to the kernel at boot time to prevent ATAPI drivers from being loaded for them. In fact, the default behavior for Slackware is to try to load the ide-scsi module, but it will fail if there are no available devices left with which to use it.
If you want to boot Linux from a boot floppy and still have ide-scsi work, you must do one of two things: You can compile a custom kernel that does not include ATAPI support for CD-ROMS and then load the ide-scsi module, or you can use lilo to boot from your boot floppy (this is possible; see the Boot Disk How-to for details), insert the appropriate append statements, and then load the ide-scsi module as before.
This is what I needed to do to get my CD-RW up and running the way I wanted. This list is more or less based on the (default) "Welcome to Slackware" Email from Patrick from the Slack v9.0 install. -- J.W.
1. Verify this line is in /etc/lilo.conf: append="hdc=ide-scsi"
2. Verify this line in /etc/rc.d/rc.modules is uncommented:
3. As root, run: cat /proc/scsi/scsi (the CD-RW should be listed)
chmod is a command that you can use to change permissions on a file. (Run either: 'man chmod' or 'info chmod' for complete details.) You can either add (+) or remove (-) privs, at either the user (u), group (g), or other (o) level. The usual privs are read (r), write (w), and execute (x), but there's also the 'setuid' (s) which (as I understand it) will allow a program to be run under the privs of the _file_ instead of under the privs of the _user_. Note that this only has meaning in the context of an executable file.
Thus, if root has done a "chmod u+s" on a given executable file (which technically belongs to root) then it would allow ordinary users to run that program with the file's permissions (ie, root) rather then the user's permissions. That is my understanding of it anyway. There are a lot of people here who know a lot more than I do, and I would defer to their greater knowledge. -- J.W.