Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
On Fri 2017-06-02 02:53:47 +0200, Michael Biebl wrote: > Seems like you want a Breaks/Replaces: runit-init in runit to ensure the > package is properly upgraded for users who have already runit-init > installed. good call, thanks for the reminder. I'll do that in 2.1.2-9.2, which i'll upload shortly and then send an unblock. --dkg signature.asc Description: PGP signature
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
On Wed, 31 May 2017 13:26:36 -0400 Daniel Kahn Gillmor wrote: > I apologize for the oversight, and want to know if it'd be ok for me to > upload 2.1.2-9.2 using the attached debdiff. I've pushed a queue of > these changes into the "unstable" branch at > https://anonscm.debian.org/git/collab-maint/runit.git already if you'd > prefer to review them there. Seems like you want a Breaks/Replaces: runit-init in runit to ensure the package is properly upgraded for users who have already runit-init installed. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
Hi all-- On Tue 2017-05-30 13:07:01 -0400, Daniel Kahn Gillmor wrote: > I've now done this NMU, and filed #863732 to unblock the upload. > > I've pushed the changes in a git branch to > https://anonscm.debian.org/git/collab-maint/runit.git, which is forked > from of https://anonscm.debian.org/git/users/kaction-guest/runit.git and > should probably be re-merged at some point. > > fwiw, the practice of keeping just the debian/ directory in git seems > odd to me and makes it more difficult for me to contribute to the > NMU-maintenance of the package. if i was going to do more work on the > package, i'd certainly prefer it to be converted to a standard > git-buildpackage-style "ladder" repo. I regret to say that i think i did this upload suboptimally. by just dropping the runit-init package, we've left debian users who want runit as pid 1 with no options other than to rebuild the package, because nothing is shipping /sbin/runit or /sbin/runit-init. in jessie, /sbin/runit and /sbin/runit-init are both shipped in the runit package. What i should have done is to move /sbin/runit and /sbin/runit-init into the runit package itself, rather than drop them entirely. I've made this change and would like to propose a 2.1.2-9.2 upload, with attached debdiff. I've tested this with a guest system which now does load runit as PID 1 when booted with a kernel argument of "init=/sbin/runit-init". I apologize for the oversight, and want to know if it'd be ok for me to upload 2.1.2-9.2 using the attached debdiff. I've pushed a queue of these changes into the "unstable" branch at https://anonscm.debian.org/git/collab-maint/runit.git already if you'd prefer to review them there. Regards, --dkg diff -Nru runit-2.1.2/debian/changelog runit-2.1.2/debian/changelog --- runit-2.1.2/debian/changelog 2017-05-30 11:46:28.0 -0400 +++ runit-2.1.2/debian/changelog 2017-05-31 12:44:38.0 -0400 @@ -1,3 +1,11 @@ +runit (2.1.2-9.2) unstable; urgency=medium + + * non-maintainer upload + * re-add /sbin/runit{,-init} to runit package so it remains possible to +use runit as PID 1 + + -- Daniel Kahn Gillmor Wed, 31 May 2017 12:44:38 -0400 + runit (2.1.2-9.1) unstable; urgency=medium * non-maintainer upload diff -Nru runit-2.1.2/debian/control runit-2.1.2/debian/control --- runit-2.1.2/debian/control 2017-05-28 15:07:36.0 -0400 +++ runit-2.1.2/debian/control 2017-05-31 12:44:38.0 -0400 @@ -6,7 +6,6 @@ Homepage: http://smarden.org/runit/ Build-Depends: bash-completion, debhelper (>= 9), - dh-exec, dh-systemd, dh-runit (>= 1.6), dh-buildinfo (>= 0.11+nmu1), diff -Nru runit-2.1.2/debian/rules runit-2.1.2/debian/rules --- runit-2.1.2/debian/rules 2017-05-28 15:08:57.0 -0400 +++ runit-2.1.2/debian/rules 2017-05-31 12:44:38.0 -0400 @@ -9,9 +9,6 @@ override_dh_systemd_enable: dh_systemd_enable --name runit -override_dh_installman-arch: - dh_installman - override_dh_runit: runscripts/getty dh_runit diff -Nru runit-2.1.2/debian/runit.install runit-2.1.2/debian/runit.install --- runit-2.1.2/debian/runit.install 2017-05-28 14:51:14.0 -0400 +++ runit-2.1.2/debian/runit.install 2017-05-31 12:44:38.0 -0400 @@ -8,7 +8,9 @@ runit-*/src/chpst /usr/bin runit-*/src/runsvchdir /usr/sbin runit-*/src/utmpset/usr/sbin +runit-*/src/runit-init /sbin +runit-*/src/runit /sbin runit-*/etc/debian/1 /etc/runit runit-*/etc/2 /etc/runit -runit-*/etc/debian/3 /etc/runit \ No newline at end of file +runit-*/etc/debian/3 /etc/runit diff -Nru runit-2.1.2/debian/runit.manpages runit-2.1.2/debian/runit.manpages --- runit-2.1.2/debian/runit.manpages 2017-05-28 14:51:14.0 -0400 +++ runit-2.1.2/debian/runit.manpages 2017-05-31 12:40:18.0 -0400 @@ -5,4 +5,6 @@ runit-*/man/chpst.8 runit-*/man/runsvchdir.8 runit-*/man/utmpset.8 +runit-*/man/runit.8 +runit-*/man/runit-init.8 debian/contrib/update-service.8 signature.asc Description: PGP signature
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
On Sun 2017-05-28 15:14:24 -0400, Daniel Kahn Gillmor wrote: > On Sun 2017-05-28 19:54:33 +0200, Ivo De Decker wrote: >> If this bug can be fixed by removing runit-init, the removal of the other >> packages isn't necessary, but please note that this would need to happen very >> soon. > > fwiw, i'm willing to provide such an NMU, because i consider runit to be > a useful package. I've now done this NMU, and filed #863732 to unblock the upload. I've pushed the changes in a git branch to https://anonscm.debian.org/git/collab-maint/runit.git, which is forked from of https://anonscm.debian.org/git/users/kaction-guest/runit.git and should probably be re-merged at some point. fwiw, the practice of keeping just the debian/ directory in git seems odd to me and makes it more difficult for me to contribute to the NMU-maintenance of the package. if i was going to do more work on the package, i'd certainly prefer it to be converted to a standard git-buildpackage-style "ladder" repo. Regards, --dkg signature.asc Description: PGP signature
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
Hi, > runit-init: Cannot reboot or shutdown after installing (or removing) the > package. See also: https://bugs.debian.org/863539 https://bugs.debian.org/863541 https://bugs.debian.org/863542 https://bugs.debian.org/863543 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
Hi there-- On Sun 2017-05-28 19:54:33 +0200, Ivo De Decker wrote: > On Sun, May 28, 2017 at 02:39:00PM +0200, Jan Niehusmann wrote: >> May I suggest only removing runit-init from the runit source package, if >> the bug can't be fixed in time for the stretch release? > > Sure. That just needs someone to upload such an NMU very soon. I suggested > this already at the end of message #49: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861536#49 > >> Because runit itself doesn't cause the issue discussed here, is useful >> on its own, and several packages depend on it. > > If this bug can be fixed by removing runit-init, the removal of the other > packages isn't necessary, but please note that this would need to happen very > soon. fwiw, i'm willing to provide such an NMU, because i consider runit to be a useful package. However, it'll be done under duress, as i don't think that the removal of runit-init is strictly necessary. fwiw, i've run debian systems with runit as PID 1 for years, long before there was a runit-init package, and without the runit-init package even today. So it's certainly possible to achieve the runit-as-pid-1 situation without the package. But if the only issue with runit-init is the first reboot when switching initsystems, then i don't think that should rise to the level of an RC bug. as written upthread, when you switch initsystems, some level of pain is to be expected. removing runit-init from debian just means that people switching init systems will have *more* pain (because they'll be totally on their own with the conversion). anyway, if folks want this NMU in order to keep runit in debian, i'll provide it, but i don't think it's a great idea. --dkg signature.asc Description: PGP signature
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
Hi, On Sun, May 28, 2017 at 07:54:33PM +0200, Ivo De Decker wrote: > On Sun, May 28, 2017 at 02:39:00PM +0200, Jan Niehusmann wrote: > > May I suggest only removing runit-init from the runit source package, if > > the bug can't be fixed in time for the stretch release? > > Sure. That just needs someone to upload such an NMU very soon. I suggested > this already at the end of message #49: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861536#49 But who decides that this is the right way to go? Just removing a package is not usually something which should be done with an NMU. Especially as this bug only affects systems switching to runit. There may be people happily running runit as their init system. Just leaving them with an unmaintained init system doesn't seem to be a good idea, either. In fact, that may be less user friendly than this bug. How could we handle future security issues in that package, for example? As runit-init is part of current stable, we need to provide some upgrade path if we want to remove it. BTW, according to the initial reporter, "The same procedure was required to return to systemd as PID1." So systemd seems to be broken in the same way. Therefore, simply replacing runit-init with a transitional package depending on systemd wouldn't work either. > If this bug can be fixed by removing runit-init, the removal of the other > packages isn't necessary, but please note that this would need to happen very > soon. Removing runit-init from the init package may be worse than keeping it, see above. Of course, removing runit-init, runit and all reverse-dependencies would be even worse, so it may be a workaround in case the release team decides that keeping runit-init in its current form is absolutely not acceptable. Jan
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
Hi, On Sun, May 28, 2017 at 02:39:00PM +0200, Jan Niehusmann wrote: > May I suggest only removing runit-init from the runit source package, if > the bug can't be fixed in time for the stretch release? Sure. That just needs someone to upload such an NMU very soon. I suggested this already at the end of message #49: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861536#49 > Because runit itself doesn't cause the issue discussed here, is useful > on its own, and several packages depend on it. If this bug can be fixed by removing runit-init, the removal of the other packages isn't necessary, but please note that this would need to happen very soon. Cheers, Ivo
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
May I suggest only removing runit-init from the runit source package, if the bug can't be fixed in time for the stretch release? Because runit itself doesn't cause the issue discussed here, is useful on its own, and several packages depend on it. Thanks, Jan
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
BTW, I really think this doesn't need to be RC. (Or, at least, should be stretch-ignore, because removing all the reverse-dependencies would be worse than just shipping with runit-init.) I agree it's bad to leave a user with a broken system. But in this case, the user gets an appropriate warning: root@sid:~# apt install runit-init Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: cgmanager fgetty getty-run libcgmanager0 libnih-dbus1 libnih1 systemd-shim Suggested packages: pm-utils The following packages will be REMOVED: init systemd-sysv The following NEW packages will be installed: cgmanager fgetty getty-run libcgmanager0 libnih-dbus1 libnih1 runit-init systemd-shim WARNING: The following essential packages will be removed. This should NOT be done unless you know exactly what you are doing! init systemd-sysv (due to init) 0 upgraded, 8 newly installed, 2 to remove and 0 not upgraded. Need to get 439 kB of archives. After this operation, 1,059 kB of additional disk space will be used. You are about to do something potentially harmful. To continue type in the phrase 'Yes, do as I say!' ?] If I get such a warning, and answer explicitly by typing "Yes, do as I say!", I'm not surprised if the system is broken afterwards. And in this case, the brokenness is easily fixed by hard-rebooting, if I understand it correctly. Not nice, but not a catastrope. Jan
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
On 05/28/2017 12:30 PM, Matthew Hoare wrote: > Would it be appropriate to provide these commands for temporary use > after switching init? This would be hack and not a proper solution which would meet Debian standards. Really, the only solution here is simply not to replace the init system from the user side or if you do it, deal with the fall out yourself. > I can attempt an NMU but I am relatively unskilled with Debian > packaging so it may take a while. We don't have that time anymore. Debian Stretch is going to be released in less than three weeks. Let's just please remove runit from Stretch. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
I can confirm that this issue also occurs with a fresh (debootstrap) installation of pure Debian stretch. I can also confirm that these four commands will reboot into the new init system without damaging the mounted filesystems: `echo 1 > /proc/sys/kernel/sysrq` `echo s > /proc/sysrq-trigger` `echo u > /proc/sysrq-trigger` `echo b > /proc/sysrq-trigger` Would it be appropriate to provide these commands for temporary use after switching init? I can attempt an NMU but I am relatively unskilled with Debian packaging so it may take a while. -- Matthew T. Hoare
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
On 05/27/2017 11:37 PM, Ivo De Decker wrote: >> Well, there is also ulibc being shipped with Debian stable. Yet, when >> someone tries to use it and breaks their system, it's not supported >> either. So, I don't think this policy can be sweepingly applied to >> every package. > > There is no package named 'ulibc', so I guess that's a typo. If you meant > uclibc, that package only ships uclibc-source, so installing that doesn't > break anything. Is it really relevant for the discussion whether I made a typo or not? My point is: There is a package called uclibc-source that people can install the source from, compile and install to completely hose their system. Simply because the C library is such a fundamental component of the system that it cannot be trivially replaced. To use the popular car analogy: Replacing the installed radio with a third-party radio will work for most people without issues. However, replacing the gearbox will probably a lot of more headaches and requires advanced technical skills and knowledge. >> I fully agree. However, runit is one of the packages which is not >> automatically removed. > > No. But it can be manually removed. Then please let's do this. I already saw it was marked for that which is good. >> You really cannot expect a fundamental component like an init system >> to be easily replace by the end user the same way they can swap their >> default text editor. > > Well, in that case there shouldn't be a package that tries to swap the init > system. If there is a package that provides the tools to do so, but lets you > do it on your own, that's a different story. It will still allow you to break > your system, but you can do that with lots of tools (certainly with your text > editor). Uhm, the package is an alternative init system. Of course, it will try to replace the init system. What else is it supposed to do? That's one of the reason I am completely opposed to ship alternative init systems and the other relevant Linux distributions like Fedora, RHEL, SLE(D,S) and openSUSE only ship systemd either. Being such a critical component of the whole stack, it simply will never be able to trivially swapped out without breaking lots of things. Hence this bug report is completely moot. When people like the original bug reporter want to replace the init system, I assume they know what they are doing so they should be able to clean up the mess afterwards. Or do you let layman replace the carburetor on a car themselves without the proper skills and knowledge and then accept when they complain that something broke in the process? Really, things like the init system, the C library, the default compiler and the kernel are *not* user-servicable parts. If you don't know what you're doing, don't touch them and don't pester the maintainers with pointless bug reports. Plus, we also clearly decided in 2014 with the CTTE decision and the follow-up GR by Ian Jackson that we do not care about alternative init systems. > As there doesn't seem to be an easy way to get an acceptable runit-init > package, which replaces the init system by just installing a package, I don't > see how the current src:runit package can stay in stretch. If someone wants to > keep it, the best option is probably to remove the runit-init binary package, > so that the other binary packages can stay. As Roger noted, that would require > an NMU to do so. The same problem will apply to sysvinit, openrc, filerc and whatever other init system we have packaged in Debian as well. I don't want to test that myself right now, but I am 99% confident that installing the openrc package will let you with the 'poweroff' and 'reboot' commands broken until you perform a hard reset. > I'd be happy to unblock such a change (if it happens in the next few days, > given the release timing announced in > https://lists.debian.org/debian-devel-announce/2017/05/msg2.html). Thanks, but no thanks. I'm happy to provide patches and perform NMUs for all kinds of packages. But I'm not touching any of these alternative init systems because I consider them a complete waste of time. There is simply absolutely no technical justification to ship multiple init systems. If someone wants to use runit or any of the other init systems, they should take care of such issues themselves and not bother other people with that. There are more important issues to work on. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
Hi, On Fri, May 26, 2017 at 12:04:59PM +0200, John Paul Adrian Glaubitz wrote: > > > As the init system is a rather fundamental component of a Linux > > > distribution, it affects many other packages, directly or indirectly > > > and it's therefore too much of a burden to provide support for all > > > init systems available in Debian. Although runit is available in > > > Debian, it does not mean that it has to be fully supported. > > > > If an init system is shipped in a stable release, it has to be supported. > > Otherwise it should not be in a stable release. > > Well, there is also ulibc being shipped with Debian stable. Yet, when > someone tries to use it and breaks their system, it's not supported > either. So, I don't think this policy can be sweepingly applied to > every package. There is no package named 'ulibc', so I guess that's a typo. If you meant uclibc, that package only ships uclibc-source, so installing that doesn't break anything. > > > A possible solution would be to modify the runit postinst scripts > > > in a way that it does not automatically overwrite the symlinks > > > for the the above commands until the machine has been rebooted > > > (e.g. by placing a script which is run only once after the system > > > has been first rebooted with runit) so that the 'poweroff' and > > > 'reboot' commands are still sent to systemd. However, the lack of > > > a reply of the runit maintainer to this particular bug report seems > > > to indicate that there is currently no interest for such a solution. > > > > If the maintainer isn't interested in making sure that this package works as > > expected, it isn't fit for a stable release... > > I fully agree. However, runit is one of the packages which is not > automatically removed. No. But it can be manually removed. > > > Thus, in order to prevent this bug report from blocking the release > > > of Debian Stretch, I have reduced its severity to 'normal'. You > > > are still welcome to propose a patch to address this issue though, > > > it's just not relevant for the upcoming Debian release. > > > > This is not a good reason to downgrade a bug. > > Again, Debian has decided to adopt systemd as the standard init > system, the same way we have decided to adopt glibc and the Linux > kernel as the standard C libraries and kernels. > > You really cannot expect a fundamental component like an init system > to be easily replace by the end user the same way they can swap their > default text editor. Well, in that case there shouldn't be a package that tries to swap the init system. If there is a package that provides the tools to do so, but lets you do it on your own, that's a different story. It will still allow you to break your system, but you can do that with lots of tools (certainly with your text editor). As there doesn't seem to be an easy way to get an acceptable runit-init package, which replaces the init system by just installing a package, I don't see how the current src:runit package can stay in stretch. If someone wants to keep it, the best option is probably to remove the runit-init binary package, so that the other binary packages can stay. As Roger noted, that would require an NMU to do so. I'd be happy to unblock such a change (if it happens in the next few days, given the release timing announced in https://lists.debian.org/debian-devel-announce/2017/05/msg2.html). Cheers, Ivo
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
On Fri, 26 May 2017 11:28:48 +0200 Ivo De Decker wrote: > If the maintainer isn't interested in making sure that this package works as > expected, it isn't fit for a stable release... FYI. The maintainer cannot respond this for the time being [0]. [0] https://www.debian.org/News/2017/20170417 -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpiyl1AnAYm8.pgp Description: PGP signature
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
Hi! On Fri, May 26, 2017 at 11:28:48AM +0200, Ivo De Decker wrote: > If a package leaves the system in a broken state, that is very much release > critical. So I'm upgrading the bug to serious. It should probably be > 'critical' (breaks the whole system), but as both are RC, that doesn't matter > that much. That is correct and I'm not arguing that per se. > > As the init system is a rather fundamental component of a Linux > > distribution, it affects many other packages, directly or indirectly > > and it's therefore too much of a burden to provide support for all > > init systems available in Debian. Although runit is available in > > Debian, it does not mean that it has to be fully supported. > > If an init system is shipped in a stable release, it has to be supported. > Otherwise it should not be in a stable release. Well, there is also ulibc being shipped with Debian stable. Yet, when someone tries to use it and breaks their system, it's not supported either. So, I don't think this policy can be sweepingly applied to every package. > > The fact that it is in Debian is merely of the result of Debian's policy to > > not limit packages from entering the distribution unless the license or > > other serious concerns prevent it. > > No. If it's broken, it should not be in a stable release. We can still remove > this package. Which hasn't happened yet. The package has been open with an RC bug for longer than 10 days and yet it wasn't removed from testing. > > This policy is a result of Debian's decision to adopt systemd as > > its default init system [1] as well as the follow up general > > resolution [2] where Debian Developers decided that providing > > support for alternative init systems was not mandatory. > > > Furthermore, as also already explained, the problem you have run > > into cannot really be trivially solved as the installing runit > > does not replace the running instance of systemd with runit so > > it is to be expected for commands like 'poweroff' and 'reboot' > > to not work until the machine has been rebooted. > > The fact that problems cannot be trivially solved doesn't mean they are not > RC. Also, I don't see how it can be 'expected' that reboot doesn't work until > you reboot. How is this supposed to work? Doing a hard reset of the machine? I'm rather curious to hear how you suggest to resolve this issue then. If there was a trivial way, then there'd be a patch for this already. You cannot replace the running init system without rebooting the machine, simply because the kernel will panic the moment PID 1 exits. What the original bug reporter here is asking to work simply cannot work. You install runit, it removes systemd and overwrites the symbolic links for 'shutdown' and 'poweroff' while systemd is still running. It is therefore inevitable that these commands don't work until you reboot the machine. And, yes, if a user desires to introduce such a breaking change to their system, they are on their own. We *did* decide to focus on systemd after all, so I don't see why we should care if users intentionally decide to break their systems. > > A possible solution would be to modify the runit postinst scripts > > in a way that it does not automatically overwrite the symlinks > > for the the above commands until the machine has been rebooted > > (e.g. by placing a script which is run only once after the system > > has been first rebooted with runit) so that the 'poweroff' and > > 'reboot' commands are still sent to systemd. However, the lack of > > a reply of the runit maintainer to this particular bug report seems > > to indicate that there is currently no interest for such a solution. > > If the maintainer isn't interested in making sure that this package works as > expected, it isn't fit for a stable release... I fully agree. However, runit is one of the packages which is not automatically removed. > > Thus, in order to prevent this bug report from blocking the release > > of Debian Stretch, I have reduced its severity to 'normal'. You > > are still welcome to propose a patch to address this issue though, > > it's just not relevant for the upcoming Debian release. > > This is not a good reason to downgrade a bug. Again, Debian has decided to adopt systemd as the standard init system, the same way we have decided to adopt glibc and the Linux kernel as the standard C libraries and kernels. You really cannot expect a fundamental component like an init system to be easily replace by the end user the same way they can swap their default text editor. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
Control: severity -1 normal On 05/04/2017 07:22 PM, John Paul Adrian Glaubitz wrote: > I'd be tempted to lower the severity to 'normal'. Downgrading this now because it is not relevant for the Stretch release. I also just noticed that you are actually not running Debian but a spin called "BunsenLabs GNU/Linux", so I'm not sure why you are reporting this bug to Debian in the first place. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
Hi Matthew! > I ran `apt install runit-init` and then attempted to reboot with > `/sbin/reboot`, `/sbin/poweroff`, `init 0` & `init 6`, all to no > effect; no error messages were returned and the exit status of all of > the commands was zero. This happens because the computer is still running systemd as the init process and any runit commands will therefore not work until the computer has been rebooted with runit as the init system. I also don't think there is a trivial way to solve this problem. And, after all, with systemd being the default and supported init system on Debian as per GR decision, you are on your own anyways when you decided to switch to one of the alternative init systems. And since runit is not officially supported to be the init system in Debian, I don't think this bug qualifies as release critical either. I'd be tempted to lower the severity to 'normal'. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
Package: runit-init Version: 2.1.2-9 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? I ran `apt install runit-init` and then attempted to reboot with `/sbin/reboot`, `/sbin/poweroff`, `init 0` & `init 6`, all to no effect; no error messages were returned and the exit status of all of the commands was zero. * What exactly did you do (or not do) that was effective (or ineffective)? Reintalled systemd-sysv then rebooted into my Arch Linux system, chrooted into BunsenLabs then installed the package from the chroot and rebooted into that init system. * What was the outcome of this action? It worked :) The same procedure was required to return to systemd as PID1. -- System Information: Distributor ID: BunsenLabs Description:BunsenLabs GNU/Linux (Helium-dev) Release:x Codename: bunsen-helium-dev Architecture: x86_64 Kernel: Linux 4.10.0-11.1-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages runit-init depends on: ii getty-run 2.1.2-9 ii libc6 2.24-10 ii runit 2.1.2-9 runit-init recommends no packages. runit-init suggests no packages. -- no debconf information