Bug#765803: Status of prompting / notification on upgrade for init system switch?
]] Tollef Fog Heen ]] Martin Pitt Tollef Fog Heen [2014-10-21 19:19 +0200]: I would be particularly interested in your take on the analysis that Steve Langasek posted to the debian-devel thread on why listing systemd-shim as the first alternative dependency for libpam-systemd makes sense and should not cause any negative effects for systemd users. In a steady state, this would probably be ok. However, we've so far seen two instances of -shim breaking for systemd users (https://bugs.debian.org/746242 and https://bugs.debian.org/765101), by shipping outdated security policies. We are worried that this will happen again on future updates of systemd. 8-4 now eliminates the copied d-bus policy entirely. This was by and large a leftover when Ubuntu had the split systemd-services, and other than that there was one remaining delta in the policy which we discussed yesterday and found to be unnecessary (and detrimental). That is good to hear. I'm hoping you're right there aren't any other ways for it to regress for non-shim users. I just became aware of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767468 . Not directly a shim bug, but cgmanager is pulled in by shim. (I have not done any analysis on the bug myself apart from reading it, but it looks reasonable.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhnwfr9x@aexonyam.err.no
Bug#765803: Status of prompting / notification on upgrade for init system switch?
]] Russ Allbery Tollef Fog Heen tfh...@err.no writes: ]] Russ Allbery Thanks, Tollef! Okay, so there does appear to be a conflict here. It sounds like your primary technical concern, not addressed by Martin's mail, is that getting the dependencies right to install systemd on initial install but not upgrade to it are tricky and have a lot of corner cases, and you feel like it's late in the release process to make that change. (This is apart from the general feeling that users would be better off with the default, which is more of a judgement call about policy.) Is that a fair summary? Yes. Thanks! I do think that argues for a clear testing plan if someone proposes a change in how the dependencies are structured to avoid upgrading to it. Right. I think the right approach is to upgrade unless the user vetoes it, but that's something reasonable people can disagree about. (I've come around to the idea that we should prompt on upgrades, as much as I loathe prompts.) I don't particularly like this argument. This is the reason why we should fix bugs in systemd-shim and be sure that it's RC-free in the release, not a reason to not install it unless those bugs can't be fixed. In general, we fix software that has bugs rather than avoid installing it, unless those bugs aren't fixable. Based on that argument, we should install as much software as possible on users' desktops, to ensure we expose as many weird interaction bugs as possible. I don't actually believe this is what you mean, so if you want to EXPN a bit, please do. Right, my point here is that I don't think we should choose libpam-systemd dependency order purely on the basis of perception of how many bugs there currently are in the native systemd support versions the systemd-shim support. That's partly a special case to this particular transition: there is obviously huge controversy over which approach is better for the average user, and both sides feel like the other program is obviously more buggy. I can agree with that. The other argument for having libpam-systemd depend on systemd-sysv | systemd-shim rather than the other way around is that systemd-sysv is the default (in Debian), the recommended (by the maintainer) and the most well-tested fulfiller of the dependency. systemd-shim working properly is probably going to be RC for jessie. I don't think there's any way to avoid that unless it's so bad that the people who are working on it say that there's no way that it can be stable for jessie and give up on that. I don't think that's very likely. No disagreements from me here. So avoiding it in dependencies because it has RC bugs doesn't, in that sense, help us get jessie out the door faster, because I doubt we're going to release jessie until it's in a reasonable state anyway. If it makes you happier, we can avoid it as the preferred solution for the reasons listed above. I'm not picky. :-) Maybe I'm analyzing this wrong and it's more likely than I think that people are going to give up on getting systemd-shim working, or the project is going to be willing to release without it working, but I'm pretty dubious. I'm less concerned about whether -shim works or not (since my main concern is whether systemd itself works correctly or not). I'm more concerned about it breaking things for people who are using systemd (directly or indirectly). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87h9ykfh7c@aexonyam.err.no
Bug#765803: Status of prompting / notification on upgrade for init system switch?
On Tue, Oct 21, 2014 at 07:19:32PM +0200, Tollef Fog Heen wrote: An important detail is, that on upgrades, we keep the sysvinit package installed, which ships /lib/sysvinit/init. This makes it very easy to boot using sysvinit, even if systemd is the default /sbin/init. We proposed a patch for grub2 (https://bugs.debian.org/757298), which makes this even more straightforward. Unfortunately this patch hasn't been merged yet and we are still waiting for a reply from the maintainer. That's my fault, sorry. I've been pretty swamped in a number of ways recently and took longer than I should have done to realise what was going on; but I'm now taking steps to deal with it (as per my blog). I'll make sure that some variant of that patch gets into jessie, since it seems like a reasonable change regardless of what else is decided here. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141030142309.gb3...@riva.ucam.org
Bug#765803: Status of prompting / notification on upgrade for init system switch?
On Fri, Oct 24, 2014 at 01:31:55PM +0200, Tollef Fog Heen wrote: I would even go so far as to say that it's good that we're exposing these bugs now, during our release preparation process, so that they can be fixed prior to jessie. We need systemd-shim to work properly in jessie if we can find the resources to do that work; we know that a lot of users will want to continue using sysvinit for jessie. systemd is a big change, and, even if one thinks that the same thing that happpened with udev will happen to it in the long run, as with udev we need to support both configurations at least until one of them naturally fades away (if that happens). And, so far, it looks like the resources to make systemd-shim work will be available. I don't think the necessary manpower to fix those bugs is available. If so, why are we now then at ten days before the freeze with bugs that were made release critical in -shim more than a month ago with no subsequent response from the maintainer? Is that bug #759745 which was assigned to systemd-shim 8 days ago and appears to be a duplicate of bug #757348, or bug #756076 which was marked *resolved* on September 10 and was reopened, with a subsequent history that in no way explains why it's been marked as grave? Regardless, I don't think the RC bugs will be fixed is still not an excuse for enforcing a different set of bugs via the dependencies of libpam-systemd. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141025071504.gd15...@virgil.dodds.net
Re: Bug#765803: Status of prompting / notification on upgrade for init system switch?
]] Russ Allbery Thanks, Tollef! Okay, so there does appear to be a conflict here. It sounds like your primary technical concern, not addressed by Martin's mail, is that getting the dependencies right to install systemd on initial install but not upgrade to it are tricky and have a lot of corner cases, and you feel like it's late in the release process to make that change. (This is apart from the general feeling that users would be better off with the default, which is more of a judgement call about policy.) Is that a fair summary? Yes. One specific point on the libpam-systemd issue: Tollef Fog Heen tfh...@err.no writes: In a steady state, this would probably be ok. However, we've so far seen two instances of -shim breaking for systemd users (https://bugs.debian.org/746242 and https://bugs.debian.org/765101), by shipping outdated security policies. We are worried that this will happen again on future updates of systemd. We are also worried about it still having release critical bugs and the feedback we are hearing from the desktop maintainers is that they see bugs which are tracked down to bugs in -shim. We therefore don't believe that is a good choice for desktop users. I don't particularly like this argument. This is the reason why we should fix bugs in systemd-shim and be sure that it's RC-free in the release, not a reason to not install it unless those bugs can't be fixed. In general, we fix software that has bugs rather than avoid installing it, unless those bugs aren't fixable. Based on that argument, we should install as much software as possible on users' desktops, to ensure we expose as many weird interaction bugs as possible. I don't actually believe this is what you mean, so if you want to EXPN a bit, please do. I would even go so far as to say that it's good that we're exposing these bugs now, during our release preparation process, so that they can be fixed prior to jessie. We need systemd-shim to work properly in jessie if we can find the resources to do that work; we know that a lot of users will want to continue using sysvinit for jessie. systemd is a big change, and, even if one thinks that the same thing that happpened with udev will happen to it in the long run, as with udev we need to support both configurations at least until one of them naturally fades away (if that happens). And, so far, it looks like the resources to make systemd-shim work will be available. I don't think the necessary manpower to fix those bugs is available. If so, why are we now then at ten days before the freeze with bugs that were made release critical in -shim more than a month ago with no subsequent response from the maintainer? Steve's argument is that choosing sysvinit-core over systemd-sysv should automatically reflect on choosing systemd-shim over systemd-sysv. We do not necessarily think this is the case and both decisions need to be taken on their own. I thought the argument was that listing systemd-shim first makes no difference except in the case where someone does not currently have systemd installed at all. In other words, both of those decisions can still be taken on their own, and that dependency order will preserve the existing state. Did I get that wrong? Not sure, maybe Michael can comment on this bit? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m261f9hff8@rahvafeir.err.no
Bug#765803: Status of prompting / notification on upgrade for init system switch?
]] Ian Jackson Russ Allbery writes (Bug#765803: Status of prompting / notification on upgrade for init system switch?): Thanks, Tollef! Okay, so there does appear to be a conflict here. It sounds like your primary technical concern, not addressed by Martin's mail, is that getting the dependencies right to install systemd on initial install but not upgrade to it are tricky and have a lot of corner cases, and you feel like it's late in the release process to make that change. That's not the impression I got from Tollef's mail. I thought his concern was mostly bugs in systemd-shim. Surely the question of the default can be addressed easily enough in the installer - it can just be told, explicitly, to install systemd. And by «the installer», you mean d-i, vmdebootstrap, ganeti, libvirt, pbuilder, schroot, rootstrap and fai, to list a few ways of installing Debian? It's less work to just document how to keep sysvinit in the release notes, something I surely hope we're going to do anyway. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m24muthfdu@rahvafeir.err.no
Bug#765803: Status of prompting / notification on upgrade for init system switch?
I think you got bit by the Mail-Followup-To and your messages didn't make it to the CTTE bug. Tollef Fog Heen tfh...@err.no writes: ]] Russ Allbery Thanks, Tollef! Okay, so there does appear to be a conflict here. It sounds like your primary technical concern, not addressed by Martin's mail, is that getting the dependencies right to install systemd on initial install but not upgrade to it are tricky and have a lot of corner cases, and you feel like it's late in the release process to make that change. (This is apart from the general feeling that users would be better off with the default, which is more of a judgement call about policy.) Is that a fair summary? Yes. Thanks! I do think that argues for a clear testing plan if someone proposes a change in how the dependencies are structured to avoid upgrading to it. I don't particularly like this argument. This is the reason why we should fix bugs in systemd-shim and be sure that it's RC-free in the release, not a reason to not install it unless those bugs can't be fixed. In general, we fix software that has bugs rather than avoid installing it, unless those bugs aren't fixable. Based on that argument, we should install as much software as possible on users' desktops, to ensure we expose as many weird interaction bugs as possible. I don't actually believe this is what you mean, so if you want to EXPN a bit, please do. Right, my point here is that I don't think we should choose libpam-systemd dependency order purely on the basis of perception of how many bugs there currently are in the native systemd support versions the systemd-shim support. That's partly a special case to this particular transition: there is obviously huge controversy over which approach is better for the average user, and both sides feel like the other program is obviously more buggy. Rather, I think we should decide whether we're upgrading users by default or not upgrading users by default, on the basis of the broader situation with both stacks plus the various social aspects to this whole argument, and then choose dependencies that cause the fewest problems for the most users given the background of that decision. systemd-shim working properly is probably going to be RC for jessie. I don't think there's any way to avoid that unless it's so bad that the people who are working on it say that there's no way that it can be stable for jessie and give up on that. I don't think that's very likely. So avoiding it in dependencies because it has RC bugs doesn't, in that sense, help us get jessie out the door faster, because I doubt we're going to release jessie until it's in a reasonable state anyway. Maybe I'm analyzing this wrong and it's more likely than I think that people are going to give up on getting systemd-shim working, or the project is going to be willing to release without it working, but I'm pretty dubious. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87egtxcx3h@hope.eyrie.org
Bug#765803: Status of prompting / notification on upgrade for init system switch?
]] Martin Pitt Tollef Fog Heen [2014-10-21 19:19 +0200]: I would be particularly interested in your take on the analysis that Steve Langasek posted to the debian-devel thread on why listing systemd-shim as the first alternative dependency for libpam-systemd makes sense and should not cause any negative effects for systemd users. In a steady state, this would probably be ok. However, we've so far seen two instances of -shim breaking for systemd users (https://bugs.debian.org/746242 and https://bugs.debian.org/765101), by shipping outdated security policies. We are worried that this will happen again on future updates of systemd. 8-4 now eliminates the copied d-bus policy entirely. This was by and large a leftover when Ubuntu had the split systemd-services, and other than that there was one remaining delta in the policy which we discussed yesterday and found to be unnecessary (and detrimental). That is good to hear. I'm hoping you're right there aren't any other ways for it to regress for non-shim users. Of course there are still a lot of bug reports *in* -shim, i. e. which hit when you run with sysvinit or upstart. But that's the opposite case of what you were concerned about, right? Indeed. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fvedfdea@xoog.err.no
Bug#765803: Status of prompting / notification on upgrade for init system switch?
On Thu, Oct 23, 2014 at 8:13 PM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Oct 23, 2014 at 10:21:27PM -0400, Sam Hartman wrote: Josh == Josh Triplett j...@joshtriplett.org writes: Josh - It can't check for generated lines for serial consoles or Josh similar; finish-install can generate various additional Josh inittab lines, which the check should include. Since when did systemd actually handle these correctly? I've generally found that systemd will give me a serial console only if the kernel console is that serial console. I've found that if I manually enable a serial console but have the kernel console go somewhere else, I end up with a system I cannot log into when I upgrade to systemd. This has been no end of frustration and I hope that your check correctly prompts in this case even when the line I generate is exactly the same as a line generated by the installer. If it's gotten better and I'd actually get a console in that case, that's of course fine too. It should either let me know I'm about to hurt myself or work:-) Either behavior is fine. TTBOMK, you'll automatically get a console on a serial port in a few cases: - If the kernel console points there (console=ttyS0); note that this works even if you change that console. - If the console is identified as a default system console (works for virtual machine serial ports, and for systems with unusually named standard console serial ports). See systemd-getty-generator. In other cases, you have to manually systemctl enable serial-getty@ttyX.service. I wonder if it might make sense to do a one-time migration that parses /etc/inittab, looks for serial console getty lines, and enables serial-getty@.service for any consoles it finds gettys for? If you are going to the work of parsing it all, would it not make sense to make a systemd generator out of it? -- Cameron Norman -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CALZWFRJsMWVXXx5iz=kstt82dn3ovddc9xrhn8asqon-wvk...@mail.gmail.com
Bug#765803: Status of prompting / notification on upgrade for init system switch?
]] Cameron Norman Please trim bits you're not replying to. El mar, 21 de oct 2014 a las 10:19 , Tollef Fog Heen tfh...@err.no escribió: ]] Russ Allbery I would be particularly interested in your take on the analysis that Steve Langasek posted to the debian-devel thread on why listing systemd-shim as the first alternative dependency for libpam-systemd makes sense and should not cause any negative effects for systemd users. In a steady state, this would probably be ok. However, we've so far seen two instances of -shim breaking for systemd users (https://bugs.debian.org/746242 and https://bugs.debian.org/765101), by shipping outdated security policies. We are worried that this will happen again on future updates of systemd. Josh Triplett proposed a long term solution to the problem you point out here that will work across systemd upgrades. What are your thoughts on that solution? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765101#38 That seems like a fine approach to me. I thought it already depended on systemd, though. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m2h9ywhakn@rahvafeir.err.no
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Russ Allbery r...@debian.org writes: I think default is about what we install with fresh installs. That's consistent with the other examples you list, where we've picked a default. I agree. Bdale pgpbspOmI0C3L.pgp Description: PGP signature
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Bdale Garbee writes (Bug#765803: Status of prompting / notification on upgrade for init system switch?): Russ Allbery r...@debian.org writes: I think default is about what we install with fresh installs. That's consistent with the other examples you list, where we've picked a default. I agree. I think it would be helpful to write this up as a resolution. How about: -8- 1. In February the TC decided that the default init system for Linux in Debian jessie would be systemd. We have been asked what this should mean for systems being upgraded from earlier Debian releases: Should existing installs be automatically switched to systemd ? Should users be prompted ? 2. Normally when Debian changes the default provider of some service, this means that new installs get the new provider. We do not transition existing installs to the new provider during upgrades, unless the old provider is being removed. 3. The TC did not intend that our decision should extend to switching existing Debian GNU/Linux installations from sysvinit to systemd. Nor do we think that those users should be prompted to switch init system. 4. So, if an existing installation has its init system switched, as a result of upgrading or of installing packages, that is a bug (unless it is not possible to retain the existing init system). -8- The caveat in (4) avoids prejudging the results of the coupling question which is the subject of the GR process at the moment. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21574.29282.239270.556...@chiark.greenend.org.uk
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Ian Jackson ijack...@chiark.greenend.org.uk writes: I think it would be helpful to write this up as a resolution. How about: -8- 1. In February the TC decided that the default init system for Linux in Debian jessie would be systemd. We have been asked what this should mean for systems being upgraded from earlier Debian releases: Should existing installs be automatically switched to systemd ? Should users be prompted ? 2. Normally when Debian changes the default provider of some service, this means that new installs get the new provider. We do not transition existing installs to the new provider during upgrades, unless the old provider is being removed. 3. The TC did not intend that our decision should extend to switching existing Debian GNU/Linux installations from sysvinit to systemd. Nor do we think that those users should be prompted to switch init system. 4. So, if an existing installation has its init system switched, as a result of upgrading or of installing packages, that is a bug (unless it is not possible to retain the existing init system). This implies that we had decided not to change init systems on upgrade. I don't believe that's correct. I didn't express an opinion on it one way or another and intended to leave that for further discussion within the project. I'm happy to vote for a resolution that clarifies that our previous decision expressed no opinion on whether the init system should be changed on upgrade. Whether it should be upgraded is a question that has not come before us until just now, and therefore clearly wasn't something we decided last February. If we need to decide that, we should do it in the context of the current bug, not in the context of last February, and it's not clear to me yet whether the TC even has actionable jurisdiction (in that there may not even be a conflict). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8738aha191@hope.eyrie.org
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Russ Allbery writes (Re: Bug#765803: Status of prompting / notification on upgrade for init system switch?): This implies that we had decided not to change init systems on upgrade. I don't believe that's correct. I didn't express an opinion on it one way or another and intended to leave that for further discussion within the project. We have been asked to decide on this question in #746578 even if you don't think my own referral in #762194 is good enough. It comes up in #765803 too, although the question there is phrased differently. it's not clear to me yet whether the TC even has actionable jurisdiction (in that there may not even be a conflict). Svante Signell and I have clearly said that we think users should not be switched automatically. Tollef Fog Heen claimed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#134 that there is consensus on debian-devel in favour of the switch. In earlier messages you have framed some of these bugs as requests to overrule particular maintainers, whose packages had dependencies which were causing this switch. I think the principle, of whether this switch should be made automatic, ought to be addressed separately, and should be regarded as a question of overlapping jurisdictions. We can't have different maintainers fighting over init on users' systems by publishing packages with dependencies which result in their preferred setup. I think we should therefore issue a set of general guidance along the lines of the draft I just posted. If that guidance has technical consequences for the dependencies in particular packages, and the maintainers do not agree, then that might involve the TC overruling a particular maintainer to ensure that the general principle is implemented. Your objection that you feel we hadn't decided at the time could be addressed by altering para 3 of my draft to read: 3. The TC does not feel that our decision should extend to switching existing Debian GNU/Linux installations from sysvinit to systemd. Nor do we think that those users should be prompted to switch init system. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21574.32635.815548.602...@chiark.greenend.org.uk
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Ian Jackson ijack...@chiark.greenend.org.uk writes: Tollef Fog Heen claimed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#134 that there is consensus on debian-devel in favour of the switch. That was some time ago, and Martin has expressed a different opinion. I think the systemd team should have a chance to talk this over internally and see if they still feel that this is the right choice for Debian. (I know that we're on a bit of a schedule here due to the freeze.) In earlier messages you have framed some of these bugs as requests to overrule particular maintainers, whose packages had dependencies which were causing this switch. I think the principle, of whether this switch should be made automatic, ought to be addressed separately, and should be regarded as a question of overlapping jurisdictions. We can't have different maintainers fighting over init on users' systems by publishing packages with dependencies which result in their preferred setup. The primary question that's obviously a maintainer override is the order of dependencies in libpam-systemd, and I still think we can reach a consensus there without the TC needing to rule on something. I think we should therefore issue a set of general guidance along the lines of the draft I just posted. I believe it would be a mistake to start doing that without giving the systemd maintainers a chance to discuss Martin's message and the overall issue, and to decide if there's actually a conflict here. Your objection that you feel we hadn't decided at the time could be addressed by altering para 3 of my draft to read: 3. The TC does not feel that our decision should extend to switching existing Debian GNU/Linux installations from sysvinit to systemd. Nor do we think that those users should be prompted to switch init system. If you're proposing this as a resolution of #765803, that's fine. I haven't decided if that's something I'd agree with yet or not. However, I was under the impression that you were proposing that we issue a resolution, independent of #765803, that clarifies our February decision. I was trying to say that I think that might be a reasonable course of action, but it would need to just say that our February decision didn't express an opinion about upgrades. That's how I understood it, at least; the other members of the TC can obviously weigh in if they disagree. In *that* context, paragraph 3 (and 4) of your proposal are obviously out of place and shouldn't be included. It may be that I just misunderstood the context of your proposal, given that, now that I re-read it, it sounds like you were aiming for a resolution of #765803 all along. In which case I'm just confused, and what I'm arguing about isn't even what you were intending. :) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oat58lae@hope.eyrie.org
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Russ Allbery writes (Re: Bug#765803: Status of prompting / notification on upgrade for init system switch?): If you're proposing this as a resolution of #765803, that's fine. I'm not sure I follow. You think it would be proper for the TC to pass a resolution along the lines of the one I proposed, but only if it's a resolution to #765803 rather than one of the other bug reports ? That's fine, I don't care precisely what subset of the bugs we regard it as closing. It may be that I just misunderstood the context of your proposal, given that, now that I re-read it, it sounds like you were aiming for a resolution of #765803 all along. In which case I'm just confused, and what I'm arguing about isn't even what you were intending. :) Yes, I was aiming for a resolution of #765803 and #762194 all along. I have sent my mail to just #765803 because that's where most of the discussion happened. Passing a resolution along the lines I proposed does not directly dispose of #746578, but it would inform our discussion of that issue. I haven't decided if that's something I'd agree with yet or not. I think we need to get on with this. This question was raised in the context of #746578 in May and #762194 in September. I don't think the question is very complicated, even in the absence of Martin Pitt's email. So I hereby formally propose the following draft: -8- 1. In February the TC decided that the default init system for Linux in Debian jessie would be systemd. We have been asked what this should mean for systems being upgraded from earlier Debian releases: Should existing installs be automatically switched to systemd (#762194) ? Should users be prompted (#765803) ? 2. Normally when Debian changes the default provider of some service, this means that new installs get the new provider. We do not transition existing installs to the new provider during upgrades, unless the old provider is being removed. 3. The TC does not feel that our decision should extend to switching existing Debian GNU/Linux installations from sysvinit to systemd. Nor do we think that those users should be prompted to switch init system. 4. So, if an existing installation has its init system switched, as a result of upgrading or of installing packages, that is a bug (unless it is not possible to retain the existing init system). -8- Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21574.34515.624973.911...@chiark.greenend.org.uk
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Hi Ian, On 10/21/2014 05:44 PM, Ian Jackson wrote: I think the principle, of whether this switch should be made automatic, ought to be addressed separately, and should be regarded as a question of overlapping jurisdictions. We can't have different maintainers fighting over init on users' systems by publishing packages with dependencies which result in their preferred setup. What gives you the impression that different maintainers fight over providing init? I have not seen that happening. Ansgar -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54468897.2080...@43-1.org
Bug#765803: Status of prompting / notification on upgrade for init system switch?
On Mon, 20 Oct 2014 10:06:31 -0400 Martin Pitt mp...@debian.org wrote: I'll leave this to the Debian maintainers, as I'm mostly responsible for the Ubuntu side, haven't really discussed this with the two Michaels/Tollef/Marco, and I don't feel qualified to speak for the Debian systemd team. My personal opinion: Given how close we are to the release and how many regression reports we still get, it seems prudent to not change the currently running init systems for upgrades for Jessie yet, but only set up systemd for new installs. I know this is not really in the spirit of the TC decision to make systemd the default init system, but at this point in time it might be the pragmatic compromise. The systemd package gets literally swamped with bug reports (of all kinds of usefulness/quality), and there's simply not enough maintainers to keep up with the flood. Many of those are indeed not actual bugs in systemd, but bugs in other packages, local That swamped with bug reports does not match my impression of reading the systemd packaging list. As far as I can tell, this is not the view of the Debian maintainers either. My impression from the bug reports is that systemd-shim does not work particularly reliably. So automatically installing systemd-shim does not seem any safer than automatically installing systemd from the view of avoiding breaking old systems. The other direction (running sysvinit or upstart with -shim) has not been so unproblematic though, as systemd-shim's bug list shows. This definitively needs some love, but then again we've run this for a fair while in Ubuntu (even in our 14.04 LTS) without too many problems. So my feeling is that we can certainly stabilize -shim by the jessie release. (We need to do that anyway, as we need to support sysvinit regardless of what we do on upgrades/new installs.) Is there some reason to believe that there would be _more_ success with this than with resolving the remaining integration issues with systemd? And shouldn't work on the latter be higher priority? -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1413908276.29980.1.ca...@pp1.inet.fi
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Thanks, Tollef! Okay, so there does appear to be a conflict here. It sounds like your primary technical concern, not addressed by Martin's mail, is that getting the dependencies right to install systemd on initial install but not upgrade to it are tricky and have a lot of corner cases, and you feel like it's late in the release process to make that change. (This is apart from the general feeling that users would be better off with the default, which is more of a judgement call about policy.) Is that a fair summary? One specific point on the libpam-systemd issue: Tollef Fog Heen tfh...@err.no writes: In a steady state, this would probably be ok. However, we've so far seen two instances of -shim breaking for systemd users (https://bugs.debian.org/746242 and https://bugs.debian.org/765101), by shipping outdated security policies. We are worried that this will happen again on future updates of systemd. We are also worried about it still having release critical bugs and the feedback we are hearing from the desktop maintainers is that they see bugs which are tracked down to bugs in -shim. We therefore don't believe that is a good choice for desktop users. I don't particularly like this argument. This is the reason why we should fix bugs in systemd-shim and be sure that it's RC-free in the release, not a reason to not install it unless those bugs can't be fixed. In general, we fix software that has bugs rather than avoid installing it, unless those bugs aren't fixable. I would even go so far as to say that it's good that we're exposing these bugs now, during our release preparation process, so that they can be fixed prior to jessie. We need systemd-shim to work properly in jessie if we can find the resources to do that work; we know that a lot of users will want to continue using sysvinit for jessie. systemd is a big change, and, even if one thinks that the same thing that happpened with udev will happen to it in the long run, as with udev we need to support both configurations at least until one of them naturally fades away (if that happens). And, so far, it looks like the resources to make systemd-shim work will be available. Steve's argument is that choosing sysvinit-core over systemd-sysv should automatically reflect on choosing systemd-shim over systemd-sysv. We do not necessarily think this is the case and both decisions need to be taken on their own. I thought the argument was that listing systemd-shim first makes no difference except in the case where someone does not currently have systemd installed at all. In other words, both of those decisions can still be taken on their own, and that dependency order will preserve the existing state. Did I get that wrong? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lho971zf@hope.eyrie.org
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Russ Allbery writes (Bug#765803: Status of prompting / notification on upgrade for init system switch?): Thanks, Tollef! Okay, so there does appear to be a conflict here. It sounds like your primary technical concern, not addressed by Martin's mail, is that getting the dependencies right to install systemd on initial install but not upgrade to it are tricky and have a lot of corner cases, and you feel like it's late in the release process to make that change. That's not the impression I got from Tollef's mail. I thought his concern was mostly bugs in systemd-shim. Surely the question of the default can be addressed easily enough in the installer - it can just be told, explicitly, to install systemd. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21574.40050.527334.10...@chiark.greenend.org.uk
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes: Thanks, Tollef! Okay, so there does appear to be a conflict here. It sounds like your primary technical concern, not addressed by Martin's mail, is that getting the dependencies right to install systemd on initial install but not upgrade to it are tricky and have a lot of corner cases, and you feel like it's late in the release process to make that change. That's not the impression I got from Tollef's mail. I thought his concern was mostly bugs in systemd-shim. Surely the question of the default can be addressed easily enough in the installer - it can just be told, explicitly, to install systemd. It would be better to let Tollef speak for himself, so re-adding the systemd mailing list, but I believe his message was addressing two different issues: whether to switch init systems on upgrade, and the dependencies on libpam-systemd (since I explicitly asked about that). The issue of bugs in systemd-shim came up in the latter context, and I replied to that in that context. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnp571jh@hope.eyrie.org
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Ian Jackson ijack...@chiark.greenend.org.uk writes: 2. Normally when Debian changes the default provider of some service, this means that new installs get the new provider. We do not transition existing installs to the new provider during upgrades, unless the old provider is being removed. That's not strictly true. Packages may not be removed, but the default for various applications can and certainly does change on upgrades. I'm thinking of things like which gcc version is the default on a system. 3. The TC did not intend that our decision should extend to switching existing Debian GNU/Linux installations from sysvinit to systemd. Nor do we think that those users should be prompted to switch init system. I agree that we did not intend there to be some spontaneous move to transition all existing sysvinit users to systemd. 4. So, if an existing installation has its init system switched, as a result of upgrading or of installing packages, that is a bug (unless it is not possible to retain the existing init system). The caveat in (4) avoids prejudging the results of the coupling question which is the subject of the GR process at the moment. I don't think it does so sufficiently to allow me to be in favor of this resolution. If we admit to the possibility that there might be a package with a legitimate hard dependency on a specific init system other than the one currently installed, a user who willingly chooses that package would be within their rights to consider it a bug if their init system were *not* changed. So, to me, this all boils down to whether we think such a dependency should be allowed to exist in the archive. Given the apparent inevitability of a GR, I'd rather we just wait and see how it turns out. Bdale pgplEezrE9YdF.pgp Description: PGP signature
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Bdale Garbee writes (Bug#765803: Status of prompting / notification on upgrade for init system switch?): Ian Jackson ijack...@chiark.greenend.org.uk writes: 4. So, if an existing installation has its init system switched, as a result of upgrading or of installing packages, that is a bug (unless it is not possible to retain the existing init system). The caveat in (4) avoids prejudging the results of the coupling question which is the subject of the GR process at the moment. I don't think it does so sufficiently to allow me to be in favor of this resolution. Can you suggest some weaker text which would help ? I agree that we did not intend there to be some spontaneous move to transition all existing sysvinit users to systemd. That is what is happening and it is how many people are interpreting the TC resolution. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21574.57293.379463.659...@chiark.greenend.org.uk
Bug#765803: Status of prompting / notification on upgrade for init system switch?
El mar, 21 de oct 2014 a las 10:19 , Tollef Fog Heen tfh...@err.no escribió: ]] Russ Allbery Hello Russ, CTTE, Hello, systemd maintainers. We (the Technical Committee) have received a request to override a maintainer decision around whether systems are switched from sysvinit to systemd on upgrade. However, it's not clear to me that an actual decision has been made that we would need to override. There have been multiple (fairly high-noise) discussions in debian-devel about this, and some previous concrete design discussion, but in all of the other, mostly unproductive threads on this topic, I've lost track of status or the current proposed approach. The currently implemented approach is largely the same as what we proposed and discussed publicly back in July (https://lists.debian.org/debian-devel/2014/07/msg00611.html). It's based on work by Steve Langasek, who did the groundwork to do the switch on upgrades within one release cycle by splitting up the sysvinit package and moving the contents into a new, non-essential sysvinit-core package. A summary of the changes: 1/ Introduction of a new, essential meta package named init, which depends on systemd-sysv | sysvinit-core | upstart 2/ sysvinit became a transitional package, which is non-essential, and pre-depends on init. 3/ Adjusting priorities of affected packages accordingly. New installations = The new init package will ensure that systemd-sysv is installed as default init on Linux and by demoting the priority of sysvinit and sysvinit-core to optional those packages will not be installed anymore. Upgrades On upgrades, the old, essential sysvinit package will be replaced by the new, non-essential sysvinit package which pulls in the new init package which in turn makes sure systemd-sysv is installed. In summary, on both new installations and upgrades, the default is switched. Upgrade safety measures === An important detail is, that on upgrades, we keep the sysvinit package installed, which ships /lib/sysvinit/init. This makes it very easy to boot using sysvinit, even if systemd is the default /sbin/init. We proposed a patch for grub2 (https://bugs.debian.org/757298), which makes this even more straightforward. Unfortunately this patch hasn't been merged yet and we are still waiting for a reply from the maintainer. One change is that we see there is a need for a check in postinst that will look for common misconfigurations and potential errors and if so, inform the user about those problems and how he can fix those or roll back to sysvinit (which is basically as simple as running apt-get install sysvinit-core). We'd like to ship those checks in a dedicated script, which can be run by the user at any time. So far, we believe that the best course of action is, to only show that debconf prompt if potential problems are detected. This could be easily changed though, to always show the debconf prompt on upgrades to raise awareness and visibility of the change. We believe it is a bad idea to stop changing to systemd on upgrades. One of the reasons for this is we have the dependencies in place to actually get upgrades and initial installations to behave as specified. If we change how we want this done, somebody needs to sit down and do that work again, testing all the various edge cases. Getting this right is not trivial. Two weeks before the freeze is pretty late to start that work. Prior art = We also like to mention, that there is prior art regarding this change. When we switched to dependency based booting in squeeze, this was done on new installations as well as on upgrades. I would be particularly interested in your take on the analysis that Steve Langasek posted to the debian-devel thread on why listing systemd-shim as the first alternative dependency for libpam-systemd makes sense and should not cause any negative effects for systemd users. In a steady state, this would probably be ok. However, we've so far seen two instances of -shim breaking for systemd users (https://bugs.debian.org/746242 and https://bugs.debian.org/765101), by shipping outdated security policies. We are worried that this will happen again on future updates of systemd. Josh Triplett proposed a long term solution to the problem you point out here that will work across systemd upgrades. What are your thoughts on that solution? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765101#38 We are also worried about it still having release critical bugs and the feedback we are hearing from the desktop maintainers is that they see bugs which are tracked down to bugs in -shim. We therefore don't believe that is a good choice for desktop users. Steve's argument is that choosing sysvinit-core over systemd-sysv should automatically reflect on choosing systemd-shim over systemd-sysv. We do not necessarily think this is the case and both decisions need to be
Bug#765803: Status of prompting / notification on upgrade for init system switch?
On Sun, 19 Oct 2014 21:10:10 +1100 Stuart Prescott stu...@debian.org wrote:
inittab_unusual_lines=$(
grep '^[^#]' /etc/inittab |
while read line ; do
case $line in
'id:2:initdefault:') ;;
[...]
I wonder if it would just be easier to look at the md5sum of the file and
compare it to the md5sum of the inittab that was shipped in various releases
-- that's a fairly idiomatic approach to dealing with config files that
changed.
I considered that approach, but that has two issues:
- It doesn't take into account inittab files that have a mixture of
lines from the inittab files of multiple releases, all of which are
supported. The approach I used can include lines from any number of
inittab variations.
- It can't check for generated lines for serial consoles or similar;
finish-install can generate various additional inittab lines, which
the check should include.
- It unnecessarily prompts even if only comments or whitespace have been
edited.
modified_initscripts=$(
grep -lE '^/etc/init\.d/' /var/lib/dpkg/info/*.conffiles |
xargs basename -s '.conffiles' |
xargs dpkg -V |
grep '^..5.. c /etc/init\.d/' |
cut -d' ' -f3
)
For testing for modified init scripts, see also #760897 -- note that dpkg -V
requires jessie's dpkg (it is not available in wheezy). For some upgrades
between releases, we have advocated that people upgrade dpkg and apt first
and
then upgrade to the new release using the new versions of the tools but this
is far from idiot proof. There's a persistent expectation that just doing a
dist-upgrade should be enough and we see day-in-day-out that people do *not*
read the release notes.
Gah, I didn't realize that dpkg -V didn't exist in wheezy. The package
with this check in its init script could have a Pre-Depends on jessie's
dpkg, which would solve the problem, but that may or may not be
desirable.
Based on the code from 760897, here's a version that should work with
wheezy's dpkg:
modified_initscripts=$(
dpkg-query --show -f'${Conffiles}' |
sed 's, /,\n/,g' |
sed -n '/^\/etc\/init\.d\//s/^\([^ ]*\) \(.*\)$/\2 \1/p' |
md5sum --quiet -c 2/dev/null |
cut -d: -f1
)
(Note that md5sum exits with non-zero if any of the checksums fail, but
since it isn't the last thing in the pipe, that doesn't actually matter
here.)
- Josh Triplett
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141020031036.GA21941@thin
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Hello Russ, Russ Allbery [2014-10-18 20:59 -0700]: When one of you has a chance, could you update this bug with the current thinking around how to handle upgrades I'll leave this to the Debian maintainers, as I'm mostly responsible for the Ubuntu side, haven't really discussed this with the two Michaels/Tollef/Marco, and I don't feel qualified to speak for the Debian systemd team. My personal opinion: Given how close we are to the release and how many regression reports we still get, it seems prudent to not change the currently running init systems for upgrades for Jessie yet, but only set up systemd for new installs. I know this is not really in the spirit of the TC decision to make systemd the default init system, but at this point in time it might be the pragmatic compromise. The systemd package gets literally swamped with bug reports (of all kinds of usefulness/quality), and there's simply not enough maintainers to keep up with the flood. Many of those are indeed not actual bugs in systemd, but bugs in other packages, local misconfiguration, or mere misunderstanding, but a fair amount *are* bugs in our integration (for the release it doesn't matter that much whether they are in systemd itself or other packages). The one thing that I'd really like to avoid is interactive prompting. As much heat as the init system debate produced, from an user's POV it's pretty much a tempest in a teapot. Quite frankly, as a user I don't care that much about init systems, I just want my system to boot and apt install mysql to DTRT. Moreso, do we really expect a user to make this decision on upgrades? Look how hard it was even for us as DDs or the TC to make an informed decision -- I really don't want to push this to the user: [ ] Install init system A (may degrade some things) [ ] Install init system B (may break some things) IMHO it's a distro's job to make this qualified decision for the user based on which system he upgrades or installs. around the ordering of dependencies in libpam-systemd, and some of the other ideas (such as attempting to detect systems with /etc/inittab configuration or init scripts that don't follow systemd's assumptions) raised in those threads? I haven't looked at those in detail. It's great to see that people work on such heuristics for upgrades, but TBH it always takes a while to stabilize those. I would be particularly interested in your take on the analysis that Steve Langasek posted to the debian-devel thread on why listing systemd-shim as the first alternative dependency for libpam-systemd makes sense and should not cause any negative effects for systemd users. As https://bugs.debian.org/765101 showed, installing systemd-shim has not always been entirely inert/regression free under systemd as pid 1, but to be fair this has been the only bug of that kind ever, and there's a better solution proposed in that bug which will make this never happen again. The other direction (running sysvinit or upstart with -shim) has not been so unproblematic though, as systemd-shim's bug list shows. This definitively needs some love, but then again we've run this for a fair while in Ubuntu (even in our 14.04 LTS) without too many problems. So my feeling is that we can certainly stabilize -shim by the jessie release. (We need to do that anyway, as we need to support sysvinit regardless of what we do on upgrades/new installs.) Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Martin Pitt writes (Bug#765803: Status of prompting / notification on upgrade for init system switch?): My personal opinion: Given how close we are to the release and how many regression reports we still get, it seems prudent to not change the currently running init systems for upgrades for Jessie yet, but only set up systemd for new installs. I know this is not really in the spirit of the TC decision to make systemd the default init system, but at this point in time it might be the pragmatic compromise. I don't think the TC decision should be read as mandating that existing installations should be switched when upgrading from wheezy. As I have said, we (Debian) do not usually change the user's existing MTA, cron daemon, webserver, desktop, inetd, etc. etc. etc. when we change the default. I don't think this is any different. The question of whether this should be done is already with the TC. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21573.16345.455278.654...@chiark.greenend.org.uk
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Ian Jackson ijack...@chiark.greenend.org.uk writes: I don't think the TC decision should be read as mandating that existing installations should be switched when upgrading from wheezy. As I have said, we (Debian) do not usually change the user's existing MTA, cron daemon, webserver, desktop, inetd, etc. etc. etc. when we change the default. I don't think this is any different. I agree that previous TC decisions don't say anything one way or the other about whether systems should have their init systems changed on upgrade. I think default is about what we install with fresh installs. That's consistent with the other examples you list, where we've picked a default. The question of whether this should be done is already with the TC. However, if the systemd maintainers end up agreeing with Martin, I think that means there is no conflict and nothing that the TC needs to rule on. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ppdm8xit@hope.eyrie.org
Bug#765803: Status of prompting / notification on upgrade for init system switch?
On Sat, 18 Oct 2014 20:59:54 -0700 Russ Allbery r...@debian.org wrote: When one of you has a chance, could you update this bug with the current thinking around how to handle upgrades, around the ordering of dependencies in libpam-systemd, and some of the other ideas (such as attempting to detect systems with /etc/inittab configuration or init scripts that don't follow systemd's assumptions) raised in those threads? Not speaking for the systemd maintainers, but I just wrote and tested the following shell code to detect sysvinit-specific configuration (modified /etc/inittab or modified init scripts) that may indicate a need for manual sysadmin action (and thus a prompt). This needs a bit of work to add potential serial console getty lines generated by finish-install to the list of expected lines, as well as any other lines generated by older versions of finish-install. inittab_unusual_lines=$( grep '^[^#]' /etc/inittab | while read line ; do case $line in 'id:2:initdefault:') ;; 'si::sysinit:/etc/init.d/rcS') ;; '~~:S:wait:/sbin/sulogin') ;; 'l0:0:wait:/etc/init.d/rc 0') ;; 'l1:1:wait:/etc/init.d/rc 1') ;; 'l2:2:wait:/etc/init.d/rc 2') ;; 'l3:3:wait:/etc/init.d/rc 3') ;; 'l4:4:wait:/etc/init.d/rc 4') ;; 'l5:5:wait:/etc/init.d/rc 5') ;; 'l6:6:wait:/etc/init.d/rc 6') ;; 'z6:6:respawn:/sbin/sulogin') ;; 'ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now') ;; 'pf::powerwait:/etc/init.d/powerfail start') ;; 'pn::powerfailnow:/etc/init.d/powerfail now') ;; 'po::powerokwait:/etc/init.d/powerfail stop') ;; '1:2345:respawn:/sbin/getty 38400 tty1') ;; '2:23:respawn:/sbin/getty 38400 tty2') ;; '3:23:respawn:/sbin/getty 38400 tty3') ;; '4:23:respawn:/sbin/getty 38400 tty4') ;; '5:23:respawn:/sbin/getty 38400 tty5') ;; '6:23:respawn:/sbin/getty 38400 tty6') ;; *) echo $line ;; esac done ) modified_initscripts=$( grep -lE '^/etc/init\.d/' /var/lib/dpkg/info/*.conffiles | xargs basename -s '.conffiles' | xargs dpkg -V | grep '^..5.. c /etc/init\.d/' | cut -d' ' -f3 ) if [ -n $inittab_unusual_lines ] || [ -n $modified_initscripts ]; then # Substitute these variables into a debconf template and display it cat EOF /etc/inittab: $inittab_unusual_lines Modified init scripts: $modified_initscripts EOF fi -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141019061025.GA2391@thin
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Hello, systemd maintainers. We (the Technical Committee) have received a request to override a maintainer decision around whether systems are switched from sysvinit to systemd on upgrade. However, it's not clear to me that an actual decision has been made that we would need to override. There have been multiple (fairly high-noise) discussions in debian-devel about this, and some previous concrete design discussion, but in all of the other, mostly unproductive threads on this topic, I've lost track of status or the current proposed approach. When one of you has a chance, could you update this bug with the current thinking around how to handle upgrades, around the ordering of dependencies in libpam-systemd, and some of the other ideas (such as attempting to detect systems with /etc/inittab configuration or init scripts that don't follow systemd's assumptions) raised in those threads? I would be particularly interested in your take on the analysis that Steve Langasek posted to the debian-devel thread on why listing systemd-shim as the first alternative dependency for libpam-systemd makes sense and should not cause any negative effects for systemd users. Thanks! -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zjcsaev9@hope.eyrie.org
