Package: sysvinit-core
Version: 2.88dsf-53.2
Severity: critical
After a failed switch to systemd today (Debian bug #751585), I tried to
switch back to sysvinit but found /sbin/init missing after a reboot,
which of course prevented the system from booting.
/sbin was available in the emergency
[Michael Gold]
/sbin was available in the emergency shell and contained some files,
but 'init' wasn't there. 'dpkg -L sysvinit-core' ended at the line
'/sbin' (i.e., it was missing /sbin/shutdown, /sbin/init, etc.). I
eventually figured out to run 'dpkg -i' on that .deb; this restored
Control: reassign -1 systemd-sysv 204-6
On 2014-06-14 16:18 +0200, Michael Gold wrote:
Package: sysvinit-core
Version: 2.88dsf-53.2
Severity: critical
After a failed switch to systemd today (Debian bug #751585), I tried to
switch back to sysvinit but found /sbin/init missing after a
Control: reopen -1
Closing bugs which render the system unbootable seems a bit premature to me.
On 2014-06-14 17:03 +0200, Michael Biebl wrote:
Am 14.06.2014 16:55, schrieb Sven Joachim:
Control: reassign -1 systemd-sysv 204-6
On 2014-06-14 16:18 +0200, Michael Gold wrote:
Package:
On Sat, Jun 14, 2014 at 16:47:45 +0200, Petter Reinholdtsen wrote:
[Michael Gold]
/sbin was available in the emergency shell and contained some files,
but 'init' wasn't there. 'dpkg -L sysvinit-core' ended at the line
'/sbin' (i.e., it was missing /sbin/shutdown, /sbin/init, etc.). I
Am 14.06.2014 17:15, schrieb Sven Joachim:
This is not going to happen as this conflicts with #748355.
#748355 is about the conflict with sysvinit, not with sysvinit-core.
Fair enough. Using Conflicts: sysvinit-core in systemd-sysv would have
been the correct thing to do anyway, i.e. the fix
On Sat, Jun 14, 2014 at 17:34:21 +0200, Michael Biebl wrote:
That said, I can not reproduce the sequence of events which make
/sbin/init dissappear.
I've installed systemd-sysv in a VM, then ran apt-get install
sysvinit-core and /sbin/init was available afterwards.
So something else must
tags 751589 + unreproducible
thanks
Am 14.06.2014 18:22, schrieb Michael Gold:
On Sat, Jun 14, 2014 at 17:34:21 +0200, Michael Biebl wrote:
That said, I can not reproduce the sequence of events which make
/sbin/init dissappear.
I've installed systemd-sysv in a VM, then ran apt-get install
[Hit the send button a bit too early]
Am 14.06.2014 19:34, schrieb Michael Biebl:
As I'm not able to reproduce the issue, I'm unable to test if replacing
Breaks with Conflicts actually fixes this particular bug you are seeing.
Michael, could you test if you can reliably reproduce the issue?
If
Am 14.06.2014 18:31, schrieb Michael Biebl:
That said, even with that sequence of events /sbin/init is available here.
I'm marking the bug as unreproducible until we have steps how we can
reproduce the issue.
root@pluto:/# apt-get remove systemd
Reading package lists... Done
Building
On 2014-06-14 19:37 +0200, Michael Biebl wrote:
[Hit the send button a bit too early]
Am 14.06.2014 19:34, schrieb Michael Biebl:
As I'm not able to reproduce the issue, I'm unable to test if replacing
Breaks with Conflicts actually fixes this particular bug you are seeing.
Michael, could
Control: tags -1 - unreproducible
Control: reassign -1 sysvinit-core systemd-sysv
Control: found -1 sysvinit/2.88dsf-53
Control: found -1 systemd/204-6
You can't remove the systemd package while systemd is still the active init.
How did you force the removal?
That said, even with that
On Sat, Jun 14, 2014 at 18:31:25 +0200, Michael Biebl wrote:
Did you try apt-get remove systemd? According to apt-history that was
the first command I ran after installing it.
You can't remove the systemd package while systemd is still the active init.
How did you force the removal?
I
13 matches
Mail list logo
