On Friday 13 May 2005 07:22 pm, Brant Fitzsimmons wrote: > On Fri, 2005-05-13 at 14:42 -0400, JoeHill wrote: > > On Fri, 13 May 2005 17:00:20 +0100 > > > > Ian disseminated the following: > > > On Friday 13 May 2005 16:36, Miark wrote: > > > > On Fri, 13 May 2005 10:05:32 +0100, Margot wrote: > > > > > > > > [a half-mile of useless quotes snipped--take a hint people] > > > > > > > > > One thing nobody seems to have mentioned so far - to burn > > > > > successfully, you must use k3b as root, not as normal user. > > > > > > > > > > If you open k3b as root - either use a root terminal to open > > > > > k3b, or use the command kdesu k3b in a run command box and > > > > > then give your root password - then you should have access to > > > > > ALL files, no need to copy them to /home. > > > > > > > > I've always understood that one should do as little as possible > > > > as root for security and whatever other reasons. Isn't this kind > > > > of a Bad Thing (tm) to make people su for such a common task? > > > > > > Strange, I'm using K3B 0.11.20 here with cdrdao 1.1.9, cdrecord > > > 2.1.1a01-dvd, dvd+rw-format4.10, growisofs 5.21, makeisofs 2.1 and > > > haven't gone into root to burn anything. > > > > Do: > > > > uname -r > > > > >From what I've gleaned from Tom Brinkman's posts on this subject, it's a > > > kernel > > > > issue, not the software you are using to burn. If you did an upgrade, and > > did not install the newer kernel, your kernel may still be the older > > patched version. MandrXXX, up to now, had patched the kernel to allow for > > burning apps to access kernel space directly, but no longer. Something to > > do with conforming to the LSB (IIANM), which personally I think is a dumb > > idea, but I'm no expert. > > > > To address the previous posts, I don't see why a distro cannot allow for > > two versions of the kernel, one for people who are setting up their > > machine as a fully functional desktop box, another for those who are > > setting said box up as a server and are perhaps more paranoid about > > security. Anyhow, that's just my somewhat, possibly terribly, misinformed > > opinion. > > Has anyone checked this out yet? > > http://www.planetbeagle.org/ > > Halfway down the page there is a link titled "The definitive guide to CD > writing on recent 2.6 kernels". > > You might find it useful. ====================================== The definitive guide to CD writing on recent 2.6 kernels
Despite the fact it happened a few months ago, I still see people claiming that it is impossible to write CDâs with recent 2.6 kernels due to the internal changes. This is not true! The first thing to check is that you arenât using SCSI emulation. You donât need this in Linux 2.6 - its ugly, and apparently doesnât work. Disable SCSI emulation and use the new ATAPI features to burn âdirectlyâ (no extra configuration options needed other than general ATAPI cdrom support). Next up, check you are running the latest version of cdrtools/cdrecord, even if this means going into the testing/unstable tree. The latest at the moment is cdrtools-2.01.01_alpha01-r1. The same applies for any other cd recording software you might be using. Itâs also important that you are running the latest stable kernel. This is currently 2.6.11. If you arenât running this, then you are in no position to complain that things donât work or file bugs. A few months ago, the kernel code changed to restrict the commands which can be sent to CD writers. The restriction only allows commands that are related to CD reading and writing. The commands are listed in a table. At first, the table was too small, but thanks to user feedback I helped expand it to cover all commands needed for CD writing. It seems that many users keep advocating a patch which completely bypasses the command table - and this patch is still included in some patchsets! This is no longer needed! If it does make a difference, then its a bug in either your CD writing software or the kernel command table is missing a valid command entry. If this is the case, send me an email, and Iâll fix things up with minimum effort involved. Iâve done this a few times before and Iâm happy to do it again. Another kernel change made at the same point in time resulted in the ability to write CDâs being restricted to users with write access to the CDROM device. That makes sense, right? (Previously you just needed read access.) So the first thing to do is check that you have write access to your CDROM node. Assuming your CDROM drive is /dev/hdc, run the following: # [ -w /dev/hdc ] && echo "OK" || echo "Fix up your permissions!" If you see a message telling you to fix up your permissions, the usual procedure is to use ls to see which group owns the node (usually cdrw or cdrom), add yourself to that group, and then try again. This requires that the group has access to write to the node too. Moving on. Some software used to advise that you set the suid bit on your cdrecord binary. This means that cdrecord will always run with root priveleges, even if you execute it from a standard user account. Some kernel memory management changes broke cdrecordâs ability to run as root for a while. Even though itâs fixed now, itâs worth turning this off for the security implications alone: # chmod -s /usr/bin/cdrecord Note that xcdroast does weird things with suid bits too. For the purpose of testing, I suggest you keep away from xcdroast. In terms of software usage, people seem to be historically used to running commands like cdrecord dev=ATAPI:0,0,0. An alternative method is cdrecord dev=/dev/hdc. Thereâs been an eternal debate as to which way should be encouraged - the cdrecord author doesnât like the dev=/dev/hdc method, as you can probably gather from the warnings that appear. Right now, all you want to do is write CDâs, so no matter what you think, you need to use the dev=/dev/hdc method. Also, do avoid the dev=ATA:x,y,z notation too. Another possible problem is that your CD writing software is opening up the CD node as read-only. The kernel will reject any write commands sent to it. The software needs to be modified to open the CD node as read-write. I fixed up some of the software such as dvd+rw-tools and cdrwtool a while back - but if there is any more problematic software, please let me know. (This is why its essential that you are running the latest versions of the software in question) Finally, burn as your standard user account, not as root. Hopefully this clears some things up. If you do experience problems after following the above precisely, please file a bug.
____________________________________________________ Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com Join the Club : http://www.mandrakeclub.com ____________________________________________________
