Bug 967617 - initial-setup needs to run again if not completed
initial-setup needs to run again if not completed
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: initial-setup (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Vratislav Podzimek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-27 11:38 EDT by Dennis Gilmore
Modified: 2013-06-23 02:25 EDT (History)
4 users (show)

See Also:
Fixed In Version: initial-setup-0.3.6-2.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-23 02:25:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed patch (1.75 KB, patch)
2013-06-12 07:04 EDT, Vratislav Podzimek
no flags Details | Diff

  None (edit)
Description Dennis Gilmore 2013-05-27 11:38:06 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):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Adam Williamson 2013-05-27 20:36:21 EDT
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!
Comment 2 Adam Williamson 2013-05-27 20:37:09 EDT
hum, actually, the reference to 'lightdm' suggests this wasn't likely GNOME, so initial-setup is probably correct, unsetting needinfo.
Comment 3 Dennis Gilmore 2013-05-27 20:58:04 EDT
this was a xfce install
Comment 4 Hans de Goede 2013-06-08 17:59:09 EDT
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:

ConditionPathExists=!/etc/sysconfig/initial-setup-done

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.
Comment 5 Adam Williamson 2013-06-08 20:33:52 EDT
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...
Comment 6 Hans de Goede 2013-06-09 02:25:11 EDT
(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.
Comment 7 Adam Williamson 2013-06-09 02:36:05 EDT
Yup, that's pretty much exactly what I was thinking.
Comment 8 Vratislav Podzimek 2013-06-12 06:58:30 EDT
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?
Comment 9 Vratislav Podzimek 2013-06-12 07:04:58 EDT
Created attachment 760091 [details]
proposed patch

This is what I'd do to fix the issue.
Comment 10 Adam Williamson 2013-06-12 14:05:41 EDT
#2 seems reasonable, again, I think that's what firstboot did (only disabled itself at the very end).
Comment 11 Vratislav Podzimek 2013-06-18 08:22:21 EDT
Slightly tweaked version of the attached patch was pushed to master.
Comment 12 Fedora Update System 2013-06-18 14:54:24 EDT
initial-setup-0.3.6-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/initial-setup-0.3.6-2.fc19
Comment 13 Adam Williamson 2013-06-18 21:25:52 EDT
Looks fixed; if I reboot with i-s still running, i-s comes up again.
Comment 14 Fedora Update System 2013-06-23 02:25:47 EDT
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.

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