Date:	Tue, 30 Sep 2014 19:58:03 -0500
From:	Rob Landley <rob@...dley.net>
To:	frowand.list@...il.com, Andy Lutomirski <luto@...capital.net>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Chuck Ebbert <cebbert.lkml@...il.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Shuah Khan <shuah.kh@...sung.com>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH v5] init: Disable defaults if init= fails

On 09/30/14 19:41, Frank Rowand wrote:
> The earliest mention I find of this on lkml is v4.  Was there earlier
> discussion of this elsewhere?  (Just so I have a clue as to the full
> context and don't repeat previous discussion.)  The mention of names
> in the change logs tells me I should be able to find the discussion
> somewhere.

The previous ones had a different topic sentence (add strictinit). So
they added code to do less.

> On 9/28/2014 7:40 PM, Andy Lutomirski wrote:
>> If a user puts init=/whatever on the command line and /whatever
>> can't be run, then the kernel will try a few default options before
>> giving up.  If init=/whatever came from a bootloader prompt, then
>> this is unexpected but probably harmless.  On the other hand, if it
>> comes from a script (e.g. a tool like virtme or perhaps a future
>> kselftest script), then the fallbacks are likely to exist, but
>> they'll do the wrong thing.  For example, they might unexpectedly
>> invoke systemd.
>>
>> This makes a failure to run the specified init= process be fatal.
>>
>> As a temporary measure, users can set CONFIG_INIT_FALLBACK=y to
>> preserve the old behavior.  If no one speaks up, we can remove that
>> option entirely after a release or two.
> 
> I'm speaking up already, no need to wait two releases.  I like the
> current behavior where I can fall back into a shell without
> recompiling the kernel and/or changing the boot command line to
> debug an init failure.
> 
> I would suggest that the current behavior remain the
> default and the choice to make a failure of the specified
> init= process fatal should be an explicit choice.

Oh please no. Having to switch kernel configuration entries _on_ in
order to switch behavior _off_ is how you get nonsense like
allnoconfig_y which breaks miniconfig, why is why I patch it back out
locally:

http://landley.net/hg/aboriginal/file/1672/sources/patches/linux-deeplystupid.patch

If you're going to argue that it should "default y", that's a defensible
choice. But please don't argue for kernel config symbols with a negative
meaning or we'll start having allyesconfig_n brain damage too...

> Instead of using a config option, would adding another kernel
> command line option, such as 'init_fail_is_fatal', work for
> your needs?

That was the previous series of patches you ignored, which added code so
you can provide _extra_ kernel commands to tell it _not_ to do stuff.
The patches did not generate noticeable enthusiasm.

> I have a feeling this has already been proposed,
> as the 'strictinit' option mentioned in the changes from v3
> below might be the same concept?

That was it, yes.

Having to get your kernel config right (and your kernel command line
right) in order for your system to boot is not really a new concept, is
it? You can still specify "init=/bin/sh" if you want that. (I do it all
the time when I need to edit a system I haven't bothered to look up the
root password to.)

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists