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
Summary: | Enable fedora-* services from initscripts by default | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David Kaspar // Dee'Kej <deekej> |
Component: | fedora-release | Assignee: | Dennis Gilmore <dennis> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 27 | CC: | awilliam, deekej, dennis, jdisnard, jflorian, kellin, kevin, lnykryn, mboddu, pbrobinson, randy, robatino, rvykydal, sgallagh, zbyszek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | fedora-release-28-0.2 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-02-02 00:14:12 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: | 467765, 1469204, 1537977, 1584645 |
Description
David Kaspar // Dee'Kej
2017-09-20 09:52:20 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. Additionally, a description of what these services actually do would be nice. 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. 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 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. This will be discussed in this week's FESCo meeting, on 2017-10-06 at 16:00:00 UTC in #fedora-meeting. (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. :) 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. *** Bug 1468001 has been marked as a duplicate of this bug. *** 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). Updating the BZ status to reflect that the pull-request was merged. 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? :) (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. Ah, sorry for that, you're right. My bad. :-/ Hello Dennis, do you have any ETA on new 'fedora-release' for F27/Rawhide? 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? 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 >= ...'. (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. :) 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. (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. :) Sorry, I meant "Recommends: fedora-release >= ..." (in initscripts), rather than "Recommends: initscripts >= ...". #136 is dangerous for the reason I outlined above. (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. 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. Good point. It seems that things are OK as they are then. Okay, so I'm keeping only the
> Recommends: fedora-release >= 27-1
in 'initscripts' specfile... :)
(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). Thanks for the info. I've updated the commit as you suggested. :) 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) 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. 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) 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. 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. Sorry, not error message, *welcome* message. 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. What Adam said: just drop it. (In reply to Zbigniew Jędrzejewski-Szmek from comment #35) > What Adam said: just drop it. Acknowledged. Thank you. :) *** Bug 1512688 has been marked as a duplicate of this bug. *** clearing needinfo 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! :) (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) 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. Built new fedora-release, should be in tomorrow's rawhide. Sorry for the delay. *** Bug 1537977 has been marked as a duplicate of this bug. *** I can confirm the issue is fixed in Fedora-Rawhide-20180204.n.0 for Anaconda. |