Bug 723244 - F: Failed to install eject
F: Failed to install eject
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: lorax (Show other bugs)
rawhide
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Martin Gracik
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-19 10:09 EDT by John Reiser
Modified: 2013-07-04 08:57 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-25 04:16:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2011-07-19 10:09:06 EDT
Description of problem: Composing DVD of rawhide fails during construction of install root filesystem.


Version-Release number of selected component (if applicable):
today's git HEAD 631f59be448e5891227291a3af9693e9eb41a503
strongly related to lorax-0.8-1

How reproducible: every time


Steps to Reproduce:
1./usr/bin/pungi -c rawhide-fedora.ks \
        --destdir=$DESTDIR --name Fedora --ver $VERSION --nosource
2.
3.
  
Actual results:
   [snip]
(606/606) [100%] installing specspo-16-4.noarch
Non-fatal POSTTRANS scriptlet failure in rpm package kernel-3.0-0.rc7.git3.1.fc16.x86_64
writing .buildstamp file
removing locales
creating keymaps
creating screenfont
moving stubs
F: Failed to install eject
Traceback (most recent call last):
  File "/usr/bin/pungi", line 222, in <module>
    main()
  File "/usr/bin/pungi", line 124, in main
    mypungi.doBuildinstall()
  File "/usr/lib/python2.7/site-packages/pypungi/__init__.py", line 852, in doBuildinstall
    workdir=workdir, outputdir=outputdir)
  File "/usr/lib/python2.7/site-packages/pylorax/__init__.py", line 292, in run
    self.installtree.make_dracut_initramfs()
  File "/usr/lib/python2.7/site-packages/pylorax/installtree.py", line 557, in make_dracut_initramfs
    outfile, kernel.version])
  File "/usr/lib64/python2.7/subprocess.py", line 511, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['chroot', '/ext4/Fedora16/work/x86_64/yumroot', '/sbin/dracut', '--nomdadmconf', '--nolvmconf', '--xz', '--modules', 'base dmsquash-live', '/tmp/initramfs.img', '3.0-0.rc7.git3.1.fc16.x86_64']' returned non-zero exit status 1


Expected results: success


Additional info:
Comment 1 John Reiser 2011-07-19 10:09:54 EDT
dracut-011-1.noarch
Comment 2 Martin Gracik 2011-07-20 08:34:28 EDT
Is the eject binary in the installtree?
Comment 3 John Reiser 2011-07-20 10:48:39 EDT
Re-run fails today, bug #723538 [pungi].

Using the last DVD which did compose [July 14 ??], it looks like there is no 'eject', but the situation is complicated:
-----
$ cd $DVD/isolinux
$ file initrd.img
initrd.img: XZ compressed data
$ xz --decompress -c initrd.ing >/tmp/initrd
xz: initrd.img: Compressed data is corrupt
$ file /tmp/initrd
/tmp/initrd: ASCII cpio archive (SVR4 with no CRC)
$ cpio --list </tmp/initrd | grep eject
20486 blocks  ## no 'eject'
$ 
-----
So the first part of initrd.img is an XZ compressed output of a CPIO archive, and the CPIO archive contains no 'eject'.

[Evidently initrd.img is a "complicated" file.  Where are the utilities that know how to diagnose it?]
Comment 4 Martin Gracik 2011-07-21 04:31:12 EDT
The new initrd is complicated. It's a dracut initramfs glued together with our own xz initrd.

But what I meant is if the eject binary could be found in the yumroot directory in pungi's work directory. I guess you removed it in the meantime, so we just have to wait until the pungi bug gets fixed.
Comment 5 Martin Gracik 2011-07-26 04:11:32 EDT
Do you still get this error? Looks like other people don't hit it.
Comment 6 John Reiser 2011-07-26 10:22:51 EDT
pungi has been aborting earlier, I haven't gotten to 'eject' in a week.  Today pyorbit cannot be found.  (That's after fixing the is_beta vs. isfinal rewrite.)  Before today, there was a conflict between netxen-firmware and linux-firmware over file /usr/lib/libphan.fw.  (The string "netxen-firmware" appears nowhere except in /var/cache/pungi/ourtree/{*.sqlite, <<others>>}.)

Note You need to log in before you can comment on or make changes to this bug.