Hide Forgot
Description of problem: It shouldn't. Version-Release number of selected component (if applicable): firstboot-1.112-3.fc14.x86_64 systemd-7-3.fc14.x86_64 systemd-units-7-3.fc14.x86_64 How reproducible: Happened just now. Steps to Reproduce: 1. Have an up-to-date F-13 install 2. Upgrade to F14 + updates-testing Actual results: firstboot runs on reboot Expected results: firstboot does not run on reboot.
I could not reproduce this. I did a fresh install of F13+updates. firstboot was run, /etc/sysconfig/firstboot was created. Then I upgraded to F14+updates-testing with yum. Rebooted. firstboot did not run again.
As I tried to explain this to Lennart, I think I can guess what happened here. How firstboot gets run is via a 'firstboot' service which is installed in the package. It just starts up and checks if /etc/sysconfig/firstboot exists and contains RUN_FIRSTBOOT=NO . If that's the case, the service just does nothing and shuts down. If that's not the case, it calls the actual firstboot app. Once firstboot has been successfully run, it tries to disable itself for the future. In F13 and earlier, to do this, it does: chkconfig off firstboot echo RUN_FIRSTBOOT=NO > /etc/sysconfig/firstboot (more or less, the exact commands aren't the same but that's what it does; disable the service *and* create the config file that tells the service not to run firstboot itself). Now, for Fedora 14, we migrated firstboot to be systemd native. Instead of one sysv service, it now has two systemd services - firstboot-text.service and firstboot-graphical.service . Obviously, since F13 and earlier didn't have these, firstboot doesn't do anything to turn them off once it's been run successfully. It does in F14, but that's a moot point. So when you upgrade from an earlier release of Fedora to F14, those two systemd services get installed and enabled. So when you first boot up your shiny new F14 system, the firstboot service is now enabled; this is different from earlier releases, where it would still be disabled after the update. Usually, firstboot-the-app should still not run; the service should see the /etc/sysconfig/firstboot file contains RUN_FIRSTBOOT=NO and not run firstboot-the-app. I suspect this is what Michal saw in his test. I suspect what happened in Bill's case is that /etc/sysconfig/firstboot somehow got deleted, so firstboot went ahead and ran. This is just surmise at this point, but that's the difference I can think of in F14. In a way it's a regression, but OTOH, I don't think it should trigger unless you've done something you shouldn't have (wiped /etc/sysconfig/firstboot ).
I don't think we still have a text mode firstboot, do we?
not exactly, but it runs some kind of system-config-foobar front end. It's not hugely useful - as far as I can see, it doesn't actually contain any way to create a user account, which would likely be the number 1 thing you'd want to do - but it's there. Try a text install and see. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I suppose one way to address this would be for the firstboot package to disable the services if it's being updated, rather than initially installed. Can anyone see any problems with that? I can't see there being any practical case where you'd update the firstboot package before actually running firstboot (and still actually want firstboot to run). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Ping
this won't be a problem for F14, since we're not going with systemd any more. it'll be the case for F15, though. bumping to rawhide. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Fixed in firstboot-1.115-1