I have made several attempts to get my CR-R going, but have been thwarted, and now I fear I've tangled something up in the attempt. Would someone help me untangle this mess? I'm running SuSE 7.2 pro, and I've updated it regularly with YOU, and selected packages with yast1. I've followed the instructions in the manual, and on the sdb. I've got ide-scsi emulation running, in that I can mount a CD and read it in either my CD-rom or CD-RW drive. From the traffic on this list, I thought that was the bug hump, and it would all fall into place after that. Silly me! cdrecord -scanbus finds and identifies the drive properly. bruiser:~ # dmesg | grep hd Kernel command line: auto BOOT_IMAGE=linux ro root=301 BOOT_FILE=/boot/vmlinuz BOOT_FILE=/boot/vmlinuz hdc=ide-scsi hdb=ide-scsi ide_setup: hdc=ide-scsi ide_setup: hdb=ide-scsi ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:pio, hdd:pio hda: Maxtor 32049H2, ATA DISK drive hdb: ASUS CD-S400/A, ATAPI CD/DVD-ROM drive hdc: PLEXTOR CD-R PX-W8432T, ATAPI CD/DVD-ROM drive hdd: LS-120 CSMO 05 UHD Floppy, ATAPI FLOPPY drive hda: 40021632 sectors (20491 MB) w/2048KiB Cache, CHS=2491/255/63, UDMA(33) hdd: 123264kB, 963/8/32 CHS, 533 kBps, 512 sector size, 720 rpm hda: hda1 hda2 hda4 < hda5 > bruiser:~ # cdrecord -scanbus Cdrecord 1.11a05 (i586-pc-linux-gnu) Copyright (C) 1995-2001 Jrg Schilling Linux sg driver version: 3.1.17 Using libscg version 'schily-0.5' scsibus0: cdrecord: Warning: controller returns wrong size for CD capabilities page. 0,0,0 0) 'ASUS ' 'CD-S400/A ' '2.1H' Removable CD-ROM 0,1,0 1) 'PLEXTOR ' 'CD-R PX-W8432T' '1.07' Removable CD-ROM 0,2,0 2) * 0,3,0 3) * 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * HOWEVER, KonCD setup finds the CD-ROM, but not the CD-R (It gives me a single blank choice for 'writer device'). xcdroast, when started from the KDE menu, prompts me for root password, but then dies immediately. I tried starting it from a root console. Here's the result: bruiser:~ # xcdroast ** WARNING **: X-CD-Roast does not seem to have the correct permissions set ** WARNING **: So do as root something like that: (and read the Manual) chown root:cdwrite xcdroast; chmod 2755 xcdroast ** WARNING **: Installation problem? No set-gid bit on /usr/X11R6/lib/xcdroast-0.98/bin/cdrecord ** WARNING **: Installation problem? No set-gid bit on /usr/X11R6/lib/xcdroast-0.98/bin/cdda2wav ** WARNING **: Installation problem? No set-gid bit on /usr/X11R6/lib/xcdroast-0.98/bin/readcd ** WARNING **: Installation problem? No set-gid bit on /usr/X11R6/lib/xcdroast-0.98/bin/mkisofs ** WARNING **: Invalid cdrecord version 1.11a05 found. Expecting version 1.9 This last message is worrisome - have I updated a package, but not a dependent one? bruiser:~ # rpm -qf `which cdrecord` cdrecord-1.9-54 cdrtools-1.11a06-3 bruiser:~ # rpm -qf `which xcdroast` xcdroast-0.98alpha7-63 Hmmm, it looks like I installed two packages which contained cdrecord. So where do I go from here? re-install with force-overwrite the cdrecord package? uninstall the cdrtools? update xcdroast to a level which talks to cdrecord 1.11? Permissions on xcdroast are wide open: bruiser:~ # ls -al `which xcdroast` lrwxrwxrwx 1 root users 7 Aug 29 12:35 /usr/X11R6/bin/xcdroast -> xcdrgtk There is no 'cdwrite' entry in /etc/group I'm open to suggestions! -- Rick Green "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -Benjamin Franklin
On Tue, 2001-12-25 at 01:21, Rick Green wrote:
I have made several attempts to get my CR-R going, but have been thwarted, and now I fear I've tangled something up in the attempt. Would someone help me untangle this mess?
I'm impressed. Good job gathering data!
was the bug hump, and it would all fall into place after that. Silly me!
Well, it sort of is...
There is no 'cdwrite' entry in /etc/group
What the help message means is that xcdroast should be owned root:somegroup, and your user should be a member of somegroup, where somegroup is the same group that owns /dev/cdburner, where cdburner is the device that has the burning lasers. Get it? :) Who owns /dev/scd0? It should be root:cdrom, and the same for any executable you want to make CD-R/RWs with.
I'm open to suggestions!
From the looks of your prompt, it looked like you were using the root user to do this stuff...am I wrong? Firstly, root shouldn't be using X; secondly, root is the best user to diagnose this problem. What happens when you just use cdrecord from the command line as a user or as root? The CD-Writing HOWTO has very clear directions for each mkisofs and cdrecord; they're the only tools I ever use.
-- -=|JP|=- Need a good geek? I'm unemployed! '01 B15 SE/PP | http://www.xanga.com/cowboydren/ | < '95 SL2 Auto | cowboydren @ yahoo . com | _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
On Tuesday 25 December 2001 14:30, you wrote:
On Tue, 2001-12-25 at 01:21, Rick Green wrote:
I have made several attempts to get my CR-R going, but have been thwarted, and now I fear I've tangled something up in the attempt. Would someone help me untangle this mess?
I'm impressed. Good job gathering data!
was the bug hump, and it would all fall into place after that. Silly me!
Well, it sort of is...
There is no 'cdwrite' entry in /etc/group
What the help message means is that xcdroast should be owned root:somegroup, and your user should be a member of somegroup, where somegroup is the same group that owns /dev/cdburner, where cdburner is the device that has the burning lasers. Get it? :)
Who owns /dev/scd0? It should be root:cdrom, and the same for any executable you want to make CD-R/RWs with.
I'm open to suggestions!
From the looks of your prompt, it looked like you were using the root user to do this stuff...am I wrong? Firstly, root shouldn't be using X; secondly, root is the best user to diagnose this problem. What happens when you just use cdrecord from the command line as a user or as root? The CD-Writing HOWTO has very clear directions for each mkisofs and cdrecord; they're the only tools I ever use.
May I come in into this problem as I am just wrestling with the same kind of problem. Where to find out the ownership of /dev/sd0. I aqm a little confused at the moment. Need a geek, I believe ;-). If the /dev/sg) is not included into the ownership, cdrecord -scanbus would not give a piece of useful information or?
On Tue, 2001-12-25 at 01:58, Constant Brouerius van Nidek wrote:
May I come in into this problem as I am just wrestling with the same kind of
No, I insist that you do not. ;) Some people think I joke too much; I think they're serious too much...
problem. Where to find out the ownership of /dev/sd0.
Literally: # ls -l /dev/scd? The question mark (?) means "replace only ONE character, not more." If you used scd*, you may get 17 results, you may get more. I'm trying to play it safe... I also apologize, I meant to check the ownership of scd1, not 0, since the original poster also has a DVD-ROM drive configured as a SCSI device. the CD-RW is the important one; compare `cdrecord -scanbus` and the second number (0,*1*,0) to which device you need to chown.
I aqm a little confused at the moment. Need a geek, I believe ;-).
Getting confused is not hard; ATAPI is a weird idea to start with. ;) -- -=|JP|=- Need a good geek? I'm unemployed! '01 B15 SE/PP | http://www.xanga.com/cowboydren/ | < '95 SL2 Auto | cowboydren @ yahoo . com | _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
On Tuesday 25 December 2001 15:06, you wrote:
On Tue, 2001-12-25 at 01:58, Constant Brouerius van Nidek wrote: . ;) Some people think I joke too much; I think they're serious too much...
Jokes keep us on the sometimes long fruitless wrestle matches with commands that will not act as we hope ;-)
problem. Where to find out the ownership of /dev/sd0.
Literally:
# ls -l /dev/scd?
I aqm a little confused at the moment. Need a geek, I believe ;-).
Getting confused is not hard; ATAPI is a weird idea to start with. ;)
I have even problems with the cdrecord commands. Man pages do not seem to give you to much help if you need them. I have played around with trying to put some jpg files on a cd and even if it sometimes informed me that it was fixating a reading of the drive gave nothing written down. I am not sure if the disc is really blank so I would like to blank it. What is the right sequence of the command for that. I used to no avail cdrecord /dev/scd0 blank=all and also disc but I only get the --help information. And if I use the cdrecord command for writing, is there a posibility to dump the results in a text file? I am using (without much visible succes;-( ) cdrecord -v dev=0,0,0 speed=2 /target.iso which should wtite the prepared iso file to the cd ;-(. I could then use that text file to dump it ;-) in the hands of a geek for further help.
I have even problems with the cdrecord commands. Man pages do not seem to give you to much help if you need them. I have played around with trying to put some jpg files on a cd and even if it sometimes informed me that it was fixating a reading of the drive gave nothing written down. I am not sure if the disc is really blank so I would like to blank it. What is the right sequence of the command for that.
If you want to blank a CD-RW here it is what I use: cdrecord -vv dev=0,3,0 blank=fast speed=4 This should work for your system too if you change the device number Praise
On 25 Dec 2001, Jon Pennington wrote:
On Tue, 2001-12-25 at 01:21, Rick Green wrote:
I have made several attempts to get my CR-R going, but have been thwarted, and now I fear I've tangled something up in the attempt. Would someone help me untangle this mess?
I'm impressed. Good job gathering data! I took hints from an earlier post...
was the bug hump, and it would all fall into place after that. Silly me!
Well, it sort of is...
There is no 'cdwrite' entry in /etc/group
What the help message means is that xcdroast should be owned root:somegroup, and your user should be a member of somegroup, where somegroup is the same group that owns /dev/cdburner, where cdburner is the device that has the burning lasers. Get it? :)
That's what I thought.
Who owns /dev/scd0? It should be root:cdrom, and the same for any executable you want to make CD-R/RWs with.
I'm open to suggestions!
From the looks of your prompt, it looked like you were using the root user to do this stuff...am I wrong? My X server was started by the user, but when I tried to start xcdroast from the KDE menu, it popped up a dialog box asking for the root password,
secondly, root is the best user to diagnose this problem. What happens when you just use cdrecord from the command line as a user or as root? I haven't tried plain vanilla cdrecord, since I don't have an .iso image file handy to feed it. I believe I could create one by simply 'dd'-ing /dev/cdrom to a file, but I don't know enough about the internals of CD
Ah, this might be part of the problem: rtg@bruiser:~ > ls -al /dev/cdrom lrwxrwxrwx 1 root root 9 Sep 5 14:35 /dev/cdrom -> /dev/scd0 rtg@bruiser:~ > ls -al /dev/cdrecorder lrwxrwxrwx 1 root root 9 Sep 7 11:23 /dev/cdrecorder -> /dev/scd1 rtg@bruiser:~ > ls -al /dev/scd? brw------- 1 rtg users 11, 0 May 21 2001 /dev/scd0 brw-rw---- 1 rtg users 11, 1 May 21 2001 /dev/scd1 brw-r----- 1 root disk 11, 2 May 21 2001 /dev/scd2 This has tripped me up before, and is probably a basic concept I've never quite gotten straight - When dealing with a link, which set of permissions are the operative ones? Those on the link, or the target 'real' file/device? Does it make a difference if it's a symbolic or hard link? (It's not a part of the current problem, but I've also noted that the permissions fo a directory change when I mount a filesystem there, and I've sometimes had problems writing to floppy or zip drives as a user, because the permissions and ownership of the mount point change magically when I mount the disk...) then died immediately. I wanted to start it from an xterm, in the hopes it would throw an error message to stdout. Since it apparently wanted root permissions, I ran 'sux -' first. Firstly, root shouldn't be using X; formats to specify the blocksize and block count. WHen I attempt to start xcdroast from an xterm as an ordinary user, I get: rtg@bruiser:~ > xcdroast Gtk-WARNING **: This process is currently running setuid or setgid. This is not a supported use of GTK+. You must create a helper program instead. For further details, see: http://www.gtk.org/setuid.html Refusing to initialize GTK+. rtg@bruiser:~ > ls -al `which xcdroast` lrwxrwxrwx 1 root users 7 Aug 29 12:35 /usr/X11R6/bin/xcdroast -> xcdrgtk rtg@bruiser:~ > ls -al `which xcdrgtk` -rwxr-sr-x 1 root root 687933 May 15 2001 /usr/X11R6/bin/xcdrgtk This message seems confusing, since xcdroast appears to be a link to a gtk wrapper already... And here is another situation of a link and it's target having different ownership/permissions. It's the target which is sgid, and that seems to be the operative one.
The CD-Writing HOWTO has very clear directions for each mkisofs and > cdrecord; they're the only tools I ever use.
rtg@bruiser:~ > locate CD-Writing /usr/share/doc/howto/en/html/CD-Writing-HOWTO-1.html /usr/share/doc/howto/en/html/CD-Writing-HOWTO-2.html /usr/share/doc/howto/en/html/CD-Writing-HOWTO-3.html /usr/share/doc/howto/en/html/CD-Writing-HOWTO-4.html /usr/share/doc/howto/en/html/CD-Writing-HOWTO-5.html /usr/share/doc/howto/en/html/CD-Writing-HOWTO-6.html /usr/share/doc/howto/en/html/CD-Writing-HOWTO.html Lo and behold! It's even installed on my system, and I hadn't found it. I'm searching the web when it's right under my nose. I do some more reading...
-- Rick Green "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -Benjamin Franklin
On Wed, 2001-12-26 at 01:45, Rick Green wrote:
My X server was started by the user, but when I tried to start xcdroast from the KDE menu, it popped up a dialog box asking for the root password, then died immediately. I wanted to start it from an xterm, in the hopes it would throw an error message to stdout. Since it apparently wanted root permissions, I ran 'sux -' first.
Hmm. It's been a while since I've played with X-CDRoast...
I haven't tried plain vanilla cdrecord, since I don't have an .iso image file handy to feed it. I believe I could create one by simply 'dd'-ing /dev/cdrom to a file, but I don't know enough about the internals of CD formats to specify the blocksize and block count.
Well, the dd method works just fine, but you don't need to know anything about CD internals; that's what mkisofs(8) is for. :)
Lo and behold! It's even installed on my system, and I hadn't found it. I'm searching the web when it's right under my nose. I do some more reading...
I personally prefer the plain text versions of the document. The HTML version isn't that much more difficult, except that you have to know page numbers. If you're ever looking for a HOWTO again, just pop over to http://www.linuxdoc.org/ first or the LinuxDOC mirror at Linux.com. ;) Give this a whirl: 1) Read the whole document so that you understand. 2) Use chapter 3 as your quick guide. 3) Use Lynx and grep as your even-quicker guide. I don't have the HTML documents installed, so I'll just use the web document as an example (line breaks inserted): dren@pugelist:~$ lynx -dump \ http://www.linuxdoc.org/HOWTO/CD-Writing-HOWTO-3.html \ | grep mkisofs \ | grep private_collection mkisofs -r -o cd_image private_collection/ shell> IMG_SIZE=`mkisofs -R -q -print-size private_collection/ 2>&1 \ shell> [ "0$IMG_SIZE" -ne 0 ] && mkisofs -r private_collection/ \ That first line is helpful; gives you an example of the syntax. `mkisofs --help`gives you the flags, but I find the HOWTO more helpful with matters of syntax. dren@pugelist:~$ lynx -dump \ http://www.linuxdoc.org/HOWTO/CD-Writing-HOWTO-3.html \ | grep cdrecord \ | grep cd_image shell> cdrecord -v speed=2 dev=0,6,0 -data cd_image cdrecord -v dev=0,6,0 -data cd_image -audio track*.cdr Both lines are highly useful. Again, --help should be your first flag resource, but the HOWTO makes things so much clearer. :) -- -=|JP|=- Need a good geek? I'm unemployed! '01 B15 SE/PP | http://www.xanga.com/cowboydren/ | < '95 SL2 Auto | cowboydren @ yahoo . com | _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
A recent thread brought up the question of a symbolic link --I guess that's sl, or would it be sl, versus what it called a "real" link, which I believe is ln. I would really like to see a little help here. Somebody knows links? Thanx. --doug
ln = link ln -s = symbolic link I pretty much use ln -s all the time, that is like a shortcut in other operating systems. without the -s option you get a hard link. On Wednesday, December 26, 2001, at 05:37 PM, Doug McGarrett wrote:
A recent thread brought up the question of a symbolic link --I guess that's sl, or would it be sl, versus what it called a "real" link, which I believe is ln. I would really like to see a little help here. Somebody knows links? Thanx. --doug
-- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/support/faq and the archives at http://lists.suse.com
On 26 Dec, Doug McGarrett wrote:
A recent thread brought up the question of a symbolic link --I guess that's sl, or would it be sl, versus what it called a "real" link, which I believe is ln. I would really like to see a little help here. Somebody knows links? Thanx. --doug
The file system identifies data using something called an "inode". The file names you see in a directory point to an inode with the file's data. For example, the file /etc/config-file might have an inode of 123456789. When you type in the command "mv /etc/config-file /usr/local/etc/config-file", Linux does not move any of the file's data. It just copies the directory entry that points to inode 123456789 to /usr/local/etc. The command "ln /usr/local/etc/config-file /opt/gnome/etc/config-file" creates a pointer to inode 123456789 in /opt/gnome/etc. This is a hard link: two directory entries point to the same inode. Both file names point to the same file data. You can "rm /usr/local/etc/config-file" and /opt/gnome/etc/config-file will still contain the data. A file's data is only deleted when there are no more pointers to its inode (hard links). There are some limitations to hard links: they do not work across partitions, and they do not work for directories. In these cases you need soft links. The soft link is a reference to the target path. It does not depend on inodes. So soft links can point to directories, or files on another partition. With a soft link, the referenced file may be deleted. That creates a "broken link". The soft link still exists, but the file contains no data. Hope that helps... -- Robert Wohlfarth rjwohlfar@galaxyinternet.net "Is not life more important than food, and the body more important than clothes?" -- Matthew 6:25b
Thanks for the excellent explanation of hard and soft links. I was the one who originally brought up the question, and my real quandary concerns ownership and permissions. Would you be willing to extend your description into that area? From your explanation, it would appear that in the case of a hard link, the ownership/permissions of whatever name was referenced would be the only one controlling the access, since the other directory entry wouldn't even get read. Am I right so far? But in the case of 'soft' or symbolic links, the link is a reference to the primary file name, so both directory entries get read when a reference is attempted thru the link. Which directory entry's ownership/permissions will control the access? My specific question dealt with symbolic links to device files, specifically /dev/cdrom -> /dev/scd0 and /dev/cdrecorder -> /dev/scd1. Also links to executables with suid/sgid bits set. Can you tell I'm having trouble getting my CD burner going? -- Rick Green "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -Benjamin Franklin
On Friday 28 December 2001 05.37, Rick Green wrote:
My specific question dealt with symbolic links to device files, specifically /dev/cdrom -> /dev/scd0 and /dev/cdrecorder -> /dev/scd1. Also links to executables with suid/sgid bits set.
Can you tell I'm having trouble getting my CD burner going?
Note that cdrecord and other programs work with /dev/sg*, not scd* or sr*. sg is the SCSI Generic interface, an invention from Sun if memory serves. Check your permissions on /dev/sg* as well as scd* regards Anders
On Fri, 28 Dec 2001, Anders Johansson wrote:
On Friday 28 December 2001 05.37, Rick Green wrote:
My specific question dealt with symbolic links to device files, specifically /dev/cdrom -> /dev/scd0 and /dev/cdrecorder -> /dev/scd1. Also links to executables with suid/sgid bits set.
Can you tell I'm having trouble getting my CD burner going?
Note that cdrecord and other programs work with /dev/sg*, not scd* or sr*. sg is the SCSI Generic interface, an invention from Sun if memory serves. Check your permissions on /dev/sg* as well as scd*
Does that mean that /dev/cdrecorder should be a link to /dev/sg1 rather than /dev/scd1? They do not seem to be equivalent, since they have different major numbers... rtg@bruiser:~ > ls -al /dev/sg* crw-r----- 1 root disk 21, 0 May 21 2001 /dev/sg0 crw-r----- 1 root disk 21, 1 May 21 2001 /dev/sg1 rtg@bruiser:~ > ls -al /dev/cdrecorder lrwxrwxrwx 1 root root 9 Sep 7 11:23 /dev/cdrecorder -> /dev/scd1 rtg@bruiser:~ > ls -al /dev/scd* brw------- 1 rtg users 11, 0 May 21 2001 /dev/scd0 brw-rw---- 1 root disk 11, 1 May 21 2001 /dev/scd1 I added rtg to the 'disk' group, and changed scd0 to: rtg@bruiser:~ > ls -al /dev/scd* brw-r----- 1 root disk 11, 0 May 21 2001 /dev/scd0 I can still mount and unmount CD's on that drive, so it doesn't seem to have affected anything adversely, and now it's more consistent with the other devices. I have no idea how/when I usurped that device. -- Rick Green "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -Benjamin Franklin
On Friday 28 December 2001 21.54, Rick Green wrote:
Does that mean that /dev/cdrecorder should be a link to /dev/sg1 rather than /dev/scd1? They do not seem to be equivalent, since they have different major numbers...
No, they're not equivalent in the major/minor device sense. But sg is an alternative interface for applications to the scsi layer.
rtg@bruiser:~ > ls -al /dev/sg* crw-r----- 1 root disk 21, 0 May 21 2001 /dev/sg0 crw-r----- 1 root disk 21, 1 May 21 2001 /dev/sg1
if your user is a member of group disk (not a good idea, since this gives access to all hard drives) then chmod g+w on the sg device used by the recorder. Otherwise chmod o+rw Note that write access is needed, because commands are issued to the device by writes.
rtg@bruiser:~ > ls -al /dev/cdrecorder lrwxrwxrwx 1 root root 9 Sep 7 11:23 /dev/cdrecorder -> /dev/scd1 rtg@bruiser:~ > ls -al /dev/scd* brw------- 1 rtg users 11, 0 May 21 2001 /dev/scd0 brw-rw---- 1 root disk 11, 1 May 21 2001 /dev/scd1
I added rtg to the 'disk' group, and changed scd0 to:
rtg@bruiser:~ > ls -al /dev/scd* brw-r----- 1 root disk 11, 0 May 21 2001 /dev/scd0
I can still mount and unmount CD's on that drive, so it doesn't seem to have affected anything adversely, and now it's more consistent with the other devices. I have no idea how/when I usurped that device.
regards Anders
On Friday 28 December 2001 21.54, Rick Green wrote:
Does that mean that /dev/cdrecorder should be a link to /dev/sg1 rather than /dev/scd1?
No, leave the symlink pointing at scd1. I don't really know if any program uses it. cdrecord certainly doesn't, but it could be a good mnemonic for, say, fstab. regards Anders
At 22:16 12/26/2001 -0500, Robert Wohlfarth wrote:
/repetition deleted/
Hope that helps...
-- Robert Wohlfarth rjwohlfar@galaxyinternet.net
"Is not life more important than food, and the body more important than clothes?" -- Matthew 6:25b
Thank you, that is a big help. I really had no idea how the file system worked. Now that I see what's happening, I looked up "symbolic link" and find the command to be "ln -s" . --doug
participants (9)
-
Anders Johansson -
Constant Brouerius van Nidek -
Doug McGarrett -
egiraldez＠aditel.es -
Gnu iBook 2 -
Jon Pennington -
Praise -
Rick Green -
Robert Wohlfarth