Kernel Panic: /sbin/init not found

Kernel Panic: /sbin/init not found

[Yu, Chan KitX]

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

Hello all,

My Yocto build environment was working perfectly until last week when I got kernel panic caused by missing/sbin/init. When I examined the image, I found that /sbin/init is indeed absent from the root image. To troubleshoot the issue, I tried building a stock Yocto whose target platform is 64-bit machine using a  freshly installed Ubuntu 14.04 from another build machine.  Despite that, the kernel panic still occurs and that's the main reason I'm writing here; that is to see if anyone else has the same issue. I did not make any change or any customization to local.conf aside from setting MACHINE to 64 bit and adding the following lines which enable multilib:

IMAGE_INSTALL = "lib32-connman"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

I would be more than happy to provide necessary diagnostic message shall you request so. Let me know if you guys are able to reproduce this issue.

Chan Kit

[-- Attachment #2: Type: text/html, Size: 3030 bytes --]

Re: Kernel Panic: /sbin/init not found

[Paul Eggleton]

Hi Chan Kit,

On Thursday 02 April 2015 09:25:35 Yu, Chan KitX wrote:
> My Yocto build environment was working perfectly until last week when I got
> kernel panic caused by missing/sbin/init. When I examined the image, I
> found that /sbin/init is indeed absent from the root image. To troubleshoot
> the issue, I tried building a stock Yocto whose target platform is 64-bit
> machine using a  freshly installed Ubuntu 14.04 from another build machine.
>  Despite that, the kernel panic still occurs and that's the main reason I'm
> writing here; that is to see if anyone else has the same issue. I did not
> make any change or any customization to local.conf aside from setting
> MACHINE to 64 bit and adding the following lines which enable multilib:
> 
> IMAGE_INSTALL = "lib32-connman"
> require conf/multilib.conf
> MULTILIBS = "multilib:lib32"
> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
> 
> I would be more than happy to provide necessary diagnostic message shall you
> request so. Let me know if you guys are able to reproduce this issue.

What version of the build system are you using? What exact image are you 
building? What image output type are you trying this with (ext3 / live / 
etc.)? What is your MACHINE value? Can you attach the manifest file for the 
image that is broken?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Kernel Panic: /sbin/init not found

[Yu, Chan KitX]

[-- Attachment #1: Type: text/plain, Size: 2985 bytes --]



> -----Original Message-----
> From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
> Sent: Thursday, April 02, 2015 7:37 PM
> To: Yu, Chan KitX
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Kernel Panic: /sbin/init not found
> 
> Hi Chan Kit,
> 
> On Thursday 02 April 2015 09:25:35 Yu, Chan KitX wrote:
> > My Yocto build environment was working perfectly until last week when
> > I got kernel panic caused by missing/sbin/init. When I examined the
> > image, I found that /sbin/init is indeed absent from the root image.
> > To troubleshoot the issue, I tried building a stock Yocto whose target
> > platform is 64-bit machine using a  freshly installed Ubuntu 14.04 from
> another build machine.
> >  Despite that, the kernel panic still occurs and that's the main
> > reason I'm writing here; that is to see if anyone else has the same
> > issue. I did not make any change or any customization to local.conf
> > aside from setting MACHINE to 64 bit and adding the following lines which
> enable multilib:
> >
> > IMAGE_INSTALL = "lib32-connman"
> > require conf/multilib.conf
> > MULTILIBS = "multilib:lib32"
> > DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
> >
> > I would be more than happy to provide necessary diagnostic message
> > shall you request so. Let me know if you guys are able to reproduce this
> issue.
> 
> What version of the build system are you using? What exact image are you
> building? What image output type are you trying this with (ext3 / live / etc.)?
> What is your MACHINE value?
Build Configuration:
BB_VERSION        = "1.24.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-14.04"
TARGET_SYS        = "x86_64-poky-linux"
MACHINE           = "valleyisland-64"
DISTRO            = "poky"
DISTRO_VERSION    = "1.7.1"
TUNE_FEATURES     = "m64 corei7"
TARGET_FPU        = ""
meta
meta-yocto
meta-yocto-bsp    = "dizzy:ec75238f6cc2d2d8d40e0268f6d2acc070cbe9a4"
meta-intel
meta-valleyisland = "dizzy:c39a4bf4450845fca6f1b26ccfc0db192a4567e8"

The above is the build configuration. As of the image that I was trying to build, I did the hddimg and iso. I got the KP issue from using the iso image. I thought the issue might have to do with the meta-valleyisland so I switched to genericx86-64 instead. No luck.


Can you attach the manifest file for the image
> that is broken?

Attached.

UPDATE: I tried disabling the multilib feature by commenting out the following in local.conf:

IMAGE_INSTALL = "lib32-connman"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

I used to enable multilib in Yocto by adding those lines and it has always worked. I got this step from https://wiki.yoctoproject.org/wiki/Multilib#How_to_use_it . However, I'm not very sure if that's the proper way to enable multilib in Yocto.

Thanks,
Chan Kit


> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre

[-- Attachment #2: core-image-sato-sdk-valleyisland-64-20150402170740.rootfs.manifest --]
[-- Type: application/x-ms-manifest, Size: 89376 bytes --]

Re: Kernel Panic: /sbin/init not found

[Yu, Chan KitX]

> -----Original Message-----
> From: Yu, Chan KitX
> Sent: Friday, April 03, 2015 2:30 PM
> To: 'Paul Eggleton'
> Cc: yocto@yoctoproject.org
> Subject: RE: [yocto] Kernel Panic: /sbin/init not found
> 
> 
> 
> > -----Original Message-----
> > From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
> > Sent: Thursday, April 02, 2015 7:37 PM
> > To: Yu, Chan KitX
> > Cc: yocto@yoctoproject.org
> > Subject: Re: [yocto] Kernel Panic: /sbin/init not found
> >
> > Hi Chan Kit,
> >
> > On Thursday 02 April 2015 09:25:35 Yu, Chan KitX wrote:
> > > My Yocto build environment was working perfectly until last week
> > > when I got kernel panic caused by missing/sbin/init. When I examined
> > > the image, I found that /sbin/init is indeed absent from the root image.
> > > To troubleshoot the issue, I tried building a stock Yocto whose
> > > target platform is 64-bit machine using a  freshly installed Ubuntu
> > > 14.04 from
> > another build machine.
> > >  Despite that, the kernel panic still occurs and that's the main
> > > reason I'm writing here; that is to see if anyone else has the same
> > > issue. I did not make any change or any customization to local.conf
> > > aside from setting MACHINE to 64 bit and adding the following lines
> > > which
> > enable multilib:
> > >
> > > IMAGE_INSTALL = "lib32-connman"
> > > require conf/multilib.conf
> > > MULTILIBS = "multilib:lib32"
> > > DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
> > >
> > > I would be more than happy to provide necessary diagnostic message
> > > shall you request so. Let me know if you guys are able to reproduce
> > > this
> > issue.
> >
> > What version of the build system are you using? What exact image are
> > you building? What image output type are you trying this with (ext3 / live /
> etc.)?
> > What is your MACHINE value?
> Build Configuration:
> BB_VERSION        = "1.24.0"
> BUILD_SYS         = "x86_64-linux"
> NATIVELSBSTRING   = "Ubuntu-14.04"
> TARGET_SYS        = "x86_64-poky-linux"
> MACHINE           = "valleyisland-64"
> DISTRO            = "poky"
> DISTRO_VERSION    = "1.7.1"
> TUNE_FEATURES     = "m64 corei7"
> TARGET_FPU        = ""
> meta
> meta-yocto
> meta-yocto-bsp    = "dizzy:ec75238f6cc2d2d8d40e0268f6d2acc070cbe9a4"
> meta-intel
> meta-valleyisland = "dizzy:c39a4bf4450845fca6f1b26ccfc0db192a4567e8"
> 
> The above is the build configuration. As of the image that I was trying to
> build, I did the hddimg and iso. I got the KP issue from using the iso image. I
> thought the issue might have to do with the meta-valleyisland so I switched
> to genericx86-64 instead. No luck.
> 
> 
> Can you attach the manifest file for the image
> > that is broken?
> 
> Attached.
> 
> UPDATE: I tried disabling the multilib feature by commenting out the
> following in local.conf:
> 
> IMAGE_INSTALL = "lib32-connman"
> require conf/multilib.conf
> MULTILIBS = "multilib:lib32"
> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

Argh...I forgot to mention the main thing; that is the KP issue disappears iff I disable the multilib by removing/commenting those lines. As happy as I am since I found the root cause, I really need the multilib feature and hopefully we can dig deeper from here to fix this.

Chan Kit

Re: Kernel Panic: /sbin/init not found

[ChenQi]

On 04/03/2015 02:43 PM, Yu, Chan KitX wrote:
>
>> -----Original Message-----
>> From: Yu, Chan KitX
>> Sent: Friday, April 03, 2015 2:30 PM
>> To: 'Paul Eggleton'
>> Cc: yocto@yoctoproject.org
>> Subject: RE: [yocto] Kernel Panic: /sbin/init not found
>>
>>
>>
>>> -----Original Message-----
>>> From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
>>> Sent: Thursday, April 02, 2015 7:37 PM
>>> To: Yu, Chan KitX
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Kernel Panic: /sbin/init not found
>>>
>>> Hi Chan Kit,
>>>
>>> On Thursday 02 April 2015 09:25:35 Yu, Chan KitX wrote:
>>>> My Yocto build environment was working perfectly until last week
>>>> when I got kernel panic caused by missing/sbin/init. When I examined
>>>> the image, I found that /sbin/init is indeed absent from the root image.
>>>> To troubleshoot the issue, I tried building a stock Yocto whose
>>>> target platform is 64-bit machine using a  freshly installed Ubuntu
>>>> 14.04 from
>>> another build machine.
>>>>   Despite that, the kernel panic still occurs and that's the main
>>>> reason I'm writing here; that is to see if anyone else has the same
>>>> issue. I did not make any change or any customization to local.conf
>>>> aside from setting MACHINE to 64 bit and adding the following lines
>>>> which
>>> enable multilib:
>>>> IMAGE_INSTALL = "lib32-connman"
>>>> require conf/multilib.conf
>>>> MULTILIBS = "multilib:lib32"
>>>> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
>>>>
>>>> I would be more than happy to provide necessary diagnostic message
>>>> shall you request so. Let me know if you guys are able to reproduce
>>>> this
>>> issue.
>>>
>>> What version of the build system are you using? What exact image are
>>> you building? What image output type are you trying this with (ext3 / live /
>> etc.)?
>>> What is your MACHINE value?
>> Build Configuration:
>> BB_VERSION        = "1.24.0"
>> BUILD_SYS         = "x86_64-linux"
>> NATIVELSBSTRING   = "Ubuntu-14.04"
>> TARGET_SYS        = "x86_64-poky-linux"
>> MACHINE           = "valleyisland-64"
>> DISTRO            = "poky"
>> DISTRO_VERSION    = "1.7.1"
>> TUNE_FEATURES     = "m64 corei7"
>> TARGET_FPU        = ""
>> meta
>> meta-yocto
>> meta-yocto-bsp    = "dizzy:ec75238f6cc2d2d8d40e0268f6d2acc070cbe9a4"
>> meta-intel
>> meta-valleyisland = "dizzy:c39a4bf4450845fca6f1b26ccfc0db192a4567e8"
>>
>> The above is the build configuration. As of the image that I was trying to
>> build, I did the hddimg and iso. I got the KP issue from using the iso image. I
>> thought the issue might have to do with the meta-valleyisland so I switched
>> to genericx86-64 instead. No luck.
>>
>>
>> Can you attach the manifest file for the image
>>> that is broken?
>> Attached.
>>
>> UPDATE: I tried disabling the multilib feature by commenting out the
>> following in local.conf:
>>
>> IMAGE_INSTALL = "lib32-connman"

The problem is that you set IMAGE_INSTALL to "lib32-connman".

You should use the following.
IMAGE_INSTALL_append = " lib32-connman"
(Note there's a white space before lib32-connman in the assignment above.)

Regards,
Chen Qi

>> require conf/multilib.conf
>> MULTILIBS = "multilib:lib32"
>> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
> Argh...I forgot to mention the main thing; that is the KP issue disappears iff I disable the multilib by removing/commenting those lines. As happy as I am since I found the root cause, I really need the multilib feature and hopefully we can dig deeper from here to fix this.
>
> Chan Kit
>
>

Re: Kernel Panic: /sbin/init not found

[Yu, Chan KitX]

> -----Original Message-----
> From: ChenQi [mailto:Qi.Chen@windriver.com]
> Sent: Friday, April 03, 2015 3:03 PM
> To: Yu, Chan KitX; Paul Eggleton
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Kernel Panic: /sbin/init not found
> 
> On 04/03/2015 02:43 PM, Yu, Chan KitX wrote:
> >
> >> -----Original Message-----
> >> From: Yu, Chan KitX
> >> Sent: Friday, April 03, 2015 2:30 PM
> >> To: 'Paul Eggleton'
> >> Cc: yocto@yoctoproject.org
> >> Subject: RE: [yocto] Kernel Panic: /sbin/init not found
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
> >>> Sent: Thursday, April 02, 2015 7:37 PM
> >>> To: Yu, Chan KitX
> >>> Cc: yocto@yoctoproject.org
> >>> Subject: Re: [yocto] Kernel Panic: /sbin/init not found
> >>>
> >>> Hi Chan Kit,
> >>>
> >>> On Thursday 02 April 2015 09:25:35 Yu, Chan KitX wrote:
> >>>> My Yocto build environment was working perfectly until last week
> >>>> when I got kernel panic caused by missing/sbin/init. When I
> >>>> examined the image, I found that /sbin/init is indeed absent from the
> root image.
> >>>> To troubleshoot the issue, I tried building a stock Yocto whose
> >>>> target platform is 64-bit machine using a  freshly installed Ubuntu
> >>>> 14.04 from
> >>> another build machine.
> >>>>   Despite that, the kernel panic still occurs and that's the main
> >>>> reason I'm writing here; that is to see if anyone else has the same
> >>>> issue. I did not make any change or any customization to local.conf
> >>>> aside from setting MACHINE to 64 bit and adding the following lines
> >>>> which
> >>> enable multilib:
> >>>> IMAGE_INSTALL = "lib32-connman"
> >>>> require conf/multilib.conf
> >>>> MULTILIBS = "multilib:lib32"
> >>>> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
> >>>>
> >>>> I would be more than happy to provide necessary diagnostic message
> >>>> shall you request so. Let me know if you guys are able to reproduce
> >>>> this
> >>> issue.
> >>>
> >>> What version of the build system are you using? What exact image are
> >>> you building? What image output type are you trying this with (ext3
> >>> / live /
> >> etc.)?
> >>> What is your MACHINE value?
> >> Build Configuration:
> >> BB_VERSION        = "1.24.0"
> >> BUILD_SYS         = "x86_64-linux"
> >> NATIVELSBSTRING   = "Ubuntu-14.04"
> >> TARGET_SYS        = "x86_64-poky-linux"
> >> MACHINE           = "valleyisland-64"
> >> DISTRO            = "poky"
> >> DISTRO_VERSION    = "1.7.1"
> >> TUNE_FEATURES     = "m64 corei7"
> >> TARGET_FPU        = ""
> >> meta
> >> meta-yocto
> >> meta-yocto-bsp    = "dizzy:ec75238f6cc2d2d8d40e0268f6d2acc070cbe9a4"
> >> meta-intel
> >> meta-valleyisland = "dizzy:c39a4bf4450845fca6f1b26ccfc0db192a4567e8"
> >>
> >> The above is the build configuration. As of the image that I was
> >> trying to build, I did the hddimg and iso. I got the KP issue from
> >> using the iso image. I thought the issue might have to do with the
> >> meta-valleyisland so I switched to genericx86-64 instead. No luck.
> >>
> >>
> >> Can you attach the manifest file for the image
> >>> that is broken?
> >> Attached.
> >>
> >> UPDATE: I tried disabling the multilib feature by commenting out the
> >> following in local.conf:
> >>
> >> IMAGE_INSTALL = "lib32-connman"
> 
> The problem is that you set IMAGE_INSTALL to "lib32-connman".
> 
> You should use the following.
> IMAGE_INSTALL_append = " lib32-connman"
> (Note there's a white space before lib32-connman in the assignment above.)
> 
> Regards,
> Chen Qi

Trying that out now. Fingers crossed. Thank you sir.

Chan Kit

> 
> >> require conf/multilib.conf
> >> MULTILIBS = "multilib:lib32"
> >> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
> > Argh...I forgot to mention the main thing; that is the KP issue disappears iff
> I disable the multilib by removing/commenting those lines. As happy as I am
> since I found the root cause, I really need the multilib feature and hopefully
> we can dig deeper from here to fix this.
> >
> > Chan Kit
> >
> >

Re: Kernel Panic: /sbin/init not found

[Yu, Chan KitX]

> -----Original Message-----
> From: Yu, Chan KitX
> Sent: Friday, April 03, 2015 3:06 PM
> To: Chen, Qi (Wind River); Paul Eggleton
> Cc: yocto@yoctoproject.org
> Subject: RE: [yocto] Kernel Panic: /sbin/init not found
> 
> 
> 
> > -----Original Message-----
> > From: ChenQi [mailto:Qi.Chen@windriver.com]
> > Sent: Friday, April 03, 2015 3:03 PM
> > To: Yu, Chan KitX; Paul Eggleton
> > Cc: yocto@yoctoproject.org
> > Subject: Re: [yocto] Kernel Panic: /sbin/init not found
> >
> > On 04/03/2015 02:43 PM, Yu, Chan KitX wrote:
> > >
> > >> -----Original Message-----
> > >> From: Yu, Chan KitX
> > >> Sent: Friday, April 03, 2015 2:30 PM
> > >> To: 'Paul Eggleton'
> > >> Cc: yocto@yoctoproject.org
> > >> Subject: RE: [yocto] Kernel Panic: /sbin/init not found
> > >>
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
> > >>> Sent: Thursday, April 02, 2015 7:37 PM
> > >>> To: Yu, Chan KitX
> > >>> Cc: yocto@yoctoproject.org
> > >>> Subject: Re: [yocto] Kernel Panic: /sbin/init not found
> > >>>
> > >>> Hi Chan Kit,
> > >>>
> > >>> On Thursday 02 April 2015 09:25:35 Yu, Chan KitX wrote:
> > >>>> My Yocto build environment was working perfectly until last week
> > >>>> when I got kernel panic caused by missing/sbin/init. When I
> > >>>> examined the image, I found that /sbin/init is indeed absent from
> > >>>> the
> > root image.
> > >>>> To troubleshoot the issue, I tried building a stock Yocto whose
> > >>>> target platform is 64-bit machine using a  freshly installed
> > >>>> Ubuntu
> > >>>> 14.04 from
> > >>> another build machine.
> > >>>>   Despite that, the kernel panic still occurs and that's the main
> > >>>> reason I'm writing here; that is to see if anyone else has the
> > >>>> same issue. I did not make any change or any customization to
> > >>>> local.conf aside from setting MACHINE to 64 bit and adding the
> > >>>> following lines which
> > >>> enable multilib:
> > >>>> IMAGE_INSTALL = "lib32-connman"
> > >>>> require conf/multilib.conf
> > >>>> MULTILIBS = "multilib:lib32"
> > >>>> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
> > >>>>
> > >>>> I would be more than happy to provide necessary diagnostic
> > >>>> message shall you request so. Let me know if you guys are able to
> > >>>> reproduce this
> > >>> issue.
> > >>>
> > >>> What version of the build system are you using? What exact image
> > >>> are you building? What image output type are you trying this with
> > >>> (ext3 / live /
> > >> etc.)?
> > >>> What is your MACHINE value?
> > >> Build Configuration:
> > >> BB_VERSION        = "1.24.0"
> > >> BUILD_SYS         = "x86_64-linux"
> > >> NATIVELSBSTRING   = "Ubuntu-14.04"
> > >> TARGET_SYS        = "x86_64-poky-linux"
> > >> MACHINE           = "valleyisland-64"
> > >> DISTRO            = "poky"
> > >> DISTRO_VERSION    = "1.7.1"
> > >> TUNE_FEATURES     = "m64 corei7"
> > >> TARGET_FPU        = ""
> > >> meta
> > >> meta-yocto
> > >> meta-yocto-bsp    =
> "dizzy:ec75238f6cc2d2d8d40e0268f6d2acc070cbe9a4"
> > >> meta-intel
> > >> meta-valleyisland = "dizzy:c39a4bf4450845fca6f1b26ccfc0db192a4567e8"
> > >>
> > >> The above is the build configuration. As of the image that I was
> > >> trying to build, I did the hddimg and iso. I got the KP issue from
> > >> using the iso image. I thought the issue might have to do with the
> > >> meta-valleyisland so I switched to genericx86-64 instead. No luck.
> > >>
> > >>
> > >> Can you attach the manifest file for the image
> > >>> that is broken?
> > >> Attached.
> > >>
> > >> UPDATE: I tried disabling the multilib feature by commenting out
> > >> the following in local.conf:
> > >>
> > >> IMAGE_INSTALL = "lib32-connman"
> >
> > The problem is that you set IMAGE_INSTALL to "lib32-connman".
> >
> > You should use the following.
> > IMAGE_INSTALL_append = " lib32-connman"
> > (Note there's a white space before lib32-connman in the assignment
> > above.)
> >
> > Regards,
> > Chen Qi
> 
> Trying that out now. Fingers crossed. Thank you sir.
> 
> Chan Kit

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?

Chan Kit

Re: Kernel Panic: /sbin/init not found

[Paul Eggleton]

On Friday 03 April 2015 08:16:44 Yu, Chan KitX wrote:
> > -----Original Message-----
> > From: Yu, Chan KitX
> > Sent: Friday, April 03, 2015 3:06 PM
> > To: Chen, Qi (Wind River); Paul Eggleton
> > Cc: yocto@yoctoproject.org
> > Subject: RE: [yocto] Kernel Panic: /sbin/init not found
> > 
> > > -----Original Message-----
> > > From: ChenQi [mailto:Qi.Chen@windriver.com]
> > > Sent: Friday, April 03, 2015 3:03 PM
> > > To: Yu, Chan KitX; Paul Eggleton
> > > Cc: yocto@yoctoproject.org
> > > Subject: Re: [yocto] Kernel Panic: /sbin/init not found
> > > 
> > > On 04/03/2015 02:43 PM, Yu, Chan KitX wrote:
> > > >> -----Original Message-----
> > > >> From: Yu, Chan KitX
> > > >> Sent: Friday, April 03, 2015 2:30 PM
> > > >> To: 'Paul Eggleton'
> > > >> Cc: yocto@yoctoproject.org
> > > >> Subject: RE: [yocto] Kernel Panic: /sbin/init not found
> > > >> 
> > > >>> -----Original Message-----
> > > >>> From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
> > > >>> Sent: Thursday, April 02, 2015 7:37 PM
> > > >>> To: Yu, Chan KitX
> > > >>> Cc: yocto@yoctoproject.org
> > > >>> Subject: Re: [yocto] Kernel Panic: /sbin/init not found
> > > >>> 
> > > >>> Hi Chan Kit,
> > > >>> 
> > > >>> On Thursday 02 April 2015 09:25:35 Yu, Chan KitX wrote:
> > > >>>> My Yocto build environment was working perfectly until last week
> > > >>>> when I got kernel panic caused by missing/sbin/init. When I
> > > >>>> examined the image, I found that /sbin/init is indeed absent from
> > > >>>> the
> > > 
> > > root image.
> > > 
> > > >>>> To troubleshoot the issue, I tried building a stock Yocto whose
> > > >>>> target platform is 64-bit machine using a  freshly installed
> > > >>>> Ubuntu
> > > >>>> 14.04 from
> > > >>> 
> > > >>> another build machine.
> > > >>> 
> > > >>>>   Despite that, the kernel panic still occurs and that's the main
> > > >>>> 
> > > >>>> reason I'm writing here; that is to see if anyone else has the
> > > >>>> same issue. I did not make any change or any customization to
> > > >>>> local.conf aside from setting MACHINE to 64 bit and adding the
> > > >>>> following lines which
> > > >>> 
> > > >>> enable multilib:
> > > >>>> IMAGE_INSTALL = "lib32-connman"
> > > >>>> require conf/multilib.conf
> > > >>>> MULTILIBS = "multilib:lib32"
> > > >>>> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
> > > >>>> 
> > > >>>> I would be more than happy to provide necessary diagnostic
> > > >>>> message shall you request so. Let me know if you guys are able to
> > > >>>> reproduce this
> > > >>> 
> > > >>> issue.
> > > >>> 
> > > >>> What version of the build system are you using? What exact image
> > > >>> are you building? What image output type are you trying this with
> > > >>> (ext3 / live /
> > > >> 
> > > >> etc.)?
> > > >> 
> > > >>> What is your MACHINE value?
> > > >> 
> > > >> Build Configuration:
> > > >> BB_VERSION        = "1.24.0"
> > > >> BUILD_SYS         = "x86_64-linux"
> > > >> NATIVELSBSTRING   = "Ubuntu-14.04"
> > > >> TARGET_SYS        = "x86_64-poky-linux"
> > > >> MACHINE           = "valleyisland-64"
> > > >> DISTRO            = "poky"
> > > >> DISTRO_VERSION    = "1.7.1"
> > > >> TUNE_FEATURES     = "m64 corei7"
> > > >> TARGET_FPU        = ""
> > > >> meta
> > > >> meta-yocto
> > > >> meta-yocto-bsp    =
> > 
> > "dizzy:ec75238f6cc2d2d8d40e0268f6d2acc070cbe9a4"
> > 
> > > >> meta-intel
> > > >> meta-valleyisland = "dizzy:c39a4bf4450845fca6f1b26ccfc0db192a4567e8"
> > > >> 
> > > >> The above is the build configuration. As of the image that I was
> > > >> trying to build, I did the hddimg and iso. I got the KP issue from
> > > >> using the iso image. I thought the issue might have to do with the
> > > >> meta-valleyisland so I switched to genericx86-64 instead. No luck.
> > > >> 
> > > >> 
> > > >> Can you attach the manifest file for the image
> > > >> 
> > > >>> that is broken?
> > > >> 
> > > >> Attached.
> > > >> 
> > > >> UPDATE: I tried disabling the multilib feature by commenting out
> > > >> the following in local.conf:
> > > >> 
> > > >> IMAGE_INSTALL = "lib32-connman"
> > > 
> > > The problem is that you set IMAGE_INSTALL to "lib32-connman".
> > > 
> > > You should use the following.
> > > IMAGE_INSTALL_append = " lib32-connman"
> > > (Note there's a white space before lib32-connman in the assignment
> > > above.)
> > > 
> > > Regards,
> > > Chen Qi
> > 
> > Trying that out now. Fingers crossed. Thank you sir.
> > 
> > Chan Kit
> 
> 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.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Kernel Panic: /sbin/init not found

[Smith, Virgil]

> > 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).  You will have to "use a proper image recipe" (as Paul Eggleton also suggested).  I too ran afoul of this recently.

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

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.


________________________________

Notice to recipient: This email is meant for only the intended recipient of the transmission, and may be a communication privileged by law, subject to export control restrictions or that otherwise contains proprietary information. If you receive this email by mistake, please notify us immediately by replying to this message and then destroy it and do not review, disclose, copy or distribute it. Thank you in advance for your cooperation.

Re: 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

Re: Kernel Panic: /sbin/init not found

[Smith, Virgil]

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

Digging.... testing.... reading....
I don't know what happened in Chan Kit's case, but it looks like my earlier trouble was using IMAGE_INSTALL +=  from inside local.conf.  IMAGE_INSTALL_append isn't applied until after parsing completes.  So here is one (or rather the) way to overcome the fact that local.conf is *parsed* too early for extending variables/configuration introduced later in the *parsing* chain.

So, my earlier statement that you can't use/rely on IMAGE_INSTALL_append from local.conf is flat wrong.

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

Thanks Paul, I wasn't sure I had the whole story.

________________________________

Notice to recipient: This email is meant for only the intended recipient of the transmission, and may be a communication privileged by law, subject to export control restrictions or that otherwise contains proprietary information. If you receive this email by mistake, please notify us immediately by replying to this message and then destroy it and do not review, disclose, copy or distribute it. Thank you in advance for your cooperation.

Re: Kernel Panic: /sbin/init not found

[Yu, Chan KitX]

I guess I have mistaken something in https://wiki.yoctoproject.org/wiki/Multilib#How_to_use_it . I have simply put the line:

IMAGE_INSTALL = "lib32-connman"

which turned out to be a wrong move. I'm not entirely sure of why this has worked for me for several months but that was the case and I stuck to it until this problem took me in the knee. I'm not sure if the line above is correct in its context. lib32-connman is just a package and perhaps it should have used IMAGE_INSTALL_append or IMAGE_INSTALL+=

Chan Kit

> -----Original Message-----
> From: Smith, Virgil [mailto:Virgil.Smith@flir.com]
> Sent: Tuesday, April 07, 2015 1:13 AM
> To: Paul Eggleton
> Cc: Yu, Chan KitX; yocto@yoctoproject.org
> Subject: RE: [yocto] Kernel Panic: /sbin/init not found
> 
> 
> > 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.
> 
> Digging.... testing.... reading....
> I don't know what happened in Chan Kit's case, but it looks like my earlier
> trouble was using IMAGE_INSTALL +=  from inside local.conf.
> IMAGE_INSTALL_append isn't applied until after parsing completes.  So here
> is one (or rather the) way to overcome the fact that local.conf is *parsed*
> too early for extending variables/configuration introduced later in the
> *parsing* chain.
> 
> So, my earlier statement that you can't use/rely on IMAGE_INSTALL_append
> from local.conf is flat wrong.
> 
> > 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.
> 
> Thanks Paul, I wasn't sure I had the whole story.
> 
> ________________________________
> 
> Notice to recipient: This email is meant for only the intended recipient of the
> transmission, and may be a communication privileged by law, subject to
> export control restrictions or that otherwise contains proprietary
> information. If you receive this email by mistake, please notify us
> immediately by replying to this message and then destroy it and do not
> review, disclose, copy or distribute it. Thank you in advance for your
> cooperation.

Re: Kernel Panic: /sbin/init not found

[Paul Eggleton]

On Tuesday 07 April 2015 00:06:39 Yu, Chan KitX wrote:
> I guess I have mistaken something in
> https://wiki.yoctoproject.org/wiki/Multilib#How_to_use_it . I have simply
> put the line:
> 
> IMAGE_INSTALL = "lib32-connman"
> 
> which turned out to be a wrong move. I'm not entirely sure of why this has
> worked for me for several months but that was the case and I stuck to it
> until this problem took me in the knee. I'm not sure if the line above is
> correct in its context. lib32-connman is just a package and perhaps it
> should have used IMAGE_INSTALL_append or IMAGE_INSTALL+=

Ah, right, that page was wrong - and I have just fixed it. It's probably out-
of-date as well, and in fact there is an open bug to make sure we have what we 
need in the manual and then turn the page into a redirect.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre