disk-image-create fails for fedora-20 images

Bug #1316241 reported by Thomas Spatzier
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
diskimage-builder
Fix Released
Medium
Ian Wienand

Bug Description

When using latest diskimage-builder from github, I am getting an error when I try to build a disk image based on fedora-20.x86_64. I followed the instructs to build a disk image for heat software config, but I don't think the problem is related heat software config in particular.

Here are the last few lines of ouput I got when running disk-image-create:

Target: install.d

Script Seconds
--------------------------------------- ----------

99-up-to-date 107.477
99-os-refresh-config-install-scripts 0.094
99-install-config-templates 0.209
99-dkms 1.735
50-store-build-settings 0.009
50-heat-config-hook-script 0.008
50-heat-config-hook-puppet 45.234
50-heat-config-hook-cfn-init 0.009
50-heat-config 20.897
11-create-template-root 0.097
10-os-refresh-config 8.560
10-os-config-applier 9.201
10-os-collect-config 161.391
10-cloud-init 0.005
01-source-repositories 13.566
01-pip-manifest 0.015
01-install-pip 3.853
01-install-deps 2.783
00-fedora-fixup-vim 3.368
00-fedora-fixup-pyopenssl 1.455
00-fedora-fixup-openssl 2.839
00-fedora-fixup-audit 3.782
00-ccache 1.319
00-baseline-environment 3.106

--------------------- END PROFILING ---------------------
dib-run-parts Mon May 5 16:19:42 UTC 2014 Running /tmp/in_target.d/post-install.d/05-fstab-rootfs-label
dib-run-parts Mon May 5 16:19:42 UTC 2014 05-fstab-rootfs-label completed
dib-run-parts Mon May 5 16:19:42 UTC 2014 Running /tmp/in_target.d/post-install.d/06-network-config-nonzeroconf
NOZEROCONF=yes
dib-run-parts Mon May 5 16:19:42 UTC 2014 06-network-config-nonzeroconf completed
dib-run-parts Mon May 5 16:19:42 UTC 2014 Running /tmp/in_target.d/post-install.d/99-dkms
ls: cannot access /usr/src/linux-headers-*-*-*: No such file or directory
dib-run-parts Mon May 5 16:19:42 UTC 2014 99-dkms completed
----------------------- PROFILING -----------------------

Target: post-install.d

Script Seconds
--------------------------------------- ----------

99-dkms 0.167
06-network-config-nonzeroconf 0.005
05-fstab-rootfs-label 0.006

--------------------- END PROFILING ---------------------
dib-run-parts Mon May 5 18:19:42 CEST 2014 Running /tmp/image.Ry5ySvzs/hooks/block-device.d/10-partition
Checking that no-one is using this disk right now ...
BLKRRPART: Invalid argument
OK
Disk /dev/loop1: cannot get geometry

sfdisk: ERROR: sector 0 does not have an msdos signature
 /dev/loop1: unrecognized partition table type
No partitions found
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 May 5 18:19:42 CEST 2014 10-partition completed

Disk /dev/loop1: 303 cylinders, 255 heads, 63 sectors/track
Old situation:
New situation:
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start End #cyls #blocks Id System
/dev/loop1p1 * 1 302 302 2425815 83 Linux
/dev/loop1p2 0 - 0 0 0 Empty
/dev/loop1p3 0 - 0 0 0 Empty
/dev/loop1p4 0 - 0 0 0 Empty
Successfully wrote the new partition table

Re-reading the partition table ...

IMAGE_BLOCK_DEVICE=/dev/loop1p1
----------------------- PROFILING -----------------------

Target: block-device.d

Script Seconds
--------------------------------------- ----------

10-partition 0.112

--------------------- END PROFILING ---------------------
mke2fs 1.42 (29-Nov-2011)
Discarding device blocks: done
Filesystem label=cloudimg-rootfs
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
606480 inodes, 606453 blocks
30322 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=624951296
19 block groups
32768 blocks per group, 32768 fragments per group
31920 inodes per group
Superblock backups stored on blocks:
 32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

dib-run-parts Mon May 5 16:19:52 UTC 2014 Running /tmp/in_target.d/finalise.d/01-install-dib-first-boot
dib-run-parts Mon May 5 16:19:52 UTC 2014 01-install-dib-first-boot completed
dib-run-parts Mon May 5 16:19:52 UTC 2014 Running /tmp/in_target.d/finalise.d/11-selinux-fixfiles-restore
+ set -o pipefail
++ grep '^SELINUX=' /etc/selinux/config
++ awk -F = '{print $2}'
+ CONFIGURED_SELINUX=enforcing
+ '[' enforcing == enforcing ']'
+ setfiles /etc/selinux/targeted/contexts/files/file_contexts /
++ mktemp
+ FIXFILES_LOG=/tmp/tmp.08Cj5eM7ZH
+ fixfiles -l /tmp/tmp.08Cj5eM7ZH restore
fixfiles: No suitable file systems found
Cleaning up labels on /tmp
cat: /initial_contexts/unlabeled: No such file or directory
secon: SELinux is not enabled

Revision history for this message
Richard Su (rwsu) wrote :

I have also seen this issue when selinux is in enforcing mode. I believe the "fixfiles" command has been silently failing and it has been unearthed by this change to add "set -e" to fail scripts when there is a failure. https://github.com/openstack/diskimage-builder/commit/f6ba2aeaf45c2e4ce4879cb171e973aec78e4b0a#diff-9aa8c22f0530c01d445edc3b387345fd

I have been able to workaround this issue by changing the fixboot command to "fixfiles onboot" which move the check and relabeling to boot time. I think it would still be preferable to find a way to relabel when the images are created, because it cuts deployment time.

Changed in diskimage-builder:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Thomas Spatzier (thomas-spatzier) wrote :

Thanks for the comments, Richard. Regarding the workaround you mentioned, would this be a change to this line:

https://github.com/openstack/diskimage-builder/blob/master/elements/rpm-distro/finalise.d/11-selinux-fixfiles-restore#L14

Can you provide the exact command replacement?

Revision history for this message
Steve Baker (steve-stevebaker) wrote :

Richard, when I originally added the fixfiles it started out by doing it onboot, but that added quite some seconds to the boot time.

It would be preferable to figure out how to get fixfiles working during image build again.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to diskimage-builder (master)

Fix proposed to branch: master
Review: https://review.openstack.org/103451

Changed in diskimage-builder:
assignee: nobody → Richard Su (rwsu)
status: Triaged → In Progress
Changed in diskimage-builder:
assignee: Richard Su (rwsu) → Ian Wienand (iwienand)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to diskimage-builder (master)

Reviewed: https://review.openstack.org/103451
Committed: https://git.openstack.org/cgit/openstack/diskimage-builder/commit/?id=4e68a7965bf1a4ed0ea7dca02a63e6c7b7b02b15
Submitter: Jenkins
Branch: master

commit 4e68a7965bf1a4ed0ea7dca02a63e6c7b7b02b15
Author: Richard Su <email address hidden>
Date: Sun Jun 29 18:45:08 2014 -0700

    Remove fixfiles from rpm-distro finalize

    Running fixfiles after setfiles is redundant. setfiles
    already corrected the SELinux file security contexts.

    Change-Id: I48067f06968c5add48fa91a1496b9bf36944546c
    Closes-Bug: #1316241

Changed in diskimage-builder:
status: In Progress → Fix Committed
Tomas Sedovic (tsedovic)
Changed in diskimage-builder:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.