Bug 958436 - Fedora 19 Beta TC1 install images do not boot correctly - fall to an emergency shell
Summary: Fedora 19 Beta TC1 install images do not boot correctly - fall to an emergenc...
Keywords:
Status: CLOSED DUPLICATE of bug 956241
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 19
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F19Beta, F19BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2013-05-01 13:12 UTC by Mukundan Ragavan
Modified: 2013-05-01 18:34 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-01 18:34:58 UTC
Type: Bug


Attachments (Terms of Use)
sosreport.txt (50.96 KB, text/plain)
2013-05-01 13:12 UTC, Mukundan Ragavan
no flags Details
/run/initramfs/sosreport.txt (97.83 KB, text/plain)
2013-05-01 15:08 UTC, John Reiser
no flags Details

Description Mukundan Ragavan 2013-05-01 13:12:04 UTC
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.

Comment 1 Andre Robatino 2013-05-01 14:21:19 UTC
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.)

Comment 2 Orion Poplawski 2013-05-01 15:04:26 UTC
Me too - koan/kvm and koan --replace-self.

Comment 3 John Reiser 2013-05-01 15:08:20 UTC
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

Comment 4 satellitgo 2013-05-01 15:09:52 UTC
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

Comment 5 Andre Robatino 2013-05-01 15:44:19 UTC
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.)

Comment 6 Andre Robatino 2013-05-01 15:46:04 UTC
Also note that the potential_conflict.py script used in the test has not changed since last year.

Comment 7 Bill Nottingham 2013-05-01 16:08:46 UTC
It uses yum, so I'd start the bug report there.

Comment 8 Mukundan Ragavan 2013-05-01 17:14:04 UTC
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

Comment 9 Orion Poplawski 2013-05-01 17:16:17 UTC
Can we please stop hijacking this bug for the conflict issue?

Comment 10 Andre Robatino 2013-05-01 17:28:42 UTC
Thanks to nonamedotc's test, I filed bug 958512 for the file conflicts issue. Will also add his result to the test matrix.

Comment 11 Adam Williamson 2013-05-01 18:34:58 UTC
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 ***


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