Info about Exadata’s imageinfo and rpm’s

Recently we noticed that imageinfo was displaying the following information at a customers site. Imageinfo was not displaying data i suspected, so a quick little blogpost about what was going on there.

[root@dm01db01 ~]# dcli -g /opt/oracle.SupportTools/onecommand/dbs_group -l root "imageinfo | grep 'Image version'"
dm01db01: Image version:
dm01db02: Image version:
dm01db03: Image version:
dm01db04: Image version:
dm01db05: Image version:
dm01db06: Image version:
dm01db07: Image version:
dm01db08: Image version:

So what happened here, did those last four nodes not got updated when installing the latest CellOS QDPFE? Well it turns out that all the correct packages are installed after a quick investigation:

[root@dm0105 ~]# for i in `yum info | grep Name | grep exadata |cut -d: -f2`; do yum info $i ; done | grep 'Version\|Name'
Name       : exadata-applyconfig
Version    :
Name       : exadata-asr
Version    :
Name       : exadata-base
Version    :
Name       : exadata-commonnode
Version    :
Name       : exadata-exachk
Version    :
Name       : exadata-firmware-compute
Version    :
Name       : exadata-ibdiagtools
Version    :
Name       : exadata-ipconf
Version    :
Name       : exadata-onecommand
Version    :
Name       : exadata-oswatcher
Version    :
Name       : exadata-sun-computenode
Version    :
Name       : exadata-validations-compute
Version    :
[root@dm0101 rpm-extraxt]#

So according to yum everything is installed here, rpm -qa also confirms this so no miss-match there:

[root@dm0105 ~]# rpm -qa | grep exadata
[root@dm0101 ~]#

It looks like imageinfo is displaying incorrect information here, how come and where does it gets its information from? Well, imageinfo gets its information out of a file called

root@dm01db05 ~]# cat /opt/oracle.cellos/
created:2013-01-09 03:37:26 -0800
f331a2bfa27cc7371d936009289c23b6 *commonos.tbz
22212b4436b57fba6d53be4d7a6fd975 *dbboot.tbz
c7cf016f2180ab820010a787b77c59fb *dbfw.tbz
fd9d8b4f4a30588ca39f66015d5edc4e *dbrpms.tbz
eaa1a7973efcdcd2fe40b09828ba0e01 *debugos.tbz
290909dec5b3995aed2298f20d345aea *exaos.tbz
cfda22b7599e47bdc686acf41fd5d67c *kernel.tbz
18db43d6e94797710ffa771702be33e8 *ofed.tbz
4831ba742464caaa11c1c0153b823886 *sunutils.tbz
activated:2013-11-24 04:41:03 +0100

you can see that this file contains all the informations about the current version of your Exadata software stack as well as a list of md5 checksums of the .tbz files in /opt/oracle.cellos/iso/cellbits. We checked the md5 checksums of these files as well so now we now 100% that we are on the correct level. Now how does this file gets updated, it seems that it is out-of-date or at least not inline with our system? Well it is being generated when you are patching your compute node to another level and it is being updated by the exadata-sun-computenode rpm. Lets peek a bit into that rpm and what it is deploying, first i am going to mount an ISO file as my yum repository:

[root@dm0101 ~]# mount -o loop /u01/app/oracle/stage.2288/112_latest_repo_130109.iso /var/www/html/yum/unknown/EXADATA/dbserver/11.2/latest.2288/
[root@dm0101 ~]# cp /var/www/html/yum/unknown/EXADATA/dbserver/11.2/latest.2288/x86_64/exadata-sun-computenode- 

Next step is to extract the files from the RPM and see what we get:

[root@dm0101 ~]# mkdir /tmp/exadata-sun-computenode-
[root@dm0101 ~]# cd /tmp/exadata-sun-computenode-
[root@dm0101 exadata-sun-computenode-]# rpm2cpio ../exadata-sun-computenode- | cpio -idv
194 blocks
[root@dm0101 exadata-sun-computenode-]#

Aha! there is a file called ./opt/oracle.cellos/tmpl/ in that RPM, but it is not showing everything, it still doesn’t got the md5 checksum information in it:

[root@dm0101 exadata-sun-computenode-]# cat ./opt/oracle.cellos/tmpl/
created:2013-03-02 19:28:04 -0800
[root@dm0101 exadata-sun-computenode-]#

To find out how that gets filled we need to take a look into the script that gets executed when we install this RPM. The output bellow is a bit truncated for readability:

[root@dm0101 rpm-extraxt]# rpm --scripts -qp exadata-sun-computenode-
# Don't start post script for the fresh imaging (on zero boot)
# Don't install any files (remove them)
if [ -f /.post.imaging ]; then
  rm -f /opt/oracle.cellos/tmpl/
  rm -f /opt/oracle.cellos/
  /sbin/service exachkcfg postrpm exadata-sun-computenode

So when we install this RPM it does (among other things not shown here) remove my file and a shell script called and it then executes a new version of Now is quiet a big script and it does setup your compute node properly and then finally it reboots your compute node. In this huge script there is a function that is being called that actually calculates the md5 checksums of my cellbits directory and places that info into a variable:

md5sum_iso_cellbits ()
  local imageid_out=$1

  [ "$imageid_out" == '' ] && imageid_out=$IMAGE_ID_DEF
  print_log "Please wait. Calculating checksums for $imageid_out ..." INFO
  # Remove any existing md5 sums from the output file
  perl -ne '/[a-f\d]\s+\*.+/ or print $_' -i $imageid_out
  local tmp_lst=/tmp/msd5sum.cellbits.lst
  pushd /opt/oracle.cellos/iso/cellbits
  md5sum -b * > $tmp_lst
  cat $tmp_lst >> $imageid_out
  rm -f $tmp_lst

Finally the function db_update_imageinfo () in creates a new and up-to-date version of my file and it makes imageinfo happy again. To make a long blogpost short, the solution to our misbehaving image info (and also imagehistory btw.) was to run

yum --enablerepo=exadata_dbserver_11. reinstall exadata-sun-computenode-

and let the nodes reboot. This solved our problem with the imageinfo command, unfortunately we could not determine the root cause for the problem.

One thought on “Info about Exadata’s imageinfo and rpm’s

  1. i am seesing cell version diffrent from image version , is that a problem
    [root@onecell01 ~]# imageinfo

    Kernel version: 2.6.39-400.128.17.el5uek #1 SMP Tue May 27 13:20:24 PDT 2014 x86_64
    Cell version: OSS_12.
    Cell rpm version: cell-

    Active image version:
    Active image activated: 2014-11-18 12:09:29 -0600
    Active image status: success
    Active system partition on device: /dev/md5
    Active software partition on device: /dev/md7

    In partition rollback: Impossible

    Cell boot usb partition: /dev/sdm1
    Cell boot usb version:

    Inactive image version: undefined
    Rollback to the inactive partitions: Impossible

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s