Date   

Re: [meta-gplv2][warrior][master][PATCH] licenses: restore Elfutils-Exception from oe-core

Mikko Rapeli
 

On Wed, May 15, 2019 at 10:57:00AM +0000, Martin Jansa wrote:
* it's still used by:
recipes-devtools/elfutils/elfutils_0.148.bb:LICENSE = "(GPL-2+ & Elfutils-Exception)"
* was removed in oe-core with:
http://git.openembedded.org/openembedded-core/commit/?id=88188807a6ac9bab738a69f6b4caba9ed092d78f
* causing:
do_rootfs: The license listed Elfutils-Exception was not in the licenses collected for recipe elfutils
Looks good!

Reviewed-by: Mikko Rapeli <mikko.rapeli@bmw.de>

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
conf/layer.conf | 2 ++
licenses/Elfutils-Exception | 12 ++++++++++++
2 files changed, 14 insertions(+)
create mode 100644 licenses/Elfutils-Exception

diff --git a/conf/layer.conf b/conf/layer.conf
index 59f6a89..44c6712 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,3 +15,5 @@ LAYERVERSION_gplv2 = "1"
LAYERDEPENDS_gplv2 = "core"

LAYERSERIES_COMPAT_gplv2 = "warrior"
+
+LICENSE_PATH += "${LAYERDIR}/licenses"
diff --git a/licenses/Elfutils-Exception b/licenses/Elfutils-Exception
new file mode 100644
index 0000000..627d769
--- /dev/null
+++ b/licenses/Elfutils-Exception
@@ -0,0 +1,12 @@
+ This file describes the limits of the Exception under which you are allowed
+ to distribute Non-GPL Code in linked combination with Red Hat elfutils.
+ For the full text of the license, please see one of the header files
+ included with the source distribution or the file COPYING found in the
+ top level directory of the source.
+
+ The Approved Interfaces are the functions declared in the files:
+
+ libelf.h
+ libdw.h
+ libdwfl.h
+
--
2.17.1

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


[yocto-docs][PATCH] ref-features.xml: Remove documentation for the removed irda feature

Adrian Bunk
 

IrDA support was removed in upstream kernel 4.17,
and irda-utils as well as the feature are now also removed.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
documentation/ref-manual/ref-features.xml | 4 ----
1 file changed, 4 deletions(-)

diff --git a/documentation/ref-manual/ref-features.xml b/documentation/ref-manual/ref-features.xml
index 7a3555d0b9..b057d2d040 100644
--- a/documentation/ref-manual/ref-features.xml
+++ b/documentation/ref-manual/ref-features.xml
@@ -76,8 +76,6 @@
</para></listitem>
<listitem><para><emphasis>ext2:</emphasis> Hardware HDD or Microdrive
</para></listitem>
- <listitem><para><emphasis>irda:</emphasis> Hardware has IrDA support
- </para></listitem>
<listitem><para><emphasis>keyboard:</emphasis> Hardware has a keyboard
</para></listitem>
<listitem><para><emphasis>pcbios:</emphasis> Support for booting through BIOS
@@ -190,8 +188,6 @@
support.</para></listitem>
<listitem><para><emphasis>ipv6:</emphasis> Include IPv6 support.
</para></listitem>
- <listitem><para><emphasis>irda:</emphasis> Include IrDA support.
- </para></listitem>
<listitem><para><emphasis>keyboard:</emphasis> Include keyboard
support (e.g. keymaps will be loaded during boot).
</para></listitem>
--
2.17.1


[meta-security][PATCH] checksec: update to 1.11.1

Armin Kuster
 

* checksec.sh: Updated to 1.11.1
* checksec.sh: resolved issues with readelf
* checksec.sh: Added docker images for testing
* checksec.sh: Added armhf and aarch64 libc locations
* checksec.sh: Replace FS_COUNT with fgrep
* checksec.sh: Fixed symbols count in csv
* checksec.sh: Fixed RW-RPATH and RW-RUNPATH
* checksec.sh: Added stack canaries generated by intel compiler
* checksec.sh: Mute stat errors for non-existent directories
* checksec.sh: Removed invalid json structures and duplicate kernel checks
* checksec.sh: fixed spaces in -d option
* checksec.sh: Added stack-protector-string check
* checksec.sh: Add arm64 specific kernel checks
* checksec.sh: Add REFCOUNT_FULL to kernel tests
* checksec.sh: Remove OSX support

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
.../checksec/{checksec_1.11.bb => checksec_1.11.1.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename recipes-security/checksec/{checksec_1.11.bb => checksec_1.11.1.bb} (91%)

diff --git a/recipes-security/checksec/checksec_1.11.bb b/recipes-security/checksec/checksec_1.11.1.bb
similarity index 91%
rename from recipes-security/checksec/checksec_1.11.bb
rename to recipes-security/checksec/checksec_1.11.1.bb
index 59a67bd..835dffc 100644
--- a/recipes-security/checksec/checksec_1.11.bb
+++ b/recipes-security/checksec/checksec_1.11.1.bb
@@ -6,7 +6,7 @@ HOMEPAGE="https://github.com/slimm609/checksec.sh"

LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=93fddcca19f6c897871f9b5f9a035f4a"

-SRCREV = "a57e03c4f62dbaca0ec949bbc58491fb0c461447"
+SRCREV = "3c15cb89641c700096fdec0c1904a0cf9b83c5e2"
SRC_URI = "git://github.com/slimm609/checksec.sh"

S = "${WORKDIR}/git"
--
2.17.1


Re: Upgrading to Sumo triggered issue with python3 autopackaging - "ERROR: Nothing RPROVIDES 'python3-signal'"

Davis Roman <davis.roman84@...>
 

Hi,

Upon further inspection, I found a previous commit that appears to
have a bit more information:

python: Restructure python packaging and replace it with autopackaging
(http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=8d94b9db221d1def42f091b991903faa2d1651ce)


The following text appears helpful:


How to add a new package:
- If a user wants to add a new package all that has to be done is
modify the python2-manifest.json file, and add the required file(s)
to the FILES list, the script should handle all the rest.
Real example:
We want to add a web browser package, including the file webbrowser.py
which at the moment is on python-misc.
"webbrowser": {
"files": ["${libdir}/python2.7/lib-dynload/webbrowser.py"],
"rdepends": [],
"summary": "Python Web Browser support"}

Run bitbake python -c create_manifest and the resulting manifest
should be completed after a few seconds, showing something like:
"webbrowser": {
"files": ["${libdir}/python2.7/webbrowser.py"],
"rdepends": ["core","fcntl","io","pickle","shell","subprocess"],
"summary": "Python Web Browser support"}


So I add a section to my python3-manifest.json for the signal library
that I'm looking for:

"signal": {
"files": [
"${libdir}/python3.5/lib-dynload/signal.py"
],
"rdepends": [
],
"summary": "Python signal library"
}


I then re-run bitbake python -c create_manifest like the instructions
state however my python3-manifest.json is sadly unmodified and bitbake
still indicates that nothing rprovides 'python3-signal'

Any ideas would be greatly appreciated.

Thank you

Davis

On Wed, May 15, 2019 at 11:28 PM Davis Roman <davis.roman84@gmail.com> wrote:

Hello,

I upgraded to Sumo(2.5) and now bitbake is complaining that nothing
rprovides python3-signal.

ERROR: Nothing RPROVIDES 'python3-signal' (but
/home/worker/building/sources/meta-bluetooth/recipes-bluetooth/bluetooth-app/bluetooth-app.bb
RDEPENDS on or otherwise requires it)

After some searching I found that this is related to the restructuring
of python3 packaging in Sumo
(http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=b6777878ff03c3e956386020a19d11c875c835ae)

So according to the instructions in the above commit, I'm supposed to
first create a manifest file using:

$ bitbake python -c create_manifest

and then the json file appears to get created:

build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/python3/3.5.5-r1.0/python3-manifest.json

After a quick inspection of the created python3-manifest.json, I see
that signal.py already appears on the list.

"core": {
"cached": [
...
"${libdir}/python3.5/__pycache__/signal.*.pyc",
...
],
"files": [
...
"${libdir}/python3.5/signal.py",
...
],
"rdepends": [],
"summary": "Python interpreter and core modules"
},

Assuming that nothing else needs to be done, I then proceed to again
bitbake my application but unfortunately the original error persists.

What am I missing?

Thank you,

Davis Roman


Upgrading to Sumo triggered issue with python3 autopackaging - "ERROR: Nothing RPROVIDES 'python3-signal'"

Davis Roman <davis.roman84@...>
 

Hello,

I upgraded to Sumo(2.5) and now bitbake is complaining that nothing
rprovides python3-signal.

ERROR: Nothing RPROVIDES 'python3-signal' (but
/home/worker/building/sources/meta-bluetooth/recipes-bluetooth/bluetooth-app/bluetooth-app.bb
RDEPENDS on or otherwise requires it)

After some searching I found that this is related to the restructuring
of python3 packaging in Sumo
(http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=b6777878ff03c3e956386020a19d11c875c835ae)

So according to the instructions in the above commit, I'm supposed to
first create a manifest file using:

$ bitbake python -c create_manifest

and then the json file appears to get created:

build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/python3/3.5.5-r1.0/python3-manifest.json

After a quick inspection of the created python3-manifest.json, I see
that signal.py already appears on the list.

"core": {
"cached": [
...
"${libdir}/python3.5/__pycache__/signal.*.pyc",
...
],
"files": [
...
"${libdir}/python3.5/signal.py",
...
],
"rdepends": [],
"summary": "Python interpreter and core modules"
},

Assuming that nothing else needs to be done, I then proceed to again
bitbake my application but unfortunately the original error persists.

What am I missing?

Thank you,

Davis Roman


Re: problem adding a user

Rudolf J Streif
 

Glad to hear that it works now. I am planning on attending the YP DevDay.

:rjs

On Wed, May 15, 2019, 13:53 Greg Wilson-Lindberg <GWilson@...> wrote:

Thank you very much, that got me back on the right path.

Maybe I'll see you at the Yocto day at the Embedded Linux Conference.

Regards,

Greg Wilson-Lindberg 

Principal Firmware Engineer | Sakura Finetek USA, Inc. 

 

1750 W 214th Street | Torrance, CA 90501 | U.S.A. 

T: +1 310 783 5075 

F: +1 310 618 6902 | E: gwilson@sakuraus.com     

www.sakuraus.com           

 


Confidentiality Notice: This e-mail transmission may contain confidential or legally privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or reliance upon the contents of this e-mail is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that Sakura Finetek USA, Inc. can arrange for proper delivery, and then please delete the message from your inbox. Thank you.

 

 

From: Rudolf J Streif [mailto:rudolf.streif@...]
Sent: Wednesday, May 15, 2019 01:30 PM
To: Greg Wilson-Lindberg <GWilson@...>; Yocto list discussion <yocto@...>
Subject: Re: [yocto] problem adding a user

 

Instead of

 

useradd -p `openssl passwd test` sakura

 

which attempts to add the user and set the password which fails if the user already exists, use

 

usermod -p `openssl passwd test` sakura

 

which sets the user's password.

 

:rjs

 

On 5/15/19 1:18 PM, Greg Wilson-Lindberg wrote:

Ok, I had been using the useradd class in a couple of other recipes to allow me to copy files to the sakura user directory and another location, but owned by sakura. That seems to have been what was causing the problem.

 

I had been using the extrausers class in my top level image recipe.


So now how do I get all of this to work together? Do I need to put everything that touches the sakura user in the same recipe? It seems that I need to use only one of the useradd or extrausers classes?

 

Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 12:31 PM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user

 

The ! for the password in /etc/shadow indicates that the account is disabled:

sakura:!:18031:0:99999:7:::

 

Either there is something wrong with the password generation or it gets disabled by something else. Maybe it's worth trying with a plain image without Boot2Qt or anything else.

 

:rjs

 

 

On 5/15/19 11:46 AM, Greg Wilson-Lindberg wrote:

Hi Rudolf,

1st, yes I inherit extrausers. Attached are the passwd & shadow files.

 

It shouldn't make any difference, but I'm building this for an RPi3 using the Qt Boot2Qt version of the Yocto environment, distro 2.5.3.

 

Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 11:26 AM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user

 

Hi Greg,

 

> I've also tried both the back-quote and the single-quote, no difference.

 

Help me to understand this. the back-quotes are the right ones. If you use the single ones your password in the /etc/shadow ends up being 'openssl passwd test' (without the quotes), unless the build fails because of a parsing error (I have not tried it). Silly question, you did inherit extrausers class?

 

Can you post your /etc/passwd and /etc/shadow

 

I am surprised that this does not work with your setup. I have been doing this a gazillion times always with success.

 

:rjs

 

 

 

On 5/15/19 11:03 AM, Greg Wilson-Lindberg wrote:

Hi Rudolf,

Thanks for the reply, and the information on how openssl works.

 

I'm trying to create a user with the same group name so the code that I'm using reduces to:

EXTRA_USERS_PARAMS = "\
    useradd -p `openssl passwd test` sakura; \
    usermod -a -G sudo ${SAKURA_USER}; \
    "

I also, as you can see, removed the macros to eliminate as much confusion as possible.

 

I still can't login in using the password 'test'.

 

I've also tried both the back-quote and the single-quote, no difference.

Regards,

 

Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 10:07:47 AM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user

 

Hi Greg,

Well, I suppose I wrote the book you are referring to...


Using

useradd -p PASSWORD USER

takes the password hash for PASSWORD hence the use of openssl in:

useadd -p `openssl passwd PASSWORD` USER

openssl password creates the password hash using the original crypt hash
algorithm if no other options are specified. e.g.

$ openssl passwd hello
6hEsTksgRkeiI

With this the first two characters of the output is the salt and the
rest is the password hash. If you want openssl to create the same result
again:

$ openssl passwd -salt "6h" hello
6hEsTksgRkeiI

You can use newer algorithms like MD5 based BSD password algorithm 1:

$ openssl passwd -1 hello
$1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1

$1 : password algorithm 1
$4Mu8Fcs. : salt
$eIKgPP7RCYrb3lFZjhADA1 : password hash


If you log into the system you have to use the clear password. The
system reads the salt, creates the password hash and compares the results.


:rjs


On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote:
> I'm trying to use the example in "Embedded Linux Systems with the Yocto Project" to add a user to my Yocto build. In the book the sample code:
>
>     useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \
>
> uses openssl to generate the encrypted password string to pass to useradd. I have never been able to get this to work. When I run the openssl
> command on the cmd line I get a different value every time, this seems wrong, How can the password code compare against it if every encode
> produces a different value?
>
> I am getting the user added to the system, the home directory shows up and the user is in the passwd and group files. I just can't login to the
> account.
>
> I've obviously got something confused, any help would be appreciated.
>
> Greg Wilson-Lindberg
>  

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700
-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700
-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


[meta-raspberrypi] Screen(s) remain black on Raspberry Pi 3 B+

Bernhard Mayritsch <bit.coyote@...>
 

Hi!

I'm facing some trouble with the X-Server on the Raspberry Pi 3 B+. No matter if I use a screen on the HDMI port or running the 7" touch screen, they remain black. After testing with sumo - where at least a splash screen was shown - I moved on to thud, as recommended by Andrei Gherzan to sort out the error "No screen found." The error is gone, but nothing is shown on the screen, not even a splash screen. Switching the branches of poky, meta-openembedded and meta-raspberrypi to latest master still shows the same issue.

In order to make sure not to waste time on some hardware issue, I gave Raspbian a try; both screens (Raspberry Pi Touchscreen & HDMI) work fine there.

The entire build is pretty much default. The MACHINE is set to "raspberrypi3-64" and I added:
ENABLE_UART = "1" 
RPI_USE_U_BOOT = "1"
... to get the debug interface working and to use U-Boot which at least shows some lines on the screen during the early boot steps. There are no custom recipes or meta layers yet.
I have built core-image-x11 and core-image-sato, which both show the same behaviour. 

Xorg.0.log shows the following:

[    14.767] (II) LoadModule: "fbdev"
[    14.777] (WW) Warning, couldn't open module fbdev
[    14.777] (EE) Failed to load module "fbdev" (module does not exist, 0)

[    15.393] (II) modeset(0): EDID for output HDMI-1
[    15.393] (II) modeset(0): EDID for output Composite-1
[    15.393] (II) modeset(0): Printing probed modes for output Composite-1
[    15.393] (II) modeset(0): Modeline "720x480"x31.3   13.50  720 734 798 858  480 483 486 502 interlace (15.7 kHz e)
[    15.393] (II) modeset(0): Output HDMI-1 disconnected
[    15.393] (II) modeset(0): Output Composite-1 disconnected
[    15.393] (WW) modeset(0): No outputs definitely connected, trying again...
[    15.393] (II) modeset(0): Output HDMI-1 disconnected
[    15.393] (II) modeset(0): Output Composite-1 connected
[    15.393] (II) modeset(0): Using sloppy heuristic for initial modes
[    15.393] (II) modeset(0): Output Composite-1 using initial mode 720x480 +0+0
[    15.393] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0)
[    15.393] (==) modeset(0): DPI set to (96, 96)

It complains to be unable to load the frame buffer driver (is it used on VC4?) and correctly detects the 7" screen with its 720x480.

The X-Server seems to be up anyways:
root@raspberrypi3-64:/var/log# ps|grep -i xorg
  318 root      3700 S    xinit /etc/X11/Xsession -- /usr/bin/Xorg :0 -br -pn
  324 root      113m S<   /usr/bin/Xorg :0 -br -pn

As it's the first time I use Yocto to build a X11 image (only worked on headless systems until now) I think to miss something here. 

Does anyone have a hint  on that? 
Any help is greatly appreciated!

Thanks in advance,
Mac


Re: Building Out-of-Tree Modules on the BBB Target

Bruce Ashfield
 



On Wed, May 15, 2019 at 4:09 PM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:
> The core-image-kernel-dev image is how I do all my on target
> testing when I introduce a new reference kernel for a release.

Maybe you are correct. Maybe I should use/add in my local.conf the following:

KERNEL_DEV_TOOLS ?= "packagegroup-core-tools-profile
packagegroup-core-buildessential kernel-devsrc"
KERNEL_DEV_MODULE ?= "kernel-modules"
CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
                             ${KERNEL_DEV_TOOLS} \
                             systemtap \
                            "
I need to try these... Maybe this addendum will solve the $1 mio USD problem?!

> And IIRC the autobuilders are using a sato based image (Richard
> could confirm more easily that I could what image type the
> autobuilders are using for hello-world on target module tests).

I am just advertising something more simple. To have mandatory
/lib/modules/`uname -r` directory. And introduce few more packages, as
Fedora distro, for example, has: kernel-headers (assuming YOCTO
rootfs, the following will be installed: /usr/src/kernel/`uname
-r`/<header file directory structures>. This also makes addition of
/lib/modules/`uname -r`/build file (which is soft link to
usr/src/kernel/`uname -r`). 

These have all been discussed off an on over the past 5 years. I can't get at bugzilla right now, but all the details are logged in cases. A survey of all the distros, their kernel package, etc, were all looked at. We had to balance the traditional packaging with some new concepts and landed with what we have now.  

 
Or kernel-devel package. Then, the whole current kernel source code
will be introduced, and also support for it.

There's a case for this one as well, I'll probably have it done for the fall release. But our devsrc used to pretty much be the full source it has now been pruned down to something more manageable.  There are definitely some cases for having the full source on the target again, and it will be a separate package, just not the minimal one to build out of tree modules, etc.


 

SDK building with such a support is good/cool. But sometimes, before
introducing SDK, some tests should be done on target. NO need to
optionally include built-in layer hello-world driver example. Since I
(or you name the person) have own test drivers, which will be imported
out of tree, externally, to the target test bed!


I never use the SDK myself, so you are not alone in not going to it first. Hopefully I'll get some new patches out in the coming month before summer holidays really kick in.

Bruce

 
Just thinking loud...

Zoran
_______

On Wed, May 15, 2019 at 4:25 PM Bruce Ashfield <bruce.ashfield@...> wrote:
>
>
>
> On Wed, May 15, 2019 at 3:44 AM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:
>>
>> > That's correct. That command only adds the kernel source and
>> > build infrastructure to the SDK, not to your target image. You'd still
>> > need to arrange to have the kernel-devsrc package installed on the
>> > target image if you want it on the board's rootfs. How you arrange
>> > to have the package installed to the image varies with the image
>> > (since they all don't have the same image install variables, etc).
>>
>> And here is a $1,000,000 USD question? How to do it on Poky (as
>> example of what you have stated in RED)? ;-)
>>
>> In other words: how to arrange it on Poky (as a Referent example)?
>
>
> The core-image-kernel-dev image is how I do all my on target testing when I introduce a new reference kernel for a release. And IIRC the autobuilders are using a sato based image (Richard could confirm more easily that I could what image type the autobuilders are using for hello-world on target module tests).
>
> Bruce
>
>
>>
>>
>> Thank you,
>> Zoran
>> _______
>>
>>
>> On Wed, May 15, 2019 at 7:41 AM Bruce Ashfield <bruce.ashfield@...> wrote:
>>>
>>>
>>>
>>> On Tue, May 14, 2019 at 1:30 PM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:
>>>>
>>>> Hello Chris, Bruce,
>>>>
>>>> I have some additional data to share with you both, since I have tried
>>>> something. And here is my take on the things!
>>>>
>>>> > 1. Build using a bb recipe.
>>>> > Take a look at meta-skeleton/recipes-kernel/hello-mod for an example.
>>>> > You just need to add meta-skeleton to your bblayers.conf and then
>>>> >  bitbake hello-mod
>>>>
>>>> I looked into this example, and, yes, it is classic kernel module
>>>> definition out of the tree. With some outdated data, all cool, the
>>>> YOCTO designer should take care himself to fix these data, if using
>>>> this stuff.
>>>>
>>>> But this is NOT mandatory, since I can add out of the tree module NOT
>>>> actually using built-in module. I just use .../tmp/deploy/images/bbb/*
>>>> generated stuff, since I have automated scripts which are bringing all
>>>> these on my BBB target. Then I tftp my source code module to the
>>>> target.
>>>>
>>>> > 2. Build from the SDK:
>>>> > First, add the kernel source to the SDK by adding this to conf/local.conf
>>>> >  TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc"
>>>>
>>>> YES, this is THE command which should generate
>>>> /usr/src/kernel(s)/`uname -r` or similar... But adding it to
>>>> local.conf and after deleting kernel, then regenerating bitbake -k
>>>> core-image-minimal does not bring this path into the rootfs image!?
>>>
>>>
>>> That's correct. That command only adds the kernel source and build infrastructure to the SDK, not to your target image. You'd still need to arrange to have the kernel-devsrc package installed on the target image if you want it on the board's rootfs. How you arrange to have the package installed to the image varies with the image (since they all don't have the same image install variables, etc).
>>>
>>>
>>>>
>>>>
>>>> I did it actually using meta-bbb, and using poky referent distro as
>>>> two additional layers to the more complex bbb image!
>>>> https://github.com/jumpnow/meta-bbb.git
>>>>
>>>> The (KAS - you can figure out out of it local.conf) script I am using
>>>> to build such a BBB image is here:
>>>> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-warrior/kas-bbb-warrior.yml
>>>>
>>>> I did not try it with BBB reference poky only! Maybe I should try it
>>>> as only referent poky? What do you think?
>>>>
>>>> Does in this case is SDK build really mandatory??? Should NOT be!
>>>>
>>>
>>> You only do the SDK steps if you want to support building out of tree modules in an SDK install. So it is not mandatory for on target module builds.
>>>
>>> Bruce
>>>
>>>
>>>>
>>>> > Once the SDK is installed, generate the kernel headers:
>>>> >  sudo -i
>>>> >  . /opt/poky/2.6.2/environment-setup-cortexa8hf-neon-poky-linux-gnueabi
>>>> >  cd /opt/poky/2.6.2/sysroots/cortexa8hf-neon-poky-linux-gnueabi
>>>> >  cd /usr/src/kernel
>>>> >  make oldconfig scripts
>>>> >  exit
>>>>
>>>> This is in nutshell the same what I did (a bit different) for Embedded
>>>> Debian. This is already on the target BBB, NOT while building YOCTO
>>>> BBB image!
>>>>
>>>> > Finally, build your module using a Makefile like this
>>>> >  obj-m := hello-mod.o
>>>> >  all:
>>>> >        make -C $(SDKTARGETSYSROOT)/usr/src/kernel M=$(shell pwd)
>>>>
>>>> As said before: bringing my own module into the target BBB (I have my
>>>> own examples, and I build them on the target with the almost the same
>>>> Makefiles)
>>>>
>>>> Zoran
>>>> _______
>>>>
>>>> On Sun, May 12, 2019 at 3:15 PM Chris Simmonds <chris@...> wrote:
>>>> >
>>>> > Hi Zoran,
>>>> >
>>>> > There are two ways to do this
>>>> >
>>>> > 1. Build using a bb recipe.
>>>> > Take a look at meta-skeleton/recipes-kernel/hello-mod for an example.
>>>> > You just need to add meta-skeleton to your bblaysers.conf and then
>>>> >   bitbake hello-mod
>>>> >
>>>> >
>>>> > 2. Build from the SDK:
>>>> > First, add the kernel source to the SDK by adding this to conf/local/conf
>>>> >   TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc"
>>>> >
>>>> > Then build the SDK
>>>> >   bitbake -c populate_sdk [your image recipe]
>>>> >
>>>> > Once the SDK is installed, generate the kernel headers:
>>>> >   sudo -i
>>>> >   . /opt/poky/2.6.2/environment-setup-cortexa8hf-neon-poky-linux-gnueabi
>>>> >   cd /opt/poky/2.6.2/sysroots/cortexa8hf-neon-poky-linux-gnueabi
>>>> >   cd /usr/src/kernel
>>>> >   make oldconfig scripts
>>>> >   exit
>>>> >
>>>> > Finally, build your module using a Makefile like this
>>>> >
>>>> >   obj-m := hello-mod.o
>>>> >   all:
>>>> >         make -C $(SDKTARGETSYSROOT)/usr/src/kernel M=$(shell pwd)
>>>> >
>>>> >
>>>> > HTH,
>>>> > Chris
>>>> >
>>>> > On 12/05/2019 11:53, Zoran Stojsavljevic wrote:
>>>> > > Hello to the YOCTO community,
>>>> > >
>>>> > > I am using (to build the target for Beagle Bone Black) the following script:
>>>> > > https://github.com/ZoranStojsavljevic/bbb-yocto
>>>> > > https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-yocto.sh
>>>> > >
>>>> > > The latest kernel I am using from the following repo:
>>>> > > https://github.com/jumpnow/meta-bbb
>>>> > >
>>>> > > Is kernel 5.0.14 .
>>>> > >
>>>> > > Here is the snippet of the boot traces:
>>>> > > Starting kernel ...
>>>> > >
>>>> > > [    0.000000] Booting Linux on physical CPU 0x0
>>>> > > [    0.000000] Linux version 5.0.14-jumpnow (oe-user@oe-host) (gcc
>>>> > > version 8.3.0 (GCC)) #1 Fri May 10 13:12:33 UTC 2019
>>>> > > [    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
>>>> > > [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>>>> > > instruction cache
>>>> > > [    0.000000] OF: fdt: Machine model: TI AM335x BeagleBone Black
>>>> > > [    0.000000] Memory policy: Data cache writeback
>>>> > > [    0.000000] cma: Reserved 16 MiB at 0x9f000000
>>>> > > [    0.000000] CPU: All CPU(s) started in SVC mode.
>>>> > > [    0.000000] AM335X ES2.1 (sgx neon)
>>>> > > [    0.000000] random: get_random_bytes called from
>>>> > > start_kernel+0xa4/0x460 with crng_init=0
>>>> > > [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 130048
>>>> > > [    0.000000] Kernel command line: console=ttyO0,115200n8
>>>> > > root=/dev/ram0 ip=dhcp
>>>> > >
>>>> > > According to the documentation, the following:
>>>> > > 2.10.1. Building Out-of-Tree Modules on the Target
>>>> > > https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html
>>>> > >
>>>> > > I tried to find /usr/src/kernels/5.0.14... Directory, since I see
>>>> > > from the build that kernel-dev and kernel-devsrc are included:
>>>> > > [user@fedora29-ssd bbb-yocto]$ bitbake -s | grep kernel
>>>> > > core-image-kernel-dev                                 :1.0-r0
>>>> > > kernel-devsrc                                         :1.0-r0
>>>> > > kernel-selftest                                       :1.0-r0
>>>> > >
>>>> > > THE PROBLEM: But I could not find ob BBB target /usr/src/kernels
>>>> > > directory at all!?
>>>> > >
>>>> > > Two questions here?
>>>> > > [1] Do you have any advice on this problem (what I am missing here)?
>>>> > > [2] Alternative to [1]: how I can use cross compiler from
>>>> > > .../build/tmp to build Out-of-Tree Module for the BBB target on the
>>>> > > host?
>>>> > >
>>>> > > Thank you,
>>>> > > Zoran
>>>> > > _______
>>>> > >
>>>> >
>>>> >
>>>> > --
>>>> > Chris Simmonds, trainer and consultant at 2net
>>>> > http://www.2net.co.uk
>>>> > Author of "Mastering Embedded Linux Programming"
>>>
>>>
>>>
>>> --
>>> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
>>> - "Use the force Harry" - Gandalf, Star Trek II
>>>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: problem adding a user

Greg Wilson-Lindberg
 

Thank you very much, that got me back on the right path.

Maybe I'll see you at the Yocto day at the Embedded Linux Conference.

Regards,

Greg Wilson-Lindberg 

Principal Firmware Engineer | Sakura Finetek USA, Inc. 

 

1750 W 214th Street | Torrance, CA 90501 | U.S.A. 

T: +1 310 783 5075 

F: +1 310 618 6902 | E: gwilson@sakuraus.com     

www.sakuraus.com           

 


Confidentiality Notice: This e-mail transmission may contain confidential or legally privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or reliance upon the contents of this e-mail is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that Sakura Finetek USA, Inc. can arrange for proper delivery, and then please delete the message from your inbox. Thank you.

 

 

From: Rudolf J Streif [mailto:rudolf.streif@...]
Sent: Wednesday, May 15, 2019 01:30 PM
To: Greg Wilson-Lindberg <GWilson@...>; Yocto list discussion <yocto@...>
Subject: Re: [yocto] problem adding a user

 

Instead of

 

useradd -p `openssl passwd test` sakura

 

which attempts to add the user and set the password which fails if the user already exists, use

 

usermod -p `openssl passwd test` sakura

 

which sets the user's password.

 

:rjs

 

On 5/15/19 1:18 PM, Greg Wilson-Lindberg wrote:

Ok, I had been using the useradd class in a couple of other recipes to allow me to copy files to the sakura user directory and another location, but owned by sakura. That seems to have been what was causing the problem.

 

I had been using the extrausers class in my top level image recipe.


So now how do I get all of this to work together? Do I need to put everything that touches the sakura user in the same recipe? It seems that I need to use only one of the useradd or extrausers classes?

 

Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 12:31 PM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user

 

The ! for the password in /etc/shadow indicates that the account is disabled:

sakura:!:18031:0:99999:7:::

 

Either there is something wrong with the password generation or it gets disabled by something else. Maybe it's worth trying with a plain image without Boot2Qt or anything else.

 

:rjs

 

 

On 5/15/19 11:46 AM, Greg Wilson-Lindberg wrote:

Hi Rudolf,

1st, yes I inherit extrausers. Attached are the passwd & shadow files.

 

It shouldn't make any difference, but I'm building this for an RPi3 using the Qt Boot2Qt version of the Yocto environment, distro 2.5.3.

 

Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 11:26 AM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user

 

Hi Greg,

 

> I've also tried both the back-quote and the single-quote, no difference.

 

Help me to understand this. the back-quotes are the right ones. If you use the single ones your password in the /etc/shadow ends up being 'openssl passwd test' (without the quotes), unless the build fails because of a parsing error (I have not tried it). Silly question, you did inherit extrausers class?

 

Can you post your /etc/passwd and /etc/shadow

 

I am surprised that this does not work with your setup. I have been doing this a gazillion times always with success.

 

:rjs

 

 

 

On 5/15/19 11:03 AM, Greg Wilson-Lindberg wrote:

Hi Rudolf,

Thanks for the reply, and the information on how openssl works.

 

I'm trying to create a user with the same group name so the code that I'm using reduces to:

EXTRA_USERS_PARAMS = "\
    useradd -p `openssl passwd test` sakura; \
    usermod -a -G sudo ${SAKURA_USER}; \
    "

I also, as you can see, removed the macros to eliminate as much confusion as possible.

 

I still can't login in using the password 'test'.

 

I've also tried both the back-quote and the single-quote, no difference.

Regards,

 

Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 10:07:47 AM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user

 

Hi Greg,

Well, I suppose I wrote the book you are referring to...


Using

useradd -p PASSWORD USER

takes the password hash for PASSWORD hence the use of openssl in:

useadd -p `openssl passwd PASSWORD` USER

openssl password creates the password hash using the original crypt hash
algorithm if no other options are specified. e.g.

$ openssl passwd hello
6hEsTksgRkeiI

With this the first two characters of the output is the salt and the
rest is the password hash. If you want openssl to create the same result
again:

$ openssl passwd -salt "6h" hello
6hEsTksgRkeiI

You can use newer algorithms like MD5 based BSD password algorithm 1:

$ openssl passwd -1 hello
$1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1

$1 : password algorithm 1
$4Mu8Fcs. : salt
$eIKgPP7RCYrb3lFZjhADA1 : password hash


If you log into the system you have to use the clear password. The
system reads the salt, creates the password hash and compares the results.


:rjs


On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote:
> I'm trying to use the example in "Embedded Linux Systems with the Yocto Project" to add a user to my Yocto build. In the book the sample code:
>
>     useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \
>
> uses openssl to generate the encrypted password string to pass to useradd. I have never been able to get this to work. When I run the openssl
> command on the cmd line I get a different value every time, this seems wrong, How can the password code compare against it if every encode
> produces a different value?
>
> I am getting the user added to the system, the home directory shows up and the user is in the passwd and group files. I just can't login to the
> account.
>
> I've obviously got something confused, any help would be appreciated.
>
> Greg Wilson-Lindberg
>  

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700
-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700
-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


Re: problem adding a user

Rudolf J Streif
 

Instead of


useradd -p `openssl passwd test` sakura


which attempts to add the user and set the password which fails if the user already exists, use


usermod -p `openssl passwd test` sakura


which sets the user's password.


:rjs


On 5/15/19 1:18 PM, Greg Wilson-Lindberg wrote:

Ok, I had been using the useradd class in a couple of other recipes to allow me to copy files to the sakura user directory and another location, but owned by sakura. That seems to have been what was causing the problem.


I had been using the extrausers class in my top level image recipe.


So now how do I get all of this to work together? Do I need to put everything that touches the sakura user in the same recipe? It seems that I need to use only one of the useradd or extrausers classes?


Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 12:31 PM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user
 

The ! for the password in /etc/shadow indicates that the account is disabled:

sakura:!:18031:0:99999:7:::


Either there is something wrong with the password generation or it gets disabled by something else. Maybe it's worth trying with a plain image without Boot2Qt or anything else.


:rjs



On 5/15/19 11:46 AM, Greg Wilson-Lindberg wrote:

Hi Rudolf,

1st, yes I inherit extrausers. Attached are the passwd & shadow files.


It shouldn't make any difference, but I'm building this for an RPi3 using the Qt Boot2Qt version of the Yocto environment, distro 2.5.3.


Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 11:26 AM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user
 

Hi Greg,


> I've also tried both the back-quote and the single-quote, no difference.


Help me to understand this. the back-quotes are the right ones. If you use the single ones your password in the /etc/shadow ends up being 'openssl passwd test' (without the quotes), unless the build fails because of a parsing error (I have not tried it). Silly question, you did inherit extrausers class?


Can you post your /etc/passwd and /etc/shadow


I am surprised that this does not work with your setup. I have been doing this a gazillion times always with success.


:rjs




On 5/15/19 11:03 AM, Greg Wilson-Lindberg wrote:

Hi Rudolf,

Thanks for the reply, and the information on how openssl works.


I'm trying to create a user with the same group name so the code that I'm using reduces to:

EXTRA_USERS_PARAMS = "\
    useradd -p `openssl passwd test` sakura; \
    usermod -a -G sudo ${SAKURA_USER}; \
    "
I also, as you can see, removed the macros to eliminate as much confusion as possible.


I still can't login in using the password 'test'.


I've also tried both the back-quote and the single-quote, no difference.

Regards,


Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 10:07:47 AM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user
 
Hi Greg,

Well, I suppose I wrote the book you are referring to...


Using

useradd -p PASSWORD USER

takes the password hash for PASSWORD hence the use of openssl in:

useadd -p `openssl passwd PASSWORD` USER

openssl password creates the password hash using the original crypt hash
algorithm if no other options are specified. e.g.

$ openssl passwd hello
6hEsTksgRkeiI

With this the first two characters of the output is the salt and the
rest is the password hash. If you want openssl to create the same result
again:

$ openssl passwd -salt "6h" hello
6hEsTksgRkeiI

You can use newer algorithms like MD5 based BSD password algorithm 1:

$ openssl passwd -1 hello
$1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1

$1 : password algorithm 1
$4Mu8Fcs. : salt
$eIKgPP7RCYrb3lFZjhADA1 : password hash


If you log into the system you have to use the clear password. The
system reads the salt, creates the password hash and compares the results.


:rjs


On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote:
> I'm trying to use the example in "Embedded Linux Systems with the Yocto Project" to add a user to my Yocto build. In the book the sample code:
>
>     useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \
>
> uses openssl to generate the encrypted password string to pass to useradd. I have never been able to get this to work. When I run the openssl
> command on the cmd line I get a different value every time, this seems wrong, How can the password code compare against it if every encode
> produces a different value?
>
> I am getting the user added to the system, the home directory shows up and the user is in the passwd and group files. I just can't login to the
> account.
>
> I've obviously got something confused, any help would be appreciated.
>
> Greg Wilson-Lindberg
>  

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700
-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700
-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


Re: problem adding a user

Greg Wilson-Lindberg
 

Ok, I had been using the useradd class in a couple of other recipes to allow me to copy files to the sakura user directory and another location, but owned by sakura. That seems to have been what was causing the problem.


I had been using the extrausers class in my top level image recipe.


So now how do I get all of this to work together? Do I need to put everything that touches the sakura user in the same recipe? It seems that I need to use only one of the useradd or extrausers classes?


Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 12:31 PM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user
 

The ! for the password in /etc/shadow indicates that the account is disabled:

sakura:!:18031:0:99999:7:::


Either there is something wrong with the password generation or it gets disabled by something else. Maybe it's worth trying with a plain image without Boot2Qt or anything else.


:rjs



On 5/15/19 11:46 AM, Greg Wilson-Lindberg wrote:

Hi Rudolf,

1st, yes I inherit extrausers. Attached are the passwd & shadow files.


It shouldn't make any difference, but I'm building this for an RPi3 using the Qt Boot2Qt version of the Yocto environment, distro 2.5.3.


Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 11:26 AM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user
 

Hi Greg,


> I've also tried both the back-quote and the single-quote, no difference.


Help me to understand this. the back-quotes are the right ones. If you use the single ones your password in the /etc/shadow ends up being 'openssl passwd test' (without the quotes), unless the build fails because of a parsing error (I have not tried it). Silly question, you did inherit extrausers class?


Can you post your /etc/passwd and /etc/shadow


I am surprised that this does not work with your setup. I have been doing this a gazillion times always with success.


:rjs




On 5/15/19 11:03 AM, Greg Wilson-Lindberg wrote:

Hi Rudolf,

Thanks for the reply, and the information on how openssl works.


I'm trying to create a user with the same group name so the code that I'm using reduces to:

EXTRA_USERS_PARAMS = "\
    useradd -p `openssl passwd test` sakura; \
    usermod -a -G sudo ${SAKURA_USER}; \
    "
I also, as you can see, removed the macros to eliminate as much confusion as possible.


I still can't login in using the password 'test'.


I've also tried both the back-quote and the single-quote, no difference.

Regards,


Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 10:07:47 AM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user
 
Hi Greg,

Well, I suppose I wrote the book you are referring to...


Using

useradd -p PASSWORD USER

takes the password hash for PASSWORD hence the use of openssl in:

useadd -p `openssl passwd PASSWORD` USER

openssl password creates the password hash using the original crypt hash
algorithm if no other options are specified. e.g.

$ openssl passwd hello
6hEsTksgRkeiI

With this the first two characters of the output is the salt and the
rest is the password hash. If you want openssl to create the same result
again:

$ openssl passwd -salt "6h" hello
6hEsTksgRkeiI

You can use newer algorithms like MD5 based BSD password algorithm 1:

$ openssl passwd -1 hello
$1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1

$1 : password algorithm 1
$4Mu8Fcs. : salt
$eIKgPP7RCYrb3lFZjhADA1 : password hash


If you log into the system you have to use the clear password. The
system reads the salt, creates the password hash and compares the results.


:rjs


On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote:
> I'm trying to use the example in "Embedded Linux Systems with the Yocto Project" to add a user to my Yocto build. In the book the sample code:
>
>     useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \
>
> uses openssl to generate the encrypted password string to pass to useradd. I have never been able to get this to work. When I run the openssl
> command on the cmd line I get a different value every time, this seems wrong, How can the password code compare against it if every encode
> produces a different value?
>
> I am getting the user added to the system, the home directory shows up and the user is in the passwd and group files. I just can't login to the
> account.
>
> I've obviously got something confused, any help would be appreciated.
>
> Greg Wilson-Lindberg
>  

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700
-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


Re: Building Out-of-Tree Modules on the BBB Target

Zoran
 

The core-image-kernel-dev image is how I do all my on target
testing when I introduce a new reference kernel for a release.
Maybe you are correct. Maybe I should use/add in my local.conf the following:

KERNEL_DEV_TOOLS ?= "packagegroup-core-tools-profile
packagegroup-core-buildessential kernel-devsrc"
KERNEL_DEV_MODULE ?= "kernel-modules"
CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
${KERNEL_DEV_TOOLS} \
systemtap \
"
I need to try these... Maybe this addendum will solve the $1 mio USD problem?!

And IIRC the autobuilders are using a sato based image (Richard
could confirm more easily that I could what image type the
autobuilders are using for hello-world on target module tests).
I am just advertising something more simple. To have mandatory
/lib/modules/`uname -r` directory. And introduce few more packages, as
Fedora distro, for example, has: kernel-headers (assuming YOCTO
rootfs, the following will be installed: /usr/src/kernel/`uname
-r`/<header file directory structures>. This also makes addition of
/lib/modules/`uname -r`/build file (which is soft link to
usr/src/kernel/`uname -r`).

Or kernel-devel package. Then, the whole current kernel source code
will be introduced, and also support for it.

SDK building with such a support is good/cool. But sometimes, before
introducing SDK, some tests should be done on target. NO need to
optionally include built-in layer hello-world driver example. Since I
(or you name the person) have own test drivers, which will be imported
out of tree, externally, to the target test bed!

Just thinking loud...

Zoran
_______

On Wed, May 15, 2019 at 4:25 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:



On Wed, May 15, 2019 at 3:44 AM Zoran Stojsavljevic <zoran.stojsavljevic@gmail.com> wrote:

That's correct. That command only adds the kernel source and
build infrastructure to the SDK, not to your target image. You'd still
need to arrange to have the kernel-devsrc package installed on the
target image if you want it on the board's rootfs. How you arrange
to have the package installed to the image varies with the image
(since they all don't have the same image install variables, etc).
And here is a $1,000,000 USD question? How to do it on Poky (as
example of what you have stated in RED)? ;-)

In other words: how to arrange it on Poky (as a Referent example)?

The core-image-kernel-dev image is how I do all my on target testing when I introduce a new reference kernel for a release. And IIRC the autobuilders are using a sato based image (Richard could confirm more easily that I could what image type the autobuilders are using for hello-world on target module tests).

Bruce




Thank you,
Zoran
_______


On Wed, May 15, 2019 at 7:41 AM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:



On Tue, May 14, 2019 at 1:30 PM Zoran Stojsavljevic <zoran.stojsavljevic@gmail.com> wrote:

Hello Chris, Bruce,

I have some additional data to share with you both, since I have tried
something. And here is my take on the things!

1. Build using a bb recipe.
Take a look at meta-skeleton/recipes-kernel/hello-mod for an example.
You just need to add meta-skeleton to your bblayers.conf and then
bitbake hello-mod
I looked into this example, and, yes, it is classic kernel module
definition out of the tree. With some outdated data, all cool, the
YOCTO designer should take care himself to fix these data, if using
this stuff.

But this is NOT mandatory, since I can add out of the tree module NOT
actually using built-in module. I just use .../tmp/deploy/images/bbb/*
generated stuff, since I have automated scripts which are bringing all
these on my BBB target. Then I tftp my source code module to the
target.

2. Build from the SDK:
First, add the kernel source to the SDK by adding this to conf/local.conf
TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc"
YES, this is THE command which should generate
/usr/src/kernel(s)/`uname -r` or similar... But adding it to
local.conf and after deleting kernel, then regenerating bitbake -k
core-image-minimal does not bring this path into the rootfs image!?

That's correct. That command only adds the kernel source and build infrastructure to the SDK, not to your target image. You'd still need to arrange to have the kernel-devsrc package installed on the target image if you want it on the board's rootfs. How you arrange to have the package installed to the image varies with the image (since they all don't have the same image install variables, etc).




I did it actually using meta-bbb, and using poky referent distro as
two additional layers to the more complex bbb image!
https://github.com/jumpnow/meta-bbb.git

The (KAS - you can figure out out of it local.conf) script I am using
to build such a BBB image is here:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-warrior/kas-bbb-warrior.yml

I did not try it with BBB reference poky only! Maybe I should try it
as only referent poky? What do you think?

Does in this case is SDK build really mandatory??? Should NOT be!
You only do the SDK steps if you want to support building out of tree modules in an SDK install. So it is not mandatory for on target module builds.

Bruce



Once the SDK is installed, generate the kernel headers:
sudo -i
. /opt/poky/2.6.2/environment-setup-cortexa8hf-neon-poky-linux-gnueabi
cd /opt/poky/2.6.2/sysroots/cortexa8hf-neon-poky-linux-gnueabi
cd /usr/src/kernel
make oldconfig scripts
exit
This is in nutshell the same what I did (a bit different) for Embedded
Debian. This is already on the target BBB, NOT while building YOCTO
BBB image!

Finally, build your module using a Makefile like this
obj-m := hello-mod.o
all:
make -C $(SDKTARGETSYSROOT)/usr/src/kernel M=$(shell pwd)
As said before: bringing my own module into the target BBB (I have my
own examples, and I build them on the target with the almost the same
Makefiles)

Zoran
_______

On Sun, May 12, 2019 at 3:15 PM Chris Simmonds <chris@2net.co.uk> wrote:

Hi Zoran,

There are two ways to do this

1. Build using a bb recipe.
Take a look at meta-skeleton/recipes-kernel/hello-mod for an example.
You just need to add meta-skeleton to your bblaysers.conf and then
bitbake hello-mod


2. Build from the SDK:
First, add the kernel source to the SDK by adding this to conf/local/conf
TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc"

Then build the SDK
bitbake -c populate_sdk [your image recipe]

Once the SDK is installed, generate the kernel headers:
sudo -i
. /opt/poky/2.6.2/environment-setup-cortexa8hf-neon-poky-linux-gnueabi
cd /opt/poky/2.6.2/sysroots/cortexa8hf-neon-poky-linux-gnueabi
cd /usr/src/kernel
make oldconfig scripts
exit

Finally, build your module using a Makefile like this

obj-m := hello-mod.o
all:
make -C $(SDKTARGETSYSROOT)/usr/src/kernel M=$(shell pwd)


HTH,
Chris

On 12/05/2019 11:53, Zoran Stojsavljevic wrote:
Hello to the YOCTO community,

I am using (to build the target for Beagle Bone Black) the following script:
https://github.com/ZoranStojsavljevic/bbb-yocto
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-yocto.sh

The latest kernel I am using from the following repo:
https://github.com/jumpnow/meta-bbb

Is kernel 5.0.14 .

Here is the snippet of the boot traces:
Starting kernel ...

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.0.14-jumpnow (oe-user@oe-host) (gcc
version 8.3.0 (GCC)) #1 Fri May 10 13:12:33 UTC 2019
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[ 0.000000] OF: fdt: Machine model: TI AM335x BeagleBone Black
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] cma: Reserved 16 MiB at 0x9f000000
[ 0.000000] CPU: All CPU(s) started in SVC mode.
[ 0.000000] AM335X ES2.1 (sgx neon)
[ 0.000000] random: get_random_bytes called from
start_kernel+0xa4/0x460 with crng_init=0
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 130048
[ 0.000000] Kernel command line: console=ttyO0,115200n8
root=/dev/ram0 ip=dhcp

According to the documentation, the following:
2.10.1. Building Out-of-Tree Modules on the Target
https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html

I tried to find /usr/src/kernels/5.0.14... Directory, since I see
from the build that kernel-dev and kernel-devsrc are included:
[user@fedora29-ssd bbb-yocto]$ bitbake -s | grep kernel
core-image-kernel-dev :1.0-r0
kernel-devsrc :1.0-r0
kernel-selftest :1.0-r0

THE PROBLEM: But I could not find ob BBB target /usr/src/kernels
directory at all!?

Two questions here?
[1] Do you have any advice on this problem (what I am missing here)?
[2] Alternative to [1]: how I can use cross compiler from
.../build/tmp to build Out-of-Tree Module for the BBB target on the
host?

Thank you,
Zoran
_______

--
Chris Simmonds, trainer and consultant at 2net
http://www.2net.co.uk
Author of "Mastering Embedded Linux Programming"


--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: problem adding a user

Rudolf J Streif
 

The ! for the password in /etc/shadow indicates that the account is disabled:

sakura:!:18031:0:99999:7:::


Either there is something wrong with the password generation or it gets disabled by something else. Maybe it's worth trying with a plain image without Boot2Qt or anything else.


:rjs



On 5/15/19 11:46 AM, Greg Wilson-Lindberg wrote:

Hi Rudolf,

1st, yes I inherit extrausers. Attached are the passwd & shadow files.


It shouldn't make any difference, but I'm building this for an RPi3 using the Qt Boot2Qt version of the Yocto environment, distro 2.5.3.


Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 11:26 AM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user
 

Hi Greg,


> I've also tried both the back-quote and the single-quote, no difference.


Help me to understand this. the back-quotes are the right ones. If you use the single ones your password in the /etc/shadow ends up being 'openssl passwd test' (without the quotes), unless the build fails because of a parsing error (I have not tried it). Silly question, you did inherit extrausers class?


Can you post your /etc/passwd and /etc/shadow


I am surprised that this does not work with your setup. I have been doing this a gazillion times always with success.


:rjs




On 5/15/19 11:03 AM, Greg Wilson-Lindberg wrote:

Hi Rudolf,

Thanks for the reply, and the information on how openssl works.


I'm trying to create a user with the same group name so the code that I'm using reduces to:

EXTRA_USERS_PARAMS = "\
    useradd -p `openssl passwd test` sakura; \
    usermod -a -G sudo ${SAKURA_USER}; \
    "
I also, as you can see, removed the macros to eliminate as much confusion as possible.


I still can't login in using the password 'test'.


I've also tried both the back-quote and the single-quote, no difference.

Regards,


Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 10:07:47 AM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user
 
Hi Greg,

Well, I suppose I wrote the book you are referring to...


Using

useradd -p PASSWORD USER

takes the password hash for PASSWORD hence the use of openssl in:

useadd -p `openssl passwd PASSWORD` USER

openssl password creates the password hash using the original crypt hash
algorithm if no other options are specified. e.g.

$ openssl passwd hello
6hEsTksgRkeiI

With this the first two characters of the output is the salt and the
rest is the password hash. If you want openssl to create the same result
again:

$ openssl passwd -salt "6h" hello
6hEsTksgRkeiI

You can use newer algorithms like MD5 based BSD password algorithm 1:

$ openssl passwd -1 hello
$1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1

$1 : password algorithm 1
$4Mu8Fcs. : salt
$eIKgPP7RCYrb3lFZjhADA1 : password hash


If you log into the system you have to use the clear password. The
system reads the salt, creates the password hash and compares the results.


:rjs


On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote:
> I'm trying to use the example in "Embedded Linux Systems with the Yocto Project" to add a user to my Yocto build. In the book the sample code:
>
>     useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \
>
> uses openssl to generate the encrypted password string to pass to useradd. I have never been able to get this to work. When I run the openssl
> command on the cmd line I get a different value every time, this seems wrong, How can the password code compare against it if every encode
> produces a different value?
>
> I am getting the user added to the system, the home directory shows up and the user is in the passwd and group files. I just can't login to the
> account.
>
> I've obviously got something confused, any help would be appreciated.
>
> Greg Wilson-Lindberg
>  

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700
-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


Re: problem adding a user

Greg Wilson-Lindberg
 

Hi Rudolf,

1st, yes I inherit extrausers. Attached are the passwd & shadow files.


It shouldn't make any difference, but I'm building this for an RPi3 using the Qt Boot2Qt version of the Yocto environment, distro 2.5.3.


Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 11:26 AM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user
 

Hi Greg,


> I've also tried both the back-quote and the single-quote, no difference.


Help me to understand this. the back-quotes are the right ones. If you use the single ones your password in the /etc/shadow ends up being 'openssl passwd test' (without the quotes), unless the build fails because of a parsing error (I have not tried it). Silly question, you did inherit extrausers class?


Can you post your /etc/passwd and /etc/shadow


I am surprised that this does not work with your setup. I have been doing this a gazillion times always with success.


:rjs




On 5/15/19 11:03 AM, Greg Wilson-Lindberg wrote:

Hi Rudolf,

Thanks for the reply, and the information on how openssl works.


I'm trying to create a user with the same group name so the code that I'm using reduces to:

EXTRA_USERS_PARAMS = "\
    useradd -p `openssl passwd test` sakura; \
    usermod -a -G sudo ${SAKURA_USER}; \
    "
I also, as you can see, removed the macros to eliminate as much confusion as possible.


I still can't login in using the password 'test'.


I've also tried both the back-quote and the single-quote, no difference.

Regards,


Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 10:07:47 AM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user
 
Hi Greg,

Well, I suppose I wrote the book you are referring to...


Using

useradd -p PASSWORD USER

takes the password hash for PASSWORD hence the use of openssl in:

useadd -p `openssl passwd PASSWORD` USER

openssl password creates the password hash using the original crypt hash
algorithm if no other options are specified. e.g.

$ openssl passwd hello
6hEsTksgRkeiI

With this the first two characters of the output is the salt and the
rest is the password hash. If you want openssl to create the same result
again:

$ openssl passwd -salt "6h" hello
6hEsTksgRkeiI

You can use newer algorithms like MD5 based BSD password algorithm 1:

$ openssl passwd -1 hello
$1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1

$1 : password algorithm 1
$4Mu8Fcs. : salt
$eIKgPP7RCYrb3lFZjhADA1 : password hash


If you log into the system you have to use the clear password. The
system reads the salt, creates the password hash and compares the results.


:rjs


On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote:
> I'm trying to use the example in "Embedded Linux Systems with the Yocto Project" to add a user to my Yocto build. In the book the sample code:
>
>     useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \
>
> uses openssl to generate the encrypted password string to pass to useradd. I have never been able to get this to work. When I run the openssl
> command on the cmd line I get a different value every time, this seems wrong, How can the password code compare against it if every encode
> produces a different value?
>
> I am getting the user added to the system, the home directory shows up and the user is in the passwd and group files. I just can't login to the
> account.
>
> I've obviously got something confused, any help would be appreciated.
>
> Greg Wilson-Lindberg
>  

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


Re: problem adding a user

Rudolf J Streif
 

Hi Greg,


> I've also tried both the back-quote and the single-quote, no difference.


Help me to understand this. the back-quotes are the right ones. If you use the single ones your password in the /etc/shadow ends up being 'openssl passwd test' (without the quotes), unless the build fails because of a parsing error (I have not tried it). Silly question, you did inherit extrausers class?


Can you post your /etc/passwd and /etc/shadow


I am surprised that this does not work with your setup. I have been doing this a gazillion times always with success.


:rjs




On 5/15/19 11:03 AM, Greg Wilson-Lindberg wrote:

Hi Rudolf,

Thanks for the reply, and the information on how openssl works.


I'm trying to create a user with the same group name so the code that I'm using reduces to:

EXTRA_USERS_PARAMS = "\
    useradd -p `openssl passwd test` sakura; \
    usermod -a -G sudo ${SAKURA_USER}; \
    "
I also, as you can see, removed the macros to eliminate as much confusion as possible.


I still can't login in using the password 'test'.


I've also tried both the back-quote and the single-quote, no difference.

Regards,


Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 10:07:47 AM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user
 
Hi Greg,

Well, I suppose I wrote the book you are referring to...


Using

useradd -p PASSWORD USER

takes the password hash for PASSWORD hence the use of openssl in:

useadd -p `openssl passwd PASSWORD` USER

openssl password creates the password hash using the original crypt hash
algorithm if no other options are specified. e.g.

$ openssl passwd hello
6hEsTksgRkeiI

With this the first two characters of the output is the salt and the
rest is the password hash. If you want openssl to create the same result
again:

$ openssl passwd -salt "6h" hello
6hEsTksgRkeiI

You can use newer algorithms like MD5 based BSD password algorithm 1:

$ openssl passwd -1 hello
$1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1

$1 : password algorithm 1
$4Mu8Fcs. : salt
$eIKgPP7RCYrb3lFZjhADA1 : password hash


If you log into the system you have to use the clear password. The
system reads the salt, creates the password hash and compares the results.


:rjs


On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote:
> I'm trying to use the example in "Embedded Linux Systems with the Yocto Project" to add a user to my Yocto build. In the book the sample code:
>
>     useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \
>
> uses openssl to generate the encrypted password string to pass to useradd. I have never been able to get this to work. When I run the openssl
> command on the cmd line I get a different value every time, this seems wrong, How can the password code compare against it if every encode
> produces a different value?
>
> I am getting the user added to the system, the home directory shows up and the user is in the passwd and group files. I just can't login to the
> account.
>
> I've obviously got something confused, any help would be appreciated.
>
> Greg Wilson-Lindberg
>  

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


Re: problem adding a user

Greg Wilson-Lindberg
 

Hi Rudolf,

Thanks for the reply, and the information on how openssl works.


I'm trying to create a user with the same group name so the code that I'm using reduces to:

EXTRA_USERS_PARAMS = "\
    useradd -p `openssl passwd test` sakura; \
    usermod -a -G sudo ${SAKURA_USER}; \
    "
I also, as you can see, removed the macros to eliminate as much confusion as possible.


I still can't login in using the password 'test'.


I've also tried both the back-quote and the single-quote, no difference.

Regards,


Greg


From: Rudolf J Streif <rudolf.streif@...>
Sent: Wednesday, May 15, 2019 10:07:47 AM
To: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user
 
Hi Greg,

Well, I suppose I wrote the book you are referring to...


Using

useradd -p PASSWORD USER

takes the password hash for PASSWORD hence the use of openssl in:

useadd -p `openssl passwd PASSWORD` USER

openssl password creates the password hash using the original crypt hash
algorithm if no other options are specified. e.g.

$ openssl passwd hello
6hEsTksgRkeiI

With this the first two characters of the output is the salt and the
rest is the password hash. If you want openssl to create the same result
again:

$ openssl passwd -salt "6h" hello
6hEsTksgRkeiI

You can use newer algorithms like MD5 based BSD password algorithm 1:

$ openssl passwd -1 hello
$1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1

$1 : password algorithm 1
$4Mu8Fcs. : salt
$eIKgPP7RCYrb3lFZjhADA1 : password hash


If you log into the system you have to use the clear password. The
system reads the salt, creates the password hash and compares the results.


:rjs


On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote:
> I'm trying to use the example in "Embedded Linux Systems with the Yocto Project" to add a user to my Yocto build. In the book the sample code:
>
>     useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \
>
> uses openssl to generate the encrypted password string to pass to useradd. I have never been able to get this to work. When I run the openssl
> command on the cmd line I get a different value every time, this seems wrong, How can the password code compare against it if every encode
> produces a different value?
>
> I am getting the user added to the system, the home directory shows up and the user is in the passwd and group files. I just can't login to the
> account.
>
> I've obviously got something confused, any help would be appreciated.
>
> Greg Wilson-Lindberg
>  

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


Re: problem adding a user

Rudolf J Streif
 

Hi Greg,

Well, I suppose I wrote the book you are referring to...


Using

useradd -p PASSWORD USER

takes the password hash for PASSWORD hence the use of openssl in:

useadd -p `openssl passwd PASSWORD` USER

openssl password creates the password hash using the original crypt hash algorithm if no other options are specified. e.g.

$ openssl passwd hello
6hEsTksgRkeiI

With this the first two characters of the output is the salt and the rest is the password hash. If you want openssl to create the same result again:

$ openssl passwd -salt "6h" hello
6hEsTksgRkeiI

You can use newer algorithms like MD5 based BSD password algorithm 1:

$ openssl passwd -1 hello
$1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1

$1 : password algorithm 1
$4Mu8Fcs. : salt
$eIKgPP7RCYrb3lFZjhADA1 : password hash


If you log into the system you have to use the clear password. The system reads the salt, creates the password hash and compares the results.


:rjs

On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote:
I'm trying to use the example in "Embedded Linux Systems with the Yocto Project" to add a user to my Yocto build. In the book the sample code:

useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \

uses openssl to generate the encrypted password string to pass to useradd. I have never been able to get this to work. When I run the openssl
command on the cmd line I get a different value every time, this seems wrong, How can the password code compare against it if every encode
produces a different value?

I am getting the user added to the system, the home directory shows up and the user is in the passwd and group files. I just can't login to the
account.

I've obviously got something confused, any help would be appreciated.

Greg Wilson-Lindberg
--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


Re: Building Out-of-Tree Modules on the BBB Target

Bruce Ashfield
 



On Wed, May 15, 2019 at 3:44 AM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:
> That's correct. That command only adds the kernel source and
> build infrastructure to the SDK, not to your target image. You'd still
> need to arrange to have the kernel-devsrc package installed on the
> target image if you want it on the board's rootfs. How you arrange
> to have the package installed to the image varies with the image
> (since they all don't have the same image install variables, etc).

And here is a $1,000,000 USD question? How to do it on Poky (as
example of what you have stated in RED)? ;-)

In other words: how to arrange it on Poky (as a Referent example)?

The core-image-kernel-dev image is how I do all my on target testing when I introduce a new reference kernel for a release. And IIRC the autobuilders are using a sato based image (Richard could confirm more easily that I could what image type the autobuilders are using for hello-world on target module tests).

Bruce

 

Thank you,
Zoran
_______


On Wed, May 15, 2019 at 7:41 AM Bruce Ashfield <bruce.ashfield@...> wrote:


On Tue, May 14, 2019 at 1:30 PM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:
Hello Chris, Bruce,

I have some additional data to share with you both, since I have tried
something. And here is my take on the things!

> 1. Build using a bb recipe.
> Take a look at meta-skeleton/recipes-kernel/hello-mod for an example.
> You just need to add meta-skeleton to your bblayers.conf and then
>  bitbake hello-mod

I looked into this example, and, yes, it is classic kernel module
definition out of the tree. With some outdated data, all cool, the
YOCTO designer should take care himself to fix these data, if using
this stuff.

But this is NOT mandatory, since I can add out of the tree module NOT
actually using built-in module. I just use .../tmp/deploy/images/bbb/*
generated stuff, since I have automated scripts which are bringing all
these on my BBB target. Then I tftp my source code module to the
target.

> 2. Build from the SDK:
> First, add the kernel source to the SDK by adding this to conf/local.conf
>  TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc"

YES, this is THE command which should generate
/usr/src/kernel(s)/`uname -r` or similar... But adding it to
local.conf and after deleting kernel, then regenerating bitbake -k
core-image-minimal does not bring this path into the rootfs image!?

That's correct. That command only adds the kernel source and build infrastructure to the SDK, not to your target image. You'd still need to arrange to have the kernel-devsrc package installed on the target image if you want it on the board's rootfs. How you arrange to have the package installed to the image varies with the image (since they all don't have the same image install variables, etc).

 

I did it actually using meta-bbb, and using poky referent distro as
two additional layers to the more complex bbb image!
https://github.com/jumpnow/meta-bbb.git

The (KAS - you can figure out out of it local.conf) script I am using
to build such a BBB image is here:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-warrior/kas-bbb-warrior.yml

I did not try it with BBB reference poky only! Maybe I should try it
as only referent poky? What do you think?

Does in this case is SDK build really mandatory??? Should NOT be!


You only do the SDK steps if you want to support building out of tree modules in an SDK install. So it is not mandatory for on target module builds.

Bruce

 
> Once the SDK is installed, generate the kernel headers:
>  sudo -i
>  . /opt/poky/2.6.2/environment-setup-cortexa8hf-neon-poky-linux-gnueabi
>  cd /opt/poky/2.6.2/sysroots/cortexa8hf-neon-poky-linux-gnueabi
>  cd /usr/src/kernel
>  make oldconfig scripts
>  exit

This is in nutshell the same what I did (a bit different) for Embedded
Debian. This is already on the target BBB, NOT while building YOCTO
BBB image!

> Finally, build your module using a Makefile like this
>  obj-m := hello-mod.o
>  all:
>        make -C $(SDKTARGETSYSROOT)/usr/src/kernel M=$(shell pwd)

As said before: bringing my own module into the target BBB (I have my
own examples, and I build them on the target with the almost the same
Makefiles)

Zoran
_______

On Sun, May 12, 2019 at 3:15 PM Chris Simmonds <chris@...> wrote:
>
> Hi Zoran,
>
> There are two ways to do this
>
> 1. Build using a bb recipe.
> Take a look at meta-skeleton/recipes-kernel/hello-mod for an example.
> You just need to add meta-skeleton to your bblaysers.conf and then
>   bitbake hello-mod
>
>
> 2. Build from the SDK:
> First, add the kernel source to the SDK by adding this to conf/local/conf
>   TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc"
>
> Then build the SDK
>   bitbake -c populate_sdk [your image recipe]
>
> Once the SDK is installed, generate the kernel headers:
>   sudo -i
>   . /opt/poky/2.6.2/environment-setup-cortexa8hf-neon-poky-linux-gnueabi
>   cd /opt/poky/2.6.2/sysroots/cortexa8hf-neon-poky-linux-gnueabi
>   cd /usr/src/kernel
>   make oldconfig scripts
>   exit
>
> Finally, build your module using a Makefile like this
>
>   obj-m := hello-mod.o
>   all:
>         make -C $(SDKTARGETSYSROOT)/usr/src/kernel M=$(shell pwd)
>
>
> HTH,
> Chris
>
> On 12/05/2019 11:53, Zoran Stojsavljevic wrote:
> > Hello to the YOCTO community,
> >
> > I am using (to build the target for Beagle Bone Black) the following script:
> > https://github.com/ZoranStojsavljevic/bbb-yocto
> > https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-yocto.sh
> >
> > The latest kernel I am using from the following repo:
> > https://github.com/jumpnow/meta-bbb
> >
> > Is kernel 5.0.14 .
> >
> > Here is the snippet of the boot traces:
> > Starting kernel ...
> >
> > [    0.000000] Booting Linux on physical CPU 0x0
> > [    0.000000] Linux version 5.0.14-jumpnow (oe-user@oe-host) (gcc
> > version 8.3.0 (GCC)) #1 Fri May 10 13:12:33 UTC 2019
> > [    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
> > [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> > instruction cache
> > [    0.000000] OF: fdt: Machine model: TI AM335x BeagleBone Black
> > [    0.000000] Memory policy: Data cache writeback
> > [    0.000000] cma: Reserved 16 MiB at 0x9f000000
> > [    0.000000] CPU: All CPU(s) started in SVC mode.
> > [    0.000000] AM335X ES2.1 (sgx neon)
> > [    0.000000] random: get_random_bytes called from
> > start_kernel+0xa4/0x460 with crng_init=0
> > [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 130048
> > [    0.000000] Kernel command line: console=ttyO0,115200n8
> > root=/dev/ram0 ip=dhcp
> >
> > According to the documentation, the following:
> > 2.10.1. Building Out-of-Tree Modules on the Target
> > https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html
> >
> > I tried to find /usr/src/kernels/5.0.14... Directory, since I see
> > from the build that kernel-dev and kernel-devsrc are included:
> > [user@fedora29-ssd bbb-yocto]$ bitbake -s | grep kernel
> > core-image-kernel-dev                                 :1.0-r0
> > kernel-devsrc                                         :1.0-r0
> > kernel-selftest                                       :1.0-r0
> >
> > THE PROBLEM: But I could not find ob BBB target /usr/src/kernels
> > directory at all!?
> >
> > Two questions here?
> > [1] Do you have any advice on this problem (what I am missing here)?
> > [2] Alternative to [1]: how I can use cross compiler from
> > .../build/tmp to build Out-of-Tree Module for the BBB target on the
> > host?
> >
> > Thank you,
> > Zoran
> > _______
> >
>
>
> --
> Chris Simmonds, trainer and consultant at 2net
> http://www.2net.co.uk
> Author of "Mastering Embedded Linux Programming"


--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II



--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Unable to install additional tools in SDK

Gabriele
 

Hi all,

I need to include in my native sdk the ODB compiler in order to produce some sources. Since it is a nativesdk- only package, I wrote the following nativesdk-odb-compiler_2.5.0.bb
------------------------------------------------------------------------------------------------------------------------
inherit nativesdk

CONFIG_NAME = "odb-gcc-X"
B = "${WORKDIR}/build2"

# We must have a valid configuration before fetching
do_fetch_prepend() {
    install -d ${B}
    bpkg create -d ${B}/${CONFIG_NAME} cc       \
        --wipe                                  \
        config.cxx=g++                          \
        config.cc.coptions=-O3                  \
        config.install.root=${D}/usr
}

do_fetch() {
    bpkg fetch --trust-yes \
        --directory ${B}/${CONFIG_NAME} https://pkg.cppget.org/1/beta
}

do_compile() {
    bpkg build odb -y ${PARALLEL_MAKE} --directory ${B}/${CONFIG_NAME}
}

do_install() {
    bpkg install odb --verbose 3 --directory ${B}/${CONFIG_NAME}
}

FILES_${PN}_append = " ${SDKPATHNATIVE}"
FILES_${PN}_append = " /usr/*"
------------------------------------------------------------------------------------------------------------------------
Then added the following line in my custom image recipe:

TOOLCHAIN_HOST_TASK_append = " nativesdk-odb-compiler"

Then I run bitbake <image> -c populate_sdk and the SDK is build. Once installed, there is no trace about ODB. I digged in the bitbake output directories (image/, package/ and package-split/) and the file tree is correct, also the rpm packages are generated (however the main package is 1/10th of the ODB installed tree). Maybe I'm missing something?

Thanks in advance,
Gabriele


Re: wic cp doesn't work with ext4 partition

Marek Belisko
 

On Wed, May 15, 2019 at 1:47 PM Belisko Marek <marek.belisko@...> wrote:
Hi,

I'm trying to update some artifact after image is build using wic tool. I've tried wic rm image.wic:2/boot/uImage and this works fine (verified with wic ls). While when I want to copy something to ext4 partition (I've tried to copy to vfat boot partition and it works fine) like:
wic cp uImage_modified image.wic:2/boot and verify with wic ls file is not copied. Anything I'm missing here? Thanks.
Hmm seems that if I remove file first then it works fine. No idea why it works with vfat though. 

BR,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

/marek


8621 - 8640 of 53826