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/12645612483761152...@scdbackup.webframe.org
