[yocto] libtool problems

[Mike Tsukerman]

Hello,

I've found some problems with toolchain on target rootfs.
It does not depends on what architecture i've building for.

For example i want to build something on target rootfs.
Downloading tar archive with sources and building it. Sometimes
libtool says about old versions of package files. Upgrade of these files
with

libtoolize --copy --force and aclocal

does not always solve problems.
Sometimes it says that libXXX.la files have wrong format.

I'll be very pleased if you help me solve this problems.

-- 
Best regards, Mike Tsukerman

jabber: miketsuker...@gmail.com
jabber: war...@jabnet.org
skype: w_a_r_z_o_n
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] libtool problems

[Robert Yang]

Maybe "autoreconf -fi" helps, autoreconf will also run "libtool"
where appropriate.

// Robert

On 11/15/2011 08:02 PM, Mike Tsukerman wrote:

Hello,

I've found some problems with toolchain on target rootfs.
It does not depends on what architecture i've building for.

For example i want to build something on target rootfs.
Downloading tar archive with sources and building it. Sometimes
libtool says about old versions of package files. Upgrade of these files
with

libtoolize --copy --force and aclocal

does not always solve problems.
Sometimes it says that libXXX.la files have wrong format.

I'll be very pleased if you help me solve this problems.




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

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

Re: [yocto] UI skelecton of hob v2 is updated in wiki.

[Wang, Shane]

Thank you for the comments, Lianhao.
See mine below.

--
Shane

Lu, Lianhao wrote on 2011-11-15:

> Some comments:
> 
> 1. Do we need the "Window" menu to "to switch to any step from any step"?
> I don't think the users are allowed to skip step 2 by directly swtiching from
> step1 to step3. The "Back" and "Next" in each step should do the work.
OK, it is open. And up to Belen.
What if the user has built recipes before, and doesn't want to go step 2 for 
recipe selection but want to try another image making directly?
I agree we should consider the workflow carefully to allow/disallow user's 
input at some stage. Can we disable the menu item if it is disallowed?


> 
> 2. Do we need those "View ***.conf" and open "Open directory" items
> under "Tools" menu? I think hob is designed to help users to avoid
> viewing/editing those configuration files and recipes. What's the difference
> between build log and make log? I think we might not want to put too many
> items under menus.
Log for building recipes, and log for making image from packages.
Hob v1 can view log for debugging.

> 
> 3. In step 1 configuration, maybe we can replace the configuration variable
> names with their actual meaning, at least for the basic configurtaion
> dialogue. If we can't define the actual meaning of a configuration variable,
> we then might need to think about whether we should put that configuration
> item into the UI.
Their names are TBD. Agree. But for one variable, we need abbreviate it to 2-3 
words because the small window doesn't allow the long description in the code.

> 
> 4. In the advanced configuration dialogue, it'd better if we group those items
> by their meanings and influence, not by the filename where the configure
> variable is defined.  
Yes.

> 
> 5. Is it possible that we move some image-only related configuration items,
> i.e. IMAGE_FSTYPES, ROOTFS_FLASH_SIZE, FREE_SPCE, etc. from step1
> dialogue into the step3 dialogue?
In my previous discussion with Dongxiao, we want keep them both in step 1 and 
in step 3.
So, in step 1, user can do settings. But in step 3, he/she still has the chance 
to change.
But if we put them in step 3 only, it means we will have another "configuration 
and settings" stage.
The workflow would be:
step 1 (setting for build recipes) -> step 2 (recipe selection) -> step 3 
(setting for making image) -> step 4 (package selection).
I am not sure which is better for developer experience.


> 
> Best Regards,
> Lianhao
> 
> 
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org
>> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Wang, Shane
>> Sent: Monday, November 14, 2011 9:12 AM
>> To: yocto@yoctoproject.org
>> Subject: [yocto] UI skelecton of hob v2 is updated in wiki.
>> 
>> See https://wiki.yoctoproject.org/wiki/Hob2_(Hob_v2)#UI_Skelecton for
>> more details.
>> 
>> Please comment.
>> 
>> Thank you.
>> --
>> Shane
>> 
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


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

Re: [yocto] Yocto Technical Team Meeting

[Liu, Song]

https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.2_Status

-Original Appointment-
From: Liu, Song
Sent: Tuesday, August 16, 2011 3:27 PM
To: 'McCombe, Kevin'; Wold, Saul; Zhang, Jessica; 'deVries, Alex'; 'Polk, 
Jeffrey'; 'Hatle, Mark'; Purdie, Richard; Li, Susie; Lock, Joshua; 'Bruce 
Ashfield'; Zanussi, Tom; Hart, Darren; Flanagan, Elizabeth; Stewart, David C; 
'lieu...@windriver.com'; 'paul.ander...@windriver.com'; Osier-mixon, Jeffrey; 
Dmytriyenko, Denys; Kooi, Koen; 'yocto...@yoctoproject.org'; Erway, Tracey M; 
'Daniel Cauchy'; Wang, Shane; 'Kridner, Jason'; Yu, Ke; Rifenbark, Scott M; 
'Dixon, Brad'; 'Jeremy Puhlman'; yocto@yoctoproject.org; 
'shsift-yo...@yahoo.com'
Cc: 'mor...@mvista.com'; 'Ruff, Nithya'; Moeller, Thorsten; Saxena, Rahul; 
'Ranslam, Rob'; 'Anders Darander'; Bodke, Kishore K; Lu, Lianhao
Subject: Yocto Technical Team Meeting
When: Tuesday, November 15, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & 
Canada).
Where: Bridge Info Enclosed




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

Re: [yocto] rpm dependency errors

[Mark Hatle]

On 11/14/11 10:16 PM, Michael E Brown wrote:
> I've now run across this same error in two different contexts, and am
> having difficulty trying to figure out what is going on
> 
> First, while building meta-toolchain-sdk, I ran into
> http://pastebin.com/BT02UYk1
>  ... cut ...
> Processing task-core-standalone-gmae-sdk-target-dbg...
> | error: Failed dependencies:
> |   libgthread-2.0.so.0 is needed by libgupnp-1.0-3-0.16.1-r0.sh4
> |   libresolv.so.2 is needed by libgupnp-1.0-3-0.16.1-r0.sh4
> 
> I've confirmed that the libgupnp rpm has only SH4 binaries in it.
> 
> Next, while building a custom image, I ran across the same error with
> portmap and tcp-wrappers:
> 
> http://pastebin.com/dRb5Dum8
> 
> Note in the pastebin I extracted tcp-wrappers and 'file' says that
> everything is SH4.

This type of error usually means that those two items were required as libraries
(for the target packages) and no rpm packages available provide those items.

Usually it means they were not being packaged, but did end up in the sysroot
somehow.

The items in the pastebin are a different issue, I suspect... From the pastebin:

(Lets start with the requirements first)
> $ rpm -qp --requires tcp-wrappers-7.6-r0.sh4.rpm
> warning: tcp-wrappers-7.6-r0.sh4.rpm: Header V4 DSA signature: NOKEY, key ID
fe659c6d
> libc6 >= 2.13

This is a package requirement..

> libwrap0 >= 7.6

As is this one..

> rtld(GNU_HASH)

This is a virtual requirement -- I need a rtld that supports GNU_HASH.

> libc.so.6
> libc.so.6(GLIBC_2.3)
> libc.so.6(GLIBC_2.2)

Above three are library SONAME requirements.  I first require something with the
SONAME of "libc.so.6", and then also require two versioned symbols GLIBC_2.3 and
GLIBC_2.2.

> libwrap.so.0

This is simply an SONAME requirement.

> $ rpm -qp --provides libc6-2.13-r15+svnr14157.sh4.rpm
> warning: libc6-2.13-r15+svnr14157.sh4.rpm: Header V4 DSA signature: NOKEY, 
> key ID 47031d66
> rtld(GNU_HASH)  
> glibc  
> libc6 = 2.13-r15+svnr14157

When you look at the provides, we're not providing any of the soname/shared
library requirements.   There are a few possibilities as to the cause:

*) You simply didn't package the libraries..  check with rpm -qp -l .
Do you see /lib/libc.so.6 there?

*) The libraries inside of this package are invalid for some reason?

*) objdump isn't able to read the soname values from these libraries for some
reason.

*) elfutils version of objdump isn't able to read the soname values from these
libraries for some reason.

... look into each of those and see if you can figure out what might be wrong.
If you get to the point of investigating objdump or elfutils-objdump -- be sure
to run it against the versions from the package and not the work directory.  (It
is possible something is getting mangled at package time.)

--Mark

> --
> Michael
> 
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

[yocto] Minutes: Yocto Technical Team Meeting - Tuesday, November 15, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada)

[Liu, Song]

Attendees:
Matthew, Saul, Paul, Richard, Dave, Darren, Joshua, Tom, Jeff, Mark, Jessica, 
Sean, Scott, Bruce, Lianhao, Beth, Song
 
* Opens collection - 5 min (Song)
* Yocto 1.0.2 and 1.1.1 point release update - 5 min (Josh)
  - Had some issues last week with autobuilder. Appeared to be resolved. Beth 
had some issues working on them yesterday. Beth is proposing some patches, will 
check with Josh. Beth is trying to have a build today. Should have the build 
this week.
  - 1.1.1, not much progress, should be more progress next week. Possible more 
patches regarding most recent issues. Josh will sync with Richard.  
* Yocto 1.2 M1 Status (features development) - 10 min (Song)
  https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.2_Status 
  Just finished the status and schedule update. Please get the status in 
