According to https://www.openbsd.org/faq/faq13.html#writeDVD <https://www.openbsd.org/faq/faq13.html#writeDVD>,
> A pretty different format is DVD-RAM, which was mainly developed as a data > drive and has advanced packet writing functions, allowing it to be used like > a kind of optical hard disk. I was mainly looking for a method to make the DVD-RAM works like a hard drive. It seems the package is the only option though. Thanks and best regards, Siegfried > On Jul 27, 2019, at 6:42 PM, Brian Brombacher <[email protected]> wrote: > > See cd(4): https://man.openbsd.org/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 <[email protected] <mailto:[email protected]>> wrote: > >> >> >> On 7/25/19 7:14 PM, Zhi-Qiang Lei wrote: >>> On Jul 25, 2019, at 10:24 PM, gwes <[email protected] <mailto:[email protected]>> >>> 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. >>
