[yocto] Kernel Panic: /sbin/init not found

[Paul Eggleton]

On Friday 03 April 2015 15:31:06 Smith, Virgil wrote:
> > > OK, it turned out that prepending the space before lib32-connman does
> > > not do any good. However, commenting out the line which contains the
> > > IMAGE_INSTALL_append does. That begs the question; what does
> > > lib32-connman do?
> > 
> > It's not lib32-connman that's the problem. The problem is that you were
> > effectively setting the value of IMAGE_INSTALL to something and the
> > default in core-image.bbclass is being set with ?= , and because it's
> > already set at the time the ?= is parsed, the defaults (including the
> > chain leading to
> > sysvinit/systemd) are not being added, among many other packages. If you
> > use IMAGE_INSTALL_append rather than IMAGE_INSTALL (or use a proper image
> > recipe instead of appending to IMAGE_INSTALL from local.conf) you
> > shouldn't have a problem.
> 
> You can't use IMAGE_INSTALL_append from local.conf (as you already
> confirmed).  

This is not true in the general case. You definitely can use 
IMAGE_INSTALL_append with a leading space to add items to an image, I just 
verified that now.

I'm not clear on exactly what happened in the case we're discussing, at least 
initially it sounded like IMAGE_INSTALL = rather than IMAGE_INSTALL_append = 
was being used, which would definitely account for the behaviour described.

> The Yocto layer/configuration composition is non-intuitive.  It is easy to
> expect items in local.conf to 'override/extend' the configuration resulting
> from your layer selections in bblayers.conf, but this is not what happens. 

You can do that, it's just that there is more going on than may be readily 
apparent. We do try to simplify things from time to time where practical (and 
will continue to do so), but a certain level of complexity is basically 
required if you want the system to be flexible.

FWIW, I can strongly recommend the use of bitbake -e (or Toaster, especially 
with the upcoming 1.8 release) to get a view on how variables are being set, 
especially if you are hitting a situation where something is not working in 
the manner you expect it to.

> I'd personally prefer local.conf to be processed AFTER the conf/layer.conf
> and conf/machine/some-name.conf files, but at the very least bb needs to
> know the selected machine first.  So to tune/tweak things you need a file
> up front (local.conf) and a file at the other end (a custom recipe and/or
> layer).

local.conf *is* parsed after the layer.conf files, but not after the machine 
configuration - that is not possible, since it's local.conf that *selects* the 
MACHINE value and thus determines which machine conf file gets parsed.

My opinion on this is that for anything more than just testing or 
experimentation, you should be creating custom image recipes and a custom 
distro configuration, from which you get complete control. The distro 
configuration file is parsed almost at the end of the configuration for exactly 
the reason you mentioned.

> Also, don't think that the ordering of layers in your bblayers.conf file
> (alone) determines the overlaying/replacement of matching bb/bbappend, inc,
> or source/patch files.

The precedence of bb files and order of application of bbappends is controlled 
primarily by layer priorities; the order that layers appear in bblayers.conf 
shouldn't come into that (although it may if you have layers that have exactly 
the same priority set). The order of layers in bblayers.conf can influence the 
order in which bbclass and inc files are found *where files of the same name 
exist across different layers*, since these are found using BBPATH, which is 
prepended or appended to by each layer.conf file and thus the order in which 
those files are parsed is significant.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre