Your message dated Sun, 04 Nov 2018 12:13:17 +0800
with message-id <[email protected]>
and subject line close as wontfix, as limitation is properly documented
has caused the Debian Bug report #438529,
regarding sysvinit: /sbin/runlevel output confused in single-user
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
438529: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438529
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: sysvinit
Version: 2.86.ds1-38
Severity: normal
This is complicated; please bear with me.
If I boot from cold to runlevel 2, everything is fine; runlevel
reports "N 2" as expected.
If I boot from cold to runlevel 1 (to monkey around as root), runlevel
reports "1 S", where I'd expect "N 1" or "S 1". If I then proceed to
runlevel 2, portmap is not launched from rc2.d, and NIS and NFS
(amongst other things) break in spectacular ways. If instead I
hand-launch portmap at runlevel 1, then proceed to runlevel 2, the
remainder of the boot succeeds, and runlevel reports "S 2".
I deduce that portmap is being launched from rcS.d, then killed from
rc1.d; then /etc/init.d/rc sees "S 2" reported by runlevel, finds
rcS.d/S43portmap rather than rc1.d/K81portmap, thinks portmap must be
running already, and refuses to launch it. I can kludge round this by
renaming rcS.d/S43portmap to rcS.d/S43portmap0, but now I've looked
closer, it would appear that the underlying bug is in runlevel, or
wherever it gets its information from. The bug in runlevel is there
in sarge, but didn't matter as its /etc/init.d/rc wasn't so picky.
But then again, I'm aware changing what runlevel reports may break
other things. Feel free to reassign this to portmap.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages sysvinit depends on:
ii initscripts 2.86.ds1-38 Scripts for initializing and shutt
ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries
ii libselinux1 1.32-3 SELinux shared libraries
ii libsepol1 1.14-2 Security Enhanced Linux policy lib
ii sysv-rc 2.86.ds1-38 System-V-like runlevel change mech
ii sysvinit-utils 2.86.ds1-38 System-V-like utilities
sysvinit recommends no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Tags: wontfix
Hi Martin,
"Martin J. Carter" <[email protected]>:
> If I boot from cold to runlevel 2, everything is fine; runlevel
> reports "N 2" as expected.
Yes, indeed.
> If I boot from cold to runlevel 1 (to monkey around as root), runlevel
> reports "1 S", where I'd expect "N 1" or "S 1".
/etc/init.d/single which is executed in runlevel 1 calls "exec init -t1
S" and switches runlevel from 1 into S, thus giving us "1 S".
> If I then proceed to runlevel 2, portmap is not launched from rc2.d,
> and NIS and NFS (amongst other things) break in spectacular ways. If
> instead I hand-launch portmap at runlevel 1, then proceed to runlevel
> 2, the remainder of the boot succeeds, and runlevel reports "S 2".
> I deduce that portmap is being launched from rcS.d, then killed from
> rc1.d; then /etc/init.d/rc sees "S 2" reported by runlevel, finds
> rcS.d/S43portmap rather than rc1.d/K81portmap, thinks portmap must be
> running already, and refuses to launch it. I can kludge round this by
> renaming rcS.d/S43portmap to rcS.d/S43portmap0, but now I've looked
> closer, it would appear that the underlying bug is in runlevel, or
> wherever it gets its information from. The bug in runlevel is there
> in sarge, but didn't matter as its /etc/init.d/rc wasn't so picky.
> [...]
> I've now RTFM on init(8) under etch: not only is /bin/runlevel
> performing as advertised, but I've also been stepping into the
> blockhole mentioned in the new paragraph in the WARNINGS section. The
> only way round all this I can see would be to special-case S -> 2 as
> (S then 1) -> 2 in /etc/init.d/rc, but that way madness lies.
Indeed, Debian does not support switching from Runlevel 1 into 2, but
only Runlevel S into 2. After switching into Runlevel 1, the best way
back is to reboot as said in init(8).
Petter Reinholdtsen <[email protected]>:
> And runlevel 1 is not really the single user runlevel either. It is a
> runlevel used to pass into the single user runlevel. So there is a
> distinct difference between booting using 'linux S' or 'linux single'
> as the kernel paramenter, and using 'linux 1'.
Indded.
> Only the latter work as single user is intended to work.
This is not correct, as in init(8), Runlevel 1 is only useful to swtich
from Runlevels 2-5 into single user mode. The cold boot should use
'linux single' as what we are doing in grub.
> The others only run the boot scripts in the boot runlevel (which is
> the scrints in rcS.d/, before it switches to runlevel S which only
> runs /sbin/sulogin .
That's correct and is what we expect as "single user mode".
> [...]
> So I am not sure if this is solvable, and suggest you boot using
> 'linux 1' instead of 'linux s' to boot in single user.
Using 'linux s' is the correct way, as stated above.
Cheers,
Benda
--- End Message ---
