Bug 725566 - firstboot doesn't default to enabled after rawhide/F16 install
firstboot doesn't default to enabled after rawhide/F16 install
Product: Fedora
Classification: Fedora
Component: firstboot (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Martin Gracik
Fedora Extras Quality Assurance
Depends On:
Blocks: F16Alpha/F16AlphaBlocker
  Show dependency treegraph
Reported: 2011-07-25 16:51 EDT by James Laska
Modified: 2013-09-02 02:57 EDT (History)
7 users (show)

See Also:
Fixed In Version: firstboot-16.1-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-08-03 23:33:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description James Laska 2011-07-25 16:51:17 EDT
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 16:50:37 EDT
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 12:50:18 EDT
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 13:19:17 EDT
(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 13:23:13 EDT
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-03 20:54:19 EDT
James, can you confirm the fix in TC1 and close the bug? Thanks.
Comment 6 Adam Williamson 2011-08-03 23:33:44 EDT
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.