Re: [yocto] recipe to clean up files from rootfs

[Andre McCurdy]

On Wed, Dec 13, 2017 at 11:06 PM, Sherif Omran
 wrote:
> Here is my recipe, it runs suceeds but does not delete the files
>
> mypostprocesfunction() {
> rm -r ${IMAGE_ROOTFS}/etc/init.d/psplash.sh
> rm -r ${IMAGE_ROOTFS}/usr/bin/psplash*
> }
>
> ROOTFS_POSTPROCESS_COMMAND += "mypostprocessfunction; "
>

I think you are fundamentally misunderstanding how recipes work. At a
very high level, recipes are used to compile sources into installable
packages (e.g. ipk or rpm files) and then (as a separate step) an
image recipe creates the rootfs by unpacking a set of installable
packages.

One recipe can depend on the output of another (e.g. an image recipe
depends on the installable packages created by other recipes) but each
recipe has it's own execution environment. You can't expect to write a
recipe which changes the behaviour of another recipe, so writing a new
recipe to remove some files from the rootfs created by the image
recipe is fundamentally wrong. It's never going to work, even if you
fix every typo.

As suggested already, the normal and recommended way to remove files
from the rootfs is:

  1) Remove the package which provides the file(s) from the image you
are building (ie don't install the files in the rootfs at all).

If the file(s) you want to remove don't match the granularity of the
installable packages (ie you want to keep some files provided by a
package but remove others) then you have two basic options:

  2) Spilt the installable package into multiple smaller installable
packages (ie modify the packaging rules in the recipe which creates
the installable package).

  3) Postprocess the rootfs. For that to work, you need to add the
postprocessing function ** TO THE IMAGE RECIPE **.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] recipe to clean up files from rootfs

[Martin Hundebøll]

Hi Sherif,

On 2017-12-14 08:06, Sherif Omran wrote:

Here is my recipe, it runs suceeds but does not delete the files

mypostprocesfunction() {
rm -r ${IMAGE_ROOTFS}/etc/init.d/psplash.sh
rm -r ${IMAGE_ROOTFS}/usr/bin/psplash*
}

ROOTFS_POSTPROCESS_COMMAND += "mypostprocessfunction; "


Unless you did a copy-paste error, there's a typo in the function name:
mypostprocesfunction
mypostprocessfunction

// Martin



On Wed, Dec 13, 2017 at 2:03 PM, Mike Looijmans > wrote:


${D} won't work here, grep on ROOTFS_POSTPROCESS_COMMAND for recipes
that get it right.

And, much much much better would be to just not install psplash into
your image!

On 13-12-17 09:10, Sherif Omran wrote:

here is my recipe, the aim was to remove some files from the
init.d folder and tweek before creating the image

#
# This file was derived from the 'Hello World!' example recipe
in the
# Yocto Project Development Manual.
#

SUMMARY = "This recipe removes any missing files from the
filesystem before finalinzing it"
SECTION = "base"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

#SRC_URI = "file://*"

S = "${WORKDIR}"
BB_STRICT_CHECKSUM ="0"
ALLOW_EMPTY_${PN}="1"


#IMAGE_INSTALL = "packagegroup-core-boot
packagegroup-base-extended ${CORE_IMAGE_EXTRA_INSTALL}"
#IMAGE_INSTALL = "${CORE_IMAGE}"

#inherit core-image

my_postprocess_function() {
   rm -r ${D}${bindir}/init.d/psplash.sh
}

ROOTFS_POSTPROCESS_COMMAND += "my_postprocess_function; "

On Wed, Dec 13, 2017 at 7:22 AM, Mike Looijmans

>> wrote:

     Well, start by sharing yours first.

     Be careful when naming your shell routine, sometimes OE
considers parts
     behind the underscore as overrides and then it cannot find it.


     On 13-12-17 07:14, Sherif Omran wrote:

         hi Mike,
         i could not get it to work, if you have a recipe that
works, please
         share it. ROOTFS_POSTPROCESS_COMMAND seems to be buggy.

         thank you



         On Tue, Dec 12, 2017 at 1:58 PM, Mike Looijmans
          >
          
         
         
              E-mail: mike.looijm...@topicproducts.com

         >
              

         >>
              Website: www.topicproducts.com
 
         

              Please consider the environment before printing
this e-mail



              --


     Kind regards,

     Mike Looijmans
   

Re: [yocto] recipe to clean up files from rootfs

[Sherif Omran]

Here is my recipe, it runs suceeds but does not delete the files

mypostprocesfunction() {
rm -r ${IMAGE_ROOTFS}/etc/init.d/psplash.sh
rm -r ${IMAGE_ROOTFS}/usr/bin/psplash*
}

ROOTFS_POSTPROCESS_COMMAND += "mypostprocessfunction; "

On Wed, Dec 13, 2017 at 2:03 PM, Mike Looijmans 
wrote:

> ${D} won't work here, grep on ROOTFS_POSTPROCESS_COMMAND for recipes that
> get it right.
>
> And, much much much better would be to just not install psplash into your
> image!
>
> On 13-12-17 09:10, Sherif Omran wrote:
>
>> here is my recipe, the aim was to remove some files from the init.d
>> folder and tweek before creating the image
>>
>> #
>> # This file was derived from the 'Hello World!' example recipe in the
>> # Yocto Project Development Manual.
>> #
>>
>> SUMMARY = "This recipe removes any missing files from the filesystem
>> before finalinzing it"
>> SECTION = "base"
>> LICENSE = "MIT"
>> LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/
>> MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
>>
>> #SRC_URI = "file://*"
>>
>> S = "${WORKDIR}"
>> BB_STRICT_CHECKSUM ="0"
>> ALLOW_EMPTY_${PN}="1"
>>
>>
>> #IMAGE_INSTALL = "packagegroup-core-boot packagegroup-base-extended
>> ${CORE_IMAGE_EXTRA_INSTALL}"
>> #IMAGE_INSTALL = "${CORE_IMAGE}"
>>
>> #inherit core-image
>>
>> my_postprocess_function() {
>>   rm -r ${D}${bindir}/init.d/psplash.sh
>> }
>>
>> ROOTFS_POSTPROCESS_COMMAND += "my_postprocess_function; "
>>
>> On Wed, Dec 13, 2017 at 7:22 AM, Mike Looijmans > > wrote:
>>
>> Well, start by sharing yours first.
>>
>> Be careful when naming your shell routine, sometimes OE considers
>> parts
>> behind the underscore as overrides and then it cannot find it.
>>
>>
>> On 13-12-17 07:14, Sherif Omran wrote:
>>
>> hi Mike,
>> i could not get it to work, if you have a recipe that works,
>> please
>> share it. ROOTFS_POSTPROCESS_COMMAND seems to be buggy.
>>
>> thank you
>>
>>
>>
>> On Tue, Dec 12, 2017 at 1:58 PM, Mike Looijmans
>> 
>> >>
>> wrote:
>>
>>  On 11-12-17 15:18, Sherif Omran wrote:
>>
>>  i want to create a recipe to clean some files from the
>> rootfile
>>  system, but i don't know how to let this recipe run the
>> last one
>>  before building the rootfile system.
>>
>>
>>  You can use ROOTFS_POSTPROCESS_COMMAND in your image recipe
>> to do
>> some
>>  last-minute filesystem cleanup.
>>
>>  However, in most cases it's much better to determine what
>> recipe
>> puts the
>>  files there and modify the recipe or remove the package. It
>> would
>> help a
>>  lot if you would reveal what files you want to remove and
>> why.
>>
>>
>>  Kind regards,
>>
>>  Mike Looijmans
>>  System Expert
>>
>>  TOPIC Products
>>  Materiaalweg 4, NL-5681 RJ Best
>>  Postbus 440, NL-5680 AK Best
>>  Telefoon: +31 (0) 499 33 69 79
>> 
>> 
>>  E-mail: mike.looijm...@topicproducts.com
>> 
>>  >
>> >
>>  Website: www.topicproducts.com > >
>> 
>>
>>  Please consider the environment before printing this e-mail
>>
>>
>>
>>  --
>>
>>
>> Kind regards,
>>
>> Mike Looijmans
>> System Expert
>>
>> TOPIC Products
>> Materiaalweg 4, NL-5681 RJ Best
>> Postbus 440, NL-5680 AK Best
>> Telefoon: +31 (0) 499 33 69 79 > 3%2069%2079>
>> E-mail: mike.looijm...@topicproducts.com
>> 
>> Website: www.topicproducts.com 
>>
>> Please consider the environment before printing this e-mail
>>
>>
>>
>>
>>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79
> E-mail: mike.looijm...@topicproducts.com
> Website: www.topicproducts.com
>
> Please consider the environment before printing this e-mail
>
>
>
> ___
>
>>
>>  yocto mailing list
>> yocto@yoctoproject.org 
>> >
>> https://lists.yoctoproject.org/listinfo/yocto
>> 
>>   

Re: [yocto] Permission denied while building rocko on Debian 8

[Mircea Gliga]

Hi list

See below

On 11/12/17 15:22, Mircea Gliga wrote:



On 11/12/17 15:06, Paul Barker wrote:
On Mon, Dec 11, 2017 at 12:43 PM, Mircea Gliga 
 wrote:
So I went further and I tested in a VM running Debian 9 - there it 
works:
It looks like I get a Permission denied while building rocko only on 
Debian

8, *not* on Debian 9.

Debian 8 is listed as supported on Yocto Project Reference Manual  
here:
http://www.yoctoproject.org/docs/2.4/ref-manual/ref-manual.html#detailed-supported-distros 


Can somebody confirm this behavior ? It's a straight forward test:

$ git clone -b rocko git://git.yoctoproject.org/poky.git
$ source poky/oe-init-build-env
$ bitbake core-image-minimal

This looks like a weird permission issue rather than something
Yocto-related. How are you running your Debian 8 system? Is it bare
metal, VM, container, some hosting providers VPS, etc?
Indeed, the problem on the Debian 8 machine was that the following 
command was run sometime in the past - we needed a python service to 
listen on a privileged port:

$ sudo setcap 'cap_net_bind_service=+ep' '/usr/bin/python3.5'

Doing a setcap -r /usr/bin/python3.5 fixes the problem.

So it has nothing to do with Yocto!

Thanks for support.



Debian 8 is running on a real system, no VM etc.
I used netinstall with no desktop environment and without all the 
blows and whistles and added just what I needed, when I needed it.
This machine was used for the last 1,5 years or so for developing on 
Krogoth.
I was able to reproduce the problem on a second box, real machine, 
running Debian 8


Meanwhile I tried building rocko on another real machine, running 
Debian 9 - it works. ( in the prev email I tested in a Debian 9 VM)


Thanks



PS I've updated the thread subject to better reflect the problem.

Thanks

On 11/12/17 09:58, Mircea Gliga wrote:

Hello,

I have a working krogoth build - I build images etc, everything is 
fine.
Then I wanted to try a rocko build, I installed the needed host 
packages:
http://www.yoctoproject.org/docs/2.4/yocto-project-qs/yocto-project-qs.html#packages 


Then sourced env and bitbake core-image-minimal.
So no extra layers involved, just poky.
I get errors like this:

ERROR: gnu-config-native-20150728+gitAUTOINC+b576fa87c1-r0 do_fetch: 
Build

of do_fetch failed
ERROR: gnu-config-native-20150728+gitAUTOINC+b576fa87c1-r0 do_fetch:
Traceback (most recent call last):
   File
"/media/mircea/ExtLinux/Adventure/repository/rocko/poky/bitbake/lib/bb/build.py", 


line 644, in exec_task
 return _exec_task(fn, task, d, quieterr)
   File
"/media/mircea/ExtLinux/Adventure/repository/rocko/poky/bitbake/lib/bb/build.py", 


line 618, in _exec_task
 event.fire(TaskSucceeded(task, logfn, localdata), localdata)
   File
"/media/mircea/ExtLinux/Adventure/repository/rocko/poky/bitbake/lib/bb/event.py", 


line 222, in fire
 fire_class_handlers(event, d)
   File
"/media/mircea/ExtLinux/Adventure/repository/rocko/poky/bitbake/lib/bb/event.py", 


line 134, in fire_class_handlers
 execute_handler(name, handler, event, d)
   File
"/media/mircea/ExtLinux/Adventure/repository/rocko/poky/bitbake/lib/bb/event.py", 


line 106, in execute_handler
 ret = handler(event)
   File
"/media/mircea/ExtLinux/Adventure/repository/rocko/poky/meta/classes/buildstats.bbclass", 


line 166, in run_buildstats
 write_task_data("passed", os.path.join(taskdir, e.task), e, d)
   File
"/media/mircea/ExtLinux/Adventure/repository/rocko/poky/meta/classes/buildstats.bbclass", 


line 90, in write_task_data
 cpu, iostats, resources, childres = 
get_process_cputime(os.getpid())

   File
"/media/mircea/ExtLinux/Adventure/repository/rocko/poky/meta/classes/buildstats.bbclass", 


line 29, in get_process_cputime
 with open("/proc/%d/io" % pid, "r") as f:
PermissionError: [Errno 13] Permission denied: '/proc/1530/io'

ERROR: Task
(virtual:native:/media/mircea/ExtLinux/Adventure/repository/rocko/poky/meta/recipes-devtools/gnu-config/gnu-config_git.bb:do_fetch) 


failed with exit code '1'
ERROR: autoconf-native-2.69-r11 do_fetch: Execution of event handler
'run_buildstats' failed
Traceback (most recent call last):
   File
"/media/mircea/ExtLinux/Adventure/repository/rocko/poky/meta/classes/buildstats.bbclass", 


line 166, in run_buildstats(e=):
  elif isinstance(e, bb.build.TaskSucceeded):
 >    write_task_data("passed", os.path.join(taskdir, 
e.task), e, d)

  if e.task == "do_rootfs":
   File
"/media/mircea/ExtLinux/Adventure/repository/rocko/poky/meta/classes/buildstats.bbclass", 


line 90, in write_task_data(status='passed',
logfile='/media/mircea/ExtLinux/Adventure/repository/rocko/build/tmp/buildstats/20171211074610/autoconf-native-2.69-r11/do_fetch', 


e=,
d=):
  f.write(d.expand("Elapsed time: %0.2f seconds\n" %
elapsedtime))
 >    cpu, iostats, resources, childres =
get_process_cputime(os.getpid())
  if cpu:
   File

[linux-yocto] [yocto-4.12] [PATCH] x86/debug: Handle warnings before the notifier chain, to fix KGDB crash

[Hongzhi.Song]

From: Alexander Shishkin 

commit b8347c2196492f4e1cccde3d92fda1cc2cc7de7e upstream

Commit:

  9a93848fe787 ("x86/debug: Implement __WARN() using UD0")

turned warnings into UD0, but the fixup code only runs after the
notify_die() chain. This is a problem, in particular, with kgdb,
which kicks in as if it was a BUG().

Fix this by running the fixup code before the notifier chain in
the invalid op handler path.

Signed-off-by: Alexander Shishkin 
Tested-by: Ilya Dryomov 
Acked-by: Daniel Thompson 
Acked-by: Thomas Gleixner 
Cc: Jason Wessel 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Richard Weinberger 
Cc:  # v4.12+
Link: 
http://lkml.kernel.org/r/20170724100428.19173-1-alexander.shish...@linux.intel.com
Signed-off-by: Ingo Molnar 

This patch is to resolve the problem shown as follows, when testing KGDB with 
'echo kgdbts=V1 > /sys/module/kgdbts/parameters/kgdbts':

[  196.275931] Kernel panic - not syncing: Recursive entry to debugger
[  196.276658] CPU: 0 PID: 1495 Comm: sh Not tainted 4.12.16-yocto-standard #2
[  196.277648] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
[  196.278634] Call Trace:
[  196.278891]  
[  196.279124]  dump_stack+0x65/0x8d
[  196.279477]  ? kgdb_breakpoint+0x13/0x20
[  196.279968]  kgdb_handle_exception+0x16e/0x1a0
[  196.280405]  __kgdb_notify+0x6d/0xd0
[  196.280761]  kgdb_notify+0x23/0x40
[  196.281189]  notifier_call_chain+0x4a/0x70
[  196.281589]  atomic_notifier_call_chain+0x33/0x50
[  196.282033]  notify_die+0x2e/0x30
[  196.282469]  do_int3+0x70/0x100
[  196.282792]  int3+0x35/0x70
[  196.283080] RIP: 0010:kgdb_breakpoint+0x14/0x20
[  196.283596] RSP: :9f2a0fc01d00 EFLAGS: 0002
[  196.284078] RAX:  RBX:  RCX: 
[  196.284751] RDX: a90cd700 RSI:  RDI: a8e4ca10
[  196.285356] RBP: 9f2a0fc01d00 R08:  R09: a8e4ca10
[  196.286002] R10: 9f2a0fc01e00 R11: a90d40ed R12: a8e4d2e0
[  196.286614] R13:  R14: a90cd700 R15: 

Signed-off-by: Hongzhi.Song 
---
 arch/x86/kernel/traps.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 67db4f4..5a6b8f8 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -209,9 +209,6 @@ do_trap_no_signal(struct task_struct *tsk, int trapnr, char 
*str,
if (fixup_exception(regs, trapnr))
return 0;
 
-   if (fixup_bug(regs, trapnr))
-   return 0;
-
tsk->thread.error_code = error_code;
tsk->thread.trap_nr = trapnr;
die(str, regs, error_code);
@@ -292,6 +289,13 @@ static void do_error_trap(struct pt_regs *regs, long 
error_code, char *str,
 
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
 
+   /*
+* WARN*()s end up here; fix them up before we call the
+* notifier chain.
+*/
+   if (!user_mode(regs) && fixup_bug(regs, trapnr))
+   return;
+
if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) !=
NOTIFY_STOP) {
cond_local_irq_enable(regs);
-- 
2.8.1

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

Re: [yocto] .kernel-meta/configs folder missing make linux-raspberrypi to fail

[Zoran Stojsavljevic]

> I'm seeing the same build errors in linux-raspberrypi with various
versions of Gentoo and
> Ubuntu (mostly tested with 14.04 and 16.04), I doubt that this issue is
specific for Fedora 27.

Divide and Conquer. ;-)

