Bug 723526 - firstboot always runs even with RUN_FIRSTBOOT=NO in /etc/sysconfig/firstboot
firstboot always runs even with RUN_FIRSTBOOT=NO in /etc/sysconfig/firstboot
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: firstboot (Show other bugs)
rawhide
Unspecified Linux
unspecified Severity high
: ---
: ---
Assigned To: Martin Gracik
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F16Alpha/F16AlphaBlocker
  Show dependency treegraph
 
Reported: 2011-07-20 09:09 EDT by Andre Robatino
Modified: 2013-07-04 08:57 EDT (History)
7 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Andre Robatino 2011-07-20 09:09:09 EDT
Description of problem:
After the 20110720 Rawhide updates, including firstboot-16.0-2.fc16.x86_64, firstboot insists on running all the time. It first appeared in the middle of the yum update itself. Logging out and back in, or rebooting, doesn't get rid of it.

Version-Release number of selected component (if applicable):
firstboot-16.0-2.fc16.x86_64

How reproducible:
always
Comment 1 James Laska 2011-07-22 11:59:42 EDT
Proposing as an F16 Alpha blocker per the following Alpha release criteria [1]

  "Following on from the previous criterion, after firstboot is completed and on subsequent boots, 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 a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied "

[1] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria
Comment 2 Andre Robatino 2011-07-22 14:09:56 EDT
Additional info: my Rawhide was installed around 15 Alpha TC2, so don't know if this happens on a clean install. I plan to attempt a clean install of 16 Alpha TC1 and upgrade that to Rawhide.
Comment 3 Tim Flink 2011-07-22 17:45:02 EDT
Discussed during the 2011-07-22 blocker bug review meeting. In order to determine whether or not this is an alpha blocker, we need to know whether this is happening on fresh installs or just upgrades.

It will be revisited at the next meeting.
Comment 4 Andre Robatino 2011-07-24 08:26:57 EDT
Is there any fix for this for a non-clean install? It's been suggested that the firstboot service needs to be disabled, but there appears to be no such service on Rawhide (though I see it on F15, disabled). I'm also curious what is the proposed fix related to the "POST" Status. If it's not actually in Rawhide yet, then any Rawhide install would be affected.
Comment 5 Paul Bolle 2011-07-24 18:42:27 EDT
(In reply to comment #4)
> Is there any fix for this for a non-clean install? It's been suggested that the
> firstboot service needs to be disabled, but there appears to be no such service
> on Rawhide (though I see it on F15, disabled).

0) Combining "The Three Levels of "Off"" ( http://0pointer.de/blog/projects/three-levels-of-off.html ) with a list of firstboot's two systemd files (see for example http://koji.fedoraproject.org/koji/rpminfo?rpmID=2621374 ) the solution is to create these two symbolic links to /dev/null:
    /etc/systemd/system/firstboot-graphical.service
    /etc/systemd/system/firstboot-text.service

1) This is, of course, forces one to boot into another system (as firstboot makes normal login impossible) to edit ones Rawhide system from that system. (In my case I used some live image. But maybe firstboot still allows regular login over ssh ...) All this is nothing people running Rawhide may complain about, but it is unacceptable for people doing a regular live upgrade (eg, from F15 to F16). Or are only fresh installs supported?
Comment 6 Andre Robatino 2011-07-24 19:24:10 EDT
Thanks! I was able to go to VT #2 and run

ln -s /dev/null /etc/systemd/system/firstboot-graphical.service
ln -s /dev/null /etc/systemd/system/firstboot-text.service

which fixed it.
Comment 7 Paul Bolle 2011-07-24 20:11:16 EDT
(In reply to comment #6)
> Thanks! I was able to go to VT #2 [...]

For some reason I was unable to do that. Assuming that was my fault, this makes this situation slightly less severe.
Comment 8 Andre Robatino 2011-07-24 20:22:33 EDT
(In reply to comment #7)
> (In reply to comment #6)
> > Thanks! I was able to go to VT #2 [...]
> 
> For some reason I was unable to do that. Assuming that was my fault, this makes
> this situation slightly less severe.

There's also rescue mode, if the VT doesn't work. Sometimes I'm forced to use that, but in this case I was lucky since the VT seemed to work reliably (I was using it to do yum updates while unable to log in graphically.)
Comment 9 Andre Robatino 2011-07-25 09:39:55 EDT
Removed the symlinks I created in comment 6, then updated to

http://koji.fedoraproject.org/koji/buildinfo?buildID=255351

and verified that the new firstboot runs if and only if RUN_FIRSTBOOT is set to YES in /etc/sysconfig/firstboot. So hopefully firstboot-16.1-1.fc16 can be included in 16 Alpha TC1.
Comment 10 Martin Gracik 2011-07-25 10:00:26 EDT
Thanks for testing, but just to clarify things.

It shouldn't run if and only if RUN_FIRSTBOOT=YES is in /etc/sysconfig/firstboot.

It should run always, except if there's RUN_FIRSBOOT=NO in /etc/sysconfig/firstboot. If there's anything else in the file ("yes", "1", "on" or whatever), or the file does not exist at all, firstboot should run.

I hope I'm not confusing anyone.
Comment 11 Andre Robatino 2011-07-25 10:21:29 EDT
Sorry, my fault. I was thinking boolean and only checked "YES" and "NO" and didn't test what happened if the file was removed. Just verified that if I rename the file as "firstboot.tmp", firstboot runs.
Comment 12 Tim Flink 2011-07-28 16:44:43 EDT
Reading through the comments, it sounds like this has been fixed but hasn't been included in any of the composes yet. Can anyone confirm that?
Comment 13 James Laska 2011-07-29 08:55:36 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 compose.
Comment 14 James Laska 2011-07-29 12:49:56 EDT
Apologies, comment#13 is intended for another firstboot bug report
Comment 15 Tim Flink 2011-07-29 13:18:37 EDT
Discussed in the 2011-07-29 blocker review meeting. Moving to verified, this bug will be closed once tested with the TC1 compose.
Comment 16 Adam Williamson 2011-08-03 20:49:00 EDT
James, can you confirm the fix in TC1 and close this? Thanks.
Comment 17 Adam Williamson 2011-08-03 23:37:40 EDT
Tested TC1. Post-install, firstboot correctly runs just once and then not on subsequent boots. /etc/sysconfig/firstboot contents are correct, and firstboot services are disabled; even if I manually enable firstboot-graphical.service , the contents of /etc/sysconfig/firstboot correctly prevent firstboot from running. So AFAICT all is correct here and there are no Alpha blockers; closing.
Comment 18 James Laska 2011-08-04 07:26:48 EDT
(In reply to comment #17)
> So AFAICT all is correct here and there are no Alpha blockers;
> closing.

confirmed, agreed

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