Recently in System Administration Category

Writing an ISO Image Under Windows

| No Comments

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'.
        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
        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 ... ]

An RPM Database Fix


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 $?

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.

About this Archive

This page is an archive of recent entries in the System Administration category.

Programming is the previous category.

Web is the next category.

Find recent content on the main index or look in the archives to find all content.