Red Hat Bugzilla – Bug 967617
initial-setup needs to run again if not completed
Last modified: 2013-06-23 02:25:47 EDT
Description of problem: on fedora 19 beta for arm initial-setup was killed in the middle of being run by X crashing. when X restarted lightdm ran but not initial-setup. rebooting the host still did not result in initial-setup being run, the result was that the machine was not able to be accessed. for arm we make disk images, root is locked and the only way to get into the machine is to setup a user or root passwd via initial-setup.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Are you sure you mean initial-setup? If this was a GNOME install you want this filed against gnome-initial-setup . Just making sure as others have made this mistake.
If you saw a GNOME-ish wizard interface, that was gnome-initial-setup. If you saw what looked like anaconda newUI, that was initial-setup. The two are entirely different codebases maintained by different people. Please check and confirm which has the bug. Thanks!
hum, actually, the reference to 'lightdm' suggests this wasn't likely GNOME, so initial-setup is probably correct, unsetting needinfo.
this was a xfce install
Ok, so the problem here is that initial-setup-*.service have "Type=oneshot", which means that if the user cancels them (by pressing the quit button), or they crash they will still get disabled by systemd
Fixing this is easy, give them a none oneshot Type and then add a conditional to only start if a certain file does not exist.
Let say we use /etc/sysconfig/initial-setup-done as file, then one can test in the .service files for this like this:
And when the file exists the service will no longer start, then at the end of initial-setup *after* having done everything else touch this file, and we've created our own oneshot version which works as we want it to.
That's more or less how firstboot did it. But it is kind of a hack. Maybe we should request a new systemd service type...
(In reply to Adam Williamson from comment #5)
> That's more or less how firstboot did it. But it is kind of a hack. Maybe we
> should request a new systemd service type...
Hmm, interesting idea, we could have a type where systemd keeps starting it at boot, until it exits with 0. This assumes that it will never exit with 0 on a crash, but that seems a safe assumption.
Still if we want to fix this for F-19, we only have 9 days left, and that includes the time we need to gather feedback in bodhi, so I suggest we go for the suggested solution for F-19, and then we can do a systemd RFE for fixing this less hackish later.
Yup, that's pretty much exactly what I was thinking.
Guys, I'm afraid the problem is somewhere else. According to 'man systemd.service':
"Behaviour of 'oneshot' is similar to 'simple', however it is expected that the process has to exit before systemd starts follow-up units. RemainAfterExit= is particularly useful for this type of service."
The real problem seems to be in this line of initial-setup-*'s service files:
ExecStartPost=/bin/systemctl disable initial-setup-graphical.service initial-setup-text.service
which means, that the service is disabled right after it is started instead of on a successful exit. However, it seems that there is no way to specify a command that should be executed only on successful exit or only on failure (any would be sufficient), so there are two ways to fix this issue:
1) the hack with the file
2) moving '/bin/systemctl disable initial-setup-graphical.service initial-setup-text.service' invocation to the end of the script running the initial-setup
I'm for number 2, any ideas or other suggestions?
Created attachment 760091 [details]
This is what I'd do to fix the issue.
#2 seems reasonable, again, I think that's what firstboot did (only disabled itself at the very end).
Slightly tweaked version of the attached patch was pushed to master.
initial-setup-0.3.6-2.fc19 has been submitted as an update for Fedora 19.
Looks fixed; if I reboot with i-s still running, i-s comes up again.
initial-setup-0.3.6-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.