Bug 626855
| Summary: | read legacy inittab file for determination of default target | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matthew Miller <mattdm> |
| Component: | systemd | Assignee: | Lennart Poettering <lpoetter> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | horsley1953, lpoetter, metherid, mschmidt, notting, plautrba |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-08-24 18:49:07 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Matthew Miller
2010-08-24 15:00:02 UTC
inittab was discussed extensively in the email thread starting here: http://lists.fedoraproject.org/pipermail/devel/2010-July/138893.html Thanks Michal. I didn't remember that particular branch of that long thread. I've read some of the discussion just now, and I see several people making suggestions similar to the above. There's extensive discussion, but no real conclusion is reached. I see Lennart was not convinced back then, but I think that he has come around a little bit in general on the issue of supporting some legacy syntax for the purposes of backwards compatibility during the transition. It's a relatively small thing to do, and one pragmatic way to look at it is: do we want to encourage even more threads arguing about the merits of legacy vs. progress, or should we just implement a forward-looking compatibility option and move on? What do you mean by 'will be set'? What do you do if default.target exists, and inittab is different? (The reason that upstart still read inittab was because it didn't have a native setting location for the default boot target.) (In reply to comment #3) > What do you mean by 'will be set'? What do you do if default.target exists, and > inittab is different? If it exists, the inittab initdefault should override default.target. Perhaps to maintain consistency, it should even cause the default target link to be changed. Note that I'm not commenting on whether the inittab file we ship should contain an initdefault line or just a short paragraph explaining the new system. In fact, I lean slightly to the latter. But if someone *does* put something in there, make it work. > (The reason that upstart still read inittab was because it didn't have a native > setting location for the default boot target.) Arguably, /etc/inittab *is* its native setting location for the default boot target. I see little reason to repeat this discussion here. I'd rather do real work than repeating all discussions multiple times at different places. The result of the last discussion is that we now read initdefault on package installation. And we already have support in the %post script of the rpm to read the old initdefault setting from the inittab and apply the respective config change to systemd -- since quite some time. I have no plans to deobselete stuff that Upstart had already long obsoleted. Sorry. Closing. (In reply to comment #5) > I see little reason to repeat this discussion here. I'd rather do real work > than repeating all discussions multiple times at different places. Ok. You are welcome to have (or ignore, and appear haughty, as the case may be) this discussion over and over again once systemd is widely deployed rather than making a small change now. > The result of the last discussion is that we now read initdefault on package > installation. And we already have support in the %post script of the rpm to > read the old initdefault setting from the inittab and apply the respective > config change to systemd -- since quite some time. That keeps from horribly breaking things on upgrade, which is better than nothing. But it isn't user-friendly behavior. > I have no plans to deobselete stuff that Upstart had already long obsoleted. > Sorry. Closing. As Bill says in comment #3, this statement is not true. Upstart does not obsolete this behavior -- in fact, it is the only supported config file for setting the default runlevel. I am changing the resolution of this bug from NEXTRELEASE to WONTFIX, as your comment indicates that you're deciding not to fix the issue, not that you're fixing it for the next release. Shouldn't /etc/inittab comments be updated to reflect the current state? The comments there now are misleading and points to conf files in /etc/init which are from upstart. As long as upstart is still supported, sort of hard to have both in one file. Yes, will have to remember to change the comments if systemd obsoletes upstart in the near future. Do you want me to file it against initscripts? Sure. There's already a patch for the inittab blurb, which I sent to Bill. As I understood Bill he wanted to apply it after the beta when the adoption of systemd as default is clear. Hey, I don't care if it moves, but for God's sake, put a comment in /etc/inittab saying exactly where in the hell it moved to. I've just read all the comments in this bugzilla, and I still have no idea where it lives (other than a file possibly named default.target that exists in some directory somewhere :-). For posterity, refer to http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions |