Created attachment 742189 [details]
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
Steps to Reproduce:
1. Boot netinstall iso.
Falls to an emergency shell.
I do not know if systemd is the correct component.
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]
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
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:
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 ==
== File conflicts, listed by conflicting packages ==
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 ***