bugzilla by Monday morning so that I have time updating things on the wiki. 
Hopefully we can automate these soon.
  - Issues: 
. Paul 1565/p1, no status, (Paul) Will have this in by the end of the week.
. Beth 1546/p1, no status.
. Some features have been staying in the current for more than 2 weeks. 
Anything blocking?
  - Build status: sanity test issue, actually more of infrastructure problem, 
should be resolved by now, we are mostly green.
* Opens - 10 min
  - bootloaders (Darren): syslinux and grub2 for BSPs mostly. Couple of items 
to convert EFI bootloader. Having 2 to maintain is a lot of work, propose to 
remove grub 2 from oe core. This discussion needs to continue on the mailing 
list. I can address meta-intel BSPs only, but this can benefit others also. 
Darren will send email to the mailing list to continue the discussion. 
. Concerns (Sean) that grub 2 does not have home, will take it back to 
mentor and provide any feedback. Maybe removing syslinux.
. Darren will do research on File system and chain loading and continue the 
discussion on the mailing list. 
  - how to deal with UEFI bootloading. A few options, efi linux, some have 
interest in dual booting, would like get some understanding on which direction 
to go: desktop with more flexibility or simple ones, or multi-bootloader 
approach.
. One bootloader for one BSP. It would be nice to support more than one. 
(Mark)
. Unfortunately we would have to support both. (RP)
. (Sean) From a design/layer perspective, maybe one bootloader for one 
specific BSP. Large number of HW we want to support is non-intel.
 
  - meeting for shoeleather (Sean): Sean will organize a meeting for this 
project, if anyone is interested please email Sean.
 
* Action item Review - 5 min
1. Richard will review unsorted features and prioritize them. (WIP)
 
* Weekly team sharing (20 min)
 
Beth: get 1.0.2 build. Found some issues, finally hit the source mirror issue, 
solving it now. Got more performance for the autobuilder, a clean button for 
sstate build. This week will continue on the clean sstate build button. 
Lianhao: travelling in US, discussing HOB design issues with Jessica, Josh, 
getting clear on issues and plan. No blocking issues. Only thing we need to 
discuss now is the collaboration model with designers in UK.
Bruce: working on planning for 1.2, working on some infrastructure changes for 
tools, getting ready to push to 3.2 kernel. Having issues with laptops, taking 
30 secs to run recipes. Pseudo is taking a long time, there might be some 
issues. Database is growing really large (RP). Will take note of this and 
figure it out. 
Saul: working with Richard, maintainers issues, pull request, process and 
planning on 1.2 around package updating. This week, continue on package update. 
Out the rest of this week for Linux con in Brazil. 
Scott: working on issues on manuals. Trying to get hw together for fri ii.
Sean: going to be doing a conference call, if you are interested, please send 
me email. If there is trouble getting to me, send the email to John Cherry.
Jessica: working on plugin, tools, figure out, remote tools launch, setting up 
the meeting and framework, push to come up with a common framework. Working 
with lianhao on HOB review. Continue work on remote tools.
Mark: main thing is FS construction issues, prelink stuff, 64bit, continue to 
work on these things.
Jeff: nothing
Tom: spent time on going through some docs with Scott. Similar things last week 
with another Intel guy. Wrapping up to do video accelerating issues. Crownbay, 
emenlow. Will continue with that.
Josh: worked on 1.0.2 release and some 1.2 design work, will work on 1.1.1
Darren: spent time on some internal projects, helping get people start on BSPs, 
things around UEFI bootloading, will focus on some internal projects, get the 
final design for bootloader, as well as some BSP work.
Richard: catch up with various patches, get the build green, continue this week.
Paul: working on a number of bugs reported by community, 3 of them, a little 
bit work on the p1 issue. Continue on the p1 feature this week,





_

Re: [yocto] changing kernel config on a project built by Hob

[Joshua Lock]

Hi Jitendra,

On 11/11/11 11:37, Jitendra Shekhawat wrote:
> Newbie here. I think I've looked at the relevant documents and couldn't
> find how to do this.
> 
> What is the procedure for doing a kernel 'make menuconfig' on hob
> assisted projects?
> 
> I created a simple project using following steps:
> 1. source poky-edison-6.0/oe-init-build-env
> 2. hob
> 3. configuration under hob:
>  - Machine: atom-pc
>  - Base image: core-image-minimal 
>  - Added openssh
> 4. save the image as test.bb 
> 5. Baked the image in hob
> 6. Booted the result in Virtualbox after creating a bootable disk image,
> etc.
> 
> I need to now modify the kernel by adding CP210x USB/Serial converter
> driver.
> 
> What is the procedure for doing a 'make menuconfig' on this hob assisted
> project?

Unfortunately we don't currently support modifying the kernel config via
the hob GUI although it's certainly something we'd like to enable in the
future.

Regards,
Joshua
-- 
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][linux-yocto] mount_root: clarify error messages for when no rootfs found (V2)

[Darren Hart]

The following is a modified version the patch at:

meta/cfg/kernel-cache/patches/boot/mount_root-clarify-error-messages-for-when-no-rootfs.patch

in the linux-yocto-3.0 git repository. This version adds KERN_EMERG
so that even using loglevel=1 at boot, the end user will see:

[0.217462] VFS: Unable to mount root fs on unknown-block(8,2)
[0.223457] User configuration error - no valid root filesystem found
[0.230057] Kernel panic - not syncing: Invalid configuration from end user 
preg
[0.238992] Pid: 1, comm: swapper Not tainted 3.0.4-yocto-standard+ #2
[0.245691] Call Trace:  
   
[0.248218]  [] ? 0xc04eddbc   
   
[0.252071]  [] ? 0xc05549ad   
   
[0.255928]  [] ? 0xc05549fa   
   
[0.259790]  [] ? 0xc0554623   
   
[0.263650]  [] ? 0xc0554b1c   
   
[0.267497]  [] ? 0xc055472a   
   
[0.271344]  [] ? 0xc04f0df6   
   

Instead of just:

[0.230057] Kernel panic - not syncing: Invalid configuration from end user 
preg
...

Which is arguably no better than what this patch originally attempted to 
address.

Paul, has this patch been sent upstream for inclusion? I don't see it in Linus' 
tree.

Thanks,

Darren

--

To an end user who doesn't really know linux that well, a
message like:

  Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

may just look like cryptic computer speak indicating some
deep and complex problem, instead of the reality that they
have a simple local configuration problem.  Ideally it would
be nice to not use the misleading "panic" at all, but since
various panic notifiers are historically expecting to be
called when there is no valid rootfs, we can't change that.

So instead, this tries to make it 100% clear to folks of
any background that it is an end user configuration issue.

V2: Use KERN_EMERG so the printk context isn't lost when using loglevel

Signed-off-by: Paul Gortmaker 
Signed-off-by: Darren Hart 
---
 init/do_mounts.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/init/do_mounts.c b/init/do_mounts.c
index bb008d0..d24b8c7 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -270,7 +270,9 @@ retry:
printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
   "explicit textual name for \"root=\" boot option.\n");
 #endif
-   panic("VFS: Unable to mount root fs on %s", b);
+   printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+   printk(KERN_EMERG "User configuration error - no valid root 
filesystem found\n");
+   panic("Invalid configuration from end user prevents 
continuing");
}
 
printk("List of all partitions:\n");
@@ -282,7 +284,9 @@ retry:
 #ifdef CONFIG_BLOCK
__bdevname(ROOT_DEV, b);
 #endif
-   panic("VFS: Unable to mount root fs on %s", b);
+   printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+   printk(KERN_EMERG "User configuration error - no valid root filesystem 
found\n");
+   panic("Invalid configuration from end user prevents continuing");
 out:
putname(fs_names);
 }
-- 
1.6.5.2
-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][linux-yocto] mount_root: clarify error messages for when no rootfs found (V2)

[Paul Gortmaker]

On 11-11-15 03:19 PM, Darren Hart wrote:
> The following is a modified version the patch at:
> 
> meta/cfg/kernel-cache/patches/boot/mount_root-clarify-error-messages-for-when-no-rootfs.patch
> 
> in the linux-yocto-3.0 git repository. This version adds KERN_EMERG
> so that even using loglevel=1 at boot, the end user will see:
> 
> [0.217462] VFS: Unable to mount root fs on unknown-block(8,2)
> [0.223457] User configuration error - no valid root filesystem found
> [0.230057] Kernel panic - not syncing: Invalid configuration from end 
> user preg
> [0.238992] Pid: 1, comm: swapper Not tainted 3.0.4-yocto-standard+ #2
> [0.245691] Call Trace:
>  
> [0.248218]  [] ? 0xc04eddbc 
>  
> [0.252071]  [] ? 0xc05549ad 
>  
> [0.255928]  [] ? 0xc05549fa 
>  
> [0.259790]  [] ? 0xc0554623 
>  
> [0.263650]  [] ? 0xc0554b1c 
>  
> [0.267497]  [] ? 0xc055472a 
>  
> [0.271344]  [] ? 0xc04f0df6 
>  
> 
> Instead of just:
> 
> [0.230057] Kernel panic - not syncing: Invalid configuration from end 
> user preg
> ...
> 
> Which is arguably no better than what this patch originally attempted to 
> address.
> 
> Paul, has this patch been sent upstream for inclusion? I don't see it in 
> Linus' tree.

No, I never sent it upstream.  It seemed like such a trivial and
cosmetic change.  If you want to put the V2 comment below the ---
and send it upstream, feel free to do so.

P.

> 
> Thanks,
> 
> Darren
> 
> --
> 
> To an end user who doesn't really know linux that well, a
> message like:
> 
>   Kernel panic - not syncing: VFS: Unable to mount root fs on 
> unknown-block(0,0)
> 
> may just look like cryptic computer speak indicating some
> deep and complex problem, instead of the reality that they
> have a simple local configuration problem.  Ideally it would
> be nice to not use the misleading "panic" at all, but since
> various panic notifiers are historically expecting to be
> called when there is no valid rootfs, we can't change that.
> 
> So instead, this tries to make it 100% clear to folks of
> any background that it is an end user configuration issue.
> 
> V2: Use KERN_EMERG so the printk context isn't lost when using loglevel
> 
> Signed-off-by: Paul Gortmaker 
> Signed-off-by: Darren Hart 
> ---
>  init/do_mounts.c |8 ++--
>  1 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/init/do_mounts.c b/init/do_mounts.c
> index bb008d0..d24b8c7 100644
> --- a/init/do_mounts.c
> +++ b/init/do_mounts.c
> @@ -270,7 +270,9 @@ retry:
>   printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
>  "explicit textual name for \"root=\" boot option.\n");
>  #endif
> - panic("VFS: Unable to mount root fs on %s", b);
> + printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
> + printk(KERN_EMERG "User configuration error - no valid root 
> filesystem found\n");
> + panic("Invalid configuration from end user prevents 
> continuing");
>   }
>  
>   printk("List of all partitions:\n");
> @@ -282,7 +284,9 @@ retry:
>  #ifdef CONFIG_BLOCK
>   __bdevname(ROOT_DEV, b);
>  #endif
> - panic("VFS: Unable to mount root fs on %s", b);
> + printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
> + printk(KERN_EMERG "User configuration error - no valid root filesystem 
> found\n");
> + panic("Invalid configuration from end user prevents continuing");
>  out:
>   putname(fs_names);
>  }
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][linux-yocto] mount_root: clarify error messages for when no rootfs found (V2)

[Darren Hart]

On 11/15/2011 12:56 PM, Paul Gortmaker wrote:
> On 11-11-15 03:19 PM, Darren Hart wrote:
>> The following is a modified version the patch at:
>>
>> meta/cfg/kernel-cache/patches/boot/mount_root-clarify-error-messages-for-when-no-rootfs.patch
>>
>> in the linux-yocto-3.0 git repository. This version adds KERN_EMERG
>> so that even using loglevel=1 at boot, the end user will see:
>>
>> [0.217462] VFS: Unable to mount root fs on unknown-block(8,2)
>> [0.223457] User configuration error - no valid root filesystem found
>> [0.230057] Kernel panic - not syncing: Invalid configuration from end 
>> user preg
>> [0.238992] Pid: 1, comm: swapper Not tainted 3.0.4-yocto-standard+ #2
>> [0.245691] Call Trace:   
>>   
>> [0.248218]  [] ? 0xc04eddbc
>>   
>> [0.252071]  [] ? 0xc05549ad
>>   
>> [0.255928]  [] ? 0xc05549fa
>>   
>> [0.259790]  [] ? 0xc0554623
>>   
>> [0.263650]  [] ? 0xc0554b1c
>>   
>> [0.267497]  [] ? 0xc055472a
>>   
>> [0.271344]  [] ? 0xc04f0df6
>>   
>>
>> Instead of just:
>>
>> [0.230057] Kernel panic - not syncing: Invalid configuration from end 
>> user preg
>> ...
>>
>> Which is arguably no better than what this patch originally attempted to 
>> address.
>>
>> Paul, has this patch been sent upstream for inclusion? I don't see it in 
>> Linus' tree.
> 
> No, I never sent it upstream.  It seemed like such a trivial and
> cosmetic change.  If you want to put the V2 comment below the ---
> and send it upstream, feel free to do so.
> 

OK. We really shouldn't be holding on to patches like these. If they are
good for us, they should be good for upstream. If they are not good for
upstream, then we don't want to differ in such a way that causes
confusion for people trying to debug.

For example, I saw the latter message, thought it was due to the new
bootloader I was trying, and the bootloader author couldn't find that
string in the upstream kernel sources he develops with.

--
Darren

> P.
> 
>>
>> Thanks,
>>
>> Darren
>>
>> --
>>
>> To an end user who doesn't really know linux that well, a
>> message like:
>>
>>   Kernel panic - not syncing: VFS: Unable to mount root fs on 
>> unknown-block(0,0)
>>
>> may just look like cryptic computer speak indicating some
>> deep and complex problem, instead of the reality that they
>> have a simple local configuration problem.  Ideally it would
>> be nice to not use the misleading "panic" at all, but since
>> various panic notifiers are historically expecting to be
>> called when there is no valid rootfs, we can't change that.
>>
>> So instead, this tries to make it 100% clear to folks of
>> any background that it is an end user configuration issue.
>>
>> V2: Use KERN_EMERG so the printk context isn't lost when using loglevel
>>
>> Signed-off-by: Paul Gortmaker 
>> Signed-off-by: Darren Hart 
>> ---
>>  init/do_mounts.c |8 ++--
>>  1 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/init/do_mounts.c b/init/do_mounts.c
>> index bb008d0..d24b8c7 100644
>> --- a/init/do_mounts.c
>> +++ b/init/do_mounts.c
>> @@ -270,7 +270,9 @@ retry:
>>  printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
>> "explicit textual name for \"root=\" boot option.\n");
>>  #endif
>> -panic("VFS: Unable to mount root fs on %s", b);
>> +printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
>> +printk(KERN_EMERG "User configuration error - no valid root 
>> filesystem found\n");
>> +panic("Invalid configuration from end user prevents 
>> continuing");
>>  }
>>  
>>  printk("List of all partitions:\n");
>> @@ -282,7 +284,9 @@ retry:
>>  #ifdef CONFIG_BLOCK
>>  __bdevname(ROOT_DEV, b);
>>  #endif
>> -panic("VFS: Unable to mount root fs on %s", b);
>> +printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
>> +printk(KERN_EMERG "User configuration error - no valid root filesystem 
>> found\n");
>> +panic("Invalid configuration from end user prevents continuing");
>>  out:
>>  putname(fs_names);
>>  }

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto reference manual: error in given example

[Rifenbark, Scott M]

Hi,

I am looking at the YP Reference manual and the example in this section uses 
meta/recipes-sato/tasks/task-poky.bb, which doesn’t seem to exist in the Poky 
tree.   Since the example in the section 3.2.2 is created just for 
instructional purposes I am going to get rid of the reference to the 
‘meta/recipes-sato/tasks/task-poky.bb’ path.

To make the example correct, can I simply insert the ‘ALLOW_EMPTY = “1” 
statement as follows:


DESCRIPTION = "My Custom Tasks"

 PACKAGES = "\
 task-custom-apps \
 task-custom-apps-dbg \
 task-custom-apps-dev \
 task-custom-tools \


 task-custom-tools-dbg \
 task-custom-tools-dev \
 "



 ALLOW_EMPTY = "1"

 RDEPENDS_task-custom-apps = "\
 dropbear \
 portmap \
 psplash"

 RDEPENDS_task-custom-tools = "\


 oprofile \
 oprofileui-server \
 lttng-control \
 lttng-viewer"

 RRECOMMENDS_task-custom-tools = "\
 kernel-module-oprofile"


From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Marc Ferland
Sent: Thursday, November 10, 2011 12:48 PM
To: yocto@yoctoproject.org
Subject: [yocto] Yocto reference manual: error in given example

Hi,

The example given in section 3.2.2 is missing a:

inherit task

instruction.

Could also have been ALLOW_EMPTY = "1".

I realized this after a couple hours of debugging!

Regards,

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

Re: [yocto] what's the proper value for BB_NUMBER_THREADS?

[Rifenbark, Scott M]

I haven't heard more on this.  Should I adjust the documents to suggest 2x for 
both these variables?

Scott

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Robert P. J. Day
Sent: Thursday, November 03, 2011 10:42 AM
To: Darren Hart
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] what's the proper value for BB_NUMBER_THREADS?

On Thu, 3 Nov 2011, Darren Hart wrote:

>
>
> On 10/31/2011 10:39 AM, Gary Thomas wrote:
> > On 2011-10-31 11:25, Robert P. J. Day wrote:
> >> On Mon, 31 Oct 2011, Mark Hatle wrote:
> >>
> >>> On 10/30/11 11:15 AM, Robert P. J. Day wrote:
>  On Sun, 30 Oct 2011, Christian Gagneraud wrote:
> 
> > On 30/10/11 15:32, Robert P. J. Day wrote:
> >>
> >> all the docs recommend twice the number of cores (AFAICT), yet the
> >> template local.conf file suggests that, for a quad core, the value of
> >> 4 would be appropriate.  shouldn't that say 8?  same with
> >> PARALLEL_MAKE?
> >
> > Hi Robert,
> >
> > The Poky ref manual says (rule of thumb) x2 for BB_NUMBER_THREADS,
> > and x1.5 for PARALLEL_MAKE.
> 
> if that's the case, anyone object to my submitting a patch to
>  update local.conf.sample appropriately?
> 
>  rday
> 
> >>>
> >>> I agree the manual and local.conf files should match.  The issue
> >>> seems to be that the perfect values are subjective.  Things like
> >>> memory, disk speed, chipset latency, and of course processor
> >>> speed/cores all affect the optimal setting. But we do need a
> >>> consistent rule of thumb..  I myself usually use x2 for both THREADS
> >>> and MAKE.
> >>
> >>that's what i would normally use, assuming that having an overly
> >> high value for either of those settings can't possibly hurt.  if
> >> that's the consensus, i can adjust the references to say 2x everywhere
> >> that i know of.  just let me know.
> >
> > Look back in the archives - I think it was Richard that did a fairly
> > extensive study of this and he (whoever it was) found that there were
> > saturation points and trying to get beyond them had a negative impact.
>
> 2x on each works well up to about 12 in my experience. Richard has found
> benefits using 24 on a similar system with more memory. However, if you
> aren't building on a monster machine, then 2x serves as a reasonable
> rule of thumb.

  since i vaguely recall that i was the one who asked about this, i
can submit a patch for this unless someone else already wants to.  i
can see that the places to change would be in some of the docs, as
well as the comment in local.conf.sample.

  anyone else want to take care of that?  anyone?  bueller?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] what's the proper value for BB_NUMBER_THREADS?

[Darren Hart]

On 11/15/2011 03:08 PM, Rifenbark, Scott M wrote:
> I haven't heard more on this.  Should I adjust the documents to
> suggest 2x for both these variables?

I think that's a reasonable thing to do, yes.

--
Darren

> 
> Scott
> 
> -Original Message- From: yocto-boun...@yoctoproject.org
> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Robert P. J.
> Day Sent: Thursday, November 03, 2011 10:42 AM To: Darren Hart Cc:
> yocto@yoctoproject.org Subject: Re: [yocto] what's the proper value
> for BB_NUMBER_THREADS?
> 
> On Thu, 3 Nov 2011, Darren Hart wrote:
> 
>> 
>> 
>> On 10/31/2011 10:39 AM, Gary Thomas wrote:
>>> On 2011-10-31 11:25, Robert P. J. Day wrote:
 On Mon, 31 Oct 2011, Mark Hatle wrote:
 
> On 10/30/11 11:15 AM, Robert P. J. Day wrote:
>> On Sun, 30 Oct 2011, Christian Gagneraud wrote:
>> 
>>> On 30/10/11 15:32, Robert P. J. Day wrote:
 
 all the docs recommend twice the number of cores
 (AFAICT), yet the template local.conf file suggests
 that, for a quad core, the value of 4 would be
 appropriate.  shouldn't that say 8?  same with 
 PARALLEL_MAKE?
>>> 
>>> Hi Robert,
>>> 
>>> The Poky ref manual says (rule of thumb) x2 for
>>> BB_NUMBER_THREADS, and x1.5 for PARALLEL_MAKE.
>> 
>> if that's the case, anyone object to my submitting a patch
>> to update local.conf.sample appropriately?
>> 
>> rday
>> 
> 
> I agree the manual and local.conf files should match.  The
> issue seems to be that the perfect values are subjective.
> Things like memory, disk speed, chipset latency, and of
> course processor speed/cores all affect the optimal setting.
> But we do need a consistent rule of thumb..  I myself usually
> use x2 for both THREADS and MAKE.
 
 that's what i would normally use, assuming that having an
 overly high value for either of those settings can't possibly
 hurt.  if that's the consensus, i can adjust the references to
 say 2x everywhere that i know of.  just let me know.
>>> 
>>> Look back in the archives - I think it was Richard that did a
>>> fairly extensive study of this and he (whoever it was) found that
>>> there were saturation points and trying to get beyond them had a
>>> negative impact.
>> 
>> 2x on each works well up to about 12 in my experience. Richard has
>> found benefits using 24 on a similar system with more memory.
>> However, if you aren't building on a monster machine, then 2x
>> serves as a reasonable rule of thumb.
> 
> since i vaguely recall that i was the one who asked about this, i can
> submit a patch for this unless someone else already wants to.  i can
> see that the places to change would be in some of the docs, as well
> as the comment in local.conf.sample.
> 
> anyone else want to take care of that?  anyone?  bueller?
> 
> rday
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] rpm dependency errors

[Michael E Brown]

On Mon, 2011-11-14 at 22:16 -0600, Michael E Brown wrote:
> I've now run across this same error in two different contexts, and am
> having difficulty trying to figure out what is going on
> 
> First, while building meta-toolchain-sdk, I ran into
> http://pastebin.com/BT02UYk1
>  ... cut ...
> Processing task-core-standalone-gmae-sdk-target-dbg...
> | error: Failed dependencies:
> |   libgthread-2.0.so.0 is needed by libgupnp-1.0-3-0.16.1-r0.sh4
> |   libresolv.so.2 is needed by libgupnp-1.0-3-0.16.1-r0.sh4
> 
> I've confirmed that the libgupnp rpm has only SH4 binaries in it.
> 
> Next, while building a custom image, I ran across the same error with
> portmap and tcp-wrappers:
> 
> http://pastebin.com/dRb5Dum8
> 
> Note in the pastebin I extracted tcp-wrappers and 'file' says that
> everything is SH4.

As a bit more information, I found that when I changed to "package_ipk"
vs rpm in my local.conf, I was able to do image build and sdk builds
without incident. So this problem looks like something specific to rpm
package builds. Is there any solution to this other than just not using
rpm?

--
Michael

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

[yocto] /usr/bin/env dependencies

[Mike Tsukerman]

Hello,

I'm trying to build my own image for my own machine configuration ( based
on beagleboard )
and get some errors. Please tell me what package is missing?

error: Failed dependencies:
| /usr/bin/env is needed by automake-1.11.1-r4.armv7ahf
| /usr/bin/env is needed by slang-2.2.4-r6.armv7ahf
| /usr/bin/env is needed by mc-4.7.5.2-r2.armv7ahf
| /usr/bin/env is needed by autoconf-2.68-r3.armv7ahf
| /usr/bin/env is needed by intltool-0.40.6-r5.armv7ahf
| /usr/bin/env is needed by python-core-2.7.2-r0.0.armv7ahf
| /usr/bin/env is needed by gnu-config-0.1+cvs20080123-r4.armv7ahf


-- 
Best regards, Mike Tsukerman

jabber: miketsuker...@gmail.com
jabber: war...@jabnet.org
skype: w_a_r_z_o_n
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][linux-yocto] mount_root: clarify error messages for when no rootfs found (V2)

[Bruce Ashfield]

On 11-11-15 3:19 PM, Darren Hart wrote:

The following is a modified version the patch at:


Works for me as well, I'll update the variant in the yocto kernel
trees, while we wait to see if anyone upstream has any interest.

Bruce



meta/cfg/kernel-cache/patches/boot/mount_root-clarify-error-messages-for-when-no-rootfs.patch

in the linux-yocto-3.0 git repository. This version adds KERN_EMERG
so that even using loglevel=1 at boot, the end user will see:

[0.217462] VFS: Unable to mount root fs on unknown-block(8,2)
[0.223457] User configuration error - no valid root filesystem found
[0.230057] Kernel panic - not syncing: Invalid configuration from end user 
preg
[0.238992] Pid: 1, comm: swapper Not tainted 3.0.4-yocto-standard+ #2
[0.245691] Call Trace:
[0.248218]  [] ? 0xc04eddbc
[0.252071]  [] ? 0xc05549ad
[0.255928]  [] ? 0xc05549fa
[0.259790]  [] ? 0xc0554623
[0.263650]  [] ? 0xc0554b1c
[0.267497]  [] ? 0xc055472a
[0.271344]  [] ? 0xc04f0df6

Instead of just:

[0.230057] Kernel panic - not syncing: Invalid configuration from end user 
preg
...

Which is arguably no better than what this patch originally attempted to 
address.

Paul, has this patch been sent upstream for inclusion? I don't see it in Linus' 
tree.

Thanks,

Darren

--

To an end user who doesn't really know linux that well, a
message like:

   Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)

may just look like cryptic computer speak indicating some
deep and complex problem, instead of the reality that they
have a simple local configuration problem.  Ideally it would
be nice to not use the misleading "panic" at all, but since
various panic notifiers are historically expecting to be
called when there is no valid rootfs, we can't change that.

So instead, this tries to make it 100% clear to folks of
any background that it is an end user configuration issue.

V2: Use KERN_EMERG so the printk context isn't lost when using loglevel

Signed-off-by: Paul Gortmaker
Signed-off-by: Darren Hart
---
  init/do_mounts.c |8 ++--
  1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/init/do_mounts.c b/init/do_mounts.c
index bb008d0..d24b8c7 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -270,7 +270,9 @@ retry:
printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
   "explicit textual name for \"root=\" boot option.\n");
  #endif
-   panic("VFS: Unable to mount root fs on %s", b);
+   printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+   printk(KERN_EMERG "User configuration error - no valid root 
filesystem found\n");
+   panic("Invalid configuration from end user prevents 
continuing");
}

printk("List of all partitions:\n");
@@ -282,7 +284,9 @@ retry:
  #ifdef CONFIG_BLOCK
__bdevname(ROOT_DEV, b);
  #endif
-   panic("VFS: Unable to mount root fs on %s", b);
+   printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+   printk(KERN_EMERG "User configuration error - no valid root filesystem 
found\n");
+   panic("Invalid configuration from end user prevents continuing");
  out:
putname(fs_names);
  }


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