|Summary:||firstboot always runs even with RUN_FIRSTBOOT=NO in /etc/sysconfig/firstboot|
|Product:||[Fedora] Fedora||Reporter:||Andre Robatino <robatino>|
|Component:||firstboot||Assignee:||Martin Gracik <mgracik>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||awilliam, bcl, dmach, jlaska, mgracik, pebolle, tflink|
|Fixed In Version:||firstboot-16.1-2.fc16||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-08-04 03:37:40 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Andre Robatino 2011-07-20 13:09:09 UTC
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 15:59:42 UTC
Proposing as an F16 Alpha blocker per the following Alpha release criteria  "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 "  https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria
Comment 2 Andre Robatino 2011-07-22 18:09:56 UTC
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 21:45:02 UTC
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 12:26:57 UTC
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 22:42:27 UTC
(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 23:24:10 UTC
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-25 00:11:16 UTC
(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-25 00:22:33 UTC
(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 13:39:55 UTC
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 14:00:26 UTC
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 14:21:29 UTC
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 20:44:43 UTC
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 12:55:36 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 compose.
Comment 14 James Laska 2011-07-29 16:49:56 UTC
Apologies, comment#13 is intended for another firstboot bug report
Comment 15 Tim Flink 2011-07-29 17:18:37 UTC
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-04 00:49:00 UTC
James, can you confirm the fix in TC1 and close this? Thanks.
Comment 17 Adam Williamson 2011-08-04 03:37:40 UTC
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.