Re: [PATCH v5] init: Disable defaults if init= fails

[Frank Rowand <frowand.list@gmail.com>]

On 9/30/2014 5:58 PM, Rob Landley wrote:
> 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.

Thanks!  That gives me the context I was looking for.

For posterity and anyone searching in the future, the previous
threads were:

   [PATCH ...] init: Add strictinit to disable init= fallbacks

> 
>> 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...

Yes, "default y" is a valid answer to my request.

> 
>> 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.

But there also was not a strong push back either.  Just Chuck's suggestion
of an alternate syntax, and your suggestion of instead using a config
option (and possibly immediately deprecating the config option).

You could as easily frame the argument that the added code was to
tell the kernel to "_do_ stuff" (panic) instead of "_not_ do stuff".
But that is just semantics on my part; whatever.

I thought the general trend was to try to avoid adding config options.
The strictinit method seems fine to me.


>> 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.)

Yes, of course I can.  So it falls back to personal preference (as I said,
I like that some failed boots will drop into a shell without having to
change the kernel command line).

-Frank