Bug 967617 - initial-setup needs to run again if not completed
Summary: initial-setup needs to run again if not completed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: initial-setup
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vratislav Podzimek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-27 15:38 UTC by Dennis Gilmore
Modified: 2013-06-23 06:25 UTC (History)
4 users (show)

Fixed In Version: initial-setup-0.3.6-2.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-06-23 06:25:47 UTC
Type: Bug
Embargoed:


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

Description Dennis Gilmore 2013-05-27 15:38:06 UTC
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-28 00:36:21 UTC
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-28 00:37:09 UTC
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-28 00:58:04 UTC
this was a xfce install

Comment 4 Hans de Goede 2013-06-08 21:59:09 UTC
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-09 00:33:52 UTC
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 06:25:11 UTC
(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 06:36:05 UTC
Yup, that's pretty much exactly what I was thinking.

Comment 8 Vratislav Podzimek 2013-06-12 10:58:30 UTC
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 11:04:58 UTC
Created attachment 760091 [details]
proposed patch

This is what I'd do to fix the issue.

Comment 10 Adam Williamson 2013-06-12 18:05:41 UTC
#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 12:22:21 UTC
Slightly tweaked version of the attached patch was pushed to master.

Comment 12 Fedora Update System 2013-06-18 18:54:24 UTC
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-19 01:25:52 UTC
Looks fixed; if I reboot with i-s still running, i-s comes up again.

Comment 14 Fedora Update System 2013-06-23 06:25:47 UTC
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.