Red Hat Bugzilla – Bug 895258
livemedia-creator appears to hang when using --novirt and --image-only
Last modified: 2013-05-21 23:16:26 EDT
Created attachment 678480 [details]
Kickstart file used for testing.
Description of problem:
livemedia-creator appears to hang when running on an F18 ARM host using --novirt and --image-only options.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run livemedia-creator on an F18 ARM host:
--make-disk --no-virt --image-only --keep-image \
2. The process starts, and the following is displayed
2012-11-09 22:32:19,119: disk_size = 4GB
2012-11-09 22:32:19,120: disk_img = /var/tmp/diskltaROk.img
2012-11-09 22:32:19,121: install_log = /root/virt-install.log
3. No further progress is detected.
Runs to completion.
This was run on and F18 Arm HighBank host.
The kickstart file used is also attached.
Created attachment 678481 [details]
tarball of the logs
Created attachment 678490 [details]
Created attachment 678491 [details]
program log file
Created attachment 678492 [details]
storage log file
Hey Brian, what do we need to do to advance this issue? Any pointers for diagnostics?
Try running the ks in a virt with vnc. I know this is for arm, but error handling in the text mode anaconda doesn't always do the right thing when it fails.
You can also send a USR2 signal to the anaconda process and it will hopefully dump its state into /tmp/anaconda-tb-*
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I have tried running livemedia-creator again with the following versions installed:
It no longer hangs at the same point, but I continue to get the following errors:
AttributeError: 'YumBase' object has no attribute 'preconf'
Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-bluesky&arch=armhfp error was
No repomd file
The first error looks similar to:
I think the second is due to the fact that fedora-bluesky only includes primary architectures, and armhfp is a secondary architecture. I'm not sure where fedora-bluesky is coming from, because the kickstart file provides the correct repos for the the install.
repo --name=fedora --mirrorlist="http://mirrors.fedoraproject.org/metalink?repo=fedora-18&arch=armhfp"
The command I use is:
--make-disk --no-virt --image-only --keep-image \
but in _configureBaseRepo (/usr/lib/python2.7/site-packages/pyanaconda/packaging/yumpayload.py) under:
elif method.method == "url":
I can display the values:
url = http://intranet.ges.redhat.com/es/Fedora/fedora-secondary/releases/18/Fedora/armhfp/os/
mirrorlist = None
So it does find the correct URL, although the mirrorlist value is still 'None' at that point. If I use a baseurl in place of the mirrorlist in the kickstart file I still get the same results.
If I run the same basic setup on an f18 x86_64 box it works, since it finds the things it needs in fedora-bluesky (primary architecture).
Please let me know if you need more information on this issue, or if you have any recommendations for me to try to help debug it. We have an ARM system in the Huntsville boardfarm set up to test and debug this issue.
Created attachment 696616 [details]
livemedia-creator log snippets for F18
I have been doing some additional testing on this, and found that the latest version is not really 'hung', but instead waiting on keyboard input. I found that when it appears to be hung, I can press the Enter key a few times, and it will resume displaying output. Apparently the two errors I reported before are not fatal. Once the process is complete we get another traceback indicating that anaconda was unable to unmount the image:
SystemError: (32, 'umount: /mnt/sysimage: target is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))')
I also noticed that the process waits for more keyboard input at completion:
Installation complete. Press return to quit
I have included the significant portions of the log, showing the progress and errors.
Additional note: I tested the image that was created, and it boots successfully on the target board. I think if we can fix the issues mentioned in comment 10 we will be able to start using the F18 tools (anaconda and lorax) for all ARM disk image creation. Please let me know if you would like a separate BZ for each error, or if the information and logs provided here are adequate. I will assist in testing, or providing access to a test environment, if that would be helpful.
Working with the latest versions of anaconda and lorax:
I have found that livemedia-creator will sometimes work to produce images with no errors until the unmount issue (Comment 10), but other times it will revert to the original errors (Comment 8) and fail to complete. The behavior is inconsistent between runs. I have been able to produce images up to six times consecutively using the same kickstart file and command line, and later in the same day have six consecutive failures with the same errors, still using the same kickstart file and command line, and on the same build host. Is it possible that something external to the system (a repo failure) could result in anaconda using the wrong (default) repos?
Please let me know if you need any additional information.
anaconda-19.23-1.fc19 has been submitted as an update for Fedora 19.
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-19.23-1.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
anaconda-19.24-1.fc19 has been submitted as an update for Fedora 19.
anaconda-19.24-1.fc19, python-blivet-0.12-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.