Diskimage-builder (DIB) produces a non-bootable RHEL 6.7 QCOW2-image

Dear DIB team,

1. We are running:
diskimage-builder (DIB: http://docs.openstack.org/developer/diskimage-builder/) to create a custom Red Hat Enterprise Linux (RHEL) version 6 QCOW2 image (see: https://rhn.redhat.com/rhn/software/channel/downloads/Download.do?cid=16952)

on a host offering the following environment:
- RHEL 7.1
- dib-utils 0.0.9-1
- sfdisk 2.23.2 (util-linux 2.23.2)

2. Reproduction is done when:
We've set the following environment variables to allow a proper execution and connection setup with our RHEL Satellite environment for package updates during the diskimage-builder run:

- export DIB_RHSM_USER=<user>
- export DIB_RHSM_PASSWORD=<password>
- export DIB_SAT_URL=https://<host>.xx.xxxxx.xxx/XMLRPC
- export DIB_SAT_KEY=<key_1>,<key_2>
- export DIB_RHN_CHANNELS=""
- export DIB_REG_TYPE=rhn
- export DIB_RELEASE=6.7-20150706.0
- export DIB_CLOUD_IMAGES=file:///root
- export DIB_IMAGE_SIZE=5
- export TMP_DIR=$HOME/oso

Optionally, setting break point before starting "block-device" phase in DIB:
- export break=before-block-device

The command we use to start the DIB image creation process (without having set the environment variable "break")
diskimage-builder/bin/disk-image-create --no-tmpfs -a amd64 vm rhel <custom_dib_element> -o RHEL-x86_64-openshift-origin-broker >/tmp/dib_rhel.log 2>&1

The command es use to start the DIB image creation process (when having set the environment variable "break")
diskimage-builder/bin/disk-image-create --no-tmpfs -a amd64 vm rhel <custom_dib_element> -o RHEL-x86_64-openshift-origin-broker

Import the created image into OpenStack Kilo Glance via:
glance image-create --name RHEL-x86_64-oso-broker --is-public true --disk-format qcow2 --container-format bare < RHEL-x86_64-openshift-origin-broker.qcow2

Launch an instance of the imported image via OpenStack Horizon or OpenStack Nova and take a look on the instance's log file below:
/var/lib/nova/instances/<instance_id>/console.log

It'll stay empty. That documents that the image did not boot!

3. Analysis and root cause identification:
The problem seems to be located within the "block-device.d" phase running outside "chroot" where the partition table writing respectively the bootloader handling seems to fail.

With an activated "break=before-block-device" environment variable we could especially re-produce the same problematic log output (see https://drive.google.com/file/d/0B6btT4vDRIz_NkhScXpnV2Q4UEE/view?usp=sharing) via a manual execution of the following command:
dib-run-parts /root/oso/image.<identifier>/hooks/block-device.d

beyond the chroot environment. This shows the problematic "sfdisk" command, too. Below the generated interesting log output of DIB:

...
dib-run-parts Mon Sep 21 18:29:08 CEST 2015 Running /root/oso/image.c8DfiJSU/hooks/block-device.d/10-partition
Checking that no-one is using this disk right now ...
BLKRRPART: Invalid argument
OK

sfdisk: Disk /dev/loop2: cannot get geometry

sfdisk: /dev/loop2: unrecognized partition table type

sfdisk: No partitions found

sfdisk: Warning: The partition table looks like it was made
  for C/H/S=*/181/40 (instead of 652/255/63).
For this listing I'll assume that geometry.

sfdisk: start: (c,h,s) expected (0,51,9) found (0,32,33)

sfdisk: end: (c,h,s) expected (1023,180,40) found (652,180,40)

Warning: partition 1 does not end at a cylinder boundary
end of partition 1 has impossible value for cylinders: 652 (should be in 0-651)
BLKRRPART: Invalid argument
If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)
dib-run-parts Mon Sep 21 18:29:08 CEST 2015 10-partition completed

Disk /dev/loop2: 652 cylinders, 255 heads, 63 sectors/track
Old situation:
New situation:
Units: sectors of 512 bytes, counting from 0

   Device Boot Start End #sectors Id System
/dev/loop2p1 * 2048 10485759 10483712 83 Linux
/dev/loop2p2 0 - 0 0 Empty
/dev/loop2p3 0 - 0 0 Empty
/dev/loop2p4 0 - 0 0 Empty
Successfully wrote the new partition table

Re-reading the partition table ...

IMAGE_BLOCK_DEVICE=/dev/loop2p1

...

dib-run-parts Mon Sep 21 18:29:32 CEST 2015 Running /root/oso/image.c8DfiJSU/hooks/cleanup.d/51-bootloader
+ set -eu
+ set -o pipefail
+ '[' -n /root/oso/image.c8DfiJSU/mnt ']'
+ source /root/oso/diskimage-builder/bin/../lib/img-functions
+ '[' -d /root/oso/image.c8DfiJSU/mnt/boot/extlinux ']'
+ CONF=/root/oso/image.c8DfiJSU/mnt/boot/extlinux/extlinux.conf
+ select_boot_kernel_initrd /root/oso/image.c8DfiJSU/mnt
+ TARGET_ROOT=/root/oso/image.c8DfiJSU/mnt
+ BOOTDIR=/root/oso/image.c8DfiJSU/mnt/boot
+ '[' -n '' -a -n '' ']'
+ '[' -f /root/oso/image.c8DfiJSU/mnt/etc/redhat-release ']'
++ grep PAE
++ ls -1rv /root/oso/image.c8DfiJSU/mnt/boot/vmlinuz-2.6.32-573.3.1.el6.x86_64 /root/oso/image.c8DfiJSU/mnt/boot/vmlinuz-2.6.32-573.el6.x86_64
++ grep -v debug
++ head -1
++ echo ''
+ KERNEL=
++ ls -1rv /root/oso/image.c8DfiJSU/mnt/boot/vmlinuz-2.6.32-573.3.1.el6.x86_64 /root/oso/image.c8DfiJSU/mnt/boot/vmlinuz-2.6.32-573.el6.x86_64
++ grep -v debug
++ head -1
+ KERNEL=/root/oso/image.c8DfiJSU/mnt/boot/vmlinuz-2.6.32-573.el6.x86_64
+ '[' '!' /root/oso/image.c8DfiJSU/mnt/boot/vmlinuz-2.6.32-573.el6.x86_64 ']'
++ basename /root/oso/image.c8DfiJSU/mnt/boot/vmlinuz-2.6.32-573.el6.x86_64
+ KERNEL=vmlinuz-2.6.32-573.el6.x86_64
+ KERNEL_VERSION=2.6.32-573.el6.x86_64
+++ ls /root/oso/image.c8DfiJSU/mnt/boot/initramfs-2.6.32-573.el6.x86_64.img
++ basename /root/oso/image.c8DfiJSU/mnt/boot/initramfs-2.6.32-573.el6.x86_64.img
+ RAMDISK=initramfs-2.6.32-573.el6.x86_64.img
+ '[' '!' initramfs-2.6.32-573.el6.x86_64.img ']'
+ sudo sh -c 'cat > /root/oso/image.c8DfiJSU/mnt/boot/extlinux/extlinux.conf <<_EOF_
DEFAULT linux

LABEL linux
    KERNEL /boot/vmlinuz-2.6.32-573.el6.x86_64
    APPEND ro root=LABEL=cloudimg-rootfs console=tty0 console=ttyS0,115200 nofb nomodeset vga=normal
    INITRD /boot/initramfs-2.6.32-573.el6.x86_64.img
_EOF_'
dib-run-parts Mon Sep 21 18:29:32 CEST 2015 51-bootloader completed

When uploading the original non-modified/non-customized RHEL QCOW2 image retrieved from https://rhn.redhat.com/rhn/software/channel/downloads/Download.do?cid=16952 to OpenStack Glance and booting from it, it works successfully and Nova's instance log file contains the expected boot information!

From our point of view there seems to be bug within the DIB. Do you agree? Maybe it's related to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1481158