Date   

Minutes: Yocto Technical Team (Tuesday, August 02, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada))

Liu, Song <song.liu@...>
 

Messages to the team:
 
* Thanks and kudos to the team, Yocto 1.1 has reached feature complete. The team is working on completing the build and bug fixes now. Many have been working really hard to make this happen, especially people working on multi-lib, HOB, kernel works, builds and QA, etc. Thanks to Nitin for completing x32 while his fingers are still hurting :)
* The current plan is to have M3 RC2 build today or tomorrow, then QA will run weekly test on RC2. Will have another build RC3 with critical fixes over the weekend and have QA run full test next week on RC3.
 
Attendees:
Mark, Paul, Saul, Josh, Jefro, Dave, Scott, Jessica, Tom, Richard, Jason, Song
 
New Action Item List:
------------------------------------------------------------------------------------------------------------------------------------
* The team to review ALL bugs they own and do some estimation. Please put the estimation on the white board by next Thursday (8/4/11)
------------------------------------------------------------------------------------------------------------------------------------
* ScottR will follow up with Paul on doc auto-generation and revision inclusion in the doc. The goal is to have docs refer to the release?
* Song will follow up with Tracey to make sure marketing planning happens between milestones so that there is no disruption to the development schedule.
  
 
Agenda:
 
1. Opens collection - 5 min (Song)
2. M3 release criteria and plan - 20 min (team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria
* Yocto 1.1 reached feature complete last week.
* 2 tasks remaining for M3 (Beth)
3. M4: bug effort estimate (see messages above)
4. Opens - 10 min
i. Yocto 1.2 feature request
ii. Saul: The state of pull request, and consolidated pull request:
* Sending out to consolidated pull request, as M3 is wrapping up. Saul will look at the remaining pull requests, things will move forward a little slower, 24 hours response time for pull request. Saul will be out next week. Richard will be handling the pull requests.
iii. ScottR: ADT/HOB scripts: 2 videos for ADT and HOB.
*Jessica/Josh creating the video piece and script. Scott needs the scripts. Just a heads up. Jessica and Josh are ok with this. This is scheduled for M4.
 
5. Action item Review - 5 min
 
Action Item List:
------------------------------------------------------------------------------------------------------------------------------------
* The team to review ALL bugs they own and do some estimation. Please put the estimation on the white board by next Thursday (8/4/11)
------------------------------------------------------------------------------------------------------------------------------------
* Saul: talk to Jianjun, QA should work with developers to make sure we can cover more distro testing (informal) before major release. Joshua and Darren volunteers for some of these testing. (Done)
* Beth/Darren/ScottR: document the central location in the release, and put any doc changes in the location after release.
- git repos should match the website
- Include the revision in the doc when we generate the doc from the source. See how we can auto generate the doc. Scott will follow up Paul on this. The goal is to have doc refer to the release.
* Song will follow up with Tracey to make sure marketing planning happens between milestones so that there is no disruption to the development schedule.
- Tracey was on vacation. Back this week


Re: kernel panic - not syncing: No init found

Bruce Ashfield <bruce.ashfield@...>
 

On 08/02/11 01:38, Francis Meyvis wrote:
Hello,

When I mounted the root image on loop back device, I actually ran the
init program. It executed and complained about missing params. I tried
with the 5, like for network connected inittab. Then init complained
there was no /dev/initctl. So combining this with the replies I got, I
think the latest /sbin/init on yocto master does not support a default
run level? I think the architecture of my root image is for x86 cause my
pc could exec it.

Any suggestions on how to continue?
Interesting, since this is failing on multiple image types,
there should be different init scripts at play, each with
different requirements that should be met by the rootfs
generation.

Have you tried updating master and re-building ? Some of
the issues from last week should be resolved at this point.

The boards are known to boot, and boot out of the box, so
either this is something transient, or unique to your setup
at the moment.

Bruce


Groetjes,
Francis

On Aug 1, 2011 6:04 AM, "Bruce Ashfield" <bruce.ashfield@...
<mailto:bruce.ashfield@...>> wrote:
> On 11-07-31 11:30 PM, Tom Zanussi wrote:
>> On Sun, 2011-07-31 at 19:42 -0700, Bruce Ashfield wrote:
>>> On 11-07-31 3:44 PM, Francis Meyvis wrote:
>>>> Hello,
>>>>
>>>> I probably miss something trivial.
>>>> I cloned the git://git.yoctoproject.org/poky.git
<http://git.yoctoproject.org/poky.git>
>>>> I build on a 64 bit machine a qemux86-64
>>>> (. ./oe-init-build-env qemux86-64 and changing the conf/local.conf)
>>>> I build the core-image-sato& core-image-minimal.
>>>> Then I try to run with
>>>> runqemu qemux86-64 core-image-sato ext3
>>>>
>>>> But both sato and minimal give me this message:
>>>> Kernel panic - not syncing: No init found.
>>>>
>>>> As runqemu showed me the full command line I tried to add the --append
>>>> command line option
>>>> init=/sbin/init and /sbin/init.sysvinit
>>>> But that did not help (there's a message saying Failed to execute
>>>> /sbin/init. Attempting defaults...)
>>>> I verified by mounting these ext3 images on a loop device that there's
>>>> really a /sbin/init present.
>>>>
>>>> Can somebody tell what I'm doing wrong?
>>>
>>> Can you send a full bootlog, or paste it somewhere accessible ?
It's hard
>>> to say what's with the information you've given.
>>>
>>> Is this the latest yocto master ?
>>>
>>> If you are seeing that message it typically means that the the
>>> device that is being used as the root isn't ready (fixed by
>>> rootwait/rootdelay) or isn't supported (i.e. NFS root without
>>> the right ethernet device). Changing what init is, won't change
>>> the result if either one of those is the case.
>>>
>>
>> I'm also seeing this on both sugarbay and jasperforest with the latest
>> master. rootwait doesn't help.
>>
>> rtc_cmos 00:07: setting system clock to 2010-01-02 05:35:34 UTC
>> (1262410534)
>> Freeing unused kernel memory: 720k freed
>> Failed to execute /init
>> Kernel panic - not syncing: No init found. Try passing init= option to
>> kernel.
>> See Linux Documentation/init.txt for guidance.
>> Pid: 1, comm: swapper Not tainted 3.0.0-rc7-yocto-standard+ #1
>> Call Trace:
>> [<ffffffff81541b77>] panic+0x9b/0x191
>> [<ffffffff81540862>] init_post+0xc0/0xc0
>> [<ffffffff8188bcef>] kernel_init+0x17b/0x17b
>> [<ffffffff8154b234>] kernel_thread_helper+0x4/0x10
>> [<ffffffff8188bb74>] ? start_kernel+0x377/0x377
>> [<ffffffff8154b230>] ? gs_change+0xb/0xb
>>
>> I thought initially it had something to do with the -live image changes,
>> but reverting the two -live patches didn't help.
>>
>> The problem seems to coincide with the tune file changes, but that may
>> be a red herring.
>
> Nope. I don't think it's a red herring:
>
> Both of these:
>
> Freeing unused kernel memory: 720k freed
> Failed to execute /init
>
> Indicate that the device came up and init was loaded, the kernel
> passed control to userspace and then things went bad. i.e. you just
> ran init of the wrong arch or something incompatible with the
> kernel support, etc.
>
> Since I'm having no trouble with old rootfs and new kernels, that's
> another sign. I'm assuming that old userspace's boot for you ?
>
> Bruce
>
>>
>> Tom
>>
>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>> BTW is there any way to not have to run qemu with root permissions?
>>>> I ran the android emulator and it does not require me to be root.
>>>> Should I configure something on my Ubuntu machine to get qemu to
function?
>>>>
>>>> Thanks,
>>>> francis
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@... <mailto:yocto@...>
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@... <mailto:yocto@...>
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>



_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: examples / docs on utilizing an external toolchain

Rifenbark, Scott M <scott.m.rifenbark@...>
 

Is the problem here that we need better documentation on using a prebuilt toolchain? I will have to learn more about the context of the problem from someone. The bug could just be against documentation in general and specify the need for "better documentation using a prebuilt toolchain."

ScottR

-----Original Message-----
From: Kumar Gala [mailto:galak@...]
Sent: Tuesday, August 02, 2011 9:10 AM
To: Stewart, David C
Cc: 'yocto@...'; Rifenbark, Scott M
Subject: Re: [yocto] examples / docs on utilizing an external toolchain

I can, but not sure what the bug is.

- k

On Jul 28, 2011, at 11:39 PM, Stewart, David C wrote:

Scott - I have had a couple of questions about this exact topic. Can you please submit a bug on this? Thanks.

Sent from my Blackberry

