Bug 725566 - firstboot doesn't default to enabled after rawhide/F16 install
Summary: firstboot doesn't default to enabled after rawhide/F16 install
Alias: None
Product: Fedora
Classification: Fedora
Component: firstboot
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Martin Gracik
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F16Alpha, F16AlphaBlocker
TreeView+ depends on / blocked
Reported: 2011-07-25 20:51 UTC by James Laska
Modified: 2013-09-02 06:57 UTC (History)
7 users (show)

Fixed In Version: firstboot-16.1-2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-08-04 03:33:44 UTC

Attachments (Terms of Use)

Description James Laska 2011-07-25 20:51:17 UTC
Description of problem:

firstboot isn't enabled after a default install.  It seems that F15 versions of firstboot enabled themselves in %scripts (unless I'm reading the f15 %scripts wrong).  However, this support doesn't exist in the current F16 package (from what I can tell).

Version-Release number of selected component (if applicable):
* firstboot-16.1-1.fc16

Steps to Reproduce:
1. Install a default package set of rawhide/F16 from http://serverbeach1.fedoraproject.org/pub/alt/stage/20110721-3/
Actual results:

firstboot never starts

Expected results:

firstboot-graphical.service should be enabled after a default graphical install

Additional info:

If the firstboot package doesn't enable itself by default, should anaconda be responsible for turning it on?

diff --git a/pyanaconda/packages.py b/pyanaconda/packages.py
index a2c061c..1e4c3c9 100644
--- a/pyanaconda/packages.py
+++ b/pyanaconda/packages.py
@@ -57,6 +57,8 @@ def firstbootConfiguration(anaconda):
         f = open(anaconda.rootPath + '/etc/sysconfig/firstboot', 'w+')
+    elif anaconda.firstboot == FIRSTBOOT_DEFAULT:
+        # FIXME - run `systemctl enable firstboot-graphical.service` ?

Comment 1 Tim Flink 2011-07-28 20:50:37 UTC
This pretty clearly hits the following F16 alpha release criterion:

In most cases, 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. 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.

+1 alpha blocker

I am curious if this bug is related to the fix for bug 723526.

Comment 2 James Laska 2011-07-29 16:50:18 UTC
Confirmed fix with firstboot-16.1-2.fc16.  This package wasn't in the rawhide
repo and needed to be downloaded and tested manually.  

Let's keep this open until we are certain that firstboot is in a branched f16

Comment 3 James Laska 2011-07-29 17:19:17 UTC
(In reply to comment #2)
> Let's keep this open until we are certain that firstboot is in a branched f16
> compose.

Moved to VERIFIED.  Can move to CLOSED once TC1 is available

Comment 4 Tim Flink 2011-07-29 17:23:13 UTC
Discussed in the 2011-07-29 blocker review meeting. Accepted as F16 alpha blocker due to violation of criteria listed in comment #1.


Comment 5 Adam Williamson 2011-08-04 00:54:19 UTC
James, can you confirm the fix in TC1 and close the bug? Thanks.

Comment 6 Adam Williamson 2011-08-04 03:33:44 UTC
Just tested TC1. Firstboot correctly ran on the first boot after install, and did not run on the second. I'd say this is OK to close.

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