SCGSKELETON(1L)

💅 SCGSKELETON(1L) — Schily´s USER COMMANDS, but make it group chat

okay so bestie, welcome to the scgskeleton manual page. yes the manual name is literally right there in the title, no cap. sit down, grab a strawberry 🍓, and let's get into it.

---

🦋 NAME

scgskeleton — a skeleton program for SCSI transport using libscg 💀✨

---

✨ SYNOPSIS

scgskeleton dev=device [ options ]

that's it. that's the whole vibe. dev= first, options after. periodt. 💅

---

🌸 DESCRIPTION

Scgskeleton is a skeleton program — like, a demo lil template — that shows off the interfaces and the capabilities of the SCSI transport library libscg. it's giving "here's how you'd do it, now go build your own main character program." 🔥

🎀 Device naming

so you need a device name and you're like "which one tho??" — no worries. for a list of possible device name parameters, just call:

scgskeleton -scanbus

or

scgskeleton dev=help

and then pick the right dev= parameter based on the device listing it hands you. easy. iconic. 🫶

---

👑 OPTIONS

🌈 the full lineup, no skips

• -help — prints a short summary of the p options and exists. yes, "exists" — we're keeping the original text exactly as it is, don't come for me 🙈
• -version — print version information and exit. short, sweet, slays.

---

• dev=target — set the SCSI target for the CD/DVD/BluRay-Recorder, see notes above. a typical target device specification is dev=1,6,0. if a filename must be provided together with the numerical target specification, that filename is implementation specific (so like, it depends on your OS, not on me). the correct filename in this case can be found in the system specific manuals of the target operating system. on a FreeBSD system without CAM support, you need to use the control device (e.g. /dev/rcd0.ctl). a correct device specification in this case may be dev=/dev/rcd0.ctl:@. 🎀

💜 General SCSI addressing

the target device to the dev= option refers to scsibus/target/lun of the CD/DVD/BluRay-Recorder. communication on SunOS is done with the SCSI general driver scg. other operating systems are using a library simulation of this driver. possible syntax is: dev= scsibus,target,lun or dev= target,lun. in the latter case, the CD/DVD/BluRay-Recorder has to be connected to the default SCSI bus of the machine. Scsibus, target and lun are integer numbers. some operating systems or SCSI transport implementations may require to specify a filename in addition. in this case the correct syntax for the device is: dev= devicename:scsibus,target,lun or dev= devicename:target,lun. if the name of the device node that has been specified on such a system refers to exactly one SCSI device, a shorthand in the form dev= devicename:@ or dev= devicename:@,lun may be used instead of dev= devicename:scsibus,target,lun. ✨

🔥 Remote SCSI addressing

to access remote SCSI devices, you need to prepend the SCSI device name by a remote device indicator. the remote device indicator is either REMOTE:user@host: or REMOTE:host:. a valid remote SCSI device name may be: REMOTE:user@host: to allow remote SCSI bus scanning, or REMOTE:user@host:1,0,0 to access the SCSI device at host connected to SCSI bus # 1, target 0, lun 0. in order to allow remote access to a specific host, the rscsi(1) program needs to be present and configured on the host. 🦋

🧚 Alternate SCSI transports

ATAPI drives are just SCSI drives that inherently use the ATA packet interface as SCSI command transport layer build into the IDE (ATA) transport. you may need to specify an alternate transport layer on the command line if your OS does not implement a fully integrated kernel driver subsystem that allows to access any drive using SCSI commands via a single unique user interface. 😭

to access SCSI devices via alternate transport layers, you need to prepend the SCSI device name by a transport layer indicator. the transport layer indicator may be something like USCSI: or ATAPI:. to get a list of supported transport layers for your platform, use dev= HELP:. 🌟

💀 Portability Background

to make scgskeleton portable to all UNIX platforms, the syntax dev= devicename:scsibus,target,lun is preferred, because it hides OS specific knowledge about device names from the user. a specific OS may not necessarily support a way to specify a real device file name, nor a way to specify scsibus,target,lun. 🙃

Scsibus 0 is the default SCSI bus on the machine. watch the boot messages for more information, or look into /var/adm/messages for more information about the SCSI configuration of your machine. if you have problems to figure out what values for scsibus,target,lun should be used, try the -scanbus option of scgskeleton described below. 💅

🍓 Using logical names for devices

if no dev option is present, scgskeleton will try to get the device from the CDR_DEVICE environment. 🌸

if a file /etc/default/cdrecord exists, and if the argument to the dev= option or the CDR_DEVICE environment does not contain the characters ',', '/', '@' or ':', it is interpreted as a device label name that was defined in the file /etc/default/cdrecord (see FILES section). iykyk.

👑 Autotarget Mode

if no dev= option and no CDR_DEVICE environment is present, or if it only contains a transport specifyer but no address notation, scgskeleton tries to scan the SCSI address space for CD-ROM drives. if exactly one is found, this is used by default. so generous of it. 🫶

---

