Red Hat Bugzilla – Full Text Bug Listing
|Summary:||livemedia-creator appears to hang when using --novirt and --image-only|
|Product:||[Fedora] Fedora||Reporter:||D. Marlin <dmarlin>|
|Component:||lorax||Assignee:||Brian Lane <bcl>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||18||CC:||anaconda-maint-list, bcl, blc, jdulaney, pbrobinson|
|Fixed In Version:||anaconda-19.24-1.fc19||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-05-21 23:16:26 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description D. Marlin 2013-01-14 17:55:30 EST
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): lorax-18.29-1.fc18 How reproducible: Consistently Steps to Reproduce: 1. Run livemedia-creator on an F18 ARM host: livemedia-creator \ --make-disk --no-virt --image-only --keep-image \ --armplatform=None \ --ks=F18-vexpress-mate.ks 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. Actual results: Logs attached. Expected results: Runs to completion. Additional info: This was run on and F18 Arm HighBank host. The kickstart file used is also attached.
Comment 5 Brendan Conoboy 2013-02-01 11:03:36 EST
Hey Brian, what do we need to do to advance this issue? Any pointers for diagnostics?
Comment 6 Brian Lane 2013-02-01 12:09:48 EST
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-*
Comment 7 Fedora Admin XMLRPC Client 2013-02-04 10:05:09 EST
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Comment 8 D. Marlin 2013-02-11 17:18:30 EST
I have tried running livemedia-creator again with the following versions installed: anaconda-18.37.12-1.fc18.armv7hl lorax-18.30-1.fc18.armv7hl pykickstart-1.99.22-1.fc18.noarch 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: https://bugzilla.redhat.com/show_bug.cgi?id=867591 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. url --url="http://intranet.ges.redhat.com/es/Fedora/fedora-secondary/releases/18/Fedora/armhfp/os/" repo --name=fedora --mirrorlist="http://mirrors.fedoraproject.org/metalink?repo=fedora-18&arch=armhfp" The command I use is: livemedia-creator \ --make-disk --no-virt --image-only --keep-image \ --armplatform=tegra \ --ks=<PathToKickstarts>/F18-trimslice-test.ks 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.
Comment 9 D. Marlin 2013-02-12 15:36:45 EST
Created attachment 696616 [details] livemedia-creator log snippets for F18
Comment 10 D. Marlin 2013-02-12 15:37:59 EST
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.
Comment 11 D. Marlin 2013-02-13 11:59:49 EST
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.
Comment 12 D. Marlin 2013-02-28 15:42:05 EST
Working with the latest versions of anaconda and lorax: anaconda-18.37.12-1.fc18 lorax-18.31-1.fc18 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.
Comment 13 Fedora Update System 2013-04-30 08:21:52 EDT
anaconda-19.23-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/anaconda-19.23-1.fc19
Comment 14 Fedora Update System 2013-04-30 16:00:14 EDT
Package anaconda-19.23-1.fc19: * 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: https://admin.fedoraproject.org/updates/FEDORA-2013-7049/anaconda-19.23-1.fc19 then log in and leave karma (feedback).
Comment 15 Fedora Update System 2013-05-03 17:04:57 EDT
anaconda-19.24-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/anaconda-19.24-1.fc19
Comment 16 Fedora Update System 2013-05-21 23:16:26 EDT
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.