Bug 1015053

Summary:	Unable to boot a fresh installed F20-Beta-TC1
Product:	[Fedora] Fedora	Reporter:	Joachim Backes <joachim.backes>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	amulhern, anaconda-maint-list, dshea, g.kaviyarasu, joachim.backes, jonathan, mkolman, sbueno, vanmeeuwen+fedora, vpodzime
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-10-17 08:24:43 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Joachim Backes 2013-10-03 11:32:47 UTC

Description of problem:
I installed F20-Beta TC1 in VirtualBox, without UEFI flag (own
partitioning, x86_64, booting from netinst.iso) flawlessly. The
installed system hangs on boot, only a black screen. Running the iso in
troubleshooting mode and (re)writing the grub2 boot record was
possible. But still no boot possible (grub2 does not present any
bootable system, only a command prompt).

output of the mount command (in the rescue shell):

/dev/sda1 on / type ext4 (rw,relatime,seclabel,data=ordered)
devtmpfs on /dev type devtmpfs
(rw,nosuid,seclabel,size=362692k,nr_inodes=90673,mode=755)
devpts on /dev/pts type devpts
(rw,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,relatime,seclabel)
/dev/sda2 on /home type ext4 (rw,relatime,seclabel,data=ordered)
proc on /proc type proc (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
sysfs on /sys type sysfs (rw,relatime,seclabel)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)

/etc/fstab:

#
# /etc/fstab
# Created by anaconda on Thu Oct  3 07:32:42 2013
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=e5ac9be3-0ff9-4478-8f6a-f13ae1dfcdcf /                       ext4
  defaults        1 1
UUID=e70ba418-deb0-4af1-83fc-6e3ded10dd57 /home                   ext4
  defaults        1 2
UUID=a892fae8-4a5a-487e-9927-8f3d1e0f3fa0 swap                    swap
  defaults        0 0


Version-Release number of selected component (if applicable):
F20-Beta-TC1

How reproducible:
always

Steps to Reproduce:
1.see description
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Joachim Backes 2013-10-08 16:43:37 UTC

Still the same effect with TC2!

But if booting into runlevel 3, this is possible. Then logging in as root and starting "init 5" will present the graphical GDM login! After have logged in, gnome-shell runs.

Comment 2 Vratislav Podzimek 2013-10-16 13:57:14 UTC

If booting into runlevel 3 works, it's probably not an anaconda issue. It seems like the X server fails to start or something like that.

What exactly happens if you try to boot to runlevel 5 (default)?

Comment 3 Joachim Backes 2013-10-17 06:08:35 UTC

Booting F20-Beta-TC4 in VirtualBox VM boots fine, both with and without explicit given runlevel (5 for example) as kernel boot parameter.

So I think the described effect is only a buggy behaviour of TC1 or TC2.

You may close the BZ.