----- Original Message -----
From: Kumar Gala [mailto:galak@...]
Sent: Wednesday, July 27, 2011 08:37 PM
To: Yocto discussion list <yocto@...>
Subject: [yocto] examples / docs on utilizing an external toolchain

It seems like there is a way to use a prebuilt toolchain with poky but no real details.

Some refs in the docs like:

POKYMODE
Toolchain selector. It can be external toolchain built from Poky or few supported combinations of upstream GCC or CodeSourcery Labs toolchain.

But grepping the code there doesn't seem to be any actual use of POKYMODE. There seems to be some references even on the autobuilder about this 'nightly-external-toolchain'. So wondering what the details where on how to configure things to use an external toolchain.

- k
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: examples / docs on utilizing an external toolchain

Kumar Gala <galak@...>
 

I can, but not sure what the bug is.

- k

On Jul 28, 2011, at 11:39 PM, Stewart, David C wrote:

Scott - I have had a couple of questions about this exact topic. Can you please submit a bug on this? Thanks.

Sent from my Blackberry

----- Original Message -----
From: Kumar Gala [mailto:galak@...]
Sent: Wednesday, July 27, 2011 08:37 PM
To: Yocto discussion list <yocto@...>
Subject: [yocto] examples / docs on utilizing an external toolchain

It seems like there is a way to use a prebuilt toolchain with poky but no real details.

Some refs in the docs like:

POKYMODE
Toolchain selector. It can be external toolchain built from Poky or few supported combinations of upstream GCC or CodeSourcery Labs toolchain.

But grepping the code there doesn't seem to be any actual use of POKYMODE. There seems to be some references even on the autobuilder about this 'nightly-external-toolchain'. So wondering what the details where on how to configure things to use an external toolchain.

- k
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: Magic/File problems

Jeff Mitchell <jmitchell@...>
 

Hi there,

On 08/01/2011 06:18 PM, Saul Wold wrote:
Which version of poky are you working with?
Git master as of that point. Revision 46cf540e63a848512617b20fd8492f81bfb2f704

There was a problem that we
had with file at one point and thought was fixed. If you check in your
tmp/sysroots directory for the host machine, do you have a file.real?
I do have a tmp/sysroots/x86_64-linux/usr/bin/file.real -- although I'm building for BeagleBoard, and don't have one in that directory.

Thanks,
Jeff


Re: kernel panic - not syncing: No init found

Francis Meyvis <francis.meyvis@...>
 

Hello,

When I mounted the root image on loop back device, I actually ran the init program. It executed and complained about missing params. I tried with the 5, like for network connected inittab. Then init complained there was no /dev/initctl. So combining this with the replies I got, I think the latest /sbin/init on yocto master does not support a default run level? I think the architecture of my root image is for x86 cause my pc could exec it.

Any suggestions on how to continue?

Groetjes,
Francis

On Aug 1, 2011 6:04 AM, "Bruce Ashfield" <bruce.ashfield@...> wrote:
> On 11-07-31 11:30 PM, Tom Zanussi wrote:
>> On Sun, 2011-07-31 at 19:42 -0700, Bruce Ashfield wrote:
>>> On 11-07-31 3:44 PM, Francis Meyvis wrote:
>>>> Hello,
>>>>
>>>> I probably miss something trivial.
>>>> I cloned the git://git.yoctoproject.org/poky.git
>>>> I build on a 64 bit machine a qemux86-64
>>>> (. ./oe-init-build-env qemux86-64 and changing the conf/local.conf)
>>>> I build the core-image-sato& core-image-minimal.
>>>> Then I try to run with
>>>> runqemu qemux86-64 core-image-sato ext3
>>>>
>>>> But both sato and minimal give me this message:
>>>> Kernel panic - not syncing: No init found.
>>>>
>>>> As runqemu showed me the full command line I tried to add the --append
>>>> command line option
>>>> init=/sbin/init and /sbin/init.sysvinit
>>>> But that did not help (there's a message saying Failed to execute
>>>> /sbin/init. Attempting defaults...)
>>>> I verified by mounting these ext3 images on a loop device that there's
>>>> really a /sbin/init present.
>>>>
>>>> Can somebody tell what I'm doing wrong?
>>>
>>> Can you send a full bootlog, or paste it somewhere accessible ? It's hard
>>> to say what's with the information you've given.
>>>
>>> Is this the latest yocto master ?
>>>
>>> If you are seeing that message it typically means that the the
>>> device that is being used as the root isn't ready (fixed by
>>> rootwait/rootdelay) or isn't supported (i.e. NFS root without
>>> the right ethernet device). Changing what init is, won't change
>>> the result if either one of those is the case.
>>>
>>
>> I'm also seeing this on both sugarbay and jasperforest with the latest
>> master. rootwait doesn't help.
>>
>> rtc_cmos 00:07: setting system clock to 2010-01-02 05:35:34 UTC
>> (1262410534)
>> Freeing unused kernel memory: 720k freed
>> Failed to execute /init
>> Kernel panic - not syncing: No init found. Try passing init= option to
>> kernel.
>> See Linux Documentation/init.txt for guidance.
>> Pid: 1, comm: swapper Not tainted 3.0.0-rc7-yocto-standard+ #1
>> Call Trace:
>> [<ffffffff81541b77>] panic+0x9b/0x191
>> [<ffffffff81540862>] init_post+0xc0/0xc0
>> [<ffffffff8188bcef>] kernel_init+0x17b/0x17b
>> [<ffffffff8154b234>] kernel_thread_helper+0x4/0x10
>> [<ffffffff8188bb74>] ? start_kernel+0x377/0x377
>> [<ffffffff8154b230>] ? gs_change+0xb/0xb
>>
>> I thought initially it had something to do with the -live image changes,
>> but reverting the two -live patches didn't help.
>>
>> The problem seems to coincide with the tune file changes, but that may
>> be a red herring.
>
> Nope. I don't think it's a red herring:
>
> Both of these:
>
> Freeing unused kernel memory: 720k freed
> Failed to execute /init
>
> Indicate that the device came up and init was loaded, the kernel
> passed control to userspace and then things went bad. i.e. you just
> ran init of the wrong arch or something incompatible with the
> kernel support, etc.
>
> Since I'm having no trouble with old rootfs and new kernels, that's
> another sign. I'm assuming that old userspace's boot for you ?
>
> Bruce
>
>>
>> Tom
>>
>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>> BTW is there any way to not have to run qemu with root permissions?
>>>> I ran the android emulator and it does not require me to be root.
>>>> Should I configure something on my Ubuntu machine to get qemu to function?
>>>>
>>>> Thanks,
>>>> francis
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@...
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@...
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>


Re: Magic/File problems

Saul Wold <sgw@...>
 

On 08/01/2011 10:55 AM, Jeff Mitchell wrote:
On my host system I have the "file" utility version 5.05. The version in
poky/in my build directories is version 5.04. I'm seeing a lot of builds
fail with the following:

| error: magic_load(ms, /usr/share/misc/magic) failed: File 5.4 supports
only version 7 magic files. `/usr/share/misc/magic.mgc' is version 8

Note that the version there is 5.4; this doesn't match anything as far
as I can tell.

Any ideas?
Jeff,

Which version of poky are you working with? There was a problem that we had with file at one point and thought was fixed. If you check in your
tmp/sysroots directory for the host machine, do you have a file.real?

We needed to create a cover script which correctly pointed file to the right magic.mgc file.

Hope that helped.

Sau!


Thanks,
Jeff
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Rescheduled: mailing lists are moving to a new host

Michael Halstead <michaelx.d.halstead@...>
 

The move originally scheduled for today will now happen on Wednesday August 3rd from 10pm to midnight PDT.

For reference, we will move mailing lists and related services to new hardware hosted at the OSU Open Source Lab. Archive access will be available during the entire process but changes using the web interface at lists.yoctoproject.org may be lost. E-mail sent to lists will be delayed until the transition is complete. If you send an e-mail to the list during the move expect that it will go through after a few hours. There should be no need to resend e-mail.

Michael Halstead
Intel OTC Yocto


Magic/File problems

Jeff Mitchell <jmitchell@...>
 

On my host system I have the "file" utility version 5.05. The version in poky/in my build directories is version 5.04. I'm seeing a lot of builds fail with the following:

| error: magic_load(ms, /usr/share/misc/magic) failed: File 5.4 supports only version 7 magic files. `/usr/share/misc/magic.mgc' is version 8

Note that the version there is 5.4; this doesn't match anything as far as I can tell.

Any ideas?

Thanks,
Jeff


Re: POKY_DISTRO_VERSION or OECORE_DISTRO_VERSION?

Zhang, Jessica
 

Lianhao,

For DISTRO_VERSION, we still need to use POKY_DISTRO_VERSION since our distro is "POKY" as to other rename to OECORE, are those variables that're distro neutral. Hope you get the idea. I've asked RP the same question and his answer is before we can figure out a mechanism to make everything distro neutral, we have stay with the existing POKY naming convention for certain variables that are specific to the distro.

Thanks,
Jessica

-----Original Message-----
From: Lu, Lianhao
Sent: Monday, August 01, 2011 12:45 AM
To: Zhang, Jessica; Ke, Liping
Cc: yocto@...
Subject: POKY_DISTRO_VERSION or OECORE_DISTRO_VERSION?

Hi Jessica,

I noticed the we still use POKY_DISTRO_VERSION in the environment while some other variables have changed their prefix to OECORE_ (e.g. OECORE_NATIVE_SYSROOT, etc.)

Which prefix should we use for those version related variables in the environment files? OECORE_ or POKY_?

-Lianhao


Re: crownbay-noemgd poky-image-minimal fails to build

Andre Haupt <andre@...>
 

On Fri, Jul 29, 2011 at 10:32:03AM -0400, Bruce Ashfield wrote:
As for the second, there's a patch in the 2.6.34 kernel tree
that is dealing with it:

http://git.pokylinux.org/cgit/cgit.cgi/linux-yocto-2.6.34/commit/?h=standard&id=72ca49ab08b8eb475cec82a10049503602325791


It sounds like there may be a SRCREV problem for the board that
isn't picking up that change. Can you confirm that this commit
is in your board branch ? You can check in your build directory
for linux.
This commit is not in the crownbay-standard branch.
Argh. That explains it. You can always cherry pick / apply
it locally. This is intended to be a blanket fix, and
I just double checked and I for some reason *don't* see
it on that one branch either, which means it isn't a SRCREV
error hiding it.

I'm going to merge the patch out to the BSP branch now, but
you'd still need a SRCREV update to see the change in your
build.
I pushed out the change. If your SRCREV is
a945cd4a4b27c8f9165f4064c8c60e4df569b4c5 for the
crownbay, you'll pickup the commit.
Thank you very much, Bruce. The patch is now picked up, and
the build runs successfully.

cheers,

Andre


POKY_DISTRO_VERSION or OECORE_DISTRO_VERSION?

Lu, Lianhao <lianhao.lu@...>
 

Hi Jessica,

I noticed the we still use POKY_DISTRO_VERSION in the environment while some other variables have changed their prefix to OECORE_ (e.g. OECORE_NATIVE_SYSROOT, etc.)

Which prefix should we use for those version related variables in the environment files? OECORE_ or POKY_?

-Lianhao


Re: kernel panic - not syncing: No init found

Bruce Ashfield <bruce.ashfield@...>
 

On 11-07-31 11:30 PM, Tom Zanussi wrote:
On Sun, 2011-07-31 at 19:42 -0700, Bruce Ashfield wrote:
On 11-07-31 3:44 PM, Francis Meyvis wrote:
Hello,

I probably miss something trivial.
I cloned the git://git.yoctoproject.org/poky.git
I build on a 64 bit machine a qemux86-64
(. ./oe-init-build-env qemux86-64 and changing the conf/local.conf)
I build the core-image-sato& core-image-minimal.
Then I try to run with
runqemu qemux86-64 core-image-sato ext3

But both sato and minimal give me this message:
Kernel panic - not syncing: No init found.

As runqemu showed me the full command line I tried to add the --append
command line option
init=/sbin/init and /sbin/init.sysvinit
But that did not help (there's a message saying Failed to execute
/sbin/init. Attempting defaults...)
I verified by mounting these ext3 images on a loop device that there's
really a /sbin/init present.

Can somebody tell what I'm doing wrong?
Can you send a full bootlog, or paste it somewhere accessible ? It's hard
to say what's with the information you've given.

Is this the latest yocto master ?

If you are seeing that message it typically means that the the
device that is being used as the root isn't ready (fixed by
rootwait/rootdelay) or isn't supported (i.e. NFS root without
the right ethernet device). Changing what init is, won't change
the result if either one of those is the case.
I'm also seeing this on both sugarbay and jasperforest with the latest
master. rootwait doesn't help.

