Hi, While I have no direct experience with it, there is a kernel tracing facility called System Tap (http://sourceware.org/systemtap/), which I've heard folks can use to observe the behavior of a running kernel. You may be able to selectively trace open calls that fail in the fashion you desire using it.
/ken On 08/10/2012 03:59 AM, Thomas Schmitt wrote: > Hi, > >> I'm wondering if the problem is the iso9660 file system that K3B put onto >> the disc? > > I seriously doubt. > At least dd should have no scruples to overwrite any filesystem. > > The block device driver has no idea of filesystems. > The only connection would be open(2) flag O_EXCL. mount uses it > to tell others that the drive is in use. To learn about it, the > other program would have to use O_EXCL, too, But open_sr0.c > does not do that and even if so, then it would cause error 16 EBUSY > rather than 30 EROFS. > > The problem seems to be in the way how the kernel perceives the > drive or the medium. > > >> Perhaps when faced with read-only media, the kernel simply >> assumes that the device itself is read-only. > > That would be an expensive one-way-road for re-usable media. > > Drive and medium appear as one thing to the software which controls > the drive. The medium type is expressed by the SCSI "profile" number. > This is not exactly a medium type identifier but a promise that the > drive can perform certain actions on the loaded medium. > In a write-capable drive a BD-RE should cause profile 0x43. > In a read-only drive, a BD-RE might well appear as 0x40 BD-ROM. > > But we know from dvd+rw-format and xorriso that the drive reports > profile 0x43 = BD-RE and that one can write data onto the medium. > So for some reason the kernel (actually the block device driver) > seems to get it wrong. > > > Well, maybe the refusal has other reasons. > One approach would be to debug the kernel: insert printk() and > compile and reboot. Multiple times. > It would be tricky to do this in a virtual machine, but not impossible. > See > http://libburnia-project.org/wiki/QemuXorriso > > I recently did a similar try-and-error research on Debian squeeze > in order to find out why Linux would not mount the HFS+ aspect of > a xorriso hybrid image. (It turned out that the kernel has hardcoded > APM block size 512, whereas xorriso used 2048 by default.) > To my luck, i could use qemu for the development cycles. > > This is not a task where i can help from remote. > One would have to find the occasions where error 30 (EROFS) is > emitted during the course of open(2). > Each of them would have to be equipped by printk() which puts text > into the system log (dmesg, /var/log/messages, ...). > Then you try from userspace to open("/dev/sr0", O_RDWR); and look > in the log for messages from your printk(). > > Theories will emerge and fail. If you are lucky then you find out > enough to revert the system change that has hit you. (Obviously > something must have triggered the change in behavior.) > > Or you can send a request for help to Linux Kernel Mailing List, > which is a rough territory if one is not well prepared. Especially > since Debian kernels are usually not the newest ones. > > > Have a nice day :) > > Thomas > > -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org Archive: http://lists.debian.org/50258cb1.8000...@rahul.net
