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
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
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.
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.
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.
(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?
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.
(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.
(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.)
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.
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.
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.
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?
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.
Apologies, comment#13 is intended for another firstboot bug report
Discussed in the 2011-07-29 blocker review meeting. Moving to verified, this bug will be closed once tested with the TC1 compose.
James, can you confirm the fix in TC1 and close this? Thanks.
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.
(In reply to comment #17) > So AFAICT all is correct here and there are no Alpha blockers; > closing. confirmed, agreed