Writing ISO Images to CD with cdrecord
In the old command-line days, about the only way to write a CD-ROM on a Linux system was to know the set of commands that build an ISO filesystem and then copy it to a CD. Today, with the availability of GUI-based CD creation programs such as K3B, the old command-line method is pretty much forgotten.
Those GUIs are fine for building a CD from ordinary files stored on your hard disk--text, data, music and such--but sometimes you need to do the equivalent of copying a CD image onto a new CD. A common occurrence of this is with a Linux distribution. For example, Knoppix is distributed in this manner, as is the SuSE Live Evaluation.
You might think that using cp or dd would do the trick in this situation. After all, to us UNIX people, a file is a file. Unfortunately, that doesn't work with creating CDs, because you can't simply write bits to the CD and be home free.
Fortunately, there is a program that understands how to deal with writing CDs like this and isolates you from most of the pain. The program is cdrecord, and most GUI-based CD creation programs actually use cdrecord to do the actual writing.
Unless you know the address at which your CD writer lives on the bus, you should enter cdrecord -scanbus. This command scans for devices and prints out their addresses in the format that cdrecord wants. Note that I am doing this with a SCSI CD writer. I am not sure what you will see with an IDE device.
In my case, the line of output that matters is:
0,4,0 4) 'HP ' 'CD-Writer+ 9600 ' '1.0a' Removable CD-ROM
and the 0,4,0 in the line is the information I need to feed to the cdrecord program.
Most likely this is all the information you need to have, as cdrecord polls the device and seems to default well. If this is not the case, grab the manual for your CD writer, type man cdrecord and start reading.
Assuming you don't want to get fancy, a command line with dev= followed by the device and then the name of the ISO image to write out should be enough. Optionally, the -v option gives you a little more information when the program is running. On my system, for example, I enter the following to write the SuSE 9.0 ISO image:
cdrecord -v dev=0,4,0 Suse-9.0*iso
The *, of course, is a shell wildcard that saves me from typing a very long file name. For comparison's sake, this is what the command's output looks like:
Cdrecord 2.0 (i686-suse-linux) Copyright (C) 1995-2002 JÃ¶rg Schilling TOC Type: 1 = CD-ROM cdrecord: Warning: not running as root user, fs= option ignored. scsidev: '0,4,0' scsibus: 0 target: 4 lun: 0 Linux sg driver version: 3.1.24 Using libscg version 'schily-0.7' cdrecord: Warning: using inofficial libscg transport code version (firstname.lastname@example.org '@(#)scsi-linux-sg.c 1.75 02/10/21 Copyright 1997 J. Schilling'). atapi: 0 Device type : Removable CD-ROM Version : 4 Response Format: 2 Capabilities : SYNC Vendor_info : 'HP ' Identifikation : 'CD-Writer+ 9600 ' Revision : '1.0a' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : MMC-2 SWABAUDIO Supported modes: TAO PACKET SAO SAO/R96R RAW/R96R Drive buf size : 4183552 = 4085 KB FIFO size : 4194304 = 4096 KB Track 01: data 648 MB Total size: 745 MB (73:50.37) = 332278 sectors Lout start: 745 MB (73:52/28) = 332278 sectors Current Secsize: 2048 ATIP info from disk: Indicated writing power: 7 Is not unrestricted Is not erasable ATIP start of lead in: -11597 (97:27/28) ATIP start of lead out: 336601 (74:50/01) Disk type: Short strategy type (Phthalocyanine or similar) Manuf. index: 20 Manufacturer: Princo Corporation Blocks total: 336601 Blocks current: 336601 Blocks remaining: 4323 RBlocks total: 346489 RBlocks current: 346489 RBlocks remaining: 14211 Starting to write CD/DVD at speed 12 in real TAO mode for single session. Last chance to quit, starting real write 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Performing OPC... Starting new track at sector: 0 Track 01: 648 of 648 MB written (fifo 100%) [buf 99%] 12.1x. Track 01: Total bytes read/written: 680501248/680501248 (332276 sectors). Writing time: 400.168s Average write speed 11.9x. Min drive buffer fill was 99% Fixating... Fixating time: 22.958s cdrecord: fifo had 10719 puts and 10719 gets. cdrecord: fifo was 0 times empty and 10592 times full, min fill was 93%.
There is some useful information in there, as well as one very important piece of information. In the last line, cdrecord tells you if the FIFO ever was empty and how low it ever got. This is the buffer to the device. You are transferring the data to the CD in real time. If the FIFO is ever empty, the CD will be corrupted. The minimum fill percentage is a good way to check how close you are to not keeping up. If this number gets fairly low, you should stop all unnecessary processes when you are writing a CD.
Copyright (c) 2004, LG Staff. Originally published in Linux Gazette issue 98. Copyright (c) 2004, Specialized Systems Consultants, Inc.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Rogue Wave Software's Zend Server
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide