Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1493479 - Enable fedora-* services from initscripts by default
Summary: Enable fedora-* services from initscripts by default
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-release
Version: 27
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Dennis Gilmore
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1468001 1537977 (view as bug list)
Depends On:
Blocks: ZedoraTracker F28BetaBlocker 1537977 1584645
TreeView+ depends on / blocked
 
Reported: 2017-09-20 09:52 UTC by David Kaspar // Dee'Kej
Modified: 2018-05-31 11:32 UTC (History)
15 users (show)

Fixed In Version: fedora-release-28-0.2
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-02 00:14:12 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1537977 0 high CLOSED fedora-import-state not enabled in installer -> kickstart network configuration is broken 2022-05-16 11:32:56 UTC
Red Hat Bugzilla 1538638 0 unspecified CLOSED /etc/resolv.conf not created 2022-05-16 11:32:56 UTC
Red Hat Bugzilla 1584645 0 unspecified CLOSED Rename of fedora-* services in 90-default.preset 2022-05-16 11:32:56 UTC

Internal Links: 1537977 1538638 1584645

Description David Kaspar // Dee'Kej 2017-09-20 09:52:20 UTC
Hello! :)

Description of problem:

Previously, the initscripts package was using symlinks to automatically "register" services that should be started when system boots up.

Nowadays, that should be managed by your package, via (if I'm not mistaken):
/usr/lib/systemd/system-preset/90-default.preset

We have fixed the initscripts to no longer use symlinks for these services:
https://github.com/fedora-sysv/initscripts/pull/127

Please, enable these services by default:
* fedora-import-state.service
* fedora-load-modules.service
* fedora-readonly.service

Thank you! :)

  -- Dee'Kej --

Comment 1 Stephen Gallagher 2017-09-20 10:02:43 UTC
If you read through https://fedoraproject.org/wiki/Packaging:DefaultServices?rd=DefaultServices you will see what the criteria are for Fedora to enable a service by default. In particular, it provides a shortcut for filing requests for presets that will ask several key questions.

Please read https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&format=fedora-systemd-request and copy those questions into a comment on this BZ and provide answers.

Comment 2 Stephen Gallagher 2017-09-20 10:04:33 UTC
Additionally, a description of what these services actually do would be nice.

Comment 3 Zbigniew Jędrzejewski-Szmek 2017-09-20 10:13:47 UTC
The switch to use presets is very good.

But I think this is also an excellent chance to deprecate and disable those services by default in F28+.

- fedora-load-modules.service - identical functionality is provided by systemd-modules-load.service, I doubt that anyone is using this.

- fedora-import-state.service - I'd be particularly happy to get rid of this one. It's been a source of problems in the past and calls restorecon and complicates things. Copying things around to transfer state from the initramfs to the final system has been obsoleted by /run. So if there is any service in Fedora that still uses this mechanism, is should be weaned off.

- fedora-readonly.service - I'm not sure how widely this is used. We don't have a direct replacement, even though systemd provides read-only views of the system to various services. Personally I haven't seen fedora-readonly used, but if there are people using it, then of course we can keep it around and have the service enabled by default (it checks /etc/sysconfig/readonly-root for READONLY=yes|no, so the service being enabled by itself does not do anything).

So, to make things more concrete, I think we should:
1. leave fedora-load-modules.service disabled in presets
2. leave fedora-import-state.service disabled in presets
3. check what is using f-i-s.service and update it to use /run directly
4. propose a change for F28, about deprecating the first two, and asking for opinions about fedora-readonly.service
5. for F28, leave the first two services disabled, and make a decision about the third based on feedback.

Comment 4 Lukáš Nykrýn 2017-09-20 14:48:05 UTC
fedora-import-state.service is important on machines that have / on remote filesystem. Since the setup in done in initrd we need to transfer ifcfg files, dhcp leases, resolv.conf and something fcoe-related.

We need to make some changes in NM, initscripts, dracut and lldpad before we can think about disabling fedora-import-state.service

Comment 5 Stephen Gallagher 2017-10-02 13:10:26 UTC
I have escalated this discussion to FESCo for a decision. It will be discussed at the meeting on Friday, Oct. 6th at 1600 UTC in #fedora-meeting on Freenode IRC.

Comment 6 Randy Barlow 2017-10-04 19:04:36 UTC
This will be discussed in this week's FESCo meeting, on 2017-10-06 at 16:00:00 UTC in #fedora-meeting.

Comment 7 David Kaspar // Dee'Kej 2017-10-05 11:07:18 UTC
(In reply to Randy Barlow from comment #6)
> This will be discussed in this week's FESCo meeting, on 2017-10-06 at
> 16:00:00 UTC in #fedora-meeting.

I will be there. :)

Comment 8 Zbigniew Jędrzejewski-Szmek 2017-10-07 06:48:55 UTC
I doubt that FeSCO should be involved at this point. FeSCO's role is to decide between conflicting plans of action, once the sides have clarified their positions. I don't think we have reached that point here yet. In addition, FeSCO can't effectively tell people to implement big things if they haven't volunteered for it.

In the light of comment #c4, major work would be required to stop enabling  fedora-import-state.service without major regressions. I'm not volunteering to rewrite NM, initscripts, dracut and lldpad, so the default option of leaving things without major changes until somebody volunteers to do the work is going to win.

We don't have much information about the other two points. I'll write to fedora-devel to gather feedback.

Comment 9 Zbigniew Jędrzejewski-Szmek 2017-10-11 16:47:09 UTC
*** Bug 1468001 has been marked as a duplicate of this bug. ***

Comment 10 Zbigniew Jędrzejewski-Szmek 2017-10-11 16:55:40 UTC
After discussing this with Lukáš and Michal, we agreed to leave fedora-load-modules.service disabled by default, and keep the other two enabled.

I updated my PR https://pagure.io/fedora-release/pull-request/109 to do this.

The questions from comment #1 and #2 are answered in the PR (see https://pagure.io/fork/zbyszek/fedora-release/c/c0dbaabb816ac181e79f07244dc461f4ef65d86d).

Comment 11 David Kaspar // Dee'Kej 2017-10-16 12:57:55 UTC
Updating the BZ status to reflect that the pull-request was merged.

Comment 12 David Kaspar // Dee'Kej 2017-10-16 13:02:15 UTC
This change should IMHO require the synchronous releases of new versions of both 'initscripts' and 'fedora-release' packages, or at least the 'fedora-release' should be released first.

@Dennis, when do you plan to do a next release of this package? We're planning to release the new version of initscripts relatively soon (maybe this week), but we don't expect to land it into final freeze (but rather in "fresh" updates) for F27.

Would it be possible to prepare/release the 'fedora-release' package in the same time window as us? :)

Comment 13 Stephen Gallagher 2017-10-16 13:07:53 UTC
(In reply to David Kaspar [Dee'Kej] from comment #11)
> Updating the BZ status to reflect that the pull-request was merged.

In general, POST is the status that we use for indicating that a patch has been merged. MODIFIED is for when it has appeared in a build in Koji and ON_QA is when it shows up in updates-testing (automatically set by Bodhi).

Sticking with this convention makes it easier to see where in the process we are.

Comment 14 David Kaspar // Dee'Kej 2017-10-16 13:25:05 UTC
Ah, sorry for that, you're right. My bad. :-/

Comment 15 David Kaspar // Dee'Kej 2017-10-19 09:28:23 UTC
Hello Dennis,

do you have any ETA on new 'fedora-release' for F27/Rawhide?

Comment 16 Adam Williamson 2017-10-25 22:09:53 UTC
https://bodhi.fedoraproject.org/updates/FEDORA-2017-b365b0a636

There has not been an updated build for Rawhide, however.

Do we need to include an initscripts build in that update, for this to work properly?

Comment 17 Zbigniew Jędrzejewski-Szmek 2017-10-26 05:39:49 UTC
I don't think it's needed to include the initscripts build. It can be done at later time, but should include a 'Requires: fedora-release >= ...'.

Comment 18 David Kaspar // Dee'Kej 2017-10-30 15:26:00 UTC
(In reply to Adam Williamson from comment #16)
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-b365b0a636
> 
> There has not been an updated build for Rawhide, however.
> 
> Do we need to include an initscripts build in that update, for this to work
> properly?

If you release the 'fedora-release' package sooner, then it should not break anything (in regards to initscripts). It will mean the Fedora will be ready for when we make a new release of initscripts. :) In the meantime, some services will still be enabled by default by symlinks from initscripts package.

Releasing the 'fedora-release' before initscripts will allow us to properly test the upgrade triggers that we created for the transition:

https://github.com/fedora-sysv/initscripts/pull/127/commits/848d083ac8c827442364022d38d442e62accc783#diff-19805c24876f7b40ffecaa684780ae74R77

(In reply to Zbigniew Jędrzejewski-Szmek from comment #17)
> I don't think it's needed to include the initscripts build. It can be done
> at later time, but should include a 'Requires: fedora-release >= ...'.

Actually, I have created a for initscripts to have "weak dependency" (to use Recommends) on 'fedora-release'. I will also add Conflicts for older 'fedora-release' versions.

https://github.com/fedora-sysv/initscripts/pull/136

IMHO, we shouldn't force users to have the Fedora branding installed. They should be able to unistall the branding (fedora-release package) if they wish. I'm not sure if any other packages have hard-requires on 'fedora-release', but at least initscripts do not need it anymore. :)

Comment 19 Zbigniew Jędrzejewski-Szmek 2017-10-30 17:00:01 UTC
Conflicts is risky: fedora-release is not procteced in /etc/{yum,dnf}/protected.d, so a Conflicts with initscripts could cause it to be uninstalled. I think it's good enough to make use Recommends: initscripts >= ...

@mohanboddu can you do a fedora-release update for Rawhide too ASAP? It's holding up this change and a violation of policy to have a lower-versioned release in F27 then in rawhide.

Comment 20 David Kaspar // Dee'Kej 2017-10-30 17:28:04 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #19)
> Conflicts is risky: fedora-release is not procteced in
> /etc/{yum,dnf}/protected.d, so a Conflicts with initscripts could cause it
> to be uninstalled. I think it's good enough to make use Recommends:
> initscripts >= ...

Ah, looks like I didn't make myself clear enough... I wanted to have this change in initscripts (not in fedora-release):

https://github.com/fedora-sysv/initscripts/pull/136/files

AFAIK, this should forbid users on older Fedora (F26, F25, ...) to install the latest version of initscripts. This was we can prevent for users to end up with unbootable system, because the fedora-import.state wouldn't be correctly enabled.

And nothing regarding Recommends/Conflicts should be changed for 'initscripts' in  'fedora-release'... ;)

Does it make more sense now? :)

> @mohanboddu can you do a fedora-release update for Rawhide too ASAP? It's
> holding up this change and a violation of policy to have a lower-versioned
> release in F27 then in rawhide.

Please, let us now when you do. I'll try to make a new release of initscripts after that ASAP as well. :)

Comment 21 Zbigniew Jędrzejewski-Szmek 2017-10-30 17:30:41 UTC
Sorry, I meant "Recommends: fedora-release >= ..." (in initscripts), rather than "Recommends: initscripts >= ...".

#136 is dangerous for the reason I outlined above.

Comment 22 David Kaspar // Dee'Kej 2017-10-30 17:32:47 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #21)
> Sorry, I meant "Recommends: fedora-release >= ..." (in initscripts), rather
> than "Recommends: initscripts >= ...".
> 
> #136 is dangerous for the reason I outlined above.

Ah, ok, that makes more sense to me now. :) I'll discuss it tomorrow with Lukas, and remove the Conflicts then if he has no objections.

Comment 23 Adam Williamson 2017-10-30 20:52:24 UTC
I'd be cautious about changing much there, especially to address what seems a lot like a non-problem (we explicitly don't support mixing and matching packages between releases, and I can't really see any reason an F25 or F26 user would even *want* to pull an initscripts from F27).

Especially note that we explicitly do NOT ever want anything to have a hard dependency on fedora-release (or any other branding package) as we explicitly intend to allow Fedora to be easily de-branded: this is why we have generic-release and the neutral 'system-release' that both fedora-release and generic-release Provide.

Comment 24 Zbigniew Jędrzejewski-Szmek 2017-10-31 07:11:06 UTC
Good point. It seems that things are OK as they are then.

Comment 25 David Kaspar // Dee'Kej 2017-10-31 11:41:23 UTC
Okay, so I'm keeping only the

> Recommends: fedora-release >= 27-1

in 'initscripts' specfile... :)

Comment 26 Stephen Gallagher 2017-10-31 11:45:19 UTC
(In reply to David Kaspar [Dee'Kej] from comment #25)
> Okay, so I'm keeping only the
> 
> > Recommends: fedora-release >= 27-1
> 
> in 'initscripts' specfile... :)

Please use
Recommends: system-release >= 27-1

Rather than fedora-release, simply because we don't want this to be broken for Fedora remixes (which use some variant of generic-release instead of fedora-release so they aren't in trademark violation).

Comment 27 David Kaspar // Dee'Kej 2017-10-31 13:18:23 UTC
Thanks for the info. I've updated the commit as you suggested. :)

Comment 28 Adam Williamson 2017-10-31 17:29:38 UTC
I'm not sure if that'll work, as the 'system-release' Provide is not versioned that way:

[adamw@adam fedora-release-notes (f26)]$ rpm -q --provides fedora-release
config(fedora-release) = 27-1
fedora-release = 27-1
fedora-release-nonproduct = 27
fedora-release-standard = 22-0.8
redhat-release
system-release
system-release(27)

Comment 29 Zbigniew Jędrzejewski-Szmek 2017-10-31 20:44:45 UTC
Let's not overthink this. Most people install initscripts and fedora-release during initial installation, and those people will get the latest versions anyway. The number of people who install initscripts on an existing system _and_ have un-upgraded fedora-release is very small. Let's just ignore this case.

Comment 30 David Kaspar // Dee'Kej 2017-11-01 09:28:18 UTC
OK, so what is the consensus here? Which one should it be?

> Recommends: fedora-release >= 27-1

or

> Recommends: system-release

or

> Recommends: system-release(27)

Comment 31 Zbigniew Jędrzejewski-Szmek 2017-11-01 14:07:51 UTC
That line is a poor man's mechanism to make sure that fedora-release does not get uninstalled by mistake. That was fine when initscripts was mandatory. But now initscripts is not mandatory anymore, so this doesn't even work. You can just drop this line altogether.

Comment 32 Adam Williamson 2017-11-01 15:57:45 UTC
Actually, it isn't (at least it wasn't intended that way). Here ya go, fact fans:

https://bugzilla.redhat.com/show_bug.cgi?id=68903

The dependency was a straightforward one: initscripts actually read /etc/redhat-release to print an error message. So it got 'Requires: /etc/redhat-release'. In 2010, build 9.15-1, this was changed to 'Requires: /etc/system-release', without explanation (beyond "clean up some deprecated items", I guess). Then in 2012, the comment "Not strictly required, but nothing else requires it" was added.

AFAICT, initscripts no longer reads /etc/redhat-release or /etc/system-release - at least I can find no reference to either path in any file in the initscripts package, nor the 'Welcome to' string. So I think it's fine to drop the requirement.

Also note that "nothing else requires it" is (no longer?) true: setup does. Neither initscripts nor setup is a dnf protected package, so both *can* be removed.

Comment 33 Adam Williamson 2017-11-01 15:58:00 UTC
Sorry, not error message, *welcome* message.

Comment 34 David Kaspar // Dee'Kej 2017-11-06 09:27:01 UTC
Okay guys, what's the final decision here?

I really want to prepare the initscripts release ASAP, but this is currently blocking me to do so. I need to know which should be used there. Thank you.

Comment 35 Zbigniew Jędrzejewski-Szmek 2017-11-07 14:45:32 UTC
What Adam said: just drop it.

Comment 36 David Kaspar // Dee'Kej 2017-11-07 14:58:23 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #35)
> What Adam said: just drop it.

Acknowledged. Thank you. :)

Comment 37 Zbigniew Jędrzejewski-Szmek 2017-11-13 20:59:00 UTC
*** Bug 1512688 has been marked as a duplicate of this bug. ***

Comment 38 Dennis Gilmore 2018-01-17 17:46:16 UTC
clearing needinfo

Comment 39 David Kaspar // Dee'Kej 2018-01-24 16:39:41 UTC
Guys, these changes were not merged/released into Rawhide (F28)! We have released the changes in initscripts, because we expected you have fixed it in Rawhide as well...

This already causes problems for kicstart setup in BZ #1537977. This needs to be fixed ASAP, or we will most likely have much more people complaining as the time goes.

Please, make a new Rawhide/F28 relase based on latest commit in master branch. It contains the necessary change to fix this. Thanks! :)

Comment 40 Radek Vykydal 2018-02-01 08:56:01 UTC
(In reply to David Kaspar [Dee'Kej] from comment #39)

> Please, make a new Rawhide/F28 relase based on latest commit in master
> branch. It contains the necessary change to fix this. Thanks! :)

Yes, we really need to get this fixed, rawhide/f28 installer network configuration is badly broken because of fedora-import-state not being enabled in installer image (bug #1537977 bug #1538638)

Comment 41 Fedora Blocker Bugs Application 2018-02-01 12:22:42 UTC
Proposed as a Blocker for 28-beta by Fedora user dkaspar using the blocker tracking app because:

 Because of changes in initscripts package, it was necessary to update the `/usr/lib/systemd/system-preset/90-default.preset` file in 'fedora-release` package, to include these services:
* fedora-import-state.service (A mechanism to transfer state between the initramfs and the real system. Obsolete since /run was introduced, but still used by some services.)
* enable fedora-readonly.service (An initscripts mechanism for readonly root.)

The fix was properly delivered into F27 as requested. However, it didn't make into Rawhide (F28) as it should. As a result, the F27 works as intended, but for Rawhide (F28) the installer network configuration is badly broken because of fedora-import-state not being enabled in installer image.

It is now starting to result of cascade of new BZs being created. (See https://bugzilla.redhat.com/show_bug.cgi?id=1537977 and https://bugzilla.redhat.com/show_bug.cgi?id=1538638.)

This is a serious issue that significantly decreases the quality of Fedora distribution, and we shouldn't release F28 until this is resolved. Therefore, I'm proposing this issue as a F28-beta blocker.

Comment 42 Kevin Fenzi 2018-02-02 00:14:12 UTC
Built new fedora-release, should be in tomorrow's rawhide. 

Sorry for the delay.

Comment 43 Radek Vykydal 2018-02-05 07:39:39 UTC
*** Bug 1537977 has been marked as a duplicate of this bug. ***

Comment 44 Radek Vykydal 2018-02-05 07:42:16 UTC
I can confirm the issue is fixed in Fedora-Rawhide-20180204.n.0 for Anaconda.


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