• timeout=# — set the default SCSI command timeout value to # seconds. the default SCSI command timeout is the minimum timeout used for sending SCSI commands. if a SCSI command fails due to a timeout, you may try to raise the default SCSI command timeout above the timeout value of the failed command. if the command runs correctly with a raised command timeout, please report the better timeout value and the corresponding command to the author of the program. if no timeout option is present, a default timeout of 40 seconds is used. ⏱️
• debug=#, -d — set the misc debug value to # (with debug=#) or increment the misc debug level by one (with -d). if you specify -dd, this equals to debug=2. this may help to find problems while opening a driver for libscg. as well as with sector sizes and sector types. using -debug slows down the process and may be the reason for a buffer underrun. 🔍
• kdebug=#, kd=# — tell the scg-driver to modify the kernel debug value while SCSI commands are running. 🛠️
• -silent, -s — do not print out a status report for failed SCSI commands. sometimes you just don't wanna hear it. 🤫
• -v — increment the level of general verbosity by one. this is used e.g. to display the progress of the process. 📈
• -V — increment the verbose level with respect of SCSI command transport by one. this helps to debug problems during the process, that occur in the CD-Recorder. if you get incomprehensible error messages you should use this flag to get more detailed output. -VV will show data buffer content in addition. using -V or -VV slows down the process. 🐢
• -scanbus — scan all SCSI devices on all SCSI busses and print the inquiry strings. this option may be used to find SCSI address of the devices on a system. the numbers printed out as labels are computed by: bus * 100 + target. 🚌
• scgopts=list — a comma separated list of SCSI options that are handled by libscg. the implemented options may be uptated indepentendly from applications. currently, one option: ignore-resid is supported to work around a Linux kernel bug. 🐛
• ts=# — set the maximum transfer size for a single SCSI command to #. the syntax for the ts= option is the same as for cdrecord fs=# or sdd bs=#. 🎚️

if no ts= option has been specified, scgskeleton defaults to a transfer size of 256 kB. if libscg gets lower values from the operating system, the value is reduced to the maximum value that is possible with the current operating system. sometimes, it may help to further reduce the transfer size or to enhance it, but note that it may take a long time to find a better value by experimenting with the ts= option. 💀

---

🌈 EXAMPLES

bestie. there are literally no examples here. the section exists, it's just empty. iconic honestly. 💅 (nothing to add, nothing to skip.)

---

🦋 ENVIRONMENT

• RSH — if the RSH environment is present, the remote connection will not be created via rcmd(3) but by calling the program pointed to by RSH. use e.g. RSH=/usr/bin/ssh to create a secure shell connection. 🔐

note that this forces cdrecord to create a pipe to the rsh(1) program and disallows cdrecord to directly access the network socket to the remote server. this makes it impossible to set up performance parameters and slows down the connection compared to a root initiated rcmd(3) connection. 😭

• RSCSI — if the RSCSI environment is present, the remote SCSI server will not be the program /opt/schily/sbin/rscsi but the program pointed to by RSCSI. note that the remote SCSI server program name will be ignored if you log in using an account that has been created with a remote SCSI server program as login shell. 🙈

---

👑 SEE ALSO

cdrecord(1), scg(7), rcmd(3), ssh(1). 🫶

---

⭐ NOTES

nothing here either, bestie — the section's there, but it's giving empty. keeping it exactly where it belongs. 🌸

💅 DIAGNOSTICS 💅

okay so when a SCSI command decides to flop, the error message it spits out usually looks like this, bestie:

scgskeleton: I/O error. test unit ready: scsi sendcmd: no error
CDB:  00 20 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 25 00 00 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x25 Qual 0x00 (logical unit not supported) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.002s timeout 40s

and like… let me walk you through it line by line because it's lowkey a whole story ✨

• Line one is all about the transport of the command. The text after the first colon is the error text for the system call, from the kernel's point of view. Usually it's I/O error unless other problems happen. The next words are a short description of the SCSI command that's failing. The rest of the line tells you whether there were any problems transporting the command over the SCSI bus. fatal error means it was genuinely not possible to transport the command — like, no device present at the requested SCSI address. 💀
• Line two prints the SCSI command descriptor block for the failed command. (That's the CDB: bit, bestie.)
• Line three gives you the info on the SCSI status code the command returned, if the transport of the command succeeds. This one is error info coming straight from the SCSI device. 🫶
• Line four is a hex dump of the auto request sense information for the command.
• Line five is the error text for the sense key if it's available, followed by the segment number — which is only valid if the command was a copy command. And if the error message isn't directly related to the current command, the text deferred error gets appended. 🙈
• Line six is the error text for the sense code and the sense qualifier, if available. If the type of the device is known, the sense data gets decoded from tables in scsierrs.c. The text is followed by the error value for a field replaceable unit.
• Line seven prints the block number related to the failed command, plus text for several error flags. Heads up though: the block number may not be valid. ⚠️
• Line eight (the manpage literally writes "the eight line" — we love a typo icon 👑) reports the timeout that was set up for this command and the time the command actually needed to complete.

---

🦋 BUGS 🦋

…so this section is just. Empty. Nothing in it. Zero notes, no cap. 🎀

Consider this your reminder that "no known bugs" and "nobody wrote anything here" are giving the exact same energy, and honestly? Iconic of it. 💅

---

💖 AUTHOR 💖

This whole thing was blessed to us by:

Joerg Schilling
Seestr. 110
D-13353 Berlin
Germany

More info lives at: http://cdrecord.org/private/cdrecord.html

Got support questions? Slide into: cdrtools-support@lists.sourceforge.net

If you've definitely found a bug (like, you're sure sure), send a mail to: cdrtools-developers@lists.sourceforge.net or joerg.schilling@fokus.fraunhofer.de

Wanna subscribe? Use: https://lists.sourceforge.net/lists/listinfo/cdrtools-developers or https://lists.sourceforge.net/lists/listinfo/cdrtools-support

---

and that's the page, bestie!! 🫶 this gorgeous lil manual page is brought to you by Joerg Schilling, dated 2016/01/26, and it's filed under SCGSKELETON(1L) — go forth and skeleton your SCSI commands responsibly ✨💜