Created attachment 742189 [details] sosreport.txt Description of problem: I tried to boot Fedora 19 x86_64 Beta TC1 netinstall iso on Virtualbox VM. This is the same VM that I used many times to test Alpha TCs to release. When I boot the iso, I do not proceed to get anaconda, but the system falls in to an emergency shell with the message "Entering emergency shell ...... " It also produced a log file sosreport.txt (attached). Version-Release number of selected component (if applicable): Fedora 19 x86_64 Beta TC1 How reproducible: Always Steps to Reproduce: 1. Boot netinstall iso. Actual results: Falls to an emergency shell. Expected results: Start anaconda. Additional info: I do not know if systemd is the correct component. Checksum: ok Media check done the image: ok. If any other log file is needed, please let me know.
Confirmed on i386 and x86_64 DVD and netinst (using KVM). Automatic Blocker by https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Automatic_blockers : "Complete failure of any release-blocking TC/RC image to boot at all under any circumstance - "DOA" image (conditional failure is not an automatic blocker) ". (Not sure how much independent checking is necessary for this to qualify.)
Me too - koan/kvm and koan --replace-self.
Created attachment 742239 [details] /run/initramfs/sosreport.txt Removing " quiet" from the end of the kernel boot command line, and using USB2.0 boot (livecd-iso-to-disk of full DVD) on real hardware: Warning: /dev/root does not exist Generating "/run/initramfs/sosreport.txt
1-)confirmed here in virtualBox for both arches of netinstall and i386 DVD. 2_) dd if=Fedora-19-Beta-TC1-x86_64-netinst.iso of=/dev/sdc bs=2M confirmed on bare metal
Don't know if it's relevant, but https://fedoraproject.org/wiki/QA:Testcase_Mediakit_FileConflicts , which normally takes me negligible resources and a few seconds to complete, is now a supercomputing benchmark. I had no trouble with previous DVD composes, even though they were about the same size. It now takes up almost all CPU and eventually sucks up all RAM as well. I only have 4 GiB, can someone with more try to complete it? (I didn't file a separate bug since I didn't know what component to file under or even if it is a bug. But thought there was a chance it was connected to this.)
Also note that the potential_conflict.py script used in the test has not changed since last year.
It uses yum, so I'd start the bug report there.
For whatever it is worth, # python potential_conflict.py --repofrompath=media,/mnt/temp -r media Getting complete filelist for: file:///mnt/temp/ 552456 files found. Looking for duplicated filenames: 5292 duplicates found. Doing more advanced checks to see if these are real conflicts: 5% complete ( 264/ 5292, 8/sec), 0 found - eta 0:09:51 10% complete ( 528/ 5292, 8/sec), 0 found - eta 0:09:26 15% complete ( 792/ 5292, 9/sec), 0 found - eta 0:08:41 20% complete ( 1056/ 5292, 8/sec), 1 found - eta 0:08:12 25% complete ( 1320/ 5292, 8/sec), 1 found - eta 0:07:40 30% complete ( 1584/ 5292, 8/sec), 2 found - eta 0:07:09 35% complete ( 1848/ 5292, 8/sec), 3 found - eta 0:06:38 40% complete ( 2112/ 5292, 8/sec), 3 found - eta 0:06:07 45% complete ( 2376/ 5292, 8/sec), 3 found - eta 0:05:37 50% complete ( 2640/ 5292, 9/sec), 3 found - eta 0:05:05 55% complete ( 2904/ 5292, 8/sec), 3 found - eta 0:04:34 60% complete ( 3168/ 5292, 8/sec), 3 found - eta 0:04:03 65% complete ( 3432/ 5292, 8/sec), 4 found - eta 0:03:32 70% complete ( 3696/ 5292, 8/sec), 6 found - eta 0:03:02 75% complete ( 3960/ 5292, 9/sec), 6 found - eta 0:02:31 80% complete ( 4224/ 5292, 8/sec), 6 found - eta 0:02:01 85% complete ( 4488/ 5292, 9/sec), 6 found - eta 0:01:31 90% complete ( 4752/ 5292, 8/sec), 9 found - eta 0:01:01 95% complete ( 5016/ 5292, 8/sec), 10 found - eta 0:00:31 100% complete ( 5280/ 5292, 8/sec), 10 found - eta 0:00:01 10 file conflicts found. 3 package conflicts found. == Package conflicts == 1:mariadb-5.5.30-1.fc19.x86_64 community-mysql-5.5.30-5.fc19.x86_64 2:libpng-devel-1.5.13-2.fc19.x86_64 libpng12-devel-1.2.50-3.fc19.x86_64 1:mariadb-server-5.5.30-1.fc19.x86_64 community-mysql-server-5.5.30-5.fc19.x86_64 == File conflicts, listed by conflicting packages == python-django-1.4.5-2.fc19.noarch python-django14-1.4.5-5.fc19.noarch /usr/lib/python2.7/site-packages/django/contrib/humanize/models.pyc /usr/lib/python2.7/site-packages/django/contrib/humanize/models.pyo /usr/lib/python2.7/site-packages/django/contrib/markup/models.pyc /usr/lib/python2.7/site-packages/django/contrib/markup/models.pyo /usr/lib/python2.7/site-packages/django/contrib/staticfiles/models.pyc /usr/lib/python2.7/site-packages/django/contrib/staticfiles/models.pyo /usr/lib/python2.7/site-packages/django/contrib/webdesign/models.pyc /usr/lib/python2.7/site-packages/django/contrib/webdesign/models.pyo /usr/lib/python2.7/site-packages/django/utils/simplejson/__init__.pyc /usr/lib/python2.7/site-packages/django/utils/simplejson/__init__.pyo
Can we please stop hijacking this bug for the conflict issue?
Thanks to nonamedotc's test, I filed bug 958512 for the file conflicts issue. Will also add his result to the test matrix.
bcl says this is probably 956241: we need to re-spin with a newer lorax. I'm on it. *** This bug has been marked as a duplicate of bug 956241 ***