Bug 853415

Summary:	firstboot isn't installed and run during first boot
Product:	[Fedora] Fedora	Reporter:	Petr Schindler <pschindl>
Component:	comps	Assignee:	Bill Nottingham <notting>
Status:	CLOSED ERRATA	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	18	CC:	awilliam, dan.mashal, g.kaviyarasu, johannbg, jonathan, kparal, reklov, robatino, rvokal, vanmeeuwen+fedora
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	AcceptedBlocker
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-09-12 19:42:39 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:
Bug Depends On:
Bug Blocks:	752654

Description Petr Schindler 2012-08-31 13:07:36 UTC

Description of problem:
firstboot isn't installed and run during first boot - so no user is created. There is no user which could be used after system start (if user didn't set root password).

This happens with Gnome desktop installation.

Version-Release number of selected component (if applicable):
Fedora-18-Alpha-TC4-x86_64-DVD.iso
anaconda-18.6.4

How reproducible:
always

Steps to Reproduce:
1. boot, choose language
2. choose some mirror in installation source
3. choose Gnome desktop in software selection
4. choose default disk layout
5. continue to the installation
6. reboot
  
Actual results:
firstboot doesn't run and it is no installed

Expected results:
firstboot is installed and run during first boot

Additional info:
I propose this bug as alpha blocker due to criterion:
'In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied. The firstboot utility must be able to create a working user account'

Comment 1 Chris Lumens 2012-08-31 14:13:40 UTC

firstboot is part of the base-x group, which does not appear to be listed in the grouplist for any environment in comps.  I think that's where this needs to be fixed.  anaconda never selected firstboot in the past.

Comment 2 Bill Nottingham 2012-08-31 16:37:59 UTC

Fixed in comps.

Comment 3 Bill Nottingham 2012-08-31 21:02:23 UTC

*** Bug 853557 has been marked as a duplicate of this bug. ***

Comment 4 Adam Williamson 2012-08-31 23:07:39 UTC

+1 blocker per criterion cited in report.

Comment 5 Jóhann B. Guðmundsson 2012-09-01 17:46:57 UTC

Still present on TC-5

Comment 6 Adam Williamson 2012-09-04 19:48:42 UTC

johann: TC5 was built before the comps change had propagated (it takes several hours after a change to comps before a compose will reflect it), as dennis didn't have time to wait before doing the compose. next compose will have the fix.

Comment 7 Adam Williamson 2012-09-05 16:25:41 UTC

Discussed at 2012-09-05 blocker review meeting. Accepted as a blocker per criterion cited in original report.

Comment 8 Kamil Páral 2012-09-07 11:18:21 UTC

Due to bug 855310 I can't really check whether this is fixed in Alpha TC6.

Comment 9 Dan Mashal 2012-09-08 01:28:09 UTC

This is fixed at least on pretc7-1 netinstall. Will test with DVD

Comment 10 Kamil Páral 2012-09-11 18:49:42 UTC

This is fixed with F18 Alpha RC2.

Comment 11 Adam Williamson 2012-09-12 19:42:39 UTC

Then it can be closed, since it was a comps bug - no update to push.