BSP Team Bug Triage

From Yocto Project
Jump to: navigation, search

Contents

New Team bugs (No Priority)

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboard
12557nightly-oe-selftest failed for nightly build 849Stephano CetolaNEWnormalUndecided---
 1      
IDSummaryAssigneeStatusProductSeverityPMilestoneWhiteboard
 0       

New BSP bugs (No milestone)

IDSummarySeverityPMilestoneAssigneeStatusWhiteboardE
12557nightly-oe-selftest failed for nightly build 849normalUndecided---Stephano CetolaNEW
 1       
IDSummarySeverityPMilestoneAssigneeStatusWhiteboardE
 0       

High/Medium+ Bugs

IDSummary (12 tasks) SeverityPMilestoneAssigneeStatusWhiteboardE
12544*
12544

Building the same modules in two different folders at two different times results in about 15 different kernel-module-lttng packages having different srcversions (please see the attached file). This makes no sense, as the source code for the modules should be identical, hence the srcversion as well.

This was only observed with meta-intel, without meta-intel the srcversion seems to be always the same.
kernel-module-lttng-xxx contain non-deterministic srcversionnormalMedium+2.1.4Juro BystrickyNEW
12277*
12277 The reasons for the failures are identified in 12277
dbus-test-ptest is brokennormalMedium+2.5 M2Juro BystrickyIN PROGRESS DESIGN1.5
12404*
12404 wic rm does not currently remove directories, nor does it support the -r flag
wic rm should remove directories and support the -r flagnormalMedium+2.5 M3Amber ElliotNEW4
12058*
12058

The only place the error message is issued is in kvm-all.c:

   do {
       ret = kvm_ioctl(s, KVM_CREATE_VM, type);
   } while (ret == -EINTR);
   if (ret < 0) {
       fprintf(stderr, "ioctl(KVM_CREATE_VM) failed: %d %s\n", -ret,
               strerror(-ret));

So the kvm_ioctl(KVM_CREATE_VM,type) fails to allocate the memory.

So this is the kvm_dev_ioctl call from the dmesg. Somewhere within KVM_CREATE_VM we tried to allocate 2**6 pages of contiguous memory and failed.
Qemu fails to start on recent kernels with KVM alloc() failurenormalMedium+2.5 M3Juro BystrickyIN PROGRESS DESIGN3
12300*
12300 Moving to DESIGN phase as I research these tools to properly create documentation.
remove yocto-[bsp|kernel] documentationnormalMedium+2.5 M3Stephano CetolaIN PROGRESS DESIGN4
12338*
12338

openembedded-core/scripts/lib/checklayer/__init__.py uses an undefined LayerError class, which fails when that code path is hit:

Traceback (most recent call last):

 File "/fast/work/intel-iot-refkit/openembedded-core/scripts/yocto-check-layer", line 203, in <module>
   ret =  main()
 File "/fast/work/intel-iot-refkit/openembedded-core/scripts/yocto-check-layer", line 100, in main
   dep_layers = detect_layers(args.dependency, args.no_auto)
 File "/fast/work/intel-iot-refkit/openembedded-core/scripts/lib/checklayer/__init__.py", line 134, in detect_layers
   layer = _detect_layer(root)
 File "/fast/work/intel-iot-refkit/openembedded-core/scripts/lib/checklayer/__init__.py", line 111, in _detect_layer
   layer['collections'] = _get_layer_collections(layer['path'])
 File "/fast/work/intel-iot-refkit/openembedded-core/scripts/lib/checklayer/__init__.py", line 46, in _get_layer_collections
   raise LayerError(exc)

NameError: name 'LayerError' is not defined

I happened to trigger this when adding meta-measured to refkit. meta-measured/conf/layer.conf uses BBPATH := "${BBPATH}:${LAYERDIR}" instead of the normal BBPATH .= ":${LAYERDIR}", and that causes:

Traceback (most recent call last):

 File "/fast/work/intel-iot-refkit/openembedded-core/scripts/lib/checklayer/__init__.py", line 44, in _get_layer_collections
   ldata = bb.parse.handle(lconf, ldata, include=True)
 File "/fast/work/intel-iot-refkit/bitbake/lib/bb/parse/__init__.py", line 117, in handle
   return h['handle'](fn, data, include)
 File "/fast/work/intel-iot-refkit/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 165, in handle
   statements.eval(data)
 File "/fast/work/intel-iot-refkit/bitbake/lib/bb/parse/ast.py", line 36, in eval
   statement.eval(data)
 File "/fast/work/intel-iot-refkit/bitbake/lib/bb/parse/ast.py", line 58, in eval
   bb.parse.ConfHandler.include(self.filename, s, self.lineno, data, "include required")
 File "/fast/work/intel-iot-refkit/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 83, in include
   include_single_file(parentfn, fn, lineno, data, error_out)
 File "/fast/work/intel-iot-refkit/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 94, in include_single_file
   bbpath = "%s:%s" % (dname, data.getVar("BBPATH"))
 File "/fast/work/intel-iot-refkit/bitbake/lib/bb/data_smart.py", line 608, in getVar
   return self.getVarFlag(var, "_content", expand, noweakdefault, parsing)
 File "/fast/work/intel-iot-refkit/bitbake/lib/bb/data_smart.py", line 794, in getVarFlag
   value = self.expand(value, cachename)
 File "/fast/work/intel-iot-refkit/bitbake/lib/bb/data_smart.py", line 436, in expand
   return self.expandWithRefs(s, varname).value
 File "/fast/work/intel-iot-refkit/bitbake/lib/bb/data_smart.py", line 426, in expandWithRefs
   raise ExpansionError(varname, s, exc) from exc

bb.data_smart.ExpansionError: Failure expanding variable BBPATH, expression was ${BBPATH}:/fast/work/intel-iot-refkit/meta-measured which triggered exception Exception: variable BBPATH references itself!

Building with meta-measured is fine, it's just the compat check which fails?
checklayer: undefined LayerErrornormalMedium+2.5 M3Stephano CetolaNEW
12412*
12412 I see that reverting 92e1c7d47e695eb4ce1a863cd0f6c49dca1c2339 does fix the issue, but it also breaks parallel do_image_wic calls. I'd like to find a solution to both issues so I am putting this back into design and pushing off till M3.
WIC: rootfs wrong file ownership on rocko branchnormalMedium+2.5 M3Stephano CetolaIN PROGRESS DESIGNBackport 2.4.2
12495*
12495 This will help moving tasks that used to be covered by Saul.
Add Stephano & Cal to QA Alert EmailsnormalMedium+2.5 M3Stephano CetolaACCEPTED1
12496update dropdowns to include sumonormalMedium+2.5 M3Stephano CetolaACCEPTED1
12517*
12517 and also the help message should not assume/display UID/GID=1000/1000 but display the actual UID/GID.
Update documentation on gen-tapdevs scriptnormalMedium+2.5 M3Stephano CetolaACCEPTED
12408*
12408 Currently just waiting on the patch for 12205 to be accepted, latest version submitted 1/30.
Update wic documentation to remove outdated "help" referencesnormalMedium+FutureAmber ElliotIN PROGRESS IMPLEMENTATION
 11       

NEEDINFO

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboard
 0      

REOPENDED

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboard
 0      

Old Milestone

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboard
 0      

YP 2.5 remaining BSP Team Enhancements

IDSummary (29 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
3343*
3343

Please note that upstream version is 2.8.2: "The latest is 2.8.2, released Dec 14, 2017."

http://people.redhat.com/sgrubb/audit/index.html
perf script: install audit-libs-python to get syscall name for syscall-displaying scriptsAnuj MittalNEWenhancementLow2.52
6278*
6278 See bug#5322
runqemu without /etc/resolv.confJuro BystrickyNEWenhancementMedium2.53
9442*
9442 Moved to 2.2 M2.
Please add virtio console to qemux86-64.confJuro BystrickyIN PROGRESS DESIGNenhancementMedium2.52
9782*
9782

It's a vague bug which needs clarification and splitting into the component parts:

  • opkg should support parallel zlib implementations
  • rpm -- ditto --
  • dpkg -- ditto --
  • Vet sstate to ensure parallel implementations are used
  • Vet fetcher to ensure parallel decompress is used
Moving to 2.3.
Add support for parallel gzip to package creationJuro BystrickyACCEPTEDenhancementMedium2.54
10726*
10726 Returning version to 2.3.
Add a test to verify if oe-pkgdata-util print help when no parameters specifiedAmber ElliotACCEPTEDenhancementMedium2.52
10957*
10957

There is a tool developed for similar purpose: http://git.denx.de/?p=u-boot.git;a=tree;f=tools/binman;h=706dfe34f9557807ffa7eeab80c502145d3cddbc;hb=HEAD

It's tightly coupled with uboot, so probably we can't use it, but we should look at least look at a possibility to reuse it's ideas.
wic: support generating raw flash imagesStephano CetolaIN PROGRESS DESIGNenhancementMedium2.55
11279*
11279

In image.bbclass: get_rootfs_size()

   rootfs_alignment = int(d.getVar('IMAGE_ROOTFS_ALIGNMENT'))
   overhead_factor = float(d.getVar('IMAGE_OVERHEAD_FACTOR'))
   rootfs_req_size = int(d.getVar('IMAGE_ROOTFS_SIZE'))
   rootfs_extra_space = eval(d.getVar('IMAGE_ROOTFS_EXTRA_SPACE'))
   rootfs_maxsize = d.getVar('IMAGE_ROOTFS_MAXSIZE')
   image_fstypes = d.getVar('IMAGE_FSTYPES') or 
   initramfs_fstypes = d.getVar('INITRAMFS_FSTYPES') or 
   initramfs_maxsize = d.getVar('INITRAMFS_MAXSIZE')
ROOTFS_SIZE gets set with the value of the above function.
wic: honor IMAGE_ROOTFS_EXTRA_SPACE et alAmber ElliotNEWenhancementMedium2.51
12018*
12018 The output of bitbake --help should be grouped to make it easier to read. For example showing first the options that a normal user would use (-C --runall etc), then debugging options, then internal flags (or even hide those behind --help-internal?)
Help output should be groupedAmber ElliotNEWenhancementMedium2.5
12217*
12217

Currently, when IMAGE_FSTYPES has f2fs, bitbake fails with:

No IMAGE_CMD defined for IMAGE_FSTYPES entry 'f2fs'.
Support F2FSCalifornia SullivanNEWenhancementMedium2.54
12320*
12320

The multiple-kernel built and deployed in one image from BZ#11363 leads to the next enhancement request: enabling multiple kernels in systemd-boot or grub-efi (or other) boot menu.

This is fairly common in mainline Linux distributions and an increasingly frequent request from our customers, especially during development and integration.

In addition to enabling the multiple kernels, while we are at it we should enable multiple kernel command lines in the menu (different options for the same kernel binary).

An example use case is to compare latency/performance of (1) "standard" (e.g. 4.9.47), (2)"stable preempt_rt" (e.g. 4.9.47-rt37) and (3) "rt-devel" (e.g. 4.13.10-rt3) kernels (different binaries) without and with (4,5,6) debug enabled (command line argument).

The three kernels (1,2,3) should be discoverable at image creation time (using, e.g. KERNEL_PACKAGE_NAME[]) and the boot menu should be able to be "auto" populated. The additional command line argument entries (4,5,6) would clearly need to be manually configured by a different mechanism.
Enable multiple kernels and multiple kernel command lines in systemd-boot, grub-efi menuCalifornia SullivanNEWenhancementMedium2.5
6630*
6630

I also added some comments in https://bugzilla.yoctoproject.org/show_bug.cgi?id=4389, I believe fixing 4389 will also address this one (6630).

In any case, the changes will affect kernel-devsrc (not kernel-dev).
linux-yocto: kernel-dev package does not include target arch scripts binariesJuro BystrickyIN PROGRESS DESIGN COMPLETEenhancementMedium2.5 M23
12128*
12128

(In reply to comment #17) > Just to complete the loop here, there have been various discussions between > the people in question here. > > I believe we now all agree that in high level terms: > > * The Quickstart should become a "Getting Started" which may be slightly > longer

How about "Getting Started With Yocto Project" as a new title?

> * We should tweak the quickstart flow to include setting up and adding your > own local layer for customisations

Get me this information and I will get it in the manual. Keep in mind we do have a section in the dev-manual called "Understanding and Creating Layers" (http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#understanding-and-creating-layers). Is the information different than what is in this section?

> * Some reference to terminology are important for the new user experience as > terminology continues to be something which confuses people.

I can add a reference-like terminology section at the end of the QS. Bear in mind we have a large section of terminology definitions in the current ref-manual (http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-terms). I see no problems with some key terms being duplicated here if the need for them to be local out weighs the inconvenience of double-documenting them. Once practice that is done in the YP doc set is to link to a term's definition when it is introduced.

> * The Getting Started Guide would end with a set of "cross road" pointers > into the specific task based doucmentation about how users may do various > things.

This section is in place but is missing some of the information we want to link to. I need people to actually look and see if the list of "other places" is adequate. I formed the list from what was suggested in Comment 1. Here are the current sections... http://www.yoctoproject.org/docs/2.5/yocto-project-qs/yocto-project-qs.html#qs-guided-examples and http://www.yoctoproject.org/docs/2.5/yocto-project-qs/yocto-project-qs.html#going-beyond-builds

> * There may be two variants of the 'quickstart' piece, one for a container > based CROPS and one for a native Linux version.

I need clarification on this... My understanding is that for a container-based set up the only difference is getting CROPS in there. Presumably, once you have that running, you basically have a native-looking and behaving shell. Once the shell is available, things become exactly like preparing a native Linux machine. Are my assumptions wrong here?

> * We need to move lots of the incidental notes from the quickstart to > improve the flow. (e.g. real hardware like minnow becomes its own section > pointed to by the cross roads pointer, the lists of packages for specific > distros should be in the reference manual in sections, we can point to that > from the quickstart).

If we move the example that builds an image for minnow out of the QS, then are you saying we leave just the example that builds for QEMU?

Also, BTW - we do point to the ref-manual for proper packages needed to set up the host. The ref-manual has always been the definitive location for that information. Right now, we duplicate the "Essential" packages in the QS as part of the "setup" section. So, we are saying here that we don't want that duplication? It is okay to send the user to another manual for that part of the setup? But, we can duplicate terms?

> > The key thing to keep in mind that whilst the quickstart has served us well > for 7-8 years, its time to take a fresh look at it and adapt it to changes

> in the project like layers.
Rework the Quickstart and intro to the manualsStephano CetolaIN PROGRESS DESIGNenhancementMedium2.5 M220
12188*
12188 Building for genericx86 and genericx86-64 should generate a wic image file by default. Also, wic.bmap should be included for faster media creation.
Make wic the default image type for genericx86 and genericx86-64California SullivanACCEPTEDenhancementMedium2.5 M24
4389*
4389

(In reply to comment #22) > Created attachment 4213 [details] > patches being tested.

The approach is on-track, and is what I was considering as well. So we are aligned with that. I'm just glad I didn't go any further with my work before realizing we were looking at the same thing.

I'm going to submit my kernel-devsrc changes early next week (Monday is a holiday here), and after that, you can easily slide these changes on top of my patch into the new package build process.

Did you want a copy of the WIP patch for the new dev-src for testing ?
kernel: Remove "make scripts" requirement for module building from SDK/on targetJuro BystrickyIN PROGRESS DESIGNenhancementMedium+2.5 M25
10073*
10073

With the above branch anything installed to /boot/ ends up in the boot partition with no additional work. It also has multi kernel support thanks to Harris' multi kernel patch.

Some limitations/issues:

  • Must use efi-bootdisk.wks.in as EFI_PROVIDER
  • core-image-minimal doesn't install the preferred kernel to /boot/
  • In other images the preferred kernel ends up in /boot/ twice, once as bzimage and once as its whole name due to my copy function
  • Only systemd-boot and grub-efi bootloaders have packages that install to /boot/ so far
  • live images (with rootfs.img) can't be created with this yet
wic: generic bootloader-agnostic EFI pluginCalifornia SullivanIN PROGRESS IMPLEMENTATIONenhancementMedium+2.5 M25
10987*Use initramfs-framework for initialization by default in OE-CoreCalifornia SullivanIN PROGRESS IMPLEMENTATIONenhancementMedium+2.5 M25
11291*
11291

Agreed that we need to break the bug down more as this is a metabug.

Action taken to file the other bugs!
Don't generate live images for x86California SullivanNEWenhancementMedium+2.5 M21
11018*
11018

This will be built and deployed using LAVA:

http://yp-lava-server.jf.intel.com
Auto deploy and boot meta-intel images built with the ABStephano CetolaIN PROGRESS DESIGNenhancementMedium2.5 M33
12086*
12086 I'm not familiar with autobuilder, can anyone do it, please ?
Create an autobuilder script to test for long path errorsStephano CetolaNEWenhancementMedium2.5 M33
12282*
12282 Various yocto-compat-layer.py tests are skipped for BSP layers when a --machine option isn't passed, investigate yocto-compat-layer.py options to ensure the full potential of the tool can be utilised from the autobuilder.
CheckYoctoCompat buildstep should support additional optionsStephano CetolaACCEPTEDenhancementMedium2.5 M33
10646*
10646

Master now supports/builds Nios2 qemu http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=7f45ea5083b845490bc3db2a449b6e8b71

With the layer meta-altera it is fairly simple to build core-image-minimal (with initramfs) and run this image on 10m50 Altera board (with GHRD FPGA flashed). It is also possible to boot the image via u-boot over Ethernet.

However, moving to 2.5 as some documentation and additional testing is required.
Add support for Altera/Nios2 in qemuJuro BystrickyIN PROGRESS REVIEWenhancementMedium+2.5 M35
11176*
11176 Still in review...
Add optional command to rootfs-postprocess to remove non-determinism from rootfsJuro BystrickyIN PROGRESS REVIEWenhancementMedium+2.5 M33
11177*
11177 There have been some incremental progress. Generally, archive commands (tar, gzip) are scattered all over. Several patches were accepted that fix some of the issues, but there are a few more left. Some patches are still pending/being reviewed in ML. So moving to 2.5 M1 for completion, as more patches are to follow before this can be closed as RESOLVED.
Generate archives with deterministic metadataJuro BystrickyIN PROGRESS DESIGNenhancementMedium+2.5 M32
11178*
11178

Sent patch to the ML: https://patchwork.openembedded.org/patch/143060/

Moving to 2.5 M1, a slightly better version is being tested.
Use SOURCE_DATE_EPOCHJuro BystrickyIN PROGRESS REVIEWenhancementMedium+2.5 M32
11179*
11179

Patch sent to the ML:https://patchwork.openembedded.org/patch/143060/

This being an enhancement, it is unlikely to be merged in 2.4M4, so moving to 2.5M1
Ensure TZ is also set to a consistent valueJuro BystrickyIN PROGRESS REVIEWenhancementMedium+2.5 M31
11775*
11775

perhaps we could check to see if it acts like bash or dash. e.g. if [ "$RANDOM" != "" ]; then

echo "I am bash"

else

echo " I am dash"
fi
oe-init-build-env should check for dash and throw a meaningful errorStephano CetolaIN PROGRESS IMPLEMENTATIONenhancementMedium+2.5 M31
11816*
11816

It should be possible to support secure boot with systemd-boot as the bootloader.

Systemd-boot can be signed, and when in secure boot mode will validate that the kernel is also signed. This is a minimal secure boot implementation, with the downside that the chain of trust only extends as far as the kernel. Neither the initrd or kernel command line will be validated, making it fairly easy to defeat.

There also seems to be recent work getting systemd-boot to work with the shim program, which is prevalent in other secure boot implementations on the Linux side: https://github.com/systemd/systemd/pull/5702/commits/40a2f0684749dffcc2ae076137264354683333d8
secure boot implementation using systemd-boot bootloaderCalifornia SullivanNEWenhancementMedium+2.5 M34
12189*
12189

One of the things you would commonly want to cp into a wic image using wic cp is lib/modules/kernel-version. This would require a recursive copy. e.g.

wic cp modules--4.x.x/ wicimage:/lib/modules/
wic cp should support recursive copiesAmber ElliotNEWenhancementMedium+2.5 M34
12422*
12422

This is an offshoot of https://bugzilla.yoctoproject.org/show_bug.cgi?id=5866

providing a better specified deliverable.

The goal of this enhancement is to build reproducible images for:

$ MACHINE=qemux86 bitbake core-image-minimal


The resulting images of this build are placed in the folder <builddir>/tmp/deploy/images/qemux86

Repeating the build in a different folder will place the images in: <builddir-different>/tmp/deploy/images/qemux86

The build is deemed reproducible if the following files in both build folders are binary identical:

bzImage-qemux86.bin core-image-minimal-qemux86.tar.bz2

modules-qemux86.tgz
Support reproducible build for core-image-minimal imagesJuro BystrickyIN PROGRESS IMPLEMENTATIONenhancementMedium+2.5 M32
 29       

Amber Bugs

IDSummary (9 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
10726*
10726 Returning version to 2.3.
Add a test to verify if oe-pkgdata-util print help when no parameters specifiedAmber ElliotACCEPTEDenhancementMedium2.52
11279*
11279

In image.bbclass: get_rootfs_size()

   rootfs_alignment = int(d.getVar('IMAGE_ROOTFS_ALIGNMENT'))
   overhead_factor = float(d.getVar('IMAGE_OVERHEAD_FACTOR'))
   rootfs_req_size = int(d.getVar('IMAGE_ROOTFS_SIZE'))
   rootfs_extra_space = eval(d.getVar('IMAGE_ROOTFS_EXTRA_SPACE'))
   rootfs_maxsize = d.getVar('IMAGE_ROOTFS_MAXSIZE')
   image_fstypes = d.getVar('IMAGE_FSTYPES') or 
   initramfs_fstypes = d.getVar('INITRAMFS_FSTYPES') or 
   initramfs_maxsize = d.getVar('INITRAMFS_MAXSIZE')
ROOTFS_SIZE gets set with the value of the above function.
wic: honor IMAGE_ROOTFS_EXTRA_SPACE et alAmber ElliotNEWenhancementMedium2.51
11977*
11977 We should print a message to suggest which modules are missing.
bitbake -g -u taskexp <target> raises an import exceptionAmber ElliotNEWminorMedium2.53
12018*
12018 The output of bitbake --help should be grouped to make it easier to read. For example showing first the options that a normal user would use (-C --runall etc), then debugging options, then internal flags (or even hide those behind --help-internal?)
Help output should be groupedAmber ElliotNEWenhancementMedium2.5
12205*
12205

additionally, we need a couple of pattern matchable examples. For instance, the fact that I look at partition 1 but doing $ wic ls myImage.wic:1 is not clear at all, from the help line.

similar for cp and rm
'wic help' / 'wic --help' output is not user friendly. Needs to be redoneAmber ElliotIN PROGRESS REVIEWnormalMedium2.53
12189*
12189

One of the things you would commonly want to cp into a wic image using wic cp is lib/modules/kernel-version. This would require a recursive copy. e.g.

wic cp modules--4.x.x/ wicimage:/lib/modules/
wic cp should support recursive copiesAmber ElliotNEWenhancementMedium+2.5 M34
12404*
12404 wic rm does not currently remove directories, nor does it support the -r flag
wic rm should remove directories and support the -r flagAmber ElliotNEWnormalMedium+2.5 M34
12169*
12169 IoTG is excited about this. They currently scp files off their booted image, but this would be a great help to them sometime in the future. No rush though.
wic cp allows me to cp a file into a wic partition, it should let me cp one out as well.Amber ElliotNEWenhancementLowFuture3
12408*
12408 Currently just waiting on the patch for 12205 to be accepted, latest version submitted 1/30.
Update wic documentation to remove outdated "help" referencesAmber ElliotIN PROGRESS IMPLEMENTATIONnormalMedium+Future
 9       

Anuj Bugs

IDSummary (5 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
3343*
3343

Please note that upstream version is 2.8.2: "The latest is 2.8.2, released Dec 14, 2017."

http://people.redhat.com/sgrubb/audit/index.html
perf script: install audit-libs-python to get syscall name for syscall-displaying scriptsAnuj MittalNEWenhancementLow2.52
2552*
2552 This could be similar to phoronix work also
x32: identify workload & collect benchmark data to show value of x32Anuj MittalNEWnormalLowFuture6
3358*
3358 Have to check what is needed for the rest of the archs.
perf: enable new 'perf trace' toolAnuj MittalNEWenhancementMediumFuture5
3359*
3359 I have a version that doesn't segfault, but doesn't find the debug info it needs. Need to debug further.
perf: add perf-dwarf featureAnuj MittalNEWenhancementMediumFuture5
6119*
6119 Ee Peng, can you please check if this is still an issue and close this if it isn't? I can't reproduce this now on latest.
verify that perf test command worksAnuj MittalNEWnormalMediumFuture5
 5       

Cal Bugs

IDSummary (20 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
10966*
10966 I'm not sure this is needed if we implement bootfs recipes. Lowering severity.
Make the IMAGE_BOOT_FILES interface generally availableCalifornia SullivanNEWminorMedium2.54
11726*
11726

(In reply to comment #1) > Did the keyboard work after the X system finished initializing? > > Can you try a different keyboard?

Keyboard and Mouse are responsive, it doesn't seem to affect the functioning.
[Testimage]Multiple errors present in dmesg_ouput.logCalifornia SullivanNEWnormalMedium2.52
11937*
11937

This module is also getting some other error with NUC and LSB image (2.4 M4 rc1 meta-intel) by using the configuration below.

core-image-lsb-sdk intel-corei7-64


================================================
Build Configuration: BB_VERSION = "1.35.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "x86_64-poky-linux" MACHINE = "intel-corei7-64" DISTRO = "poky-lsb" DISTRO_VERSION = "2.4" TUNE_FEATURES = "m64 corei7" TARGET_FPU = "" meta meta-poky meta-yocto-bsp = "HEAD:65d23bd7986615fdfb0f1717b615534a2a14ab80" meta-intel = "master:863590f9bc7104fef698ce6b89ec24dfce542df1"


===============================================
167 NOTE: test_parselogs (parselogs.ParseLogsTest) 168 NOTE: ... FAIL

........

195 NOTE: ====================================================================== 196 NOTE: FAIL: test_parselogs (parselogs.ParseLogsTest) 197 NOTE: ---------------------------------------------------------------------- 198 NOTE: Traceback (most recent call last): 199 File "/home/jzepeda/2.4rc3/poky/meta/lib/oeqa/core/decorator/__init__.py", ine 32, in wrapped_f 200 return func(*args, **kwargs) 201 File "/home/jzepeda/2.4rc3/poky/meta/lib/oeqa/core/decorator/__init__.py", ine 32, in wrapped_f 202 return func(*args, or fails should be present in logs**kwargs) 203 File "/home/jzepeda/2.4rc3/poky/meta/lib/oeqa/runtime/cases/parselogs.py", ine 363, in test_parselogs 204 self.assertEqual(errcount, 0, msg=self.msg) 205 AssertionError: 262 != 0 : Log: /home/jzepeda/2.4rc3/poky/automated/tmp/work/intel_corei7_64-poky-linux/core-image-lsb-sdk/1.0-r0/access.log

ERROR: core-image-lsb-sdk-1.0-r0 do_testimage: core-image-lsb-sdk - FAILED - check the task log and the ssh log ERROR: core-image-lsb-sdk-1.0-r0 do_testimage: Function failed: do_testimage ERROR: Logfile of failure stored in: /home/jzepeda/2.4rc3/poky/automated/tmp/work/intel_corei7_64-poky-linux/core-image-lsb-sdk/1.0-r0/temp/log.do_testimage.29482 ERROR: Task (/home/jzepeda/2.4rc3/poky/meta/recipes-extended/images/core-image-lsb-sdk.bb:do_testimage) failed with exit code '1'


6954 *********************** 6955 262 errors found in logs.



==========================================================
(The access log contains some public IPs from intel that Im not allowed to attach)

EXPECTED OUTCOME: Errors must not be gotten.

Actual status: FAILED
[Testcase 1059] Parselogs is failing corei7-64-lsb on Cherry Hill giving error: *ERROR* timed out waiting for Punit DDR DVFS requestCalifornia SullivanACCEPTEDnormalMedium2.52
12019*
12019 Practically every distro has moved from -intel to -modesettings because its a better, faster driver. I think we should to.
Use xf86-video-modesettings instead of -intelCalifornia SullivanACCEPTEDnormalMedium2.53
12187*
12187

BUILD: 2.4 M4: rc3-65d23bd7986615fdfb0f1717b615534a2a14ab80 ENVIRONMENT: genericx86-64_NUC NUC Model: NUC6i5SYH IMAGES: core-image-sato-sdk.wic, core-image-sato-sdk.hddimg

The "snd_hda_codec_hdmi" parselog errors continue appearing in 2.4 RC3 on automatic BSP testing for genericx86-64 images in NUC (in both, wic and hddimg formats). For more reference, I have attached the log file with more details about the execution using the hddimg version.

This is an example of the errors that appear:

Central error: [ 1.453224] snd_hda_codec_hdmi: probe of hdaudioC0D2 failed with error -16

[ 1.448566] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y [ 1.449571] snd_hda_intel 0000:00:1f.3: control 3:0:0:ELD:0 is already present [ 1.449609] snd_hda_codec_hdmi: probe of hdaudioC0D2 failed with error -16 [ 1.452014] snd_hda_intel 0000:00:1f.3: Too many HDMI devices [ 1.452015] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y [ 1.452015] snd_hda_intel 0000:00:1f.3: Too many HDMI devices [ 1.452016] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y [ 1.452017] snd_hda_intel 0000:00:1f.3: Too many HDMI devices [ 1.452017] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y [ 1.453193] snd_hda_intel 0000:00:1f.3: control 3:0:0:ELD:0 is already present [ 1.453224] snd_hda_codec_hdmi: probe of hdaudioC0D2 failed with error -16 [ 1.453793] snd_hda_codec_generic hdaudioC0D2: ignore pin 0x7, too many assigned pins [ 1.453795] snd_hda_codec_generic hdaudioC0D2: autoconfig for Generic: line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line [ 1.453796] snd_hda_codec_generic hdaudioC0D2: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 1.453796] snd_hda_codec_generic hdaudioC0D2: hp_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 1.453797] snd_hda_codec_generic hdaudioC0D2: mono: mono_out=0x0 [ 1.453798] snd_hda_codec_generic hdaudioC0D2: dig-out=0x5/0x6 [ 1.453799] snd_hda_codec_generic hdaudioC0D2: inputs: [ 1.455463] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input4 [ 1.455526] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input5

[ 1.455598] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input6
not audio- play (wav) with HDMI, 2.4California SullivanNEWnormalMedium2.53
12214*
12214

For more reference, I found the following old thread on the Ubuntu forums, mentioning CONFIG_USB_SUSPEND as a probable cause for this error.

https://ubuntuforums.org/showthread.php?t=797789
[TC 1059] test_parselogs failed om MMAX64 (Turbot, WIC image) : usb 1-3: device descriptor read/64, error -71California SullivanNEWnormalMedium2.5
12217*
12217

Currently, when IMAGE_FSTYPES has f2fs, bitbake fails with:

No IMAGE_CMD defined for IMAGE_FSTYPES entry 'f2fs'.
Support F2FSCalifornia SullivanNEWenhancementMedium2.54
12224*
12224 Right, does not occur if you use an hddimg instead of wic. Examining the contents the only difference bootloader wise is the syslinux config, so I believe that's where the problem lies.
wic image created for qemux86-64 stalls on undefined video mode number: 318California SullivanNEWnormalMedium2.52
12320*
12320

The multiple-kernel built and deployed in one image from BZ#11363 leads to the next enhancement request: enabling multiple kernels in systemd-boot or grub-efi (or other) boot menu.

This is fairly common in mainline Linux distributions and an increasingly frequent request from our customers, especially during development and integration.

In addition to enabling the multiple kernels, while we are at it we should enable multiple kernel command lines in the menu (different options for the same kernel binary).

An example use case is to compare latency/performance of (1) "standard" (e.g. 4.9.47), (2)"stable preempt_rt" (e.g. 4.9.47-rt37) and (3) "rt-devel" (e.g. 4.13.10-rt3) kernels (different binaries) without and with (4,5,6) debug enabled (command line argument).

The three kernels (1,2,3) should be discoverable at image creation time (using, e.g. KERNEL_PACKAGE_NAME[]) and the boot menu should be able to be "auto" populated. The additional command line argument entries (4,5,6) would clearly need to be manually configured by a different mechanism.
Enable multiple kernels and multiple kernel command lines in systemd-boot, grub-efi menuCalifornia SullivanNEWenhancementMedium2.5
12188*
12188 Building for genericx86 and genericx86-64 should generate a wic image file by default. Also, wic.bmap should be included for faster media creation.
Make wic the default image type for genericx86 and genericx86-64California SullivanACCEPTEDenhancementMedium2.5 M24
10073*
10073

With the above branch anything installed to /boot/ ends up in the boot partition with no additional work. It also has multi kernel support thanks to Harris' multi kernel patch.

Some limitations/issues:

  • Must use efi-bootdisk.wks.in as EFI_PROVIDER
  • core-image-minimal doesn't install the preferred kernel to /boot/
  • In other images the preferred kernel ends up in /boot/ twice, once as bzimage and once as its whole name due to my copy function
  • Only systemd-boot and grub-efi bootloaders have packages that install to /boot/ so far
  • live images (with rootfs.img) can't be created with this yet
wic: generic bootloader-agnostic EFI pluginCalifornia SullivanIN PROGRESS IMPLEMENTATIONenhancementMedium+2.5 M25
10987*Use initramfs-framework for initialization by default in OE-CoreCalifornia SullivanIN PROGRESS IMPLEMENTATIONenhancementMedium+2.5 M25
11291*
11291

Agreed that we need to break the bug down more as this is a metabug.

Action taken to file the other bugs!
Don't generate live images for x86California SullivanNEWenhancementMedium+2.5 M21
10455[morty][Test Case 1059] Parselogs is failing on genericx86 (32 and 64 bits) giving error: blk_update_request: I/O error, dev loop0California SullivanIN PROGRESS DESIGNnormalMedium2.5 M32
11816*
11816

It should be possible to support secure boot with systemd-boot as the bootloader.

Systemd-boot can be signed, and when in secure boot mode will validate that the kernel is also signed. This is a minimal secure boot implementation, with the downside that the chain of trust only extends as far as the kernel. Neither the initrd or kernel command line will be validated, making it fairly easy to defeat.

There also seems to be recent work getting systemd-boot to work with the shim program, which is prevalent in other secure boot implementations on the Linux side: https://github.com/systemd/systemd/pull/5702/commits/40a2f0684749dffcc2ae076137264354683333d8
secure boot implementation using systemd-boot bootloaderCalifornia SullivanNEWenhancementMedium+2.5 M34
9525*
9525 Duplicate of 9525.
Make install prompt available on all consolesCalifornia SullivanACCEPTEDenhancementMedium2.64
11807*
11807 The kernel lets you build firmware into it via the CONFIG_EXTRA_FIRMWARE and CONFIG_EXTRA_FIRMWARE_DIR variables. We should have some way to set and use these variables in a kernel recipe.
kernel tooling should support building in firmwareCalifornia SullivanNEWenhancementMedium2.63.5
12170*
12170

(In reply to comment #0) > The objective of this bug is to examine the viability to add ext2 support to > poky tiny images.

Just to clarify, this bug is to add support for creating/modifying ext partitions on poky-tiny, this will be added via busybox.

While doing this I will also check what other functionality should or may be added to poky-tiny.
Add mkfs.ext support to busybox on poky-tinyCalifornia SullivanIN PROGRESS REVIEWenhancementMedium2.63
8773*
8773

The differences between the two BSP sets are mostly logical right now:

common-pc is a base configuration + virtio configurations + some AMD configurations.

intel-common is common-pc without virtio or AMD configurations, but with many Intel drivers enabled, and with expanded module support.

There are some changes I would like to make, but it would be mostly cosmetic, so I am lowering the priority on this for now.
refactor yocto-kernel-cache common-pc / intel-common scc/cfg file to reduce delta & overlapCalifornia SullivanACCEPTEDenhancementMediumFuture11
 19       

Juro Bugs

IDSummary (48 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
12421*
12421

This is an offshoot of https://bugzilla.yoctoproject.org/show_bug.cgi?id=5866

providing a better specified deliverable.

The goal of this enhancement is to build reproducible packages and images for:

$ MACHINE=qemux86 bitbake core-image-minimal

It is assumed the packages are Debian.

The resulting Debian packages of this build are placed in the folder <builddir>/tmp/deploy/deb Repeating the build in a different folder will place the packages in: <builddir-different>/tmp/deploy/deb

The build is deemed reproducible if all packages in both build folders are binary identical.

This enhancement strongly depends on SOURCE_DATE_EPOCH support.

https://bugzilla.yoctoproject.org/show_bug.cgi?id=11178
Support reproducible build for (Debian) packages built for core-image-minimalJuro BystrickyNEWenhancementMedium+2.1.4
12544*
12544

Building the same modules in two different folders at two different times results in about 15 different kernel-module-lttng packages having different srcversions (please see the attached file). This makes no sense, as the source code for the modules should be identical, hence the srcversion as well.

This was only observed with meta-intel, without meta-intel the srcversion seems to be always the same.
kernel-module-lttng-xxx contain non-deterministic srcversionJuro BystrickyNEWnormalMedium+2.1.4
2655*In /usr/bin/ldd shared library path mentioned multiple times ( RTLDLIST="/lib/ld-linux.so.2 /lib/ld-linux.so.2 )Juro BystrickyIN PROGRESS REVIEWnormalLow2.5
11919*
11919

libcrypto needs some patching to achieve binary reproducibility.

Note (in the attached diffoscope output) that the host environment ends up in the .rodata section. Hopefully stripping the embedded string "compiler: i586-poky-linux-gcc ..." of all host build references will fix all binary reproducibility issues.
libcrypto: improve binary reproducibilityJuro BystrickyACCEPTEDnormalLow2.52.5
12000*
12000

https://autobuilder.yocto.io/builders/nightly-qa-extras/builds/450/steps/BuildImages_3/logs/stdio

/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-extras/build/build/tmp/work/i686-nativesdk-mingw32-pokysdk-mingw32/nativesdk-mingw-w64-runtime/3.1.0-r0/build' | i686-pokysdk-mingw32-gcc -E --sysroot=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-extras/build/build/tmp/work/i686-nativesdk-mingw32-pokysdk-mingw32/nativesdk-mingw-w64-runtime/3.1.0-r0/recipe-sysroot -x c ../mingw-w64-v3.1.0/mingw-w64-crt/lib32/msvcrt.def.in -Wp,-w -I../mingw-w64-v3.1.0/mingw-w64-crt/def-include | /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-extras/build/build/tmp/hosttools/sed 's/^#/;/' >lib32/msvcrt.def

| /bin/bash: lib32/msvcrt.def: No such file or directory
[mingw32] nativesdk-mingw-w64-runtime fails to compileJuro BystrickyNEWnormalLow2.5
12543*
12543

Please see the attached file: diffoscope output of two builds in two different folders at two different times. Notice the host references (build path)). This can be fixed by the patch https://patchwork.openembedded.org/patch/147228/

In order to remove the timestamps from all .pyc files we need to recompile them with python-native, as we cannot rely on the host python being able to do that.

(both python-native and python3-native were patched to derive the timestamp from SOURCE_DATE_EPOCH if present)
(reproducibility) python-xcbgen contains host references and timestampsJuro BystrickyNEWnormalLow2.5reproducibility
6278*
6278 See bug#5322
runqemu without /etc/resolv.confJuro BystrickyNEWenhancementMedium2.53
8582*
8582

(In reply to comment #1) > Juro, do you think this one is fixed with the recent pseudo patch > (http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/ > ?id=7aba4c930e94316a90ada6022792ecb00ff2cf86 )?

Depends how you define "fixed". If this is a pseudo error message, it should now end up in the pseudo error log. As the message explicitly says ERROR:...ignored, something else will eventually break (not being able to install correctly). So not being able to even glimpse the message may actually obfuscate the failed install even more. So IMHO the message should be made more prominent, not less. (Unless the pseudo log is parsed for errors at some point)

Typical error will be something like: (see https://bugzilla.yoctoproject.org/show_bug.cgi?id=8581 )

chown: changing ownership of 'xxx': Operation not permitted

So the root cause of the error is not obvious. However fixing it is quit simple:

set

NO32LIBS = "0"

in local.conf.

Having said this, it is very unlikely anyone will encounter this error with 2.1 and later.
Error message not in log fileJuro BystrickyNEWnormalMedium2.52
9442*
9442 Moved to 2.2 M2.
Please add virtio console to qemux86-64.confJuro BystrickyIN PROGRESS DESIGNenhancementMedium2.52
9782*
9782

It's a vague bug which needs clarification and splitting into the component parts:

  • opkg should support parallel zlib implementations
  • rpm -- ditto --
  • dpkg -- ditto --
  • Vet sstate to ensure parallel implementations are used
  • Vet fetcher to ensure parallel decompress is used
Moving to 2.3.
Add support for parallel gzip to package creationJuro BystrickyACCEPTEDenhancementMedium2.54
11024*
11024 I've a new QA test that spots libtool wrapper scripts, and it appears that lttng-tools is installing libtool wrapper scripts instead of binaries when ptest is enabled.
lttng-tools ships libtool wrappers as ptest binariesJuro BystrickyIN PROGRESS DESIGNnormalMedium2.55
11299*
11299

Having an incorrect/stale record in the database could be in principle caused by sqlite.

So I tried pseudo (Rocko) with modified settings, such as:

"PRAGMA locking_mode = NORMAL;", "PRAGMA busy_timeout = 2000;"

Still observed failures.

I updated sqlite to the latest version (3.21.0)

Still observed failures.


BB_VERSION = "1.37.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "i586-poky-linux" MACHINE = "qemux86" DISTRO = "poky" DISTRO_VERSION = "2.4+snapshot-20171215" TUNE_FEATURES = "m32 i586" TARGET_FPU = "" meta meta-poky

meta-yocto-bsp = "master:b73e96e7f3f5d1ba3a221d99792a7a3c7ef42c21"
glibc-locale warning [host-user-contaminated]Juro BystrickyIN PROGRESS DESIGNnormalMedium2.55
11770*
11770

Preliminary notes: Managed to reproduce all listed problems.

For qemux86/x264 upgrading the recipe for the latest stable version did not fix the problem.

http://git.videolan.org/?p=x264.git;a=shortlog;h=refs/heads/stable
texrels found for x264/libproxy/python3-pycairo for poky-lsbJuro BystrickyACCEPTEDnormalMedium2.53
11802*
11802

So today this happened again. One thing worth mentioning is that I killed a runnning "bitbake core-image-minimal" with CTRL-C running in "konsole".

Moments later I tried to re-run bitbake core-image-minimal and X server crashed practically right away.
system spontaneously logs out while building core-imageJuro BystrickyNEWnormalMedium2.53.14
12061*
12061

Not easy to reproduce.

I would like to close this one, but I still have the failing environment around and I would like to come to the bottom of this.
failed to build eSDKJuro BystrickyNEWnormalMedium2.51
12137*
12137

With the patch in ML we fail "test_kernel_module":

NOTE: core-image-sato-sdk-1.0-r0 do_testimage: FAIL [3.527s]: test_kernel_module (kernelmodule.KernelModuleTest) NOTE: core-image-sato-sdk-1.0-r0 do_testimage: ---------------------------------------------------------------------- NOTE: core-image-sato-sdk-1.0-r0 do_testimage: Traceback (most recent call last):

 File "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/meta/lib/oeqa/core/decorator/__init__.py", line 32, in wrapped_f
   return func(*args, **kwargs)
 File "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/meta/lib/oeqa/core/decorator/__init__.py", line 32, in wrapped_f
   return func(*args, **kwargs)
 File "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/meta/lib/oeqa/core/decorator/__init__.py", line 32, in wrapped_f
   return func(*args, **kwargs)
 File "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/meta/lib/oeqa/runtime/cases/kernelmodule.py", line 40, in test_kernel_module
   self.assertEqual(status, 0, msg='\n'.join([cmd, output]))

AssertionError: 2 != 0 : cd /usr/src/kernel && make scripts

 HOSTCC  scripts/basic/fixdep
 HOSTCC  scripts/kconfig/conf.o
 SHIPPED scripts/kconfig/zconf.tab.c
 SHIPPED scripts/kconfig/zconf.lex.c
 SHIPPED scripts/kconfig/zconf.hash.c
 HOSTCC  scripts/kconfig/zconf.tab.o
 HOSTLD  scripts/kconfig/conf

scripts/kconfig/conf --silentoldconfig Kconfig

      • Configuration file ".config" not found!
      • Please run some configurator (e.g. "make oldconfig" or
      • "make menuconfig" or "make xconfig").

make[2]: *** [scripts/kconfig/Makefile:39: silentoldconfig] Error 1 make[1]: *** [Makefile:548: silentoldconfig] Error 2

make: *** No rule to make target 'include/config/auto.conf', needed by 'scripts'. Stop.
kernel_devsrc: occasional incorrect permissionsJuro BystrickyIN PROGRESS DESIGNnormalMedium2.55
12215*
12215

So because there is now locale fr_FR present, the locale gets tested and the test fails. The locale was not present before, so this is a new test.

It is not quite clear why the test fails, the testing is done by the program "pcretest". Looking at the source code (pcretest.c) I see this will not be a walk in the park, as the this is basically just one giant spaghetti code. (the "test routine" is 2783 lines long!)
ptest-runner libpcre one failedJuro BystrickyACCEPTEDnormalMedium2.52.5
12229*
12229

Just some notes: the failing test is part of bash-ptest suite. This is not a new bug/regression. There are (and have been) several tests failing, but instead of a bulk

"bash-ptest fails" we now file individual individual bug reports for tests that fail.
ptest-runner FAIL: run-lastpipe, 2.4_M4_rc2Juro BystrickyACCEPTEDnormalMedium2.51
12230*
12230

Ptest-runner tests were executed and observing this run-new-exp failures on the results.

POKY : 2.4_M4_r2 COMMIT:da05a01423a60a23cd1073eb0ad3776e5bf4f2a8 HW: NUC 6i5SYH IMAGES: https://autobuilder.yocto.io/pub/releases/yocto-2.4.rc2/machines/genericx86-64/core-image-sato-sdk-ptest-genericx86-64.hddimg

Results Chart table: https://wiki.yoctoproject.org/wiki/Ptest_da05a01423a60a23cd1073eb0ad3776e5bf4f2a8

EXPECTED OUTCOME: The pass rate goes up the percentage


ACTUAL OUTCOME: The pass rate goes up the percentage
==============================
run-new-exp 627c627 < argv[1] = <host(2)[4.4]# > --- > argv[1] = <host(2)[4.4]$ > FAIL: run-new-exp
==============================
note:

full-log in attachment
ptest-runner FAIL: run-new-exp, 2.4_M4_rc2Juro BystrickyACCEPTEDnormalMedium2.51
12231*
12231

Ptest-runner tests were executed and observing this run-vredir failures on the results.

POKY : 2.4_M4_r2 COMMIT:da05a01423a60a23cd1073eb0ad3776e5bf4f2a8 HW: NUC 6i5SYH IMAGES: https://autobuilder.yocto.io/pub/releases/yocto-2.4.rc2/machines/genericx86-64/core-image-sato-sdk-ptest-genericx86-64.hddimg

Results Chart table: https://wiki.yoctoproject.org/wiki/Ptest_da05a01423a60a23cd1073eb0ad3776e5bf4f2a8

EXPECTED OUTCOME: The pass rate goes up the percentage


ACTUAL OUTCOME: The pass rate goes up the percentage


==========================================================================
run-vredir 90,91c90,91 < ./vredir6.sub: line 10: /dev/null: Too many open files < ./vredir6.sub: line 13: /dev/null: Too many open files --- > ./vredir6.sub: redirection error: cannot duplicate fd: Invalid argument > ./vredir6.sub: line 13: /dev/null: Invalid argument FAIL: run-vredir
==========================================================================
note:

full=log in attachent
ptest-bash cases failed in 2.4_M4_rc2, [FAIL: run-vredir]Juro BystrickyACCEPTEDnormalMedium2.51
12478*ldd_2.26: non-deterministic buildJuro BystrickyIN PROGRESS REVIEWminorMedium2.5
12480*libc6-dbg: non deterministic build (multilib)Juro BystrickyIN PROGRESS REVIEWnormalMedium2.5
12493*
12493

https://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/1277/steps/Running%20Sanity%20Tests/logs/stdio shows confusing output from qemurunner.py:

NOTE: recipe core-image-sato-sdk-1.0-r0: task do_testimage: Failed ERROR: Task (/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/meta/recipes-sato/images/core-image-sato-sdk.bb:do_testimage) failed with exit code '1' ERROR: core-image-minimal-1.0-r0 do_testimage: Didn't receive a console connection from qemu. Here is the qemu command line used: powerpc-poky-linux-gcc -mno-spe -fuse-ld=bfd -ffile-prefix-map=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ppc-lsb/build/build/tmp/work-shared/qemuppc/kernel-source=/kernel-source/ -Wp,-MD,arch/powerpc/mm/.mmap.o.d -nostdinc -isystem /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ppc-lsb/build/build/tmp/work/qemuppc-poky-linux/linux-yocto/4.9.65+gitAUTOINC+4553798a3e_5174e51fa0-r0/recipe-sysroot-native/usr/bin/powerpc-poky-linux/../../lib/powerpc-poky-linux/gcc/powerpc-poky-linux/7.2.0/include -I/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ppc-lsb/build/build/tmp/work-shared/qemuppc/kernel-source/arch/powerpc/include -I./arch/powerpc/include/generated/uapi -I./arch/powerpc/include/generated -I/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ppc-lsb/build/build/tmp/work-shared/qemuppc/kernel-source/include -I./include -I/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ppc-lsb/build/build/tmp/work-shared/qemuppc/kernel-source/arch/powerpc/include/uapi -I/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ppc-lsb/build/build/tmp/work-shared/qemuppc/kernel-source/include/uapi -I./include/generated/uapi -include /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ppc-lsb/build/build/tmp/work-shared/qemuppc/kernel-source/include/linux/kconfig.h -I/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ppc-lsb/build/build/tmp/work-shared/qemuppc/kernel-source/arch/powerpc/mm -Iarch/powerpc/mm -D__KERNEL__ -I/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ppc-lsb/build/build/tmp/work-shared/qemuppc/kernel-source/arch/powerpc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -msoft-float -pipe -I/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ppc-lsb/build/build/tmp/work-shared/qemuppc/kernel-source/arch/powerpc -ffixed-r2 -mmultiple -mno-altivec -mno-vsx -mno-spe -mspe=no -funit-at-a-time -fno-dwarf2-cfi-asm -mno-string -mcpu=powerpc -mno-sched-epilog -Wa,-maltivec -mbig-endian -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -O2 --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-var-tracking-assignments -g -pg -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Werror -DKBUILD_BASENAME="mmap" -DKBUILD_MODNAME="mmap" -c -o arch/powerpc/mm/mmap.o /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ppc-lsb/build/build/tmp/work-shared/qemuppc/kernel-source/arch/powerpc/mm/mmap.c and output from runqemu: runqemu - INFO - Continuing with the following parameters:

runqemu - INFO - Using preconfigured tap device tap0 runqemu - INFO - If this is not intended, touch /tmp/qemu-tap-locks/tap0.skip to make runqemu skip tap0. runqemu - INFO - Network configuration: 192.168.7.2::192.168.7.1:255.255.255.0 runqemu - INFO - Running /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-i386 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -drive file=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/build/tmp/deploy/images/qemux86/core-image-minimal-qemux86.ext4,if=virtio,format=raw -vga vmware -show-cursor -usb -device usb-tablet -device virtio-rng-pci -serial tcp:127.0.0.1:38655 -pidfile pidfile_23574 -cpu pentium2 -enable-kvm -m 256 -serial tcp:127.0.0.1:39061 -snapshot -kernel /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/build/tmp/deploy/images/qemux86/bzImage--4.12.18+git0+b66a4f9730_558fe84d69-r0.2-qemux86-20180116144236.bin -append 'root=/dev/vda rw highres=off clocksource=kvm-clock hpet=disable noapic nolapic mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1 console=tty1 console=ttyS0,115200n8 printk.time=1'

runqemu - ERROR - Failed to run qemu: ioctl(KVM_CREATE_VM) failed: 12 Cannot allocate memory qemu-system-i386: failed to initialize KVM: Cannot allocate memory

runqemu - INFO - Releasing lockfile for tap device 'tap0'

I suspect that qemu exits immediately (or quickly) yet the timeout doesn't notice and the pid was recycled so the commandline is a ppc compile command instead. We should fix it to detect early exits from qemu and not display confusing commandlines.
Confusing output when qemu fails to run.Juro BystrickyNEWnormalMedium2.5
12516e2fsprogs: POT-​Creation-​Date removed non-deterministicallyJuro BystrickyNEWnormalMedium2.5reproducible
12523*
12523 Please see the attached diffoscope output. Build host build directory path is present in various places. (Possibly other build host leaks as well)
(reproducibility) python3-gpg contains build host referencesJuro BystrickyNEWnormalMedium2.5
12524*
12524

autoconf-doc package contains autoconf.info. This file contains date when this file was created, i.e. "This manual (31 January 2018) .."

Therefore, two builds done on two different dates will embed different dates, hence breaking reproducibility. The date is obtained from mtime of "autoconf.texi", unfortunately we patch this file and change the mtime as a consequence. The remedy would be to set the mtime to SOURCE_DATE_EPOCH, as preserving the mtime of a file we explicitly modified by patching would hide/mislead the fact the file was truly modified.
(reproducibility) autoconf-info contains build dateJuro BystrickyIN PROGRESS DESIGN COMPLETEnormalMedium2.5reproducibility
12525*
12525 Please see the attached diffoscope output. Build host build directory path is present in various places. (Possibly other build host leaks as well)
(reproducibility) python3-iniparse contains build host referencesJuro BystrickyNEWnormalMedium2.5reproducibility
12526*
12526 Seems configuring with "with_build_date=xxx" can solve this.
(reproducibility) jpeg-tools, libjpeg62 contain build dateJuro BystrickyIN PROGRESS IMPLEMENTATIONnormalMedium2.5reproducibility
12528(reproducibility) systemtap_3.2, systemtap-dbg_3.2 contains build host referencesJuro BystrickyNEWnormalMedium2.5reproducibility
6630*
6630

I also added some comments in https://bugzilla.yoctoproject.org/show_bug.cgi?id=4389, I believe fixing 4389 will also address this one (6630).

In any case, the changes will affect kernel-devsrc (not kernel-dev).
linux-yocto: kernel-dev package does not include target arch scripts binariesJuro BystrickyIN PROGRESS DESIGN COMPLETEenhancementMedium2.5 M23
4389*
4389

(In reply to comment #22) > Created attachment 4213 [details] > patches being tested.

The approach is on-track, and is what I was considering as well. So we are aligned with that. I'm just glad I didn't go any further with my work before realizing we were looking at the same thing.

I'm going to submit my kernel-devsrc changes early next week (Monday is a holiday here), and after that, you can easily slide these changes on top of my patch into the new package build process.

Did you want a copy of the WIP patch for the new dev-src for testing ?
kernel: Remove "make scripts" requirement for module building from SDK/on targetJuro BystrickyIN PROGRESS DESIGNenhancementMedium+2.5 M25
12277*
12277 The reasons for the failures are identified in 12277
dbus-test-ptest is brokenJuro BystrickyIN PROGRESS DESIGNnormalMedium+2.5 M21.5
10646*
10646

Master now supports/builds Nios2 qemu http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=7f45ea5083b845490bc3db2a449b6e8b71

With the layer meta-altera it is fairly simple to build core-image-minimal (with initramfs) and run this image on 10m50 Altera board (with GHRD FPGA flashed). It is also possible to boot the image via u-boot over Ethernet.

However, moving to 2.5 as some documentation and additional testing is required.
Add support for Altera/Nios2 in qemuJuro BystrickyIN PROGRESS REVIEWenhancementMedium+2.5 M35
11176*
11176 Still in review...
Add optional command to rootfs-postprocess to remove non-determinism from rootfsJuro BystrickyIN PROGRESS REVIEWenhancementMedium+2.5 M33
11177*
11177 There have been some incremental progress. Generally, archive commands (tar, gzip) are scattered all over. Several patches were accepted that fix some of the issues, but there are a few more left. Some patches are still pending/being reviewed in ML. So moving to 2.5 M1 for completion, as more patches are to follow before this can be closed as RESOLVED.
Generate archives with deterministic metadataJuro BystrickyIN PROGRESS DESIGNenhancementMedium+2.5 M32
11178*
11178

Sent patch to the ML: https://patchwork.openembedded.org/patch/143060/

Moving to 2.5 M1, a slightly better version is being tested.
Use SOURCE_DATE_EPOCHJuro BystrickyIN PROGRESS REVIEWenhancementMedium+2.5 M32
11179*
11179

Patch sent to the ML:https://patchwork.openembedded.org/patch/143060/

This being an enhancement, it is unlikely to be merged in 2.4M4, so moving to 2.5M1
Ensure TZ is also set to a consistent valueJuro BystrickyIN PROGRESS REVIEWenhancementMedium+2.5 M31
12058*
12058

The only place the error message is issued is in kvm-all.c:

   do {
       ret = kvm_ioctl(s, KVM_CREATE_VM, type);
   } while (ret == -EINTR);
   if (ret < 0) {
       fprintf(stderr, "ioctl(KVM_CREATE_VM) failed: %d %s\n", -ret,
               strerror(-ret));

So the kvm_ioctl(KVM_CREATE_VM,type) fails to allocate the memory.

So this is the kvm_dev_ioctl call from the dmesg. Somewhere within KVM_CREATE_VM we tried to allocate 2**6 pages of contiguous memory and failed.
Qemu fails to start on recent kernels with KVM alloc() failureJuro BystrickyIN PROGRESS DESIGNnormalMedium+2.5 M33
12422*
12422

This is an offshoot of https://bugzilla.yoctoproject.org/show_bug.cgi?id=5866

providing a better specified deliverable.

The goal of this enhancement is to build reproducible images for:

$ MACHINE=qemux86 bitbake core-image-minimal


The resulting images of this build are placed in the folder <builddir>/tmp/deploy/images/qemux86

Repeating the build in a different folder will place the images in: <builddir-different>/tmp/deploy/images/qemux86

The build is deemed reproducible if the following files in both build folders are binary identical:

bzImage-qemux86.bin core-image-minimal-qemux86.tar.bz2

modules-qemux86.tgz
Support reproducible build for core-image-minimal imagesJuro BystrickyIN PROGRESS IMPLEMENTATIONenhancementMedium+2.5 M32
5695*
5695

Looking at the log file, looks like several tests fail due to a know issue related to the default encoding used in Yocto-build images ('utf-8') being different from the assumed 'ascii' by the tests (see bug 10522). This will no longer be the case after 2.5 M1 milestone, when manifest patches that remove the mentioned default encoding are scheduled to be implemented.

Among others, the following are in this case (UnicodeEncodeError not raised):

test_hasattr test_0_args_with_overridden___str__ test_1_arg test_1_arg_with_overridden___str__ test_many_args_with_overridden___str__ test_unicode test_output_htmlcalendar test_with_marshal

that said, it would be worth testing with the default encoding set to 'ascii' to verify this.
python: ptest cases failedJuro BystrickyNEWnormalLowFuture
8097*Build Appliance: Missing splash screenJuro BystrickyNEWnormalLowFuture2
8583*
8583 Meant to say hard-coded paths (not links).
strace shows accesses in non-existent location.Juro BystrickyIN PROGRESS DESIGNminorLowFuture 2
3999*
3999

Darren,

Ok - thanks. So when the bug is resolved the yocto-kernel script will provide new information to the user.

Thanks
provide description and compatibility data with kern-features.rcJuro BystrickyIN PROGRESS DESIGNenhancementMediumFuture2
5087*
5087 Reference documentation about timekeeping in vmWare VMs.
Sometimes building under BA can fail due to make utility reporting timestamps anomaliesJuro BystrickyNEWnormalMediumFuture5
5421*
5421 Once multiconfig interdependencies work, this should be implementable.
Support multiple MACHINE installs per SDKJuro BystrickyNEWenhancementMediumFuture
9885*
9885

I'm afraid this is not possible, or at least it is not trivial. There are dozens of header files that are needed. As we cannot distribute the extracted files, the onus of extraction is put up the user. meta-darwin layer README contains the instructions on how to do this. However, it is possible there is an alternative out there somewhere in the open source community (similar to mingw, which provide their own set of header files

in order not to infringe on MS copyright). I am not aware of anything like that, though.
[meta-darwin] remove dependency on Mac OS SDK components which aren't distributableJuro BystrickyNEWenhancementMediumFuture
11348*Create demo showing Yocto built FPGA image in actionJuro BystrickyNEWenhancementMediumFuture5
 47       

Stephano Bugs

IDSummary (2 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
11018*
11018

This will be built and deployed using LAVA:

http://yp-lava-server.jf.intel.com
Auto deploy and boot meta-intel images built with the ABStephano CetolaIN PROGRESS DESIGNenhancementMedium2.5 M33
5841*
5841 I suspect this has something to do with the VERB table provided by firmware as the driver reads that for configuration data. Some additional investigation is warranted though. Marking as low priority as the audio does play.
Minnow: hda-intel: Invalid position bufferStephano CetolaNEWnormalLowFuture
 2       

Saul Bugs

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboardE
 0       

Bruce Bugs

IDSummary (23 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
12535*kernel-devsrc do_package takes unreasonably long timeBruce AshfieldIN PROGRESS IMPLEMENTATIONnormalMedium2.1.4
12430*
12430

root@qemux86-64:~# uname -a Linux qemux86-64 4.9.71-rt18-yocto-preempt-rt #1 SMP PREEMPT RT Sat Dec 23 23:46:40 EST 2017 x86_64 GNU/Linux root@qemux86-64:~# zcat /proc/config.gz | grep -i aufs CONFIG_AUFS_FS=y CONFIG_AUFS_BRANCH_MAX_127=y

  1. CONFIG_AUFS_BRANCH_MAX_511 is not set
  2. CONFIG_AUFS_BRANCH_MAX_1023 is not set
  3. CONFIG_AUFS_BRANCH_MAX_32767 is not set

CONFIG_AUFS_SBILIST=y

  1. CONFIG_AUFS_HNOTIFY is not set
  2. CONFIG_AUFS_EXPORT is not set
  3. CONFIG_AUFS_XATTR is not set
  4. CONFIG_AUFS_FHSM is not set
  5. CONFIG_AUFS_RDU is not set
  6. CONFIG_AUFS_DIRREN is not set
  7. CONFIG_AUFS_SHWH is not set
  8. CONFIG_AUFS_BR_RAMFS is not set
  9. CONFIG_AUFS_BR_FUSE is not set

CONFIG_AUFS_BDEV_LOOP=y

  1. CONFIG_AUFS_DEBUG is not set
root@qemux86-64:~#
linux-yocto_4.9 (pyro): aufs fails to buildBruce AshfieldIN PROGRESS REVIEWnormalMedium+2.3.41
6986*
6986 I'm holding onto this one.
linux-yocto do_patch fails with a long working directory pathBruce AshfieldIN PROGRESS DESIGNnormalMedium2.52
12482*
12482

Perf can be optionally build with many features:

Auto-detecting system features: ... dwarf: [ on ] ... dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ OFF ] ... libaudit: [ OFF ] ... libbfd: [ on ] ... libelf: [ on ] ... libnuma: [ OFF ] ... numa_num_possible_cpus: [ OFF ] ... libperl: [ on ] ... libpython: [ on ] ... libslang: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ... libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ OFF ] ... bpf: [ on ]


The perf recipe has partial PACKAGECONFIG feature support.

Investigate and if needed add support for libaudit, *numa*, get_cpuid.
perf: Add PACKAGECONFIGs for auto-detected features such as libauditBruce AshfieldACCEPTEDenhancementMedium2.53
7646*
7646 Moving to M3.
KBUILD_DEFCONFIG does not work if config file is created as a result of patch to be appliedBruce AshfieldIN PROGRESS IMPLEMENTATIONenhancementMedium2.5 M23
9813*
9813 Still no cycles. moving to m4.
Strange kernel image for qemumips and qemumips64 in deploy directoryBruce AshfieldIN PROGRESS DESIGNnormalMedium2.5 M21
10962*
10962

Marking this as accepted, and putting 4 days in as an estimate.

I also put m3 as the milestone, but it will more than likely get pushed out of the 2.3 release unless someone grabs this from me.
device tree compiler does not support @ to compile overlayBruce AshfieldACCEPTEDnormalMedium2.5 M24
12034*
12034 There are additional failures with qemuppc with bug #12183 and bug #12209
backtrace in dmesg on qemuppc with 4.9Bruce AshfieldIN PROGRESS DESIGNnormalMedium+2.5 M25
12290*
12290

Given current events on the mailing list ('kernel: Add support for multiple kernel packages'), I am postponing doing anything here for now, as this touches similar places.

I have a slightly better understanding of the issues now, tough. And it's slightly different than described originally in comment #0.

One of my recipes is kernel-module-mac80211.bb, which builds more than one kernel module, each for different hardware. Let's call one of those modules ralink.ko.

One important thing I didn't mention before is that I have KERNEL_MODULES_META_PACKAGE = "". I need this, because the recipe name corresponds to a helper kernel module created during the build, and there is no main kernel module as such which could serve as the recipe name.


Firstly, I need to add extra RDEPENDS to some of the automatically splitted packages. This stopped working, as my RDEPENDS_${PN} = "crda" has no effect anymore. RDEPENDS_${PN}${KERNEL_MODULE_PACKAGE_SUFFIX} = "crda" would work, if it didn't cause checksum hash mismatch errors.


Secondly, because of KERNEL_MODULES_META_PACKAGE="" I get an empty package with the name of the recipe with no additional dependencies, kernel-module-mac80211. Previously, that package contained mac80211.ko, but now mac80211.ko is moved to the kernel-module-mac80211${KERNEL_MODULE_PACKAGE_SUFFIX} package. So during image creation the empty package is installed.

Given the kernel-module-mac80211${KERNEL_MODULE_PACKAGE_SUFFIX} package does RPROVIDE kernel-module-mac80211, the issue is creation of the kernel-module-mac80211 package due to ALLOW_EMPTY_${PN} in module.bbclass.


I think I have an idea for how to solve these.
cross recipe kernel module dependency generation stopped workingBruce AshfieldACCEPTEDnormalMedium+2.5 M2Backport 2.3.3 and 2.4.1?2
8191*
8191

... and clearing the date again.

I'm not sure why there's so much mucking happening with these cases.
apply kernel config fragments to arbitrary kernelsBruce AshfieldACCEPTEDenhancementHigh2.5 M32
6022*
6022

Moving to 2.1, since this is impacted by the split of the meta data out of the kernel tree. We need that to settle, and then can much more easily to this. But squeezing it all into the same

release is a stretch.
kernel-dev: How do I know which features are available for KERNEL_FEATURES ?Bruce AshfieldIN PROGRESS DESIGN COMPLETEenhancementMedium2.5 M32
8743*
8743 This will change with the enablement of fragments for more kernel variants. So moving to 2.5, but it may be fixed with 2.4 (and I'll update accordingly then).
configme --allnoconfig breaks defconfig generated with kconfig / make savedefconfigBruce AshfieldIN PROGRESS IMPLEMENTATIONnormalMedium2.5 M33
9069*
9069 I won't have cycles for this. If someone else grabs it, I won't complain.
perf: missing python modules for scripts in 'perf report'Bruce AshfieldIN PROGRESS REVIEWnormalMedium2.5 M34
9656*NFS boot failed due No working init found kernel panic on qemuBruce AshfieldACCEPTEDnormalMedium2.5 M32
12283*
12283

Building a fitImage that include an initramfs force the kernel to depends on rootfs. This in turn cause rebuilding anything on any change.

For example, if the image is not included, building an out-of-tree kernel module require pretty much just building the kernel + the module. Yet, when you enable fitImage, building the same out-of-tree kernel module force re-building all the user space application as well.

Also, the image creation, fit or wic should not be kernel specific. The code found in kernel-fitimage.bbclass create an ITS file and then call uboot-mkimage. There is nothing there that is kernel specific.

This code should be done within the image recipe, once the kernel uImage and the rootfs has been built, as is other image type.

Now I understand that if INITRAMFS_IMAGE_BUNDLE is set to 1 that the kernel need to be involved, but when INITRAMFS_IMAGE_BUNDLE is set to 0, there are no valid reason to have the kernel create the image itself instead of the image recipe creating the image and removing that kernel/rootfs dependency.
Building a fitImage including INITRAMFS_IMAGE (wo/ BUNDLE) cause the kernel to depend on rootfs which is badBruce AshfieldACCEPTEDnormalMedium2.5 M33
12027*
12027

Ah yes.

I did find the old conversations on this topic, buried in a gcc6 upgrade thread! And one where I offered some options during the release of the 4.8 tree. We talked about shallow clones and references (actually my preference) in those threads.

We've had a "linux-yocto" tree on git.yoctoproject.org for nearly a year now, which I asked to be created to work on this in the background.

Getting reference clones is obviously more challenging since the code doesn't exist, but during the next release, I'll look at leveraging the shallow clone support and then see what would really be needed for reference clones.

(In reply to comment #2) > I believe shallow clone functionality is in bitbake already thanks for > patches from Chris. I did ask for documentation patches, I don't think I > ever got any :(. > > http://git.yoctoproject.org/cgit.cgi/poky/log/?qt=grep&q=shallow shows the > patches in question. > > The other option would be a "clone by reference" setup where we have a > common repo for kernels which we then clone the individuals from. That

> functionality obviously doesn't exist.
Merge linux-yocto git trees to a single one to reduce download times and mirror sizesBruce AshfieldACCEPTEDenhancementMedium+2.5 M34
12228*
12228 Thanks for the comments. I'm back on this now and will do some tweaks before posting a new version
Race between do_make_sccripts() and recipes using the scripts it createsBruce AshfieldIN PROGRESS IMPLEMENTATIONnormalMedium+2.5 M3
12487*
12487 I can tighten up the regex for this.
kernel-yocto: configuration fragment with defconfig in name is garbled.Bruce AshfieldIN PROGRESS REVIEWnormalMedium+2.5 M31
1924*
1924 Waiting For Upstream status is being removed, changing to Accepted.
[LTP] 'vma01' case failed on non-x86 platforms with Yocto 1.2 M2 rc1Bruce AshfieldACCEPTEDnormalMediumFuture
2267*
2267 bumping to 1.9, since this can't make the feature freeze for 1.8.
Integrate DISTRO_FEATURES with KERNEL_FEATURESBruce AshfieldIN PROGRESS DESIGN COMPLETEenhancementMediumFuture25
5305*
5305

The use case was a developer asking on #yocto how to extend a kernel with a custom driver and export it's UAPI.

I could not tell from the current situation or documentation how to perform this cleanly.

Consider this a duplicate of 5305.
Make sanitized kernel headers availableBruce AshfieldIN PROGRESS IMPLEMENTATIONenhancementMediumFuture 3
9480*
9480

It doesn't work currently:

MACHINE = "qemuarm64" DEFAULTTUNE = "aarch64_be"

$ bitbake linux-yocto


aarch64_be-poky-linux-ld.bfd: usr/initramfs_data.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file usr/initramfs_data.o make[3]: *** [usr/built-in.o] Error 1

 CC      kernel/exec_domain.o

make[2]: *** [usr] Error 2 make[2]: *** Waiting for unfinished jobs....

 OBJCOPY arch/arm64/kernel/vdso/vdso.so
 VDSOSYM arch/arm64/kernel/vdso/vdso-offsets.h
 CC      security/keys/keyring.o
 CC      kernel/panic.o
 CC      kernel/cpu.o
 AS      arch/arm64/kernel/vdso/vdso.o
 CC      kernel/exit.o
 CC      kernel/softirq.o
 LD      security/integrity/integrity.o
 CC      kernel/resource.o

aarch64_be-poky-linux-ld.bfd: security/integrity/iint.o: compiled for a little endian system and target is big endian CC fs/open.o

aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file security/integrity/iint.o make[4]: *** [security/integrity/integrity.o] Error 1 make[3]: *** [security/integrity] Error 2 make[3]: *** Waiting for unfinished jobs....

[snip]

 LD      arch/arm64/mm/built-in.o

aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/dma-mapping.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/dma-mapping.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/extable.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/extable.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/fault.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/fault.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/init.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/init.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/cache.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/cache.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/copypage.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/copypage.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/flush.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/flush.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/ioremap.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/ioremap.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/mmap.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/mmap.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/pgd.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/pgd.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/mmu.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/mmu.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/context.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/context.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/proc.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/proc.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/pageattr.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/pageattr.o make[3]: *** [arch/arm64/mm/built-in.o] Error 1 make[2]: *** [arch/arm64/mm] Error 2

 CC      fs/exec.o
[snip]
linux-yocto: make it work with arm big endianBruce AshfieldACCEPTEDenhancementMediumFuture 7
 22       
Personal tools