Recently in System Administration Category

Another task that turns out to be not too hard. I couldn't find any native support for writing ISO images under Windows XP, but there is a version of cdrecord for Windows. It requires Cygwin to be installed, but I always have that on any Windows desktop I use.

The -scanbus shows what devices are available:

$ cdrecord.exe -scanbus
Cdrecord-Clone 2.01 (i686-pc-cygwin) Copyright (C) 1995-2004 J�rg Schilling
Using libscg version 'schily-0.8'.
scsibus0:
        0,0,0     0) 'ST340014' 'A               ' '3.10' Disk
        0,1,0     1) *
        0,2,0     2) *
        0,3,0     3) *
        0,4,0     4) *
        0,5,0     5) *
        0,6,0     6) *
        0,7,0     7) HOST ADAPTOR
scsibus1:
        1,0,0   100) 'SAMSUNG ' 'CD-R/RW SW-248F ' 'R602' Removable CD-ROM
        1,1,0   101) *
        1,2,0   102) *
        1,3,0   103) *
        1,4,0   104) *
        1,5,0   105) *
        1,6,0   106) *
        1,7,0   107) HOST ADAPTOR

As 'CD-R/RW SW-248F' is pretty obviously the CD drive, I know the unit to use is 1,0,0. Writing the image to disk is as simple as:

$ cdrecord.exe -dev=1,0,0 cd-image.iso
./cdrecord: No write mode specified.
./cdrecord: Asuming -tao mode.
./cdrecord: Future versions of cdrecord may have different drive dependent defaults.
./cdrecord: Continuing in 5 seconds...
Cdrecord-Clone 2.01 (i686-pc-cygwin) Copyright (C) 1995-2004 J�rg Schilling
scsidev: '1,0,0'
scsibus: 1 target: 0 lun: 0
Using libscg version 'schily-0.8'.
Device type    : Removable CD-ROM
Version        : 0
Response Format: 1
Vendor_info    : 'SAMSUNG '
[... etc ... ]

Had a remarkably trouble-free time upgrading from RedHat 6.2 (don't ask) to Fedora Core 2. Well, if you must know, it's a development server that hasn't been broken. After the upgrade, Oracle and ColdFusion still worked. There was one thing that could be a niggle.

# rpm -qa
error: cannot open Packages database in /var/lib/rpm
no packages

In fact, any attempt to use rpm resulted in the same message. Strange thing was that looking at the underlying database everything looked fine.

# /usr/lib/rpm/rpmdb_verify /var/lib/rpm/Packages
# echo $?
0
#

After some flailing around, I decided to try seeing what was really happening. This is a habit I picked up from SnoopDOS. On Linux, the equivalent command is strace

# strace rpm -qa 2>&1| less
execve("/bin/rpm", ["rpm", "-qa"], [/* 24 vars */]) = 0
[... lots of splurging gobbledygook here ... ]
[... not having a lot to go on, I searched for instances of "rpm" ... ]
[... many lines later ...]
open("/etc/rpm/macros.db1.rpmorig", O_RDONLY|O_LARGEFILE) = 3

Ok, I don't know all that much about rpm but it should surely not be reading files with ".rpmorig" tagged onto the name. Feeling brave, I decided to try a fairly radical fix.

# cd /etc/rpm
# mkdir STUFF
# mv macros* STUFF/
# rpm -qa

... and it worked. It looks like the one line in macros.db1.rpmorig was the culprit:

%_dbapi         1

It seems that this was causing rpm to try accessing the database using an obsolete API. Oh well, now it's noted for future reference.