See cd(4): https://man.openbsd.org/cd.4

It’s not a real block device.  You’ll need to use something like the dvd+rw 
tools package already mentioned in order to write data to it.  The man page 
talks about how cd devices are represented as block devices for consistency 
with other tools like disklabel and mount.  Look at the list of ioctl’s 
supported in the man page.  It talks of tracks of data (like audio tracks) and 
such.

-Brian

> On Jul 26, 2019, at 8:23 PM, gwes <g...@oat.com> wrote:
> 
> 
> 
>> On 7/25/19 7:14 PM, Zhi-Qiang Lei wrote:
>>> On Jul 25, 2019, at 10:24 PM, gwes <g...@oat.com> wrote:
>>> 
>>>> On 7/24/19 10:19 PM, Zhi-Qiang Lei wrote:
>>>> Hi, I’m trying to encrypt a DVD-RAM before putting some files onto it on 
>>>> my OpenBSD 6.5 desktop. But neither dd nor disklabel seems able to work on 
>>>> the drive. Did I miss something?
>>>> 
>>>> $ dmesg | grep cd
>>>> cd0 at scsibus3 targ 1 lun 0: <HL-DT-ST, BD-RE BU40N, FR07> ATAPI 5/cdrom 
>>>> removable serial.13fd3940302020202020
>>>> cd0 at scsibus3 targ 1 lun 0: <HL-DT-ST, BD-RE BU40N, FR07> ATAPI 5/cdrom 
>>>> removable serial.13fd3940302020202020
>>>> 
>>>> $ doas dd if=/dev/urandom of=/dev/rcd0c bs=1k
>>>> dd: /dev/rcd0c: Invalid argument
>>>> 1+0 records in
>>>> 0+0 records out
>>>> 0 bytes transferred in 0.000 secs (0 bytes/sec)
>>>> 
>>>> $ doas disklabel -E cd0
>>>> cd0> a
>>>> partition: [a]
>>>> offset: [0]
>>>> size: [2236704]
>>>> FS type: [4.2BSD]
>>>> cd0> w
>>>> cd0> p
>>>> OpenBSD area: 0-2236704; size: 2236704; free: 0
>>>> #                size           offset  fstype [fsize bsize   cpg]
>>>>   a:          2236704                0  4.2BSD   2048 16384     1
>>>>   c:          2236704                0  unused
>>>> cd0> q
>>>> No label changes.
>>>> 
>>>> The same drive can be formatted and used on Mac OS X.
>>>> 
>>>> Thanks and best regards,
>>>> Siegfried
>>>> 
>>> Did you try 2K blocks? The low level of CDROM only works that way.
>>> 
>> 
>> Blocks larger than or equal to 2k get a "dd: /dev/rcd0c: short write on 
>> character device”. Regarding to cd(4) I thought the device is readonly, so 
>> dd(1) and disklabel(8) cannot write on it, but fdisk(8)  works fine.
>> 
>> $ doas dd if=/dev/urandom of=/dev/rcd0c bs=2k
>> dd: /dev/rcd0c: short write on character device
>> dd: /dev/rcd0c: Invalid argument
>> 1+0 records in
>> 0+1 records out
>> 512 bytes transferred in 0.008 secs (57960 bytes/sec)
>> 
>> $ doas dd if=/dev/urandom of=/dev/rcd0c bs=512
>> dd: /dev/rcd0c: Invalid argument
>> 1+0 records in
>> 0+0 records out
>> 0 bytes transferred in 0.000 secs (0 bytes/sec)
>> 
> /dev/cd0 is likely a symbolic link to something else in /dev.
> It's not clear what's going on unless we know exactly what's being used.
> "cd0" is not a usual OpenBSD device access even though one sees
> that in dmesg.
> 
> OpenBSD disk-like devices are usually referenced in the very
> old style which distinguishes "raw" [unbuffered direct to device]
> from "cooked" [system buffered]. This differs from at least Linux practice.
> Dunno about other BSDs or Macs.
> Buffered devices are essentially only used to mount as filesystems.
> 
> A raw device is /dev/r<controller-or-generic-type><unit-number><partition>
> A buffered device is /dev/<controller-or-generic-type><unit-number><partition>
> Note that there is always a partition letter.
> The kernel will always emulate a 'c' partition = whole device if necessary.
> 
> So the most specific way to refer to your cd device is /dev/rcd0c.
> 
> As a convenience and to reduce operator errors, many system maintenance
> programs will deduce /dev/r<specified-device>c from a bare device
> like sd0. This can be confusing to people new to OpenBSD.
> 

Reply via email to