[Pkg-sysvinit-devel] Re: init do not pass correct PREVLEVEL when switching from runlevel S

[Henrique de Moraes Holschuh]

On Thu, 14 Sep 2006, Petter Reinholdtsen wrote:
> [Henrique de Moraes Holschuh]
> > S has never been the single user runlevel.  WTF is init doing with S that
> > got you worried?
> 
> It is storing 'S' in the runlevel variable, and passing it as
> RUNLEVEL=S when you do 'telinit s', and 'telinit 1' is not the same as
> 'telinit s'.  For 'telinit 1', it runs the stop scripts before asking
> for the password, for 'telinit s', it just ask for the password.

Yikes.  Let's fix that.  Is that a new regression, or something that has
been there since long ago?  Is Miquel still around here?  He should know
better than we do, he's the living memory of sysv-init.

What init is doing right now *is* correct, btw.  It just was never meant to
happen (it should not allow anyone to really request a switch to runlevel S
directly after the initial bootstrap).

Now, we need to decide how to go about it.  Documentation suggests I was
slightly mistaken (the system CAN be in the "S" runlevel, but you are meant
to get to it only through a kernel boot, or from runlevel "1" -- so it is
runlevel "1" that you are never into, you just go through it).

This is also why runlevel 1 has only stop scripts, and runlevel S has only
start scripts.   It is fucked up, but it makes sense.

The fix is to teach telinit that "telinit S" always mean "telinit 1" unless
you are booting, or going from runlevel 1 to runlevel S, I think.

> This made me confused, and I started reading the source.  Our init
> implementation uses 'S' as the runlevel code for single user, and do
> not understand that '1' and 'S' are equivalent.  See also #372669 and
> #387351, which got me started on this testing.

1 and S are not equivalent runlevels (inside init), but they're supposed to
be equivalent in telinit's human interface (which is...  misleading to say
the least).

> > What you describe is the the truckload of crap inherited from System
> > V, and that is something you really ought to know about.
> 
> Yes.  But our boot system seem to include such crap in the source, so
> we need to address it. :/

Heh, you read the paper, you know how I'd suggest we go about it.

> And yes, I know it is an optimization, and I care about these
> optimizations because I want to make the boot quicker.

Then get ready for an *extreme* ammount of work.  Parallel device detection
patches hit LKML already, and that fucks up userspace sideways if you have
*anything* that can't deal with device detection order being shuffled around
at every boot.   No, it doesn't mean udev is mandatory, but it does mean you
need to hunt down exactly which /dev/foo* has the filesystem you want, etc.

And it sheds off a lot of boot time when you enable it.  So does using Linux
BIOS too, actually.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh