compat: failed to enter rc1.d by putting 1 in boot param

This is caused by the rc-default script, which invokes the default runlevel once the rcS job has stopped.

It does this by a combination of grep on the command-line and /etc/inittab files, then invoking telinit with whatever argument it found.

It only handles -s/single/S being on the command line, because that's all I knew about at the time -- it would need patching/modifying to also look for the other runlevel names and set $RL appropriately.

OK, my workaround is to modify /etc/event.d/rc-default, and make it like the following. It works for me. Thanks.
------
start on rcS/stop

script
        runlevel --reboot || true

        if grep -q -w -- "-s\|single\|S" /proc/cmdline; then
            telinit S
        elif grep -qE -w -- "[1-5]" /proc/cmdline; then
            RL="$(grep -Eo -w -- "[1-5]" /proc/cmdline)"
            if [ -n "$RL" ]; then
                telinit $RL
            else
                telinit 2
            fi
        elif [ -r /etc/inittab ]; then
            RL="$(sed -n -e "/^id:[0-9]*:initdefault:/{s/^id://;s/:.*//;p}" /etc
/inittab || true)"
            if [ -n "$RL" ]; then
                telinit $RL
            else
                telinit 2
            fi
        else
            telinit 2
        fi
end script
-------------

Oops... the above is not a good one, should be [0-9], however, if selinux=0 is assigned in bootparam, upstart will go wrong.
Therefore maybe make it like:
------
start on rcS/stop

script
        runlevel --reboot || true

        if grep -q -w -- "-s\|single\|S" /proc/cmdline; then
            telinit S
        elif grep -qE -- "[[:space:]]+[0-9][[:space:]]+" /proc/cmdline; then
            RL="$(grep -Eo -- "[[:space:]]+[0-9][[:space:]]+" /proc/cmdline)"
            if [ -n "$RL" ]; then
                telinit $RL
            else
                telinit 2
            fi
        elif [ -r /etc/inittab ]; then
            RL="$(sed -n -e "/^id:[0-9]*:initdefault:/{s/^id://;s/:.*//;p}" /etc
/inittab || true)"
            if [ -n "$RL" ]; then
                telinit $RL
            else
                telinit 2
            fi
        else
            telinit 2
        fi
end script
-------------
I bet you have better solution about this.

This should be fixed upstream by adding a --default option to telinit; and have that check things like the kernel command-line, and inittab file, and then emit the appropriate runlevel event.

rc-default can then just be exec telinit --default

the workaround fix doesn't work for me. i'm using feisty. is there any other way to fix this, or is it even being worked on?

For feisty, the rc-default is one line different from that in Edgy.
It's
  start on stopped rcS
in the beginning.

I changed it and that didn't work for me either. still booting to runlevel 2.

has anyone with feisty tested this?

Tested with Xubuntu Feisty. Nothing happens, whatever is entered in the grub-menu.lst kernel line.

Ugly.

upstream: missing feature of telinit
Ubuntu: which means it has to be done in the Ubuntu-supplied jobs, badly

This is still broken in hardy:
adding '3' to the end of my grub command line still resulted in runlevel 2. It appears that the fix mentioned in comment 4 hasn't yet made it to hardy.

ask yourself if you really need runlevels? (upstart admins dont' seem to think so, they say on there site they are there for back compat only)

for my problem (running different non interactive partition to partition dd scripts from grub option instead of normal bash prompt) I found I could achieve the same effect i had in the past with runlevels by putting one script in runlevel 2 that simply looks at /proc/cmdline for triggers i send from grub and takes the appropriate action, I also set it to enable/disable rmnologin with a token to complete the effect)

you can easily add a "grep /proc/cmdline trigger" into an if statement to control any rc script

Yes, for myself I do need runlevels.
Say, if I want to turn on sshd in rc1 in some special case, and it would be very easy for me, just link /etc/init.d/ssh in /etc/rc1.d would work. However, if I use your method, I have to modify the /etc/init.d/ssh, and I might mess it up. This is dirty hacking, not a decent method! Moreover, some security checking program will alert me if I modify /etc/init.d/sshd.
So that's why I think runlevels are important to me, and runlevels have existed for more than 3 decades IIRC. I hope upstart could be compatible with this while new features are added on it.

I think it's a bit of an overkill removing the standard Linux runlevel behavior in Ubuntu. It's not "Noobs" that get to fiddle the runlevel, rather people with more experience in Linux. Since this has no effect on the "Noob" user interface, why not leave it as it was in good old Linux? It is a useful feature for "tweakers", and I can't think of any possible harmful side effects!

<quote>randominternet: ask yourself if you really need runlevels?</quote>

There are two basic runlevel controls in the Unix/Linux world, the System V way, and BSD way. They both have there own pros and cons, and I am not going to debate them here. The way init scripts and run levels work is well defined. It is even part of the Linux Standards Base, which defines how Linux distributions are supposed to work for 3rd party vendors, application developers, etc. Take a good look at http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/tocsysinit.html and http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/runlevels.html.

If there are no separate runlevels, then standardization has been thrown out the window.

<quote>randominternet: you can easily add a "grep /proc/cmdline trigger" into an if statement to control any rc script</quote>

The end user shouldn't have to do this. With the "BSD way" everything could be thrown into one directory (as opposed to rc1.d, rc2.d, etc.) or it could be just 1 central rc script. However, there is still a separation of runlevels and controlling what each runlevel does.

I'm happy with
...
        elif grep -qE -- "[[:space:]]+[1-5]([[:space:]]|$)" /proc/cmdline; then
            RL="$(grep -Eo -- "[[:space:]]+[1-5]([[:space:]]|$)" /proc/cmdline)"
            if [ -n "$RL" ]; then
                telinit $RL
            else
                telinit 2
            fi
...
on hardy.

The problem still exists on Ubuntu 8.10.

It is important that this is fixed properly. With jigdo broken and now this, it's hard for Ubuntu to be taken seriously.

Regarding the proposed "if" statement:

            if [ -n "$RL" ]; then
                telinit $RL
            else
                telinit 2
            fi

This looks unnecessary to me. Either a runlevel was specified as a kernel parameter and this if statement gets triggered (and $RL is set), or it isn't. If it isn't, then the last part of the script will kick in:

        else
            telinit 2
        fi
end script

It looks like it was just copied from the "-r /etc/inittab" section, where inittab might exist but the initdefault line may not, but it is unnecessary in the proposed patch.

Hi all,

can't believe Scott James Remnant once wrote "This should be fixed
upstream" (in telinit ! ). Well, it still works for any other distro,
and I bet you'd get a good laugh from the upstream folks if they came
across this, which they may have since this issue came up a VERY long
time ago.
This is really one too many, and our operations are now giving up on
Ubuntu. Glad we found out before we became too involved to go back.
Let's keep serious : there is no way we or anyone just a little
UNIX-savvy will invest time and effort into troubleshooting normal UNIX
behavior just because someone preposterously believed they could change
it, without even attempting to preserve existing standard functionality.
Even if it only lasted for a minute, this would be but a sad joke, so
keep up with your good proprietary fun, but for heaven's sake, stop
claiming that Ubuntu or any operating system using upstart as it is now
would comply with LSB.

This is all we have to say.

Le jeudi 29 janvier 2009 à 06:58 +0000, Scott James Remnant a écrit :

> ** Changed in: upstart
> Target: None => 0.5-later
>

On Thu, 2009-02-05 at 17:33 +0000, dr.moe wrote:

> can't believe Scott James Remnant once wrote "This should be fixed
> upstream" (in telinit ! ).
>
Scott James Remnant (me) _is_ upstream for telinit.

Scott
--
Scott James Remnant
<email address hidden>

Le mardi 10 février 2009 à 14:30 +0000, Scott James Remnant a écrit :

> On Thu, 2009-02-05 at 17:33 +0000, dr.moe wrote:
>
> > can't believe Scott James Remnant once wrote "This should be fixed
> > upstream" (in telinit ! ).
> >
> Scott James Remnant (me) _is_ upstream for telinit.

And so ?
How does this account for anything else ?
(On a side note, the former message was addressing the team, obviously)

Your answer perplexed us for a second, and then gave us all a good
laugh.
As our final communication with Canonical; we decided to google around
for S.J.R. so as to better explain why all further messages from this
individual and company will now be piped to /dev/null here.

Referring to S.J.R.'s comments on this bug and to
http://www.fosdem.org/2009/interview/scott+james+remnant:

Scott James Remnant believes "hat sometimes you've just got to ditch the
past and start over from scratch" ; yet, the same once admitted that his
product "only handles -s/single/S being on the command line, because
that's all I knew about at the time". Hence, S.J.R. believes he can
singlehandedly change something he hardly understands (preposterous, did
we write ?) and that he among all people doesn't have to pay attention
to the recommendations of his elders.
Sadly, S.J.R appears to show enough charisma / pretention to have
convinced others to turn Ubuntu's users (and now Fedora's) into his
beta-testers ; which we definitely refuse to be, especially as we were
using what Canonical claims to be a production-ready server (no, we're
not testing this kind of product, guess why ?).

We shall give upstart a high salute when it becomes ready ; for now, the
program being almost years behind its own schedule, still not including
basic functionaliity based on the claim that it will turn better someday
(ever heard M$ representatives explain that it doesn't matter if their
product is buggy because they will be releasing a new version ?), and
S.J.R. having the extra nerve to postpone fixing certain flaws which are
so apparent that they have been reported over a dozen times, we are
simply waving goodbye (ditching as you'd say) any distro which uses
upstart in its present state.

Finally, we are glad to report that we have tired enough of mindless
one-line answers from Canonical team members who prefer to brag about
who they believe they are instead of trying to understand what may be
wrong with their work to extend our decision of ditching ubuntu to
redirecting any e-mail from Canonical / Ubuntu / related / etc. to the
black hole where they belong. Heck, we've wasted enough time tracking
down discrepancies and unexpected behaviors to bugs usually introduced
by Ubuntu's packaging or projects not to have to bear with these high
ideas of yourselves when all you should be doing is fixing those
mistakes.

Although our policy never was to ignore anybody (as Robert Silverberg
once wrote : "Ignorance cannot be forgiven, it can only be cured"), we
have spent enough valuable time reminding Ubuntu associates of their
responsibilities and received enough of these answers made of contempt
which amount to "Do you know who you're talking to ?", this latest
answer from S.J.R . being the win...

On Wed, 2009-02-11 at 16:05 +0000, dr.moe wrote:

> And so ?
> How does this account for anything else ?
> (On a side note, the former message was addressing the team, obviously)
>
What team? The only person you're addressing here is me.

> As our final communication with Canonical; we decided to google around
> for S.J.R. so as to better explain why all further messages from this
> individual and company will now be piped to /dev/null here.
>
*gulp* I hope you didn't find _those_ pictures :-/

Scott
--
Scott James Remnant
<email address hidden>

Scott James Remnant wrote:
> On Wed, 2009-02-11 at 16:05 +0000, dr.moe wrote:
>
>> And so ?
>> How does this account for anything else ?
>> (On a side note, the former message was addressing the team, obviously)
>>
> What team? The only person you're addressing here is me.

It doesn't really matter who he is addressing. The bug I reported over
a year ago that got pointed at this bug still exists today. If you
configure a server with a "-s" anywhere in the name AND use the server
installers default LVM names your fresh install will always boot into
single user mode.

The installer names your volumes based on server name but it doubles up
the dashes. That makes the grep match in rc-default to catch the server
name as a -s on the command line. Try this:

echo "servername--s--123" | grep -w -- "-s\|single\|S"

The -w argument to grep just isn't enough. It is too fragile and will
catch valid and unrelated command line arguments as a -s.

Would a patch be welcome?

Pat

On Thu, 2009-02-12 at 02:47 +0000, Pat Regan wrote:

> Scott James Remnant wrote:
> > On Wed, 2009-02-11 at 16:05 +0000, dr.moe wrote:
> >
> >> And so ?
> >> How does this account for anything else ?
> >> (On a side note, the former message was addressing the team, obviously)
> >>
> > What team? The only person you're addressing here is me.
>
> It doesn't really matter who he is addressing. The bug I reported over
> a year ago that got pointed at this bug still exists today. If you
> configure a server with a "-s" anywhere in the name AND use the server
> installers default LVM names your fresh install will always boot into
> single user mode.
>
Yes, it still exists today; as do many tens of thousands of bugs filed
in this bug tracking system.

Please note that this bug is not closed: it is not marked Invalid, and
it is not marked Won't Fix.

It is simply considered to be Low priority because the number of people
directly affected by this bug is extremely low, and there are
workarounds available from this bug report that those people may
install.

A full and proper fix will eventually be released, but there are far
more important bugs that deserve attention first; and that's without
even straying from the Upstart bug list.

Scott
--
Scott James Remnant
<email address hidden>

Scott James Remnant wrote:
> On Thu, 2009-02-12 at 02:47 +0000, Pat Regan wrote:
>> It doesn't really matter who he is addressing. The bug I reported over
>> a year ago that got pointed at this bug still exists today. If you
>> configure a server with a "-s" anywhere in the name AND use the server
>> installers default LVM names your fresh install will always boot into
>> single user mode.
>>
> Yes, it still exists today; as do many tens of thousands of bugs filed
> in this bug tracking system.
>
> Please note that this bug is not closed: it is not marked Invalid, and
> it is not marked Won't Fix.
>
> It is simply considered to be Low priority because the number of people
> directly affected by this bug is extremely low, and there are
> workarounds available from this bug report that those people may
> install.

I believe I can understand this bug ("Fail to enter rc1.d by putting 1
in bootparam in edgy") being marked as low priority.

I don't agree that the bug I files (#123147) should be a low priority.
Choosing a valid host name for a server should certainly not result in a
failure to boot correctly. It certainly wasn't the first place I looked
when it happened to me.

> A full and proper fix will eventually be released, but there are far
> more important bugs that deserve attention first; and that's without
> even straying from the Upstart bug list.

There's always something to be said about picking the low hanging fruit.

I offered, although it seems not very strongly, to write up a fix for
this problem in June of 2007. I asked again a few days ago if a patch
would be welcome. I assume you're saying that assistance is not
welcomed, then? The fix is simple enough, the -w switch for grep just
isn't the right way to separate parameters on the kernel command line.

Pat

On Sat, 2009-02-14 at 05:28 +0000, Pat Regan wrote:

> I offered, although it seems not very strongly, to write up a fix for
> this problem in June of 2007. I asked again a few days ago if a patch
> would be welcome. I assume you're saying that assistance is not
> welcomed, then? The fix is simple enough, the -w switch for grep just
> isn't the right way to separate parameters on the kernel command line.
>
I don't consider this a proper fix; a patch for a proper fix (true
default runlevel support in the Upstart code) would be welcomed.

Scott
--
Scott James Remnant
<email address hidden>

These files aren't shipped upstream, they're part of the Ubuntu package. However this is an upstream bug here about those parameters not being passed down which I've opened as #389113

I'm currently testing a new version of the rc-default script for Ubuntu

This bug was fixed in the package upstart - 0.3.10-2

---------------
upstart (0.3.10-2) karmic; urgency=low

  * debian/upstart.postinst: Use telinit u to re-exec, rather than
    kill just in case it's not Upstart that's running. LP: #92177.
  * debian/event.d/system-services/tty*: Run getty in 8-bit clean
    mode. LP: #273189.
  * debian/event.d/upstart-compat-sysv/rc-default:
    - Don't use grep -w, instead split on $IFS and iterate. LP: #385911.
    - Check for any valid runlevel, not just S. LP: #85014.
    - Make console owner, since it may spawn sulogin.
  * debian/event.d/upstart-compat-sysv/rcS:
    - Spawn sulogin if given -b or "emergency". LP: #193810.
  * debian/event.d/upstart-compat-sysv/rcS:
    - Make console owner. LP: #211402.
  * debian/event.d/upstart-compat-sysv/rcS-sulogin:
    - Place the telinit code in post-stop, checking $UPSTART_EVENT first so
      we don't change the runlevel if we were stopped due to a runlevel
      change. LP: #66002.

 -- Scott James Remnant <email address hidden> Thu, 18 Jun 2009 16:19:34 +0100