Good. New details emerged. So one problem off the potential problem list.

Zoran

On Thu, Dec 14, 2017 at 6:47 AM, Martin Jansa 
wrote:

> I'm seeing the same build errors in linux-raspberrypi with various
> versions of Gentoo and Ubuntu (mostly tested with 14.04 and 16.04), I doubt
> that this issue is specific for Fedora 27.
>
> On Thu, Dec 14, 2017 at 2:31 PM, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> > Also is worth noting that I'm running Fedora 27 which wasn't tested...
>>
>> You should start from here your investigation, since you are on not
>> tested YOCTO host distribution. And Fedoras are
>> different from release to release, certainly!
>>
>> So either you should downgrade your fedora 27 to 26 (which I doubt it is
>> possible), better to build brand new Fedora 26
>> using exactly the same packages.
>>
>> Here is a bit of help: to port all the packages to fresh installed Fedora
>> 26, use the following command to retrieve
>> packages from Fedora 27: rpm -qa --qf "%{name}.%{arch}\n" >
>> packages-list.txt
>>
>> Zoran
>>
>> On Mon, Dec 11, 2017 at 12:34 PM, Daniel.  wrote:
>>
>>> I can anticipate some info for you. I'm on version 2.4 Rocko. Building
>>> rpi-hwup-image for MACHINE=rasbiberrypi3-64. Also is worth noting that I'm
>>> running Fedora 27 which wasn't tested...
>>>
>>> I'll try to get the full log tonight and let you know
>>>
>>> Regards
>>>
>>> On Dec 11, 2017 9:26 AM, "Daniel."  wrote:
>>>
 Yeah but I got to face the error again, maybe tonight when I get home :)

 On Dec 11, 2017 9:17 AM, "Paul Barker"  wrote:

> On Sun, Dec 10, 2017 at 5:14 PM, Daniel. 
> wrote:
> > Hi everybody,
> >
> > I'm building a vanilla image for MACHINE=raspberrypi3-64. I'm doing
> the
> > build for the first time and faced an error at
> > linux-raspberrypi:do_kernel_configme. I found that
> .kernel-meta/configs
> > folder was missing, so I fired a devshell and created it. After that
> > everything works as expected and linux-raspberrypi build fines.
> >
> > The solution I got is palliative, what would be the real solution
> and what
> > is this .kernel-meta folder? I had never seem this folder before.
>
> I have seen this issue occasionally when the do_kernel_configme task
> is re-executed. A "bitbake virtual/kernel -c clean" has always
> resolved this for me, allowing the next build to succeed. It doesn't
> occur on my autobuild systems though so I figure it's an edge case I'm
> hitting when building locally as I'm hacking around on recipes.
>
> I've never seen this on the first build of the kernel though.
>
> Which version of Yocto are you using? Could you send us the build
> configuration summary and the full error messages printed by bitbake?
>
> Thanks,
>
> --
> Paul Barker
> Togán Labs Ltd
>

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

Re: [yocto] .kernel-meta/configs folder missing make linux-raspberrypi to fail

[Martin Jansa]

I'm seeing the same build errors in linux-raspberrypi with various versions
of Gentoo and Ubuntu (mostly tested with 14.04 and 16.04), I doubt that
this issue is specific for Fedora 27.

On Thu, Dec 14, 2017 at 2:31 PM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> > Also is worth noting that I'm running Fedora 27 which wasn't tested...
>
> You should start from here your investigation, since you are on not tested
> YOCTO host distribution. And Fedoras are
> different from release to release, certainly!
>
> So either you should downgrade your fedora 27 to 26 (which I doubt it is
> possible), better to build brand new Fedora 26
> using exactly the same packages.
>
> Here is a bit of help: to port all the packages to fresh installed Fedora
> 26, use the following command to retrieve
> packages from Fedora 27: rpm -qa --qf "%{name}.%{arch}\n" >
> packages-list.txt
>
> Zoran
>
> On Mon, Dec 11, 2017 at 12:34 PM, Daniel.  wrote:
>
>> I can anticipate some info for you. I'm on version 2.4 Rocko. Building
>> rpi-hwup-image for MACHINE=rasbiberrypi3-64. Also is worth noting that I'm
>> running Fedora 27 which wasn't tested...
>>
>> I'll try to get the full log tonight and let you know
>>
>> Regards
>>
>> On Dec 11, 2017 9:26 AM, "Daniel."  wrote:
>>
>>> Yeah but I got to face the error again, maybe tonight when I get home :)
>>>
>>> On Dec 11, 2017 9:17 AM, "Paul Barker"  wrote:
>>>
 On Sun, Dec 10, 2017 at 5:14 PM, Daniel.  wrote:
 > Hi everybody,
 >
 > I'm building a vanilla image for MACHINE=raspberrypi3-64. I'm doing
 the
 > build for the first time and faced an error at
 > linux-raspberrypi:do_kernel_configme. I found that
 .kernel-meta/configs
 > folder was missing, so I fired a devshell and created it. After that
 > everything works as expected and linux-raspberrypi build fines.
 >
 > The solution I got is palliative, what would be the real solution and
 what
 > is this .kernel-meta folder? I had never seem this folder before.

 I have seen this issue occasionally when the do_kernel_configme task
 is re-executed. A "bitbake virtual/kernel -c clean" has always
 resolved this for me, allowing the next build to succeed. It doesn't
 occur on my autobuild systems though so I figure it's an edge case I'm
 hitting when building locally as I'm hacking around on recipes.

 I've never seen this on the first build of the kernel though.

 Which version of Yocto are you using? Could you send us the build
 configuration summary and the full error messages printed by bitbake?

 Thanks,

 --
 Paul Barker
 Togán Labs Ltd

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

Re: [yocto] .kernel-meta/configs folder missing make linux-raspberrypi to fail

[Zoran Stojsavljevic]

> Also is worth noting that I'm running Fedora 27 which wasn't tested...

You should start from here your investigation, since you are on not tested
YOCTO host distribution. And Fedoras are
different from release to release, certainly!

So either you should downgrade your fedora 27 to 26 (which I doubt it is
possible), better to build brand new Fedora 26
using exactly the same packages.

Here is a bit of help: to port all the packages to fresh installed Fedora
26, use the following command to retrieve
packages from Fedora 27: rpm -qa --qf "%{name}.%{arch}\n" >
packages-list.txt

Zoran

On Mon, Dec 11, 2017 at 12:34 PM, Daniel.  wrote:

> I can anticipate some info for you. I'm on version 2.4 Rocko. Building
> rpi-hwup-image for MACHINE=rasbiberrypi3-64. Also is worth noting that I'm
> running Fedora 27 which wasn't tested...
>
> I'll try to get the full log tonight and let you know
>
> Regards
>
> On Dec 11, 2017 9:26 AM, "Daniel."  wrote:
>
>> Yeah but I got to face the error again, maybe tonight when I get home :)
>>
>> On Dec 11, 2017 9:17 AM, "Paul Barker"  wrote:
>>
>>> On Sun, Dec 10, 2017 at 5:14 PM, Daniel.  wrote:
>>> > Hi everybody,
>>> >
>>> > I'm building a vanilla image for MACHINE=raspberrypi3-64. I'm doing the
>>> > build for the first time and faced an error at
>>> > linux-raspberrypi:do_kernel_configme. I found that
>>> .kernel-meta/configs
>>> > folder was missing, so I fired a devshell and created it. After that
>>> > everything works as expected and linux-raspberrypi build fines.
>>> >
>>> > The solution I got is palliative, what would be the real solution and
>>> what
>>> > is this .kernel-meta folder? I had never seem this folder before.
>>>
>>> I have seen this issue occasionally when the do_kernel_configme task
>>> is re-executed. A "bitbake virtual/kernel -c clean" has always
>>> resolved this for me, allowing the next build to succeed. It doesn't
>>> occur on my autobuild systems though so I figure it's an edge case I'm
>>> hitting when building locally as I'm hacking around on recipes.
>>>
>>> I've never seen this on the first build of the kernel though.
>>>
>>> Which version of Yocto are you using? Could you send us the build
>>> configuration summary and the full error messages printed by bitbake?
>>>
>>> Thanks,
>>>
>>> --
>>> Paul Barker
>>> Togán Labs Ltd
>>>
>>
> --
> ___
> 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] .kernel-meta/configs folder missing make linux-raspberrypi to fail

[Daniel.]

PS: I just notice now that I have meta-python duplicated at bblayers.conf,

2017-12-14 0:27 GMT-02:00 Daniel. :

> Okay, sorry for the late reply!
>
> I could reproduce the same error again, I just cleanall and then build
> linux-raspberrypi again. Let's go to the logs:
>
> The whole output: https://pastebin.com/zHLpPf5V
> My config: https://pastebin.com/mKJb2tyJ
> Configured layers: https://pastebin.com/7UakkhHJ
> https://pastebin.com/xKRd8rDr
> The layers commits: https://pastebin.com/9pJCrdh4
>
> I'll let it stay in this state, so if you need any other information just
> let me know and I gather it for you. Again, I'm on fedora 27, kernel
> 4.14.3-300.fc27.x86_64, i3, 8GB ram. I think this is it.
>
> Regards!
>
>
> 2017-12-11 9:34 GMT-02:00 Daniel. :
>
>> I can anticipate some info for you. I'm on version 2.4 Rocko. Building
>> rpi-hwup-image for MACHINE=rasbiberrypi3-64. Also is worth noting that I'm
>> running Fedora 27 which wasn't tested...
>>
>> I'll try to get the full log tonight and let you know
>>
>> Regards
>>
>> On Dec 11, 2017 9:26 AM, "Daniel."  wrote:
>>
>>> Yeah but I got to face the error again, maybe tonight when I get home :)
>>>
>>> On Dec 11, 2017 9:17 AM, "Paul Barker"  wrote:
>>>
 On Sun, Dec 10, 2017 at 5:14 PM, Daniel.  wrote:
 > Hi everybody,
 >
 > I'm building a vanilla image for MACHINE=raspberrypi3-64. I'm doing
 the
 > build for the first time and faced an error at
 > linux-raspberrypi:do_kernel_configme. I found that
 .kernel-meta/configs
 > folder was missing, so I fired a devshell and created it. After that
 > everything works as expected and linux-raspberrypi build fines.
 >
 > The solution I got is palliative, what would be the real solution and
 what
 > is this .kernel-meta folder? I had never seem this folder before.

 I have seen this issue occasionally when the do_kernel_configme task
 is re-executed. A "bitbake virtual/kernel -c clean" has always
 resolved this for me, allowing the next build to succeed. It doesn't
 occur on my autobuild systems though so I figure it's an edge case I'm
 hitting when building locally as I'm hacking around on recipes.

 I've never seen this on the first build of the kernel though.

 Which version of Yocto are you using? Could you send us the build
 configuration summary and the full error messages printed by bitbake?

 Thanks,

 --
 Paul Barker
 Togán Labs Ltd

>>>
>
>
> --
> “If you're going to try, go all the way. Otherwise, don't even start. ..."
>   Charles Bukowski
>



-- 
“If you're going to try, go all the way. Otherwise, don't even start. ..."
  Charles Bukowski
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 08/12] upgradehelper.py: clean repo only once when recipes are specified

[Robert Yang]

On 12/13/2017 09:18 PM, Alexander Kanavin wrote:

On 12/13/2017 03:16 AM, Robert Yang wrote:

How about simply issuing 'git revert' after a build has failed? That's easier 
to implement than rearranging the order of commits, and the commit message 
can include a link to the build failure logs.


Sounds reasonable to me, I will update the patch.


Wait until I publish my devtool port, then if you could rebase on that, that'd 
be great!


Got it, thanks.

// Robert



Alex


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

[yocto] [meta-raspberrypi] linux kernel rt

[Sherif Omran]

hey guys,

any body tried the real time kernel? I get an error, it is snot in the
compatibility list.
can we skip it?

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

Re: [linux-yocto] New branches for AXXIA in linux-yocto-4.12

[Bruce Ashfield]

On 2017-12-13 12:33 PM, Dragomir Daniel wrote:


On 13.12.2017 19:31, Dragomir, Daniel wrote:

Hello Bruce!

Can you please create new branches for AXXIA in linux-yocto-4.12 
repository?

We'll start submitting patches soon.

standard/preempt-rt/axxia/base from standard/preempt-rt/base
standard/preempt-rt/axxia/base from standard/base


standard/preempt-rt/axxia/base from standard/preempt-rt/base
standard/axxia/base from standard/base



To ssh://g...@git.yoctoproject.org/linux-yocto-4.12.git
 * [new branch]standard/axxia/base -> standard/axxia/base
 * [new branch]standard/preempt-rt/axxia/base -> 
standard/preempt-rt/axxia/base



Bruce


My mistake. Sorry.



Thank you!
Daniel






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

Re: [linux-yocto] [PATCH 00/48] Intel Axxia updates to linux-yocto-4.9

[Bruce Ashfield]

On 2017-12-11 8:13 AM, Daniel Dragomir wrote:

Hello Bruce!

Please review and merge this series of patches in Axxia branches from
linux-yocto-4.9.



The branches showed up for me, and have now been merged.

Bruce


If all the patches are ok, please pull them from
https://github.com/axxia/axxia_yocto_linux_4.9_pull.git
into
git://git.yoctoproject.org/linux-yocto-4.9
Pull
standard/axxia/base-1.15 -> standard/axxia/base
standard/preempt-rt/axxia/base-1.15 -> standard/preempt-rt/axxia/base

NOTE: Preempt-rt branch has 4 patches in addition to the standard one.

If you add more patches to standard/(preempt-rt)/axxia/base beforehand
please notify me. I will rebase our changes so you can do a clean,
fast-forward pull.

Changes included in this series (axxia tag 1.7 to 1.15):

Linux 4.9, Axxia 1.15 Changes
 Support the Axxia reset driver and, optionally, DDR retention resets.
 Backport the commits necessary to boot reliably with the Preempt-RT
 patches and debug configuration.

Linux 4.9, Axxia 1.14 Changes
 Update the PCI LOS work around to make sure the configuration gets put
 back to normal when the speed changes from gen1 to gen2/gen3.
 Support additional SPI flash devices (Winbond W25Q128JVSIM and Cypress 
S25FL128L).
 EDAC updates:
 - Change default log settings -- nothing on the console.
 - Add 6700 support.
 - Fix issue with DDR retention reset and the use of the scratch 
register.
 Only update coresight on 6700 hardware, not simulation.
 Create a custom gpio driver for Axxia as the interrupt structure is 
different.
 Include a device tree for the axm5612.
 Fix compile errors when CONFIG_PCI_MSI is not defined.
 Axxia network interface cleanup:
 - Remove unused reference, CONFIG_NET_VENDOR_LSI.
 - Include dependecy on Axxia MDIO.

Linux 4.9, Axxia 1.13 Changes
 Update from 4.9.49 to 4.9.61.

Linux 4.9, Axxia 1.12 Changes
 Update coresight hardware tracing support to include all clusters on 6700.
 Only include coresight in the hardware device trees, not simulation.
 Update the GPIO driver for 4.9.
 Include a 12 core device tree for 5600.
 Fix compile errors when MSI is not enabled.
 Remove unused reference to CONFIG_NET_VENDOR_LSI.
 Include dependency on Axxia MDIO when enabling Axxia NEMAC.

Linux 4.9, Axxia 1.11 Changes
 Enable EDAC CMEM support when CMEM gets initialized.
 Reduce the PCIe LOS work around timeout to 1 second.
 Update the debug configuration for 5600.

Linux 4.9, Axxia 1.10 Changes
 Rebase from Linux 4.9.36 to 4.9.49.

Linux 4.9, Axxia 1.9 Changes
 Support hardware tracing using coresight and tools/perf (cluster 0 only, 
6700 only).
 Add CCN504 interrupt driven EDAC driver.

Linux 4.9, Axxia 1.8 Changes
 Remove NOSMP configurations.
 Add support for MSI interruts on 5600 and 6700.
 APC3000 support.

Linux 4.9, Axxia 1.7 Changes
 Rebase to the latest Yocto (4.9.21 to 4.9.36).
 Update USB to use the original reset sequence instead of asserting HCRST:
 - The HCRST reset breaks USB2 and USB3 in some cases.
 Fixes for PEI configuration 5.
 Fix a boot problem on 5500. In the new Axxia fault code, exceptions need 
to be masked
 on 5500 by default.
 The final change to the PCI work around (If the link is not established at 
the requested
 number of lanes...) was not included. As the hardware does not have 
the correct default
 class code, software needs to set it. With the width change work 
around, the class code
 needs to be set to the correct value each time the width is changed.
 Update the default configurations to get rid of some warnings when using 
systemd instead of
 sysv init.
 Add tracing of NCR, PEI, and PCI accesses. Tracing can be enabled using 
the bootargs or after
 booting using /sys:
 - For NCR, use trace for all accesses, and trace_value_read to display 
the value read
   after a read.
 - For PEI and PCI, use trace.
 PCI Updates:
 - Add a work around for a hardware problem. If the link is not 
established at the requested
   number of lanes, reduce and try again. If there is no link at x1, 
fail.
 - Update the LOS work around to work the the lane reduction work 
around mentioned above.
 - Add a new configuration for 5600, unsupported on the Axxia 
development board, configuration 5.
 - In configuration 2, 5600, set sw_port_1 to 0x2 instead of 0x4.
 - Always set the number of phys to 4 for 5600 and 1 for 6700.
 - Always set the link width speed change register to x1 and use the 
link control register to
   set the desired width.
 USB Updates and USB support for 5600 B* parts:
 - Use HCRST for soft resets in the driver and don't reset the PHY 
seperately sinc HCRST resets
   the PHY.
 - Move all changes to constant 

[yocto] CROPS status?

[Martin Kelly]

Hi,

I recently discovered the CROPS project at 
https://github.com/crops/crops. It looks like a great idea, but I see it 
hasn't had a commit since June 23, 2016. Is the project still active?


Thanks,
Martin
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] New branches for AXXIA in linux-yocto-4.12

[Dragomir Daniel]

On 13.12.2017 19:31, Dragomir, Daniel wrote:

Hello Bruce!

Can you please create new branches for AXXIA in linux-yocto-4.12 
repository?

We'll start submitting patches soon.

standard/preempt-rt/axxia/base from standard/preempt-rt/base
standard/preempt-rt/axxia/base from standard/base


standard/preempt-rt/axxia/base from standard/preempt-rt/base
standard/axxia/base from standard/base

My mistake. Sorry.



Thank you!
Daniel




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

Re: [yocto] recipe to clean up files from rootfs

[Mike Looijmans]

${D} won't work here, grep on ROOTFS_POSTPROCESS_COMMAND for recipes that get 
it right.


And, much much much better would be to just not install psplash into your image!

On 13-12-17 09:10, Sherif Omran wrote:
here is my recipe, the aim was to remove some files from the init.d folder and 
tweek before creating the image


#
# This file was derived from the 'Hello World!' example recipe in the
# Yocto Project Development Manual.
#

SUMMARY = "This recipe removes any missing files from the filesystem before 
finalinzing it"

SECTION = "base"
LICENSE = "MIT"
LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"


#SRC_URI = "file://*"

S = "${WORKDIR}"
BB_STRICT_CHECKSUM ="0"
ALLOW_EMPTY_${PN}="1"


#IMAGE_INSTALL = "packagegroup-core-boot packagegroup-base-extended 
${CORE_IMAGE_EXTRA_INSTALL}"

#IMAGE_INSTALL = "${CORE_IMAGE}"

#inherit core-image

my_postprocess_function() {
  rm -r ${D}${bindir}/init.d/psplash.sh
}

ROOTFS_POSTPROCESS_COMMAND += "my_postprocess_function; "

On Wed, Dec 13, 2017 at 7:22 AM, Mike Looijmans > wrote:


Well, start by sharing yours first.

Be careful when naming your shell routine, sometimes OE considers parts
behind the underscore as overrides and then it cannot find it.


On 13-12-17 07:14, Sherif Omran wrote:

hi Mike,
i could not get it to work, if you have a recipe that works, please
share it. ROOTFS_POSTPROCESS_COMMAND seems to be buggy.

thank you



On Tue, Dec 12, 2017 at 1:58 PM, Mike Looijmans

>> 
wrote:

     On 11-12-17 15:18, Sherif Omran wrote:

         i want to create a recipe to clean some files from the rootfile
         system, but i don't know how to let this recipe run the last 
one
         before building the rootfile system.


     You can use ROOTFS_POSTPROCESS_COMMAND in your image recipe to do
some
     last-minute filesystem cleanup.

     However, in most cases it's much better to determine what recipe
puts the
     files there and modify the recipe or remove the package. It would
help a
     lot if you would reveal what files you want to remove and why.


     Kind regards,

     Mike Looijmans
     System Expert

     TOPIC Products
     Materiaalweg 4, NL-5681 RJ Best
     Postbus 440, NL-5680 AK Best
     Telefoon: +31 (0) 499 33 69 79


     E-mail: mike.looijm...@topicproducts.com

     >
     Website: www.topicproducts.com 


     Please consider the environment before printing this e-mail



     --


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79 
E-mail: mike.looijm...@topicproducts.com

Website: www.topicproducts.com 

Please consider the environment before printing this e-mail






Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



___


     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] [PATCH 08/12] upgradehelper.py: clean repo only once when recipes are specified

[Alexander Kanavin]

On 12/13/2017 03:16 AM, Robert Yang wrote:

How about simply issuing 'git revert' after a build has failed? That's 
easier to implement than rearranging the order of commits, and the 
commit message can include a link to the build failure logs.


Sounds reasonable to me, I will update the patch.


Wait until I publish my devtool port, then if you could rebase on that, 
that'd be great!


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

Re: [linux-yocto] [PATCH 00/48] Intel Axxia updates to linux-yocto-4.9

[Dragomir Daniel]

On 12.12.2017 21:12, Bruce Ashfield wrote:

On 2017-12-11 8:13 AM, Daniel Dragomir wrote:

Hello Bruce!

Please review and merge this series of patches in Axxia branches from
linux-yocto-4.9.

If all the patches are ok, please pull them from
https://github.com/axxia/axxia_yocto_linux_4.9_pull.git
into
git://git.yoctoproject.org/linux-yocto-4.9
Pull
standard/axxia/base-1.15 -> standard/axxia/base
standard/preempt-rt/axxia/base-1.15 -> standard/preempt-rt/axxia/base



I'm not seeing these branches on the pull repository. Can you
double check that they are in place ?

Bruce


Hi Bruce!

I cloned again the repo to check the branches, and I was able to find them:
https://github.com/axxia/axxia_yocto_linux_4.9_pull.git
standard/axxia/base-1.15
standard/preempt-rt/axxia/base-1.15

Maybe after a fresh clone instead just a pull, you'll see the branches.
Regards,
Daniel




NOTE: Preempt-rt branch has 4 patches in addition to the standard one.

If you add more patches to standard/(preempt-rt)/axxia/base beforehand
please notify me. I will rebase our changes so you can do a clean,
fast-forward pull.

Changes included in this series (axxia tag 1.7 to 1.15):

Linux 4.9, Axxia 1.15 Changes
 Support the Axxia reset driver and, optionally, DDR retention 
resets.

 Backport the commits necessary to boot reliably with the Preempt-RT
 patches and debug configuration.

Linux 4.9, Axxia 1.14 Changes
 Update the PCI LOS work around to make sure the configuration 
gets put

 back to normal when the speed changes from gen1 to gen2/gen3.
 Support additional SPI flash devices (Winbond W25Q128JVSIM and 
Cypress S25FL128L).

 EDAC updates:
 - Change default log settings -- nothing on the console.
 - Add 6700 support.
 - Fix issue with DDR retention reset and the use of the 
scratch register.

 Only update coresight on 6700 hardware, not simulation.
 Create a custom gpio driver for Axxia as the interrupt structure 
is different.

 Include a device tree for the axm5612.
 Fix compile errors when CONFIG_PCI_MSI is not defined.
 Axxia network interface cleanup:
 - Remove unused reference, CONFIG_NET_VENDOR_LSI.
 - Include dependecy on Axxia MDIO.

Linux 4.9, Axxia 1.13 Changes
 Update from 4.9.49 to 4.9.61.

Linux 4.9, Axxia 1.12 Changes
 Update coresight hardware tracing support to include all 
clusters on 6700.
 Only include coresight in the hardware device trees, not 
simulation.

 Update the GPIO driver for 4.9.
 Include a 12 core device tree for 5600.
 Fix compile errors when MSI is not enabled.
 Remove unused reference to CONFIG_NET_VENDOR_LSI.
 Include dependency on Axxia MDIO when enabling Axxia NEMAC.

Linux 4.9, Axxia 1.11 Changes
 Enable EDAC CMEM support when CMEM gets initialized.
 Reduce the PCIe LOS work around timeout to 1 second.
 Update the debug configuration for 5600.

Linux 4.9, Axxia 1.10 Changes
 Rebase from Linux 4.9.36 to 4.9.49.

Linux 4.9, Axxia 1.9 Changes
 Support hardware tracing using coresight and tools/perf (cluster 
0 only, 6700 only).

 Add CCN504 interrupt driven EDAC driver.

Linux 4.9, Axxia 1.8 Changes
 Remove NOSMP configurations.
 Add support for MSI interruts on 5600 and 6700.
 APC3000 support.

Linux 4.9, Axxia 1.7 Changes
 Rebase to the latest Yocto (4.9.21 to 4.9.36).
 Update USB to use the original reset sequence instead of 
asserting HCRST:

 - The HCRST reset breaks USB2 and USB3 in some cases.
 Fixes for PEI configuration 5.
 Fix a boot problem on 5500. In the new Axxia fault code, 
exceptions need to be masked

 on 5500 by default.
 The final change to the PCI work around (If the link is not 
established at the requested
 number of lanes...) was not included. As the hardware does 
not have the correct default
 class code, software needs to set it. With the width change 
work around, the class code
 needs to be set to the correct value each time the width is 
changed.
 Update the default configurations to get rid of some warnings 
when using systemd instead of

 sysv init.
 Add tracing of NCR, PEI, and PCI accesses. Tracing can be 
enabled using the bootargs or after

 booting using /sys:
 - For NCR, use trace for all accesses, and trace_value_read 
to display the value read

   after a read.
 - For PEI and PCI, use trace.
 PCI Updates:
 - Add a work around for a hardware problem. If the link is 
not established at the requested
   number of lanes, reduce and try again. If there is no link 
at x1, fail.
 - Update the LOS work around to work the the lane reduction 
work around mentioned above.
 - Add a new configuration for 5600, unsupported on the Axxia 
development board, configuration 5.
 - In configuration 2, 5600, set sw_port_1 to 0x2 instead of 
0x4.

 - Always 

Re: [yocto] recipe to clean up files from rootfs

[Sherif Omran]

here is my recipe, the aim was to remove some files from the init.d folder
and tweek before creating the image

#
# This file was derived from the 'Hello World!' example recipe in the
# Yocto Project Development Manual.
#

SUMMARY = "This recipe removes any missing files from the filesystem before
finalinzing it"
SECTION = "base"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

#SRC_URI = "file://*"

S = "${WORKDIR}"
BB_STRICT_CHECKSUM ="0"
ALLOW_EMPTY_${PN}="1"


#IMAGE_INSTALL = "packagegroup-core-boot packagegroup-base-extended
${CORE_IMAGE_EXTRA_INSTALL}"
#IMAGE_INSTALL = "${CORE_IMAGE}"

#inherit core-image

my_postprocess_function() {
 rm -r ${D}${bindir}/init.d/psplash.sh
}

ROOTFS_POSTPROCESS_COMMAND += "my_postprocess_function; "

On Wed, Dec 13, 2017 at 7:22 AM, Mike Looijmans 
wrote:

> Well, start by sharing yours first.
>
> Be careful when naming your shell routine, sometimes OE considers parts
> behind the underscore as overrides and then it cannot find it.
>
>
> On 13-12-17 07:14, Sherif Omran wrote:
>
>> hi Mike,
>> i could not get it to work, if you have a recipe that works, please share
>> it. ROOTFS_POSTPROCESS_COMMAND seems to be buggy.
>>
>> thank you
>>
>>
>>
>> On Tue, Dec 12, 2017 at 1:58 PM, Mike Looijmans > > wrote:
>>
>> On 11-12-17 15:18, Sherif Omran wrote:
>>
>> i want to create a recipe to clean some files from the rootfile
>> system, but i don't know how to let this recipe run the last one
>> before building the rootfile system.
>>
>>
>> You can use ROOTFS_POSTPROCESS_COMMAND in your image recipe to do some
>> last-minute filesystem cleanup.
>>
>> However, in most cases it's much better to determine what recipe puts
>> the
>> files there and modify the recipe or remove the package. It would
>> help a
>> lot if you would reveal what files you want to remove and why.
>>
>>
>> Kind regards,
>>
>> Mike Looijmans
>> System Expert
>>
>> TOPIC Products
>> Materiaalweg 4, NL-5681 RJ Best
>> Postbus 440, NL-5680 AK Best
>> Telefoon: +31 (0) 499 33 69 79 > 3%2069%2079>
>> E-mail: mike.looijm...@topicproducts.com
>> 
>> Website: www.topicproducts.com 
>>
>> Please consider the environment before printing this e-mail
>>
>>
>>
>> --
>>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79
> E-mail: mike.looijm...@topicproducts.com
> Website: www.topicproducts.com
>
> Please consider the environment before printing this e-mail
>
>
>
> ___
>
>> yocto mailing list
>> yocto@yoctoproject.org 
>> https://lists.yoctoproject.org/listinfo/yocto
>> 
>>
>>
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto