[yocto] qemuarm: Unable to mount rootfs

[Sergey Lychagin]

Hello,

I've faced the following problem: "VFS: unable to mount root fs via NFS"
during staring pre-compiled kernel/rootfs images in quemu.
The screen-shot: http://imgur.com/XtvRc
I'm trying to start it via Eclipse as it is shown in
http://vimeo.com/30557368

I also followed the instructions described ADT user guide:
http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html
Target is qemuarm. kernel & rootfs (core-image-sato-sdkqemuarm &
zImage-qemuarm.bin) are precompiled and downloaded from here:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/machines/qemu/qemuarm/

As far as I know this kernel image should support NFS.
Could you please help me?

Thanks in advance
Sergey
___
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 09:36 PM, Bruce Ashfield wrote:
> 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.

I we can't get it upstream, I'd argue we drop this. As Paul said, it is
cosmetic. When people see this error, the only place they'll find help
is here on the yocto list. They should be able to debug the kernel with
all the Linux Kernel resources out there. Having custom kernel messages
for Yocto prevents that.

--
Darren

> 
> 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);
>>   }
> 

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

[Bruce Ashfield]

On 11-11-16 10:45 AM, Darren Hart wrote:



On 11/15/2011 09:36 PM, Bruce Ashfield wrote:

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.


I we can't get it upstream, I'd argue we drop this. As Paul said, it is
cosmetic. When people see this error, the only place they'll find help


I have no plans to drop this. It's a value add, and simply
because not everyone wants it, doesn't mean we let it go.

We can carry it and try again if it doesn't make it upstream.


is here on the yocto list. They should be able to debug the kernel with
all the Linux Kernel resources out there. Having custom kernel messages
for Yocto prevents that.


I disagree.

Bruce



--
Darren



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

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

[Darren Hart]

On 11/16/2011 07:51 AM, Bruce Ashfield wrote:
> On 11-11-16 10:45 AM, Darren Hart wrote:
>>
>>
>> On 11/15/2011 09:36 PM, Bruce Ashfield wrote:
>>> 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.
>>
>> I we can't get it upstream, I'd argue we drop this. As Paul said, it is
>> cosmetic. When people see this error, the only place they'll find help
> 
> I have no plans to drop this. It's a value add, and simply
> because not everyone wants it, doesn't mean we let it go.
> 
> We can carry it and try again if it doesn't make it upstream.
> 
>> is here on the yocto list. They should be able to debug the kernel with
>> all the Linux Kernel resources out there. Having custom kernel messages
>> for Yocto prevents that.
> 
> I disagree.

With which part? That they should be able to use all the available
resources? Or that custom kernel messages restrict where they can get
help? I don't see how you can really argue against either of those...

--
Darren

> 
> Bruce
> 
>>
>> --
>> Darren
>>
>>>
>>> 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);
}
>>>
>>
> 

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

[Bruce Ashfield]

On 11-11-16 11:00 AM, Darren Hart wrote:



On 11/16/2011 07:51 AM, Bruce Ashfield wrote:

On 11-11-16 10:45 AM, Darren Hart wrote:



On 11/15/2011 09:36 PM, Bruce Ashfield wrote:

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.


I we can't get it upstream, I'd argue we drop this. As Paul said, it is
cosmetic. When people see this error, the only place they'll find help


I have no plans to drop this. It's a value add, and simply
because not everyone wants it, doesn't mean we let it go.

We can carry it and try again if it doesn't make it upstream.


is here on the yocto list. They should be able to debug the kernel with
all the Linux Kernel resources out there. Having custom kernel messages
for Yocto prevents that.


I disagree.


With which part? That they should be able to use all the available
resources? Or that custom kernel messages restrict where they can get
help? I don't see how you can really argue against either of those...


Sorry for the short reply, I was being pulled away and couldn't
elaborate.

I don't see the two issues as being tied together or at least
not signifcantly. If  two people are debugging a kernel issue, it is
incumbent that they know the trees they are using and to ensure that
they are at least somewhat in sync. The changes aren't hidden in any
way, so it's easy to know what is in play.

It's no different than using a arch/vendor tree versus mainline
or linux-next, or even two different mainline trees where one has
a changed strings. A grep or search will fail, and at that point
we sync on the tree versions and make sure they match.

There's plenty of other bigger issues that a few different
messages coming out of the kernel that can prevent people from
using resources. So I'm not arguing that it isn't a factor, I'm
just saying that it (a custom message) isn't a significant one.

Obviously we want the patch to be upstream, that's a baseline
goal for any change and I understand frustration and losing some
time during debug. But that particular message has been proven
to save lots of time in many other situations, so I wouldn't shoot
myself in the foot by dropping it based solely on it not being
upstream.

I'd modify it to meet comments, make it optional, prepend
[yocto], dropping it would be last resort.

I'm heading AFK again, but will be back later today.

Cheers,

Bruce



--
Darren



Bruce



--
Darren



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);
+

[yocto] EXTRA_IMAGEDEPENDS documentation

[Darren Hart]

For the situation where a recipe is required to build a final image, but
the output is not needed in the root filesystem, the EXTRA_IMAGEDEPENDS
variable can be used to define this dependency. Bootloaders seem to be
the common example for this (such as the beagleboard dependency on uboot).

This variable is not defined in the poky manual nor in the documentation
tags (meta/conf/documentation.conf).

Another aspect of this that could be made more explicit in the manual is
that the various *RRECOMMENDS and *RDEPENDS variables impact what is
installed in the root filesystem (because they operate on packages - not
recipes). Scott, I'd recommend a few extra words in the *RRECOMMENDS and
*RDEPENDS documentation to this effect. For example, "... a list of
packages to install TO THE ROOT FILESYSTEM ...".

As for the EXTRA_IMAGEDEPENDS definition, perhaps something like this:

in documentation.conf:

EXTRA_IMAGEDEPENDS[doc] = "Recipes to build that do not install packages
to the root filesystem, such as bootloaders."

in the reference manual:

EXTRA_IMAGEDEPENDS
A list of recipes to be built that do not provide packages to be
installed in the root filesystem. This is typically used to specify a
required bootloader in a machine config.

Note: To add packages to the root filesystem, see the various *DEPENDS
and *RECOMMENDS variables.

Scott, I'll leave the reference manual changes to you. RP, if you agree
with my doc tag, I can submit a patch for that.

Thanks,

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

[Mark Hatle]

On 11/15/11 9:06 PM, Michael E Brown wrote:

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?


RPM packages contain more dependency information then ipk and deb packages. 
This is not a bug, but a feature.  When using RPM packages not only are 
specified dependencies there, but also soname and file level dependencies.


There is an outstanding item to add these soname and file level dependencies to 
the OE/Yocto deb and ipk implementations as well.


Trust me, if the dependency is failing, then there is something wrong with the 
packages or the binaries within the packages (or they're not compatible with the 
elfutils mechanisms used to dump that information.)


You really do need to understand the actual files present in the packages, and 
if they have the corresponding sonames that the dependent packages are looking for.


If you post your layer somewhere, I can attempt to reproduce the problem.

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

Re: [yocto] /usr/bin/env dependencies

[Mark Hatle]

On 11/15/11 10:19 PM, Mike Tsukerman wrote:

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


Each of those packages contains a shell script that is invoked with:

#!/usr/bin/env ...

Likely the "..." bit is python.

Usually busybox or coreutils will provide the /usr/bin/env binary.

If your configuration has flattened the directory structure and removed "/usr", 
then each of those packages have flaws in them and are not respecting the 
revised "bindir" information -- otherwise you are simply missing functionality 
in either busybox or coreutils.


--Mark


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


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

Re: [yocto] qemuarm: Unable to mount rootfs

[Zhang, Jessica]

Hi Sergey,



Couple questions:



1.   So did you extract your qemuarm rootfs using runquem-extract-sdk to a 
directory?

2.   Point to that directory as sysroot in your Eclipse preference setup 
page (all of this should be covered in the ADT manual)?

3.   Can you open an xterm and look for qemu process and kill all of them 
and retry launch?



Thanks,

Jessica



From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Sergey Lychagin
Sent: Wednesday, November 16, 2011 4:07 AM
To: yocto@yoctoproject.org
Subject: [yocto] qemuarm: Unable to mount rootfs



Hello,

I've faced the following problem: "VFS: unable to mount root fs via NFS" during 
staring pre-compiled kernel/rootfs images in quemu.
The screen-shot: http://imgur.com/XtvRc
I'm trying to start it via Eclipse as it is shown in http://vimeo.com/30557368

I also followed the instructions described ADT user guide: 
http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html
Target is qemuarm. kernel & rootfs (core-image-sato-sdkqemuarm & 
zImage-qemuarm.bin) are precompiled and downloaded from here: 
http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/machines/qemu/qemuarm/

As far as I know this kernel image should support NFS.
Could you please help me?

Thanks in advance
Sergey

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

Re: [yocto] applying the Yocto Project to Automotive interests

[Joshua Lock]

Tracey,

On 14/11/11 13:49, Erway, Tracey M wrote:
> Folks,
> 
> I’m presenting a Yocto Project session at the upcoming Linux Foundation
> Automotive Summit in Yokohama, Japan at the end of November.
> 
> I thought that folks on this list might have suggestions for pertinent
> subject matter that I should include in the session.
> 
> It’s only  30 minutes, so I’ll need to paint a broad picture.

I think IVI folks will be keen to know we make point releases with bug,
security and build fixes - we should see Bernard 1.0.2 and Edison 1.1.1
releases this quarter.

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

Re: [yocto] applying the Yocto Project to Automotive interests

[Mark Hatle]

On 11/14/11 3:49 PM, Erway, Tracey M wrote:

Folks,

I’m presenting a Yocto Project session at the upcoming Linux Foundation
Automotive Summit in Yokohama, Japan at the end of November.

I thought that folks on this list might have suggestions for pertinent subject
matter that I should include in the session.

It’s only 30 minutes, so I’ll need to paint a broad picture.

All suggestions welcome,


Automotive release cycles are -very- long.. in the 4-5 year development time 
frame and 10-15 year product support time frame.  As I understand it, the Yocto 
Project does not intend to continue support for any release within those time 
frames.  This is where the end user and/or OSV will need to determine the 
support requirements and support policies outside of what Yocto provides.


Yocto does not provide an "application framework" (this was a big selling point 
of Moblin/MeeGo).  Yocto allows someone to generate their own Linux distribution 
for their own needs.  What this means to someone like GENIVI is that they CAN 
create an application framework based on Yocto, but it would be work they would 
need to do (with us) likely in using a custom layer that specifies specific 
distribution settings, enhancements, etc.


Yocto is a cross-compiled build environment.  This is a departure to a lot of 
the Moblin/MeeGo work that has occurred in the past.  The advantages are you can 
use any commodity PC to target any (supported) architecture.  Disadvantages are 
that when you introduce new code, you need to ensure that it has a recipe (build 
instructions for bitbake) and can cross compile.  If everyone has to do the same 
work over and over, this can be time consuming and counter productive.  If 
people work together, the time and support burden are dramatically reduced. 
This can help negate issues people have had in the past with cross compiling. 
Note: Yocto -does- have a self hosted compile environment if it is needed, this 
is usually when cross compiling isn't easy to do for some reason.


Yocto currently does not support a set of "blessed" binary packages.  Our 
expectation is that the users of Yocto will create their own distributions, and 
then in turn provide binary packages to their own customers/users in whatever 
mechanism is appropriate.  If the automotive folks want to start with binary 
packages and simply add their own stuff on top, someone will need to create the 
distribution (see above about settings and frameworks) and provide the "blessed" 
package feeds.


Anyone have any other questions/comments let me know.  I'm pretty familiar with 
automotive and GENIVI requirements as of a few years ago.  I'm a bit out of date 
with the current work however.


--Mark


/t

*/Tracey M. Erway/*

*/The Yocto Project* - /**/www.yoctoproject.org/*

Intel Corporation

503 . 264 . 6435 Effective VM to Email Service

503 . 709 . 1221 Cell / Blackberry



___
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] EXTRA_IMAGEDEPENDS documentation

[Rifenbark, Scott M]

Darren, 

Regarding *DEPENDS  Right now these variables are documented in the YP 
Reference Manual.  Your email says that the *DEPENDS variables impact the root 
filesystem.  That is sort of vague.  
Can I just add that to each of these descriptions below?

DEPENDS - A list of build-time dependencies for a given recipe.  
The variable indicates recipes that must have been 
staged before a particular recipe can configure.

DISTRO_EXTRA_RDEPENDS - The list of packages required by the 
distribution.

LAYERDEPENDS - Lists the layers that this recipe depends upon, 
separated by spaces.  Optionally, you can dspecify a 
specific layer version for a dependency by adding it 
to the end of the layer name with a colon 
(e.g. "anotherlayer:3" to be compared against 
LAYERVERSION_anotherlayer in this case).  An error will 
be produced if any dependency is missing or the 
version numbers do not match exactly (if specified).  
This variable is used in the conf/layer.conf file and
must be suffixed with the name of the specific layer 
(e.g. LAYERDEPENDS_mylayer).

MACHINE_ESSENTIAL_EXTRA_RDEPENDS - A list of required packages 
to install as part of the package being built.  The 
build process depends on these packages being present.  
Furthermore, because this is a "machine essential" 
variable, the list of packages are essential for the 
machine to boot.  The impact of this variable affects 
images based on task-core-boot including the 
core-image-minimal image.

This variable is similar to the 
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS variable with the 
exception that the package being built has a build 
dependency on the variable's list of packages.  In other 
words, the image will not beuild if a file in this list 
is not found.

For example, suppose you are building a a runtime 
package that depends on a certain disk driver.  In this 
case, you would use the following:

  MACHINE_ESSENTIAL_EXTRA_RDEPENDS += ""

MACHINE_EXTRA_RDEPENDS - A list of optional but non-machine 
essential packages to install as part of the package 
being built.  Even though these packages are not 
essential for the machine to boot, the build process 
depends on them being present.  The impact of this 
variable affects all images based on task-base, which 
does not include the core-image-minimal or 
core-image-basic images.

This variable is similar to the 
MACHINE_EXTRA_RRECOMMENDS variable with the exception 
that the package being built has a build dependency on 
the variable's list of packages.  In other words, the 
image will not build if a file in this list is not 
found.

An example is a machine that might or might not have a 
WiFi card.  The package containing the WiFi support is 
not essential for the machine to boot the image.
If it is not there, the machine will boot but not be able 
to use the WiFi functionality.  However, if you include 
the package with the WiFi support as part of the 
variable's package list, the build process depends on 
finding the package.  In this case, you would use the 
following:

MACHINE_EXTRA_RDEPENDS += ""

RDEPENDS - A list of packages that must be installed as part of a 
package being built.  The package being built has a runtime 
dependency on the packages in the variable's list.  In 
other words, in order for the package being built to run 
correctly, it depends on these listed packages.  If a 
package in this list cannot be found during the build, 
the build will not complete.

Because the RDEPENDS variable applies to packages 
being built, you should always attach an override to the 
variable to specify the particular runtime package
that has the dependency.  For example, suppose you are 
building a development package that depends on the 
perl package.  In this case, you would use the fol

[yocto] Yocto usability questions

[Jeff Osier-Mixon]

Mark Hatle said:

> Yocto is a cross-compiled build environment.  This is a departure to a lot
> of the Moblin/MeeGo work that has occurred in the past.  The advantages are
> you can use any commodity PC to target any (supported) architecture.
>  Disadvantages are that when you introduce new code, you need to ensure
> that it has a recipe (build instructions for bitbake) and can cross
> compile.  If everyone has to do the same work over and over, this can be
> time consuming and counter productive.  If people work together, the time
> and support burden are dramatically reduced. This can help negate issues
> people have had in the past with cross compiling. Note: Yocto -does- have a
> self hosted compile environment if it is needed, this is usually when cross
> compiling isn't easy to do for some reason.
>

Mark & everyone else listening:

Would you say that (1) the need for a recipe and (2) the requirement to
cross-compile are two of the most major usability or learning-curve
disadvantages of working with the Yocto Project (and oe-core)? What would
be a third disadvantage from a usability standpoint?

Another way to put it: if you could change three things about the Yocto
Project to make it more approachable for someone who has never used it
before, what would they be?

-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] EXTRA_IMAGEDEPENDS documentation

[Darren Hart]

On 11/16/2011 12:52 PM, Rifenbark, Scott M wrote:
> Darren, 
> 
> Regarding *DEPENDS  Right now these variables are documented in the YP 
> Reference Manual.  Your email says that the *DEPENDS variables impact the 
> root filesystem.  That is sort of vague.  
> Can I just add that to each of these descriptions below?

I believe so, yes. Any place we refer to "packages" we are talking about
the root filesystem. One exception below is LAYERDEPENDS, that one does
not impact the root filesystem.

--
Darren

> 
>   DEPENDS - A list of build-time dependencies for a given recipe.  
> The variable indicates recipes that must have been 
> staged before a particular recipe can configure.
> 
>   DISTRO_EXTRA_RDEPENDS - The list of packages required by the 
> distribution.
> 
>   LAYERDEPENDS - Lists the layers that this recipe depends upon, 
> separated by spaces.  Optionally, you can dspecify a 
> specific layer version for a dependency by adding it 
> to the end of the layer name with a colon 
> (e.g. "anotherlayer:3" to be compared against 
> LAYERVERSION_anotherlayer in this case).  An error will 
> be produced if any dependency is missing or the 
> version numbers do not match exactly (if specified).  
> This variable is used in the conf/layer.conf file and
> must be suffixed with the name of the specific layer 
> (e.g. LAYERDEPENDS_mylayer).
> 
>   MACHINE_ESSENTIAL_EXTRA_RDEPENDS - A list of required packages 
> to install as part of the package being built.  The 
> build process depends on these packages being present.  
> Furthermore, because this is a "machine essential" 
> variable, the list of packages are essential for the 
> machine to boot.  The impact of this variable affects 
> images based on task-core-boot including the 
> core-image-minimal image.
> 
> This variable is similar to the 
> MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS variable with the 
> exception that the package being built has a build 
> dependency on the variable's list of packages.  In other 
> words, the image will not beuild if a file in this list 
> is not found.
> 
> For example, suppose you are building a a runtime 
> package that depends on a certain disk driver.  In this 
> case, you would use the following:
> 
>   MACHINE_ESSENTIAL_EXTRA_RDEPENDS += ""
> 
>   MACHINE_EXTRA_RDEPENDS - A list of optional but non-machine 
> essential packages to install as part of the package 
> being built.  Even though these packages are not 
> essential for the machine to boot, the build process 
> depends on them being present.  The impact of this 
> variable affects all images based on task-base, which 
> does not include the core-image-minimal or 
> core-image-basic images.
> 
> This variable is similar to the 
> MACHINE_EXTRA_RRECOMMENDS variable with the exception 
> that the package being built has a build dependency on 
> the variable's list of packages.  In other words, the 
> image will not build if a file in this list is not 
> found.
> 
> An example is a machine that might or might not have a 
> WiFi card.  The package containing the WiFi support is 
> not essential for the machine to boot the image.
> If it is not there, the machine will boot but not be able 
> to use the WiFi functionality.  However, if you include 
> the package with the WiFi support as part of the 
> variable's package list, the build process depends on 
> finding the package.  In this case, you would use the 
> following:
> 
> MACHINE_EXTRA_RDEPENDS += ""
> 
>   RDEPENDS - A list of packages that must be installed as part of a 
> package being built.  The package being built has a 
> runtime 
> dependency on the packages in the variable's list.  In 
> other words, in order for the package being built to run 
> correctly, it depends on these listed packages.  If a 
> package in this list cannot be found during the build, 
> the build will not complete.
> 
> Because the RDE

Re: [yocto] Yocto usability questions

[Mark Hatle]

On 11/16/11 4:07 PM, Jeff Osier-Mixon wrote:

Mark Hatle said:

Yocto is a cross-compiled build environment. This is a departure to a lot of
the Moblin/MeeGo work that has occurred in the past. The advantages are you
can use any commodity PC to target any (supported) architecture.
Disadvantages are that when you introduce new code, you need to ensure that
it has a recipe (build instructions for bitbake) and can cross compile. If
everyone has to do the same work over and over, this can be time consuming
and counter productive. If people work together, the time and support burden
are dramatically reduced. This can help negate issues people have had in the
past with cross compiling. Note: Yocto -does- have a self hosted compile
environment if it is needed, this is usually when cross compiling isn't easy
to do for some reason.


Mark & everyone else listening:

Would you say that (1) the need for a recipe and (2) the requirement to
cross-compile are two of the most major usability or learning-curve
disadvantages of working with the Yocto Project (and oe-core)? What would be a
third disadvantage from a usability standpoint?


1) Recipe isn't needed, unless you want automatically reproduced builds and to 
share the instructions with others... which is one our our goals.


I don't see the recipe as anything different then an SRPM, Debian src.tgz, etc. 
 The only obstacle is that it's "different" that what desktop distributions do.


2) I think cross compilation is by far the largest obstacle.  People not 
familiar with the GNU auto tools, cross compiling in general, or simply 
inexperienced developers seem to have a lot of problems with this.  I think 
OE/Yocto does a good job at providing GNU auto tools and make helpers, but it's 
far from perfect.  As far as how to improve it...  we need to keep incrementally 
improving our support, documentations and examples.  We also need to foster a 
community where people share the work they've already done... thus eliminating 
this issue.  (The meta-oe layer is a good place for this already.)


I'm sure there are other usability issues, but I've been doing cross compilation 
for so long that I'm a bit blind to some of the issues.


To me the biggest thing we need to do is make sure someone who is familiar with 
desktop Linux can step in and apply what they know to building a recipe and 
fixing cross compilation problems.  If we can do that -- it will go a long way 
toward helping resolve the issues that cause people to do self-hosted 
compilation on slow target systems.  (Note there are some things that are simply 
complicated and difficult to do like Firefox.. for those the only answer is to 
have "experts" do the work and make it available to the novices so they can see 
and understand how to work around various issues.)



Another way to put it: if you could change three things about the Yocto Project
to make it more approachable for someone who has never used it before, what
would they be?


To re-iterate:

*) We need a resource for contributed packages (meta-oe?) that will eliminate 
most of the problem.


*) We need good examples of problems and solutions to cross compilation 
difficulties

*) We need to continue to identify "common" issues and work to resolve them in 
the tooling we already support


--Mark


--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org




___
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 usability questions

[Ourada, Paul]

I apologize in advance for the top-post.

Like Mark, I'm a  20+ year veteran of "ordinary" embedded development, and so 
cross compilation is old hat for me as well. The usual commercial cross 
compilers, linkers, RTOSes, debuggers, and other libraries are usually fairly 
well integrated. Those types of environments tolerate their host environments 
fairly well, because it's pretty easy to keep everything separated.

I am much newer to Linux and embedded Linux development. I haven't used the SDK 
for Yocto yet, but I have used the Timesys SDK a little. For writing new 
code/apps, it's fairly straightforward - set up some environment variables, 
write a makefile and use cross_make, cross_configure, etc. I set up the 
embedded target to PXE boot, which keeps all executables and RFS on the host 
workstation. So for development one merely needs to drop the compiled app and 
any required configuration onto the RFS on the workstation. For writing 
kernel-level stuff, such as kernel mode drivers, one pretty much has to use the 
TimeSys factory (an extension to the kernel make environment from what I can 
tell).  

If one wants to use the TimeSys factory so that proprietary apps are built and 
loaded/installed into the RFS automagically, or build packages which are not on 
the TimeSys server, then one writes what is essentially the equivalent of the 
bitbake recipe, only in makefile format. It has all the same sorts of process 
steps: fetch, unpack, patch, auto/configure, compile, install.

Of course PXE boot can be set up for Yocto projects - I've already done it for 
the Kontron Atom board we're going to use in our next product. I hacked out the 
bzImage and root file system from the cpio image and plopped them into the 
tftpboot and exported rfs directory, and bingo - PXE booting!

Frankly, as a medical device software developer, I find the "recipe/makefile" 
paradigm much more familiar and preferable to the "app" developer paradigm. We 
have to be able to recreate bit-accurate images for our devices. A relatively 
consistent paradigm for accomplishing this is much better than cobbling 
together a bunch of ad hoc scripts.

At any rate, it seems to me that writing recipes is writing recipes, just like 
once you've used 3 or 4 editors or word processors, then you pretty much know 
what the score is when you go to pick up the 5th. Bitbake recipes aren't all 
that different from makefiles, except for the syntax,and learning the various 
meanings of different "build variables" -- oh, and using bitbake/python as 
glueinstead of jam, or make. I think that this has been the biggest source of 
frustration for me wrt to Yocto: Trying to map what I already know onto a new 
paradigm. I know - after 20 years, the mud gets a little thick and hard. ;)

But I understand the need to make things easier for the less experienced 
developer. And I get that cross compiling an embedded Linux OS is more 
intertwined with the host workstation OS than other RTOSes, even when they are 
compiled on a *nix workstation. One way that I'm addressing this for my 
development team (which has several never-done-Linux-no-way-no-how types) is 
finding links to relevant tutorials and sprinkling them in places they're 
likely to need the info. Although there is a ton of documentation out there, 
it's not always in easy to find places.

As a relative newcomer to Yocto and OE and bitbake, I can't agree with Mark 
more regarding examples and documentation. I'd suggest that you make a part of 
your process finding an inexperienced someone to run through your documentation 
and try to implement the various different features, or demonstrate knowledge 
of key concepts. The questions such a person might ask are likely pointers to 
holes in your documentation or process. This could be a good Google Summer of 
Code type exercise. Not as sexy as some, but definitely a big payoff for Yocto.

Mark mentioned the need for adding packages which are not already in the recipe 
base, but perhaps already exist in a desktop form. Making it easy to contribute 
seems like a common FOSS practice. For the difficulty aspect, someone mentioned 
in the Qt/OpenSSL thread recently that RPMs have a lot of the dependency 
information built into them, and I suspect also configuration files for 
install, or recipes for creating them. I also read in one of the Yocto blogs 
that someone on the Kernel side created a script to keep Kconfig fragments 
synched across BSPs. Might it be possible to write a script to mine a desktop 
RPM (or any other usable package format), and their associated makefile(s) to 
create as much of the bones of a bitbake recipe as can be gleaned from the 
desktop package? It might be as complex a task as the automake process itself. 
:)

Hope there was some useful information in there somewhere. :)

Paul Ourada
Sr Principal Software Engineer
Covidien, Surgical Solutions, Energy-based Devices


From: yocto-boun...@yoctopro

Re: [yocto] Yocto usability questions

[Koen Kooi]

Op 16 nov. 2011, om 23:07 heeft Jeff Osier-Mixon het volgende geschreven:

> Mark Hatle said:
> Yocto is a cross-compiled build environment.

I thought yocto was an umbrella project, not a build env. Openembedded-core is 
a  cross-compiled build environment, which poky (part of yocto) is based on.

Can we please get the messaging straight? If not, please rename poky to yocto.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto