ERROR: Task (.../kernel-module-something.bb:do_package) failed with exit code '134'

ERROR: Task (.../kernel-module-something.bb:do_package) failed with exit code '134'

[Vasyl Vavrychuk]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

I have external kernel module recipe, let's call it kernel-module-something.bb.

Sometimes, it fails with

ERROR: Task (.../kernel-module-something.bb:do_package) failed with exit code '134'

I have checked pseudo.log, it looks like this

inode mismatch: '.../kernel-module-something/1.0-r0/image/lib/modules/5.10.25-yocto-standard/extra/something.ko' ino 240205743 in db, 240631184 in request.
creat ignored for existing file '.../kernel-module-something/1.0-r0/image/lib/modules/5.10.25-yocto-standard/extra/something.ko'.
inode mismatch: '.../kernel-module-something/1.0-r0/image/lib/modules/5.10.25-yocto-standard/extra/something.ko' ino 240205743 in db, 240631184 in request.
...
a lot of inode mismatch prints
...
inode mismatch: '.../kernel-module-something/1.0-r0/sstate-build-package/package/lib/modules/5.10.25-yocto-standard/extra/something.ko' ino 240207118 in db, 240631442 in request.
path mismatch [2 links]: ino 240631442 db '.../kernel-module-something/1.0-r0/sstate-build-package/packages-split/kernel-module-something-5.10.25-yocto-standard/lib/modules/5.10.25-yocto-standard/extra/something.ko' req '.../kernel-module-something/1.0-r0/sstate-build-package/package/lib/modules/5.10.25-yocto-standard/extra/something.ko'.

Can't debug it further since it is rarely reproducible, next run failure will be some consequence of this, and after cleansstate this won't be reproducible for a while.

My recipe is simple:

inherit module

SRC_URI = " \
file://Kbuild \
file://Makefile \
file://something.c \
file://something.h \
"

S = "${WORKDIR}"

KERNEL_MODULE_AUTOLOAD = "something"

Using Yocto 3.1.10.

[-- Attachment #2: Type: text/html, Size: 2175 bytes --]

Re: [OE-core] ERROR: Task (.../kernel-module-something.bb:do_package) failed with exit code '134'

[Richard Purdie]

On Mon, 2021-09-27 at 10:44 -0700, Vasyl Vavrychuk wrote:
> I have external kernel module recipe, let's call it kernel-module-
> something.bb.
> 
> Sometimes, it fails with
> 
>   ERROR: Task (.../kernel-module-something.bb:do_package) failed with exit
> code
> '134'
> 
> I have checked pseudo.log, it looks like this
> 
>   inode mismatch: '.../kernel-module-something/1.0-
> r0/image/lib/modules/5.10.25-yocto-standard/extra/something.ko' ino 240205743
> in db, 240631184 in request.
>   creat ignored for existing file '.../kernel-module-something/1.0-
> r0/image/lib/modules/5.10.25-yocto-standard/extra/something.ko'.
>   inode mismatch: '.../kernel-module-something/1.0-
> r0/image/lib/modules/5.10.25-yocto-standard/extra/something.ko' ino 240205743
> in db, 240631184 in request.
>   ...
>   a lot of inode mismatch prints
>   ...
>   inode mismatch: '.../kernel-module-something/1.0-r0/sstate-build-
> package/package/lib/modules/5.10.25-yocto-standard/extra/something.ko' ino
> 240207118 in db, 240631442 in request.
>   path mismatch [2 links]: ino 240631442 db '.../kernel-module-something/1.0-
> r0/sstate-build-package/packages-split/kernel-module-something-5.10.25-yocto-
> standard/lib/modules/5.10.25-yocto-standard/extra/something.ko' req
> '.../kernel-module-something/1.0-r0/sstate-build-
> package/package/lib/modules/5.10.25-yocto-standard/extra/something.ko'.
>  
> Can't debug it further since it is rarely reproducible, next run failure will
> be some consequence of this, and after cleansstate this won't be reproducible
> for a while.
> 
> My recipe is simple:
> 
>   inherit module
>   
>   SRC_URI = " \
>     file://Kbuild \
>     file://Makefile \
>     file://something.c \
>     file://something.h \
>   "
>   
>   S = "${WORKDIR}"
>   
>   KERNEL_MODULE_AUTOLOAD = "something"
> 
> Using Yocto 3.1.10.


Even if you can't reproduce the error, you can likely look at the pseudo
database (in WORKDIR/pseudo/) as it is a relatively simple sqlite3 database. You
can check the inode numbers in the database compared to the files on disk and
the issue is fixed when the numbers match up.

Cheers,

Richard

Re: [OE-core] ERROR: Task (.../kernel-module-something.bb:do_package) failed with exit code '134'

[Vasyl Vavrychuk]

Hi, Richard,

> Even if you can't reproduce the error, you can likely look at the pseudo
> database (in WORKDIR/pseudo/) as it is a relatively simple sqlite3 database. You
> can check the inode numbers in the database compared to the files on disk and
> the issue is fixed when the numbers match up.

I have checked files.db but it did not help. I have found that ino in
sqllite db is what is printed in pseudo.log, and, it does not match
actual ino on the file system, as it is printed in pseudo.log too:

  inode mismatch:
'../kernel-module-smth/1.0-r0/image/lib/modules/5.10.25-yocto-standard/extra/smth.ko'
ino 701049753 in db, 639582649 in request.

The question is what has led to this mismatch. How can I debug it when
I get this situation randomly (or not randomly, but pattern is not
clear for me at the moment)?

Kind regards,
Vasyl

Re: [OE-core] ERROR: Task (.../kernel-module-something.bb:do_package) failed with exit code '134'

[Richard Purdie]

On Sat, 2021-10-30 at 23:21 +0300, Vasyl Vavrychuk wrote:
> Hi, Richard,
> 
> > Even if you can't reproduce the error, you can likely look at the pseudo
> > database (in WORKDIR/pseudo/) as it is a relatively simple sqlite3 database. You
> > can check the inode numbers in the database compared to the files on disk and
> > the issue is fixed when the numbers match up.
> 
> I have checked files.db but it did not help. I have found that ino in
> sqllite db is what is printed in pseudo.log, and, it does not match
> actual ino on the file system, as it is printed in pseudo.log too:
> 
>   inode mismatch:
> '../kernel-module-smth/1.0-r0/image/lib/modules/5.10.25-yocto-standard/extra/smth.ko'
> ino 701049753 in db, 639582649 in request.
> 
> The question is what has led to this mismatch. How can I debug it when
> I get this situation randomly (or not randomly, but pattern is not
> clear for me at the moment)?

What I was trying to highlight is that if you do a comparison of the files on
disk with the inodes in the database, you'd be able to detect whether there was
corruption whether there was an actual conflict through reuse or not.

If you can detect the corruption more easily, you can then narrow down what is
causing it and which set of files aren't matching.

Cheers,

Richard