rtc_cmos 00:07: setting system clock to 2010-01-02 05:35:34 UTC
(1262410534)
Freeing unused kernel memory: 720k freed
Failed to execute /init
Kernel panic - not syncing: No init found. Try passing init= option to
kernel.
See Linux Documentation/init.txt for guidance.
Pid: 1, comm: swapper Not tainted 3.0.0-rc7-yocto-standard+ #1
Call Trace:
[<ffffffff81541b77>] panic+0x9b/0x191
[<ffffffff81540862>] init_post+0xc0/0xc0
[<ffffffff8188bcef>] kernel_init+0x17b/0x17b
[<ffffffff8154b234>] kernel_thread_helper+0x4/0x10
[<ffffffff8188bb74>] ? start_kernel+0x377/0x377
[<ffffffff8154b230>] ? gs_change+0xb/0xb

I thought initially it had something to do with the -live image changes,
but reverting the two -live patches didn't help.

The problem seems to coincide with the tune file changes, but that may
be a red herring.
Nope. I don't think it's a red herring:

Both of these:

Freeing unused kernel memory: 720k freed
Failed to execute /init

Indicate that the device came up and init was loaded, the kernel
passed control to userspace and then things went bad. i.e. you just
ran init of the wrong arch or something incompatible with the
kernel support, etc.

Since I'm having no trouble with old rootfs and new kernels, that's
another sign. I'm assuming that old userspace's boot for you ?

Bruce


Tom


Cheers,

Bruce


BTW is there any way to not have to run qemu with root permissions?
I ran the android emulator and it does not require me to be root.
Should I configure something on my Ubuntu machine to get qemu to function?

Thanks,
francis
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: kernel panic - not syncing: No init found

Tom Zanussi <tom.zanussi@...>
 

On Sun, 2011-07-31 at 19:42 -0700, Bruce Ashfield wrote:
On 11-07-31 3:44 PM, Francis Meyvis wrote:
Hello,

I probably miss something trivial.
I cloned the git://git.yoctoproject.org/poky.git
I build on a 64 bit machine a qemux86-64
(. ./oe-init-build-env qemux86-64 and changing the conf/local.conf)
I build the core-image-sato& core-image-minimal.
Then I try to run with
runqemu qemux86-64 core-image-sato ext3

But both sato and minimal give me this message:
Kernel panic - not syncing: No init found.

As runqemu showed me the full command line I tried to add the --append
command line option
init=/sbin/init and /sbin/init.sysvinit
But that did not help (there's a message saying Failed to execute
/sbin/init. Attempting defaults...)
I verified by mounting these ext3 images on a loop device that there's
really a /sbin/init present.

Can somebody tell what I'm doing wrong?
Can you send a full bootlog, or paste it somewhere accessible ? It's hard
to say what's with the information you've given.

Is this the latest yocto master ?

If you are seeing that message it typically means that the the
device that is being used as the root isn't ready (fixed by
rootwait/rootdelay) or isn't supported (i.e. NFS root without
the right ethernet device). Changing what init is, won't change
the result if either one of those is the case.
I'm also seeing this on both sugarbay and jasperforest with the latest
master. rootwait doesn't help.

rtc_cmos 00:07: setting system clock to 2010-01-02 05:35:34 UTC
(1262410534)
Freeing unused kernel memory: 720k freed
Failed to execute /init
Kernel panic - not syncing: No init found. Try passing init= option to
kernel.
See Linux Documentation/init.txt for guidance.
Pid: 1, comm: swapper Not tainted 3.0.0-rc7-yocto-standard+ #1
Call Trace:
[<ffffffff81541b77>] panic+0x9b/0x191
[<ffffffff81540862>] init_post+0xc0/0xc0
[<ffffffff8188bcef>] kernel_init+0x17b/0x17b
[<ffffffff8154b234>] kernel_thread_helper+0x4/0x10
[<ffffffff8188bb74>] ? start_kernel+0x377/0x377
[<ffffffff8154b230>] ? gs_change+0xb/0xb

I thought initially it had something to do with the -live image changes,
but reverting the two -live patches didn't help.

The problem seems to coincide with the tune file changes, but that may
be a red herring.

Tom


Cheers,

Bruce


BTW is there any way to not have to run qemu with root permissions?
I ran the android emulator and it does not require me to be root.
Should I configure something on my Ubuntu machine to get qemu to function?

Thanks,
francis
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: kernel panic - not syncing: No init found

Bruce Ashfield <bruce.ashfield@...>
 

On 11-07-31 3:44 PM, Francis Meyvis wrote:
Hello,

I probably miss something trivial.
I cloned the git://git.yoctoproject.org/poky.git
I build on a 64 bit machine a qemux86-64
(. ./oe-init-build-env qemux86-64 and changing the conf/local.conf)
I build the core-image-sato& core-image-minimal.
Then I try to run with
runqemu qemux86-64 core-image-sato ext3

But both sato and minimal give me this message:
Kernel panic - not syncing: No init found.

As runqemu showed me the full command line I tried to add the --append
command line option
init=/sbin/init and /sbin/init.sysvinit
But that did not help (there's a message saying Failed to execute
/sbin/init. Attempting defaults...)
I verified by mounting these ext3 images on a loop device that there's
really a /sbin/init present.

Can somebody tell what I'm doing wrong?
Can you send a full bootlog, or paste it somewhere accessible ? It's hard
to say what's with the information you've given.

Is this the latest yocto master ?

If you are seeing that message it typically means that the the
device that is being used as the root isn't ready (fixed by
rootwait/rootdelay) or isn't supported (i.e. NFS root without
the right ethernet device). Changing what init is, won't change
the result if either one of those is the case.

Cheers,

Bruce


BTW is there any way to not have to run qemu with root permissions?
I ran the android emulator and it does not require me to be root.
Should I configure something on my Ubuntu machine to get qemu to function?

Thanks,
francis
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


kernel panic - not syncing: No init found

Francis Meyvis <francis.meyvis@...>
 

Hello,

I probably miss something trivial.
I cloned the git://git.yoctoproject.org/poky.git
I build on a 64 bit machine a qemux86-64
(. ./oe-init-build-env qemux86-64 and changing the conf/local.conf)
I build the core-image-sato & core-image-minimal.
Then I try to run with
runqemu qemux86-64 core-image-sato ext3

But both sato and minimal give me this message:
Kernel panic - not syncing: No init found.

As runqemu showed me the full command line I tried to add the --append
command line option
init=/sbin/init and /sbin/init.sysvinit
But that did not help (there's a message saying Failed to execute
/sbin/init. Attempting defaults...)
I verified by mounting these ext3 images on a loop device that there's
really a /sbin/init present.

Can somebody tell what I'm doing wrong?

BTW is there any way to not have to run qemu with root permissions?
I ran the android emulator and it does not require me to be root.
Should I configure something on my Ubuntu machine to get qemu to function?

Thanks,
francis


libpam-1.1.4-r1 strange behavior

Francis Meyvis <francis.meyvis@...>
 

Hello,

My download directory is on a CIFS mounted drive.
The idea was that other PCs could access the already downloaded files
on the local network.

The package libpam however failed processing.
After changing the path on which I had mounted the CIFS partition,
to a PC local download directory, the package libpam succeeded.

What I saw:

It seemed to get in a busy loop related to SMB when using files name
"*.lock" and "*.done"
I found this by starting a wireshark session to see what was going on.
It seems to try to QUERY_PATH_INFO for *.lock in the download directory.
The CIFS server responds STATUS_OBJECT_NAME_INVALID

After I changed to a local download directory,
I found these files after processing the package in the download directory:

-rw-r--r-- 1 franchan franchan 0 2011-07-31 18:38 99_pam.done
-rw-r--r-- 1 franchan franchan 0 2011-07-31 18:38 *.done
-rw-r--r-- 1 franchan franchan 0 2011-07-31 18:38
libpam-xtests.patch.done
-rw-r--r-- 1 franchan franchan 1123186 2011-06-24 13:42
Linux-PAM-1.1.4.tar.bz2
-rw-r--r-- 1 franchan franchan 0 2011-07-31 18:38
Linux-PAM-1.1.4.tar.bz2.done

According to me CIFS has troubles with these *.lock and *.done flag files.
Could the libpam package be done in another way so that it works for
CIFS files systems?
Or should I not have used CIFS fs when using bitbake?

Thanks,
francis


Yocto weekly bug trend charts -- WW31

Xu, Jiajun <jiajun.xu@...>
 

Hi all,
Yocto 1.1 M2 released last week. The new-submit vs. fixed bug is 28 vs. 36. A lot of bugs are fixed, which make both open bug number and WDD number decreased a lot -- Open bug number from 185 to 174; WDD number from 943 to 887. Bug status of WW30 could be found on https://wiki.pokylinux.org/wiki/Yocto_Bug_Trend.

Best Regards,
Jiajun


Re: [PATCH][linux-yocto-3.0] drivers/misc/pch_phub.c: don't oops if dmi_get_system_info returns NULL

Bruce Ashfield <bruce.ashfield@...>
 

On 11-07-30 2:34 PM, Khem Raj wrote:
On Thursday, July 28, 2011 04:51:41 PM Darren Hart wrote:
Bruce,

Please apply to yocto/base. Fixes a boot issue for a
tunnel creek development board.

--

commit 2b934c6236983392d01bef22e43af3051cac16f5

If dmi_get_system_info() returns NULL, pch_phub_probe() will dereferencea
a zero pointer.

This oops was observed on an Atom based board which has no BIOS, but a
bootloder which doesn't privde DMI data.

Signed-off-by: Alexander Stein<alexander.stein@...>
Cc: Tomoya MORINAGA<tomoya-linux@...>
Cc: Greg KH<gregkh@...>
Signed-off-by: Andrew Morton<akpm@...>
Signed-off-by: Linus Torvalds<torvalds@...>
---
drivers/misc/pch_phub.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/misc/pch_phub.c b/drivers/misc/pch_phub.c
index 5fe79df..01eb67b 100644
--- a/drivers/misc/pch_phub.c
+++ b/drivers/misc/pch_phub.c
@@ -686,6 +686,8 @@ static int __devinit pch_phub_probe(struct pci_dev
*pdev, }

if (id->driver_data == 1) { /* EG20T PCH */
+ const char *board_name;
+
retval = sysfs_create_file(&pdev->dev.kobj,
&dev_attr_pch_mac.attr);
if (retval)
@@ -701,7 +703,8 @@ static int __devinit pch_phub_probe(struct pci_dev
*pdev, CLKCFG_CANCLK_MASK);

/* quirk for CM-iTC board */
- if (strstr(dmi_get_system_info(DMI_BOARD_NAME), "CM-iTC"))
+ board_name = dmi_get_system_info(DMI_BOARD_NAME);
+ if (board_name&& strstr(board_name, "CM-iTC"))
May be it could be just if ( dmi_get_system_info(DMI_BOARD_NAME)&&
strstr(board_name, "CM-iTC"))

although I think compiler will already do it internally
Could very well be. I grabbed this one directly from linus' tree,
so I've got it as-is for now, but I've tagged it to be considered
later if we do decide that we want to send a tweak of this upstream

Thanks!

Bruce


pch_phub_read_modify_write_reg(chip,
(unsigned int)CLKCFG_REG_OFFSET,
CLKCFG_UART_48MHZ | CLKCFG_BAUDDIV |


Re: [PATCH][linux-yocto-3.0] drivers/misc/pch_phub.c: don't oops if dmi_get_system_info returns NULL

Khem Raj
 

On Thursday, July 28, 2011 04:51:41 PM Darren Hart wrote:
Bruce,

Please apply to yocto/base. Fixes a boot issue for a
tunnel creek development board.

--

commit 2b934c6236983392d01bef22e43af3051cac16f5

If dmi_get_system_info() returns NULL, pch_phub_probe() will dereferencea
a zero pointer.

This oops was observed on an Atom based board which has no BIOS, but a
bootloder which doesn't privde DMI data.

Signed-off-by: Alexander Stein <alexander.stein@...>
Cc: Tomoya MORINAGA <tomoya-linux@...>
Cc: Greg KH <gregkh@...>
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>
---
drivers/misc/pch_phub.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/misc/pch_phub.c b/drivers/misc/pch_phub.c
index 5fe79df..01eb67b 100644
--- a/drivers/misc/pch_phub.c
+++ b/drivers/misc/pch_phub.c
@@ -686,6 +686,8 @@ static int __devinit pch_phub_probe(struct pci_dev
*pdev, }

if (id->driver_data == 1) { /* EG20T PCH */
+ const char *board_name;
+
retval = sysfs_create_file(&pdev->dev.kobj,
&dev_attr_pch_mac.attr);
if (retval)
@@ -701,7 +703,8 @@ static int __devinit pch_phub_probe(struct pci_dev
*pdev, CLKCFG_CANCLK_MASK);

/* quirk for CM-iTC board */
- if (strstr(dmi_get_system_info(DMI_BOARD_NAME), "CM-iTC"))
+ board_name = dmi_get_system_info(DMI_BOARD_NAME);
+ if (board_name && strstr(board_name, "CM-iTC"))
May be it could be just if ( dmi_get_system_info(DMI_BOARD_NAME) &&
strstr(board_name, "CM-iTC"))

although I think compiler will already do it internally

pch_phub_read_modify_write_reg(chip,
(unsigned int)CLKCFG_REG_OFFSET,
CLKCFG_UART_48MHZ | CLKCFG_BAUDDIV |
--
Khem Raj