Bug 922885
Summary: | make sure gnome-initial-setup.service doesn't start on LiveCD | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> |
Component: | gnome-initial-setup | Assignee: | Jasper St. Pierre <jstpierr> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | admiller, awilliam, bruno, casper, jreznik, jstpierr, kevin, mclasen, robatino, vanmeeuwen+fedora, walters |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-05-17 05:01:55 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 834090 |
Description
Kamil Páral
2013-03-18 17:50:11 UTC
I guess this is somewhat implicit AlphaBlocker, tagging as such. I think I'll do the fixed that adam proposed upstream: ConditionKernelCommandLine=!rd.live.image An alternative way to do this would be to have this in the gnome-initial-setup.service: ConditionKernelCommandLine=!rd.live.image I would like to use this neat systemd capability more widely in live image stuff, but it would require a much bigger migration to systemd... (In reply to comment #3) > An alternative way to do this would be to have this in the > gnome-initial-setup.service: > > ConditionKernelCommandLine=!rd.live.image I tried this on an installed machine (it's easier to adjust the service files there than on LiveCD) and it seems to work well. The service doesn't run when rd.live.image is on kernel cmdline. I tried to build a LiveCD with this patch, but for some reason it doesn't work:
> diff --git a/fedora-live-base.ks b/fedora-live-base.ks
> index 56e3829..cbe38fa 100644
> --- a/fedora-live-base.ks
> +++ b/fedora-live-base.ks
> @@ -186,6 +186,10 @@ systemctl --no-reload disable firstboot-graphical.service 2> /dev/null || :
> systemctl stop firstboot-text.service 2> /dev/null || :
> systemctl stop firstboot-graphical.service 2> /dev/null || :
>
> +# turn off gnome-initial-setup for livecd boots
> +systemctl --no-reload disable gnome-initial-setup.service 2> /dev/null || :
> +systemctl stop gnome-initial-setup.service 2> /dev/null || :
> +
> # don't use prelink on a running live image
> sed -i 's/PRELINKING=yes/PRELINKING=no/' /etc/sysconfig/prelink &>/dev/null || :
The gnome-initial-setup.service is still executed on LiveCD boot.
(In reply to comment #5) > I tried to build a LiveCD with this patch, but for some reason it doesn't > work: I guess the problem is that the service file just touches a file (/var/lib/gdm/run-initial-setup), which then serves as an indicator for gdm. Even if we disable and stop that service, it makes no difference if it had already started. The file probably already exists. ordering can be a pain with services on the live image and systemd parallelization; I think we have to make sure that the services we try and disable via livesys.service all are explicitly set to run after livesys.service so they can be disabled by it. Viz firstboot-graphical.service: After=livesys.service This is one of the many advantages of using ConditionKernelCommandLine, of course. There is another problem with gnome-initial-setup.service, it's missing the default [Unit] header. It needs to be there if ConditionKernelCommandLine is to work.
Temporarily, I have fixed it with this spin-kickstarts patch:
> diff --git a/fedora-live-base.ks b/fedora-live-base.ks
> index 56e3829..26508c1 100644
> --- a/fedora-live-base.ks
> +++ b/fedora-live-base.ks
> @@ -311,6 +311,9 @@ rm -f /core*
> # convince readahead not to collect
> # FIXME: for systemd
>
> +# turn off gnome-initial-setup for livecd boots
> +sed -i '1i [Unit]\nConditionKernelCommandLine=!rd.live.image' /usr/lib/systemd/system/gnome-initial-setup.service
> +
> %end
But it would be better to fix at least the header in the upstream package, or both.
Since Matthias said he's willing to incorporate the fix upstream, I'm changing the component to gnome-initial-setup.
(In reply to comment #8) > There is another problem with gnome-initial-setup.service, it's missing the > default [Unit] header. It needs to be there if ConditionKernelCommandLine is > to work. https://git.gnome.org/browse/gnome-initial-setup/commit/?id=3fba63c6699e4b33d7166bd834a03e0eded909a1 But still, if it's enabled by default, g-i-s will then (AFAIK) also run on upgrades via fedup/yum. That seems less than desirable, but on the other hand we have larger issues. I'm guessing the blocker here is just running on the live cd, so we can defer this discussion to another bug too. Colin, the service file contains this: > ExecStartPost=/usr/bin/systemctl disable gnome-initial-setup.service And the spec file contains this: > %post > if [ $1 -eq 1 ] ; then > # Initial installation > /usr/bin/systemctl enable gnome-initial-setup.service &>/dev/null || : > fi So I assume it should run just once. But I'm no packaging expert. Moving to POST because it's committed upstream. This is in g-i-s 0.8, and g-i-s 0.8 is in Fedora already (we move fast round these parts). I built several live images with 0.8 yesterday, and g-i-s definitely doesn't run on live boot. So, this is fixed: closing. g-i-s starts in Fedora-19-Nightly-20130427.11-x86_64-Live-desktop-20130427.11-1.iso FWIW - I am not sure it is such a bad thing though. Reopening. This is basically bug 953766, but we might deal with them separately - the first issue is that it automatically starts on LiveCDs, the second is that it automatically starts for existing sessions. It seems that g-i-s developers dumped systemd unit files and used /etc/xdg/autostart instead. If you boot F19 Beta TC2 Live, g-i-s is displayed _after_ the liveuser is logged in. You can just ignore the window and work normally, but it can't be closed normally (there is no X button). It can be closed from the overview mode. Why did you reopen this bug ? There is no service file in gnome-initial-setup anymore. And yes, gnome-initial-setup has two modes. The first is the firstboot mode, when it runs as part of gdm (replacing the login screen). The second is the firstlogin mode, where it runs in the session, if you log in for the first time. What exactly is the bug you want to discuss ? And again, why are you discussing it in an exising, closed bug instead of opening a new one ? Well, the original problem ("g-i-s is started on LiveCD") appeared again. It was fixed before, then something changed (systemd->.desktop transition), and it's broken again. So to re-state: If you boot F19 Beta TC2 Live, g-i-s is displayed _after_ the liveuser is logged in. You can just ignore the window and work normally, but it can't be closed normally (there is no X button). It can be closed from the overview mode. If you prefer, we can open a whole new bug. I didn't want to hijack bug 953766 to deal with livecd issues, because I don't know what the intentions of g-i-s developers are (in particular the purpose of firstlogin mode, I assumed that is in itself a bug), so I'm not sure if we're dealing with several use cases or just a single common problem. I'll be happy to file a separate bug if you think it helps. I've pushed a change to spin-kickstarts that should prevent gnome-initial-setup from running on the uninstalled livecd. Note, we're not intent on forcing it not to run if you actually *want* it to run on the un-installed live. If you want it to, then that's fine. We're just working on the assumption that it's a bug. Just a note for clarity - if you actually wanted it to run on the non-installed live, that's totally fine, I think. Just so long as it doesn't offer any options which don't make sense in that context. It might actually be *nice* to have a way to configure language and stuff. I believe it is no longer running, right? (with current beta TCs/RC) Yeah, it's fine lately. |