BSP Team Bug Triage

From Yocto Project
Jump to: navigation, search

Contents

New Team bugs (No Priority)

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboard
 0      
IDSummaryAssigneeStatusSeverityPMilestoneWhiteboard
 0      

New BSP bugs (No milestone)

IDSummarySeverityPMilestoneAssigneeStatusWhiteboardE
 0       
IDSummarySeverityPMilestoneAssigneeStatusWhiteboardE
 0       

High/Medium+ Bugs

IDSummary (8 tasks) SeverityPMilestoneAssigneeStatusWhiteboardE
12278*
12278 I believe Saul sent some patches addressing this. I will verify.
lttng-modules fails do_fetch/do_compilenormalMedium+2.3.3California SullivanNEW0.5
12346*meta-intel: ISO installer silently fails to install if booted in legacy modemajorHigh2.4.1California SullivanACCEPTED1.5
11648*
11648

(In reply to comment #5) > (In reply to comment #4) > > I'm exploring the possibility to use the compiler itself to process macros. > > > > I completely agree with this, while we could parse the output of the script > and get rid of the "junk", letting the compiler take care of it would be a > better approach in my opinion, but we first need to evaluate if its worth > it, my point being that if its not a lot of junk and its easy to identify > what part of the generated file is correct it might just be easier to parse > it ourselves and clean it up depending on the build configuration, if it > proves to be rather difficult to identify these parts then its likely a > better solution would be to use the compiler for this, since we already know > its gonna do it correctly. > > Also, it might be worth investigating how others solve this problem (there's > no need to reinvent the wheel), any distro with multilib builds would have > this sort of problem, or perhaps theres something documented on > http://bugs.python.org

I ran some tests using the compiler to preprocess the headers. It does not look a good option. The IN.PY file generated after the preprocessing have important differences from the non-preprocessed IN.PY. It can be a source of incompatibilities from all the different scenarios where the IN.PY file is used. Also depending on the compiler used in cross-compilations the results might diverge in different ways.

I follow your advice and looked for the current status of this issue in the Python rooms and I found the following tickets:

Title: Cross compilation fails in regen http://bugs.python.org/issue28018

Title: fix running regen in cross http://bugs.python.org/issue17031 builds

Title: h2py.py: search the multiarch include dir if it does exist http://bugs.python.org/issue17029

They are aware of different issues with cross-compilation with the regen/h2py.py processes. Issue 28018 follow up this issues. In Python 3.6 and 3.7 regen is not used anymore, so they are not following up these issues in Python 3.5 (last version using regen). Personally I don't think there is value pursuing to fix the regen scripts since it seems to be a well known restriction for Python 3.5 and below.

I will move this ticket to "Won't do". Let me know if someone feels it is still needed to fix for Python 3.5 and below.
python doesn't parse multilib headers wellnormalMedium+2.5Alejandro HernandezACCEPTED3
11513*
11513 Integrated with the new manifest, but the changes were moved to 2.5 per Richard's request.
Python3 isn't multilib compatiblenormalMedium+2.5 M1Alejandro HernandezIN PROGRESS REVIEW2
12162*
12162

I thought those lines would do the trick:

  1. Let's try an in-tree defconfig:

KERNEL_DEFCONFIG_imx6q-phytec-mira-rdk-nand-bsp ?= "multi_v7_defconfig" KBUILD_DEFCONFIG_imx6q-phytec-mira-rdk-nand-bsp ?= "multi_v7_defconfig"

KCONFIG_MODE="--alldefconfig"
ERROR: do_kernel_metadata: Could not locate BSP definitionnormalMedium+2.5 M1Alejandro HernandezNEW
12111*
12111

Explains why I didn't hit it - I was using the install-efi.sh script rather than the install.sh script.

Your change looks sane, I'll verify and send a patch, unless you want to.
GRUB2 menuconfig is not getting generated for genericx86 ISO imagemajorMedium+2.5 M1California SullivanACCEPTED1.5
11714*
11714 I know have the hardware here, and have been attempting to reproduce the issue and have not been able to.
Intel AC 7260 Bluetooth interface stops responding after disabling BluetoothnormalMedium+2.5 M1Saul WoldIN PROGRESS IMPLEMENTATION3
10713*
10713 7887 merged now.
Allow testimage to work with slirp in addition to working with tun/tapnormalMedium+2.5 M1Todor MinchevACCEPTED3
 8       

NEEDINFO

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboard
 0      

REOPENDED

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboard
 0      

Old Milestone

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboard
12278*
12278 I believe Saul sent some patches addressing this. I will verify.
lttng-modules fails do_fetch/do_compileCalifornia SullivanNEWnormalMedium+2.3.3
 1      

YP 2.4 remaining BSP Team Enhancements

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboardE
 0       

Alejandro Bugs

IDSummary (12 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
11648*
11648

(In reply to comment #5) > (In reply to comment #4) > > I'm exploring the possibility to use the compiler itself to process macros. > > > > I completely agree with this, while we could parse the output of the script > and get rid of the "junk", letting the compiler take care of it would be a > better approach in my opinion, but we first need to evaluate if its worth > it, my point being that if its not a lot of junk and its easy to identify > what part of the generated file is correct it might just be easier to parse > it ourselves and clean it up depending on the build configuration, if it > proves to be rather difficult to identify these parts then its likely a > better solution would be to use the compiler for this, since we already know > its gonna do it correctly. > > Also, it might be worth investigating how others solve this problem (there's > no need to reinvent the wheel), any distro with multilib builds would have > this sort of problem, or perhaps theres something documented on > http://bugs.python.org

I ran some tests using the compiler to preprocess the headers. It does not look a good option. The IN.PY file generated after the preprocessing have important differences from the non-preprocessed IN.PY. It can be a source of incompatibilities from all the different scenarios where the IN.PY file is used. Also depending on the compiler used in cross-compilations the results might diverge in different ways.

I follow your advice and looked for the current status of this issue in the Python rooms and I found the following tickets:

Title: Cross compilation fails in regen http://bugs.python.org/issue28018

Title: fix running regen in cross http://bugs.python.org/issue17031 builds

Title: h2py.py: search the multiarch include dir if it does exist http://bugs.python.org/issue17029

They are aware of different issues with cross-compilation with the regen/h2py.py processes. Issue 28018 follow up this issues. In Python 3.6 and 3.7 regen is not used anymore, so they are not following up these issues in Python 3.5 (last version using regen). Personally I don't think there is value pursuing to fix the regen scripts since it seems to be a well known restriction for Python 3.5 and below.

I will move this ticket to "Won't do". Let me know if someone feels it is still needed to fix for Python 3.5 and below.
python doesn't parse multilib headers wellAlejandro HernandezACCEPTEDnormalMedium+2.53
8730*
8730 Done, but moving to 2.5 per Richard's request
separate code generating python manifest file from manifest information and improve the manifest generationAlejandro HernandezIN PROGRESS IMPLEMENTATIONenhancementMedium2.5 M18
11510*
11510 Done, but moving to 2.5 per Richard's request.
Improve the way we handle python's packaging (autopackaging)Alejandro HernandezIN PROGRESS REVIEWenhancementMedium2.5 M1LET6
11694*
11694 Donde, but moving to 2.5 per Richard's request
Python JSON manifest should be parsed directly by bitbakeAlejandro HernandezIN PROGRESS REVIEWenhancementMedium2.5 M1LET7
11695*
11695 Done but moving to 2.5, per Richard's request
Add task to create python manifest(s) automaticallyAlejandro HernandezIN PROGRESS REVIEWenhancementMedium2.5 M1LET7
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-tinyAlejandro HernandezACCEPTEDenhancementMedium2.5 M13
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-64Alejandro HernandezACCEPTEDenhancementMedium2.5 M14
11513*
11513 Integrated with the new manifest, but the changes were moved to 2.5 per Richard's request.
Python3 isn't multilib compatibleAlejandro HernandezIN PROGRESS REVIEWnormalMedium+2.5 M12
12162*
12162

I thought those lines would do the trick:

  1. Let's try an in-tree defconfig:

KERNEL_DEFCONFIG_imx6q-phytec-mira-rdk-nand-bsp ?= "multi_v7_defconfig" KBUILD_DEFCONFIG_imx6q-phytec-mira-rdk-nand-bsp ?= "multi_v7_defconfig"

KCONFIG_MODE="--alldefconfig"
ERROR: do_kernel_metadata: Could not locate BSP definitionAlejandro HernandezNEWnormalMedium+2.5 M1
3253*
3253 I wrote recipes for eibnetmux and zlogger so, if a repository is create for this layer I can share this recipes.
adding home automation layer to yoctoAlejandro HernandezNEWenhancementLowFuture
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 failedAlejandro HernandezNEWnormalLowFuture
5660*
5660 I retested this today, aside form the fact that cirrus did work using fbdev for me, everything else is as stated, bottom point: weston -Bdrm-backend.so doesnt work using any driver, I will try an see what other options we have.
Weston doesn't work properly on qemuAlejandro HernandezACCEPTEDenhancementMediumFuture7
 12       

Cal Bugs

IDSummary (19 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
12278*
12278 I believe Saul sent some patches addressing this. I will verify.
lttng-modules fails do_fetch/do_compileCalifornia SullivanNEWnormalMedium+2.3.30.5
12346*meta-intel: ISO installer silently fails to install if booted in legacy modeCalifornia SullivanACCEPTEDmajorHigh2.4.11.5
9267*
9267

I whitelisted this for genericx86-64, but my fix for meta-intel did not work.

Essentially I wanted to build the firmware into an intiramfs, and ship the kernel with the initramfs built in.

The INITRAMFS_IMAGE_BUNDLE and INITRAMFS_IMAGE variables do indeed create an initramfs/kernel bundle, but they appear to not be put into the images, as there is a large size discrepancy between the kernel that ends up in the image and the initramfs bzImage that gets created and put in the deploy directory.

I am able to hack kernel.bbclass to use the initramfs bundle if INITRAMFS_IMAGE_BUNDLE is set, but now I'm running into different kernel panics depending on what init I include in the initramfs.

This could take a bit longer...
test_parselogs (oeqa.runtime.parselogs.ParseLogsTest) failed on NUC 6i5SYH, firmware load for i915/skl_guc_ver4.bin failedCalifornia SullivanIN PROGRESS DESIGNnormalMedium2.53
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
11837*
11837 Given the information I have currently, I will be removing MGA and AST from meta-intel completely and from the XSERVER config early in 2.5
XSERVER uses xf86-video-mga from meta-oe instead of meta-intelCalifornia SullivanNEWnormalMedium2.51
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
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
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 M12
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.5 M13.5
10987*
10987 Initramfs framework has been enabled in meta-intel and is getting tested with the meta-intel bsp, should be able to generally enable this for oe-core and meta-yocto-bsps
Use initramfs-framework for initialization by default in OE-CoreCalifornia SullivanIN PROGRESS IMPLEMENTATIONenhancementMedium+2.5 M15
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 M14
12111*
12111

Explains why I didn't hit it - I was using the install-efi.sh script rather than the install.sh script.

Your change looks sane, I'll verify and send a patch, unless you want to.
GRUB2 menuconfig is not getting generated for genericx86 ISO imageCalifornia SullivanACCEPTEDmajorMedium+2.5 M11.5
9525*
9525 Duplicate of 9525.
Make install prompt available on all consolesCalifornia SullivanACCEPTEDenhancementMedium2.5 M24
4389*
4389 I meant to mark this as M+ yesterday, so the High is invalid
kernel: Remove "make scripts" requirement for module building from SDK/on targetCalifornia SullivanACCEPTEDenhancementMedium+2.5 M25
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
 18       

Saul Bugs

IDSummary (34 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
10827*
10827 moving to 2.4
Run oe-selftest -r wic for every patch coming to openembedded-core, poky and bidbake-devel listsSaul WoldIN PROGRESS IMPLEMENTATIONenhancementMedium2.5LET7
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 imagesSaul WoldIN PROGRESS DESIGNenhancementMedium2.55
10966*
10966 I'm not sure this is needed if we implement bootfs recipes. Lowering severity.
Make the IMAGE_BOOT_FILES interface generally availableSaul WoldNEWminorMedium2.54
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 alSaul WoldNEWenhancementMedium2.51
11280*
11280 Often, a user will want to gather a set of artifacts (filesystems, binaries, etc) and place those at different locations in a disk image. Obviously these offsets would be needed, as would the locations of the artifacts.
wic: set arbitrary artifacts to arbitrary locations on a disk imageSaul WoldNEWenhancementMedium2.55
11386*
11386

(In reply to comment #1) > Hey Anibal, > > Is this working on poky?, because at first sight we dont set CONFIG_KEXEC > anywhere for poky either.

Yes, it works using poky and as you mention there is a need to enable CONFIG_KEXEC into the kernel in a separate step.

Anibal
kexec-tools doesn't work with poky-tinySaul WoldACCEPTEDnormalMedium2.55
12091*
12091

Currently wic supports the "--ondisk" parameter to have fstab entries automatically generated. This though is quite problematic when the there are multiple disks on the same subsystem, think of a board with multiple SD card readers and / or eMMC: the same image could be put in mmcblk0, mmcblk1 or mmcblk2. Same goes for USB / Sata disk on sda, sdb, etc.

Alternative mounting ways are now supported (by label, by gpt-label, by UUID): https://wiki.archlinux.org/index.php/Fstab#Identifying_filesystems

It would be easier if wic could give more freedom to the developer, maybe allowing him to just freely enter the string for the <device> field for the fstab.

Think of: wic ... --device="LABEL=/recovery" ...

Afterall --ondisk is not currently used that much, it's just ignored for boot and root partitions.
wic support more mounting optionSaul WoldNEWenhancementMedium2.55
12118*
12118

Preconditions/Environment


1) Add mete-intel layer 2) Modified local.conf to use the following setting

MACHINE ??= "intel-corei7-64"
TCLIBC="musl"
DEFAULTTUNE = "corei7-64-x32"

Triggering Action/Cause


bitbake

Expectation


do_compile task failed.
muslx32: webkitgtk compilation errorSaul WoldNEWenhancementMedium2.5
12119*
12119

When the following line is added to meta/recipes-support/boost/boost.inc, the issue is no longer present:

BJAM_OPTS_append_linux-muslx32 = " abi=x32 address-model=64"

Patch with the potential fix:

http://lists.openembedded.org/pipermail/openembedded-core/2017-November/144277.html
muslx32: boost compilation errorSaul WoldNEWenhancementMedium2.5
12120*
12120

Preconditions/Environment


1) Add mete-intel layer 2) Modified local.conf to use the following setting

MACHINE ??= "intel-corei7-64"
TCLIBC="musl"
DEFAULTTUNE = "corei7-64-x32"

Triggering Action/Cause


bitbake gdb

Expectation


do_compile task failed.
muslx32: gdb compilation errorSaul WoldNEWenhancementMedium2.5
12121*
12121

Preconditions/Environment


1) Add mete-intel layer 2) Modified local.conf to use the following setting

MACHINE ??= "intel-corei7-64"
TCLIBC="musl"
DEFAULTTUNE = "corei7-64-x32"

Triggering Action/Cause


bitbake qat16

Expectation


do_compile task failed.
muslx32: qat16 compilation errorSaul WoldNEWenhancementMedium2.5
12122*
12122

Preconditions/Environment


1) Add mete-intel layer 2) Modified local.conf to use the following setting

MACHINE ??= "intel-corei7-64"
TCLIBC="musl"
DEFAULTTUNE = "corei7-64-x32"

Triggering Action/Cause


bitbake systemd-boot

Expectation


do_compile task failed.
muslx32: systemd-boot compilation errorSaul WoldNEWenhancementMedium2.5
12123*
12123

Preconditions/Environment


1) Add mete-intel layer 2) Modified local.conf to use the following setting

MACHINE ??= "intel-corei7-64"
TCLIBC="musl"
DEFAULTTUNE = "corei7-64-x32"

Triggering Action/Cause


bitbake acpica

Expectation


do_compile task failed.
muslx32: acpica compilation errorSaul WoldNEWenhancementMedium2.5
12137*
12137

The package kernel-devsrc built at various times (from scratch) can contain files that have different permissions (see the attached diffoscope file). This has been observed several times, and seems always the same files are affected:

include/config/auto.conf include/config/auto.conf.cmd include/config/tristate.conf generated/autoconf.h

So probably a race...
kernel_devsrc: occasional incorrect permissionsSaul WoldACCEPTEDnormalMedium2.55
12304*
12304

If we see this bug again, we need to save the workdir to preserve various files, it seems that the get_rootfs_size() might have returned a bad value, but we can't understand why based on the available output.

I am sending a patch to provide some of this needed information into the log output.
nightly-oe-selftest failing on do_image_ext4 stepSaul WoldIN PROGRESS REVIEWnormalMedium2.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 menuSaul WoldNEWenhancementMedium2.5
10073*
10073

Assigning to Saul for experiments.

The idea is to take this further and make bootfs populated by the recipe. I tried to do that, but failed to find a way to make unique partition UUID generated in the recipe and synchronise it with wic. It was not easy even in my initial implementation (I did it in .bbclass by merging 2 tasks into one: http://lists.openembedded.org/pipermail/openembedded-core/2017-June/138204.html)

Please, reassign back to me when you find out how we should proceed further.
wic: generic bootloader-agnostic EFI pluginSaul WoldIN PROGRESS DESIGNenhancementMedium+2.5 M15
11363*
11363

The first part of support for this has been occurring in a thread on oe-core mailing list. The latest installment is:

http://lists.openembedded.org/pipermail/openembedded-core/2017-November/144031.html

Please test this approach and give feedback. I performed a simple qemux86 build with the following in my local.conf:

PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" KERNEL_PACKAGE_NAME_pn-linux-yocto-rt = "rt-linux" KERNEL_PACKAGE_NAME_pn-linux-yocto-tiny = "tiny-linux" CORE_IMAGE_EXTRA_INSTALL = "rt-linux tiny-linux"

The resulting bzImages were in /boot as expected: bzImage -> bzImage-4.12.12-yocto-standard bzImage-4.12.12-yocto-preempt-rt

bzImage-4.12.12-yocto-tiny
Support building and deploying multiple kernels for a single imageSaul WoldIN PROGRESS REVIEWenhancementMedium+2.5 M1LET15
11714*
11714 I know have the hardware here, and have been attempting to reproduce the issue and have not been able to.
Intel AC 7260 Bluetooth interface stops responding after disabling BluetoothSaul WoldIN PROGRESS IMPLEMENTATIONnormalMedium+2.5 M13
6630*
6630 Cycles are questionable to get to this. If someone else can look into it, that would be great.
linux-yocto: kernel-dev package does not include target arch scripts binariesSaul WoldIN PROGRESS DESIGNenhancementMedium2.5 M23
11880*
11880 Accepting this. But it is unlikely that I'll have cycles for it this release. putting to m4, since this would be a stabilization fix.
kernel-devsrc: multiple System.map files present in kernel-build-artifactsSaul WoldACCEPTEDnormalMedium2.5 M22
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 x86Saul WoldNEWenhancementMedium+2.5 M21
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 copiesSaul WoldNEWenhancementMedium+2.5 M24
2394*
2394 Tom, moving to 1.5. Please target, prioritize, and accept as appropriate.
Yocto BSP Tools: add 'publish' support for the kernelSaul WoldACCEPTEDenhancementLowFuture10
2552*
2552 This could be similar to phoronix work also
x32: identify workload & collect benchmark data to show value of x32Saul WoldNEWnormalLowFuture6
9451*
9451 This is a cookbook topic for the wiki.
Document a cookbook procedure on how to change kernel versionSaul WoldACCEPTEDnormalLowFuture2
11281*
11281 If host tools and/or DEPLOY_DIR is not available, wic should still be able to create images. For example, a docker container is essentially a rootfs and some json metadata. Wic should be able to assemble these together without building the bootloader or kernel, as those are not needed in this case.
wic: should be able to run with or without bitbake/native toolsSaul WoldNEWenhancementLowFuture7
11424*
11424 The requirement for tinification/ smaller kernel size has waned, if we need to bring this back alive later we can.
poky-tiny + Link Time OptimizationSaul WoldACCEPTEDenhancementLowFutureLET20
12169*
12169

wic cp bzImage foo.wic:1/bzImage works :) wic cp foo.wic:1/bzImage . wic cp foo.wic:1/bzImage bzImage

fail :(

wic cp: error: argument dest: /big/src/myBugs/RUN/AMBER/build/at.deny is not a regular file or symlink
wic cp allows me to cp a file into a wic partition, it should let me cp one out as well.Saul WoldNEWenhancementLowFuture3
12190*
12190

I managed to completely take down my entire linux system (not just a terminal) while doing some combination of the wic (cp,ls,rm) actions.

Tried and failed to replicate it, even when running the above in a script loop.

after the crash, it said: bash: /big/src/myBugs/poky/scripts/wic: /usr/bin/env: bad interpreter: Input/output error

Mostly here in case i, or others, experience this in the future.
unreproduceable total system crash while doing wic cp,wic rm, wic lsSaul WoldNEWnormalLowFuture4
3358*
3358 Have to check what is needed for the rest of the archs.
perf: enable new 'perf trace' toolSaul WoldNEWenhancementMediumFuture5
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 featureSaul WoldNEWenhancementMediumFuture5
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.rcSaul WoldIN PROGRESS DESIGNenhancementMediumFuture2
6119*
6119

(In reply to comment #10) > Moving to 1.7. And note that qemu is explicitly *not* included.

Hi Tom, Darren,

Do you need any more investigation from QA on this?
verify that perf test command worksSaul WoldNEWnormalMediumFuture5
 34       

Swee Aun Bugs

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboardE
 0       

Todor Bugs

IDSummary (19 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
10084*
10084 This task depends on a wic plugin which can deploy non-bootloader-specific data to ESP, like a generic EFI wic plugin tracked in 10073
RMC: Deploy central database file without dependency on EFI bootloaderTodor MinchevNEWenhancementMedium2.55
11030*
11030 Attached the script mentioned in comment #9
RMC: systemd-boot EFI stub: Don't read RMC db in SecureBoot modeTodor MinchevIN PROGRESS REVIEWnormalMedium2.51
11531*
11531 When running in non-secure boot context, RMC should be able to add the fingerprint of the current board to the data store. The fingerprint generation function will be shared between EFI and userspace contexts.
RMC: [EFI] Add register board with data store functionality (non-secure boot)Todor MinchevNEWenhancementMedium2.55
11534*
11534

Parse the tasks file and process the tasks defined in it. The only supported task at present is CP (copy a file from the datastore to a target location).

Example TASKS file:

FP=123456789ABCDEFG

  CP SRC_FILE TARGET_FILE


If the board fingerprint is 123456789ABCDEFG execute task "CP SRC_FILE TARGET_FILE".
RMC: [EFI] Process tasks in TASKS fileTodor MinchevNEWenhancementMedium2.55
11535*
11535

When running in secure boot mode, RMC.efi has to verify the integrity of the data store. This involves generating and MD5 hash over the contents of the data store and comparing it to the MD5 has stored in the RMC.efi PE header (last field in data directories).

https://en.wikipedia.org/wiki/Portable_Executable#/media/File:Portable_Executable_32_bit_Structure_in_SVG_fixed.svg

If the system is running in secure boot mode and the two hashes do not match the boot process should be terminated with an appropriate message to the user.
RMC: [EFI] Verify data store integrity (secure boot)Todor MinchevNEWenhancementMedium2.55
11538*
11538

This should be something like (-b for bless):

./rmc -b -d data_store_dir -f RMC.efi
RMC: Bless data storeTodor MinchevNEWenhancementMedium2.55
11539*
11539

Verity that the MD5 hash stored in the RMC.efi PE header matches the MD5 hash generated over contents of the data store.

Example:

./rmc -v -d data_store_dir -f RMC.efi
RMC: Verify RMC.efi is properly blessedTodor MinchevNEWenhancementMedium2.55
11540*
11540

Print the contents of an existing fingerprint file - both the SMBIOS strings stored in the file and the MD5 hash corresponding to these strings.

Example:

./rmc -p -f FILE.fp
RMC: Print fingerprint file contentsTodor MinchevNEWenhancementMedium2.53
11543*
11543 RMC should be able to add the fingerprint of the current board to the data store. The fingerprint generation function will be shared between EFI and userspace contexts.
RMC: Register board with data storeTodor MinchevNEWenhancementMedium2.55
11629*
11629 Add a T&T article for a Yocto Poky image that can be booted on a de10-nano on the HPS arm SOC. This is so we can detail how to build and run a Poky image in addition to the default Angstrom one that is the current default.
document in tips and tricks how to bring up a de10-nano altera HPS with Yocto PokyTodor MinchevNEWenhancementMedium2.53
12217*
12217

Currently, when IMAGE_FSTYPES has f2fs, bitbake fails with:

No IMAGE_CMD defined for IMAGE_FSTYPES entry 'f2fs'.
Support F2FSTodor MinchevNEWenhancementMedium2.54
11537*
11537

RMC should provide an option to return the fingerprint of the current board in MD5 format.

Example:

./rmc --fp

will return b2c1a220edd348efb0108e8c98e9a28d .
RMC: Get board fingerprintTodor MinchevIN PROGRESS IMPLEMENTATIONnormalMedium2.5 M15
11544*
11544 Parse CONFIG file and enable verbosity if DEBUG=1 is found.
RMC: Add debug optionTodor MinchevACCEPTEDenhancementMedium2.5 M12
11545*
11545

Parse CONFIG file and store RMC log to file if

LOG=/path/to/log is found.
RMC: Add log optionTodor MinchevNEWenhancementMedium2.5 M13
10713*
10713 7887 merged now.
Allow testimage to work with slirp in addition to working with tun/tapTodor MinchevACCEPTEDnormalMedium+2.5 M13
11532*
11532

Parse CONFIG file and store RMC.efi log to file if

LOG=/path/to/log is found.
RMC: [EFI] Add log optionTodor MinchevNEWenhancementMedium2.5 M22
11533*
11533 Parse CONFIG file and enable verbosity if DEBUG=1 is found.
RMC: [EFI] Add debug optionTodor MinchevNEWenhancementMedium2.5 M22
10085RMC: move RMC feature out of meta-intelTodor MinchevNEWenhancementLowFuture
10988*
10988 The file deployment in RMCv2 won't rely on INSTALLER.CONFIG. Marking this as future so we can remove the current RMC-specific code from the installer script after RMCv2 is fully functional.
RMC: Create and use an initramfs-framework module for RMCTodor MinchevNEWnormalLowFuture7
 19       

Wei Tee Bugs

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboardE
 0       

Bruce Bugs

IDSummary (20 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
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.52
6986*
6986 I'm holding onto this one.
linux-yocto do_patch fails with a long working directory pathBruce AshfieldIN PROGRESS DESIGNnormalMedium2.52
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 AshfieldNEWnormalMedium2.5
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 AshfieldNEWnormalMedium+2.5Backport 2.3.3 and 2.4.1?
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 M15
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 M1
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
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
11288*
11288 I can accept this, but will have to find the cycles to look at it in the next week or so.
X Server fails to start on qemuarm64 (need CONFIG_FB?)Bruce AshfieldIN PROGRESS DESIGNnormalMedium+2.5 M32
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
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 IMPLEMENTATIONenhancementMediumFuture3
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 AshfieldACCEPTEDenhancementMediumFuture7
 19       

Saul's play area

IDSummary (9 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
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 imagesSaul WoldIN PROGRESS DESIGNenhancementMedium2.55
10966*
10966 I'm not sure this is needed if we implement bootfs recipes. Lowering severity.
Make the IMAGE_BOOT_FILES interface generally availableSaul WoldNEWminorMedium2.54
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 alSaul WoldNEWenhancementMedium2.51
11280*
11280 Often, a user will want to gather a set of artifacts (filesystems, binaries, etc) and place those at different locations in a disk image. Obviously these offsets would be needed, as would the locations of the artifacts.
wic: set arbitrary artifacts to arbitrary locations on a disk imageSaul WoldNEWenhancementMedium2.55
12091*
12091

Currently wic supports the "--ondisk" parameter to have fstab entries automatically generated. This though is quite problematic when the there are multiple disks on the same subsystem, think of a board with multiple SD card readers and / or eMMC: the same image could be put in mmcblk0, mmcblk1 or mmcblk2. Same goes for USB / Sata disk on sda, sdb, etc.

Alternative mounting ways are now supported (by label, by gpt-label, by UUID): https://wiki.archlinux.org/index.php/Fstab#Identifying_filesystems

It would be easier if wic could give more freedom to the developer, maybe allowing him to just freely enter the string for the <device> field for the fstab.

Think of: wic ... --device="LABEL=/recovery" ...

Afterall --ondisk is not currently used that much, it's just ignored for boot and root partitions.
wic support more mounting optionSaul WoldNEWenhancementMedium2.55
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 copiesSaul WoldNEWenhancementMedium+2.5 M24
11281*
11281 If host tools and/or DEPLOY_DIR is not available, wic should still be able to create images. For example, a docker container is essentially a rootfs and some json metadata. Wic should be able to assemble these together without building the bootloader or kernel, as those are not needed in this case.
wic: should be able to run with or without bitbake/native toolsSaul WoldNEWenhancementLowFuture7
12169*
12169

wic cp bzImage foo.wic:1/bzImage works :) wic cp foo.wic:1/bzImage . wic cp foo.wic:1/bzImage bzImage

fail :(

wic cp: error: argument dest: /big/src/myBugs/RUN/AMBER/build/at.deny is not a regular file or symlink
wic cp allows me to cp a file into a wic partition, it should let me cp one out as well.Saul WoldNEWenhancementLowFuture3
12190*
12190

I managed to completely take down my entire linux system (not just a terminal) while doing some combination of the wic (cp,ls,rm) actions.

Tried and failed to replicate it, even when running the above in a script loop.

after the crash, it said: bash: /big/src/myBugs/poky/scripts/wic: /usr/bin/env: bad interpreter: Input/output error

Mostly here in case i, or others, experience this in the future.
unreproduceable total system crash while doing wic cp,wic rm, wic lsSaul WoldNEWnormalLowFuture4
 9       
IDSummary (7 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
12118*
12118

Preconditions/Environment


1) Add mete-intel layer 2) Modified local.conf to use the following setting

MACHINE ??= "intel-corei7-64"
TCLIBC="musl"
DEFAULTTUNE = "corei7-64-x32"

Triggering Action/Cause


bitbake

Expectation


do_compile task failed.
muslx32: webkitgtk compilation errorSaul WoldNEWenhancementMedium2.5
12119*
12119

When the following line is added to meta/recipes-support/boost/boost.inc, the issue is no longer present:

BJAM_OPTS_append_linux-muslx32 = " abi=x32 address-model=64"

Patch with the potential fix:

http://lists.openembedded.org/pipermail/openembedded-core/2017-November/144277.html
muslx32: boost compilation errorSaul WoldNEWenhancementMedium2.5
12120*
12120

Preconditions/Environment


1) Add mete-intel layer 2) Modified local.conf to use the following setting

MACHINE ??= "intel-corei7-64"
TCLIBC="musl"
DEFAULTTUNE = "corei7-64-x32"

Triggering Action/Cause


bitbake gdb

Expectation


do_compile task failed.
muslx32: gdb compilation errorSaul WoldNEWenhancementMedium2.5
12121*
12121

Preconditions/Environment


1) Add mete-intel layer 2) Modified local.conf to use the following setting

MACHINE ??= "intel-corei7-64"
TCLIBC="musl"
DEFAULTTUNE = "corei7-64-x32"

Triggering Action/Cause


bitbake qat16

Expectation


do_compile task failed.
muslx32: qat16 compilation errorSaul WoldNEWenhancementMedium2.5
12122*
12122

Preconditions/Environment


1) Add mete-intel layer 2) Modified local.conf to use the following setting

MACHINE ??= "intel-corei7-64"
TCLIBC="musl"
DEFAULTTUNE = "corei7-64-x32"

Triggering Action/Cause


bitbake systemd-boot

Expectation


do_compile task failed.
muslx32: systemd-boot compilation errorSaul WoldNEWenhancementMedium2.5
12123*
12123

Preconditions/Environment


1) Add mete-intel layer 2) Modified local.conf to use the following setting

MACHINE ??= "intel-corei7-64"
TCLIBC="musl"
DEFAULTTUNE = "corei7-64-x32"

Triggering Action/Cause


bitbake acpica

Expectation


do_compile task failed.
muslx32: acpica compilation errorSaul WoldNEWenhancementMedium2.5
2552*
2552 This could be similar to phoronix work also
x32: identify workload & collect benchmark data to show value of x32Saul WoldNEWnormalLowFuture6
 7       
IDSummary (18 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
10827*
10827 moving to 2.4
Run oe-selftest -r wic for every patch coming to openembedded-core, poky and bidbake-devel listsSaul WoldIN PROGRESS IMPLEMENTATIONenhancementMedium2.5LET7
11386*
11386

(In reply to comment #1) > Hey Anibal, > > Is this working on poky?, because at first sight we dont set CONFIG_KEXEC > anywhere for poky either.

Yes, it works using poky and as you mention there is a need to enable CONFIG_KEXEC into the kernel in a separate step.

Anibal
kexec-tools doesn't work with poky-tinySaul WoldACCEPTEDnormalMedium2.55
12137*
12137

The package kernel-devsrc built at various times (from scratch) can contain files that have different permissions (see the attached diffoscope file). This has been observed several times, and seems always the same files are affected:

include/config/auto.conf include/config/auto.conf.cmd include/config/tristate.conf generated/autoconf.h

So probably a race...
kernel_devsrc: occasional incorrect permissionsSaul WoldACCEPTEDnormalMedium2.55
12304*
12304

If we see this bug again, we need to save the workdir to preserve various files, it seems that the get_rootfs_size() might have returned a bad value, but we can't understand why based on the available output.

I am sending a patch to provide some of this needed information into the log output.
nightly-oe-selftest failing on do_image_ext4 stepSaul WoldIN PROGRESS REVIEWnormalMedium2.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 menuSaul WoldNEWenhancementMedium2.5
10073*
10073

Assigning to Saul for experiments.

The idea is to take this further and make bootfs populated by the recipe. I tried to do that, but failed to find a way to make unique partition UUID generated in the recipe and synchronise it with wic. It was not easy even in my initial implementation (I did it in .bbclass by merging 2 tasks into one: http://lists.openembedded.org/pipermail/openembedded-core/2017-June/138204.html)

Please, reassign back to me when you find out how we should proceed further.
wic: generic bootloader-agnostic EFI pluginSaul WoldIN PROGRESS DESIGNenhancementMedium+2.5 M15
11363*
11363

The first part of support for this has been occurring in a thread on oe-core mailing list. The latest installment is:

http://lists.openembedded.org/pipermail/openembedded-core/2017-November/144031.html

Please test this approach and give feedback. I performed a simple qemux86 build with the following in my local.conf:

PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" KERNEL_PACKAGE_NAME_pn-linux-yocto-rt = "rt-linux" KERNEL_PACKAGE_NAME_pn-linux-yocto-tiny = "tiny-linux" CORE_IMAGE_EXTRA_INSTALL = "rt-linux tiny-linux"

The resulting bzImages were in /boot as expected: bzImage -> bzImage-4.12.12-yocto-standard bzImage-4.12.12-yocto-preempt-rt

bzImage-4.12.12-yocto-tiny
Support building and deploying multiple kernels for a single imageSaul WoldIN PROGRESS REVIEWenhancementMedium+2.5 M1LET15
11714*
11714 I know have the hardware here, and have been attempting to reproduce the issue and have not been able to.
Intel AC 7260 Bluetooth interface stops responding after disabling BluetoothSaul WoldIN PROGRESS IMPLEMENTATIONnormalMedium+2.5 M13
6630*
6630 Cycles are questionable to get to this. If someone else can look into it, that would be great.
linux-yocto: kernel-dev package does not include target arch scripts binariesSaul WoldIN PROGRESS DESIGNenhancementMedium2.5 M23
11880*
11880 Accepting this. But it is unlikely that I'll have cycles for it this release. putting to m4, since this would be a stabilization fix.
kernel-devsrc: multiple System.map files present in kernel-build-artifactsSaul WoldACCEPTEDnormalMedium2.5 M22
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 x86Saul WoldNEWenhancementMedium+2.5 M21
2394*
2394 Tom, moving to 1.5. Please target, prioritize, and accept as appropriate.
Yocto BSP Tools: add 'publish' support for the kernelSaul WoldACCEPTEDenhancementLowFuture10
9451*
9451 This is a cookbook topic for the wiki.
Document a cookbook procedure on how to change kernel versionSaul WoldACCEPTEDnormalLowFuture2
11424*
11424 The requirement for tinification/ smaller kernel size has waned, if we need to bring this back alive later we can.
poky-tiny + Link Time OptimizationSaul WoldACCEPTEDenhancementLowFutureLET20
3358*
3358 Have to check what is needed for the rest of the archs.
perf: enable new 'perf trace' toolSaul WoldNEWenhancementMediumFuture5
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 featureSaul WoldNEWenhancementMediumFuture5
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.rcSaul WoldIN PROGRESS DESIGNenhancementMediumFuture2
6119*
6119

(In reply to comment #10) > Moving to 1.7. And note that qemu is explicitly *not* included.

Hi Tom, Darren,

Do you need any more investigation from QA on this?
verify that perf test command worksSaul WoldNEWnormalMediumFuture5
 18       
IDSummaryAssigneeStatusSeverityPMilestoneWhiteboard
 0      
IDSummary (83 tasks) AssigneeStatusSeverityPMilestoneWhiteboard
2394Yocto BSP Tools: add 'publish' support for the kernelSaul WoldACCEPTEDenhancementLowFuture
2552x32: identify workload & collect benchmark data to show value of x32Saul WoldNEWnormalLowFuture
3253adding home automation layer to yoctoAlejandro HernandezNEWenhancementLowFuture
3358perf: enable new 'perf trace' toolSaul WoldNEWenhancementMediumFuture
3359perf: add perf-dwarf featureSaul WoldNEWenhancementMediumFuture
3999provide description and compatibility data with kern-features.rcSaul WoldIN PROGRESS DESIGNenhancementMediumFuture
4389kernel: Remove "make scripts" requirement for module building from SDK/on targetCalifornia SullivanACCEPTEDenhancementMedium+2.5 M2
5660Weston doesn't work properly on qemuAlejandro HernandezACCEPTEDenhancementMediumFuture
5695python: ptest cases failedAlejandro HernandezNEWnormalLowFuture
6119verify that perf test command worksSaul WoldNEWnormalMediumFuture
6630linux-yocto: kernel-dev package does not include target arch scripts binariesSaul WoldIN PROGRESS DESIGNenhancementMedium2.5 M2
8730separate code generating python manifest file from manifest information and improve the manifest generationAlejandro HernandezIN PROGRESS IMPLEMENTATIONenhancementMedium2.5 M1
8773refactor yocto-kernel-cache common-pc / intel-common scc/cfg file to reduce delta & overlapCalifornia SullivanACCEPTEDenhancementMediumFuture
9267test_parselogs (oeqa.runtime.parselogs.ParseLogsTest) failed on NUC 6i5SYH, firmware load for i915/skl_guc_ver4.bin failedCalifornia SullivanIN PROGRESS DESIGNnormalMedium2.5
9451Document a cookbook procedure on how to change kernel versionSaul WoldACCEPTEDnormalLowFuture
9525Make install prompt available on all consolesCalifornia SullivanACCEPTEDenhancementMedium2.5 M2
10073wic: generic bootloader-agnostic EFI pluginSaul WoldIN PROGRESS DESIGNenhancementMedium+2.5 M1
10084RMC: Deploy central database file without dependency on EFI bootloaderTodor MinchevNEWenhancementMedium2.5
10085RMC: move RMC feature out of meta-intelTodor MinchevNEWenhancementLowFuture
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 M1
10713Allow testimage to work with slirp in addition to working with tun/tapTodor MinchevACCEPTEDnormalMedium+2.5 M1
10827Run oe-selftest -r wic for every patch coming to openembedded-core, poky and bidbake-devel listsSaul WoldIN PROGRESS IMPLEMENTATIONenhancementMedium2.5LET
10957wic: support generating raw flash imagesSaul WoldIN PROGRESS DESIGNenhancementMedium2.5
10966Make the IMAGE_BOOT_FILES interface generally availableSaul WoldNEWminorMedium2.5
10987Use initramfs-framework for initialization by default in OE-CoreCalifornia SullivanIN PROGRESS IMPLEMENTATIONenhancementMedium+2.5 M1
10988RMC: Create and use an initramfs-framework module for RMCTodor MinchevNEWnormalLowFuture
11030RMC: systemd-boot EFI stub: Don't read RMC db in SecureBoot modeTodor MinchevIN PROGRESS REVIEWnormalMedium2.5
11279wic: honor IMAGE_ROOTFS_EXTRA_SPACE et alSaul WoldNEWenhancementMedium2.5
11280wic: set arbitrary artifacts to arbitrary locations on a disk imageSaul WoldNEWenhancementMedium2.5
11281wic: should be able to run with or without bitbake/native toolsSaul WoldNEWenhancementLowFuture
11291Don't generate live images for x86Saul WoldNEWenhancementMedium+2.5 M2
11363Support building and deploying multiple kernels for a single imageSaul WoldIN PROGRESS REVIEWenhancementMedium+2.5 M1LET
11386kexec-tools doesn't work with poky-tinySaul WoldACCEPTEDnormalMedium2.5
11424poky-tiny + Link Time OptimizationSaul WoldACCEPTEDenhancementLowFutureLET
11510Improve the way we handle python's packaging (autopackaging)Alejandro HernandezIN PROGRESS REVIEWenhancementMedium2.5 M1LET
11513Python3 isn't multilib compatibleAlejandro HernandezIN PROGRESS REVIEWnormalMedium+2.5 M1
11531RMC: [EFI] Add register board with data store functionality (non-secure boot)Todor MinchevNEWenhancementMedium2.5
11532RMC: [EFI] Add log optionTodor MinchevNEWenhancementMedium2.5 M2
11533RMC: [EFI] Add debug optionTodor MinchevNEWenhancementMedium2.5 M2
11534RMC: [EFI] Process tasks in TASKS fileTodor MinchevNEWenhancementMedium2.5
11535RMC: [EFI] Verify data store integrity (secure boot)Todor MinchevNEWenhancementMedium2.5
11537RMC: Get board fingerprintTodor MinchevIN PROGRESS IMPLEMENTATIONnormalMedium2.5 M1
11538RMC: Bless data storeTodor MinchevNEWenhancementMedium2.5
11539RMC: Verify RMC.efi is properly blessedTodor MinchevNEWenhancementMedium2.5
11540RMC: Print fingerprint file contentsTodor MinchevNEWenhancementMedium2.5
11543RMC: Register board with data storeTodor MinchevNEWenhancementMedium2.5
11544RMC: Add debug optionTodor MinchevACCEPTEDenhancementMedium2.5 M1
11545RMC: Add log optionTodor MinchevNEWenhancementMedium2.5 M1
11629document in tips and tricks how to bring up a de10-nano altera HPS with Yocto PokyTodor MinchevNEWenhancementMedium2.5
11648python doesn't parse multilib headers wellAlejandro HernandezACCEPTEDnormalMedium+2.5
11694Python JSON manifest should be parsed directly by bitbakeAlejandro HernandezIN PROGRESS REVIEWenhancementMedium2.5 M1LET
11695Add task to create python manifest(s) automaticallyAlejandro HernandezIN PROGRESS REVIEWenhancementMedium2.5 M1LET
11714Intel AC 7260 Bluetooth interface stops responding after disabling BluetoothSaul WoldIN PROGRESS IMPLEMENTATIONnormalMedium+2.5 M1
11726[Testimage]Multiple errors present in dmesg_ouput.logCalifornia SullivanNEWnormalMedium2.5
11807kernel tooling should support building in firmwareCalifornia SullivanNEWenhancementMedium2.5 M1
11816secure boot implementation using systemd-boot bootloaderCalifornia SullivanNEWenhancementMedium+2.5 M1
11837XSERVER uses xf86-video-mga from meta-oe instead of meta-intelCalifornia SullivanNEWnormalMedium2.5
11880kernel-devsrc: multiple System.map files present in kernel-build-artifactsSaul WoldACCEPTEDnormalMedium2.5 M2
11937[Testcase 1059] Parselogs is failing corei7-64-lsb on Cherry Hill giving error: *ERROR* timed out waiting for Punit DDR DVFS requestCalifornia SullivanACCEPTEDnormalMedium2.5
12019Use xf86-video-modesettings instead of -intelCalifornia SullivanACCEPTEDnormalMedium2.5
12091wic support more mounting optionSaul WoldNEWenhancementMedium2.5
12111GRUB2 menuconfig is not getting generated for genericx86 ISO imageCalifornia SullivanACCEPTEDmajorMedium+2.5 M1
12118muslx32: webkitgtk compilation errorSaul WoldNEWenhancementMedium2.5
12119muslx32: boost compilation errorSaul WoldNEWenhancementMedium2.5
12120muslx32: gdb compilation errorSaul WoldNEWenhancementMedium2.5
12121muslx32: qat16 compilation errorSaul WoldNEWenhancementMedium2.5
12122muslx32: systemd-boot compilation errorSaul WoldNEWenhancementMedium2.5
12123muslx32: acpica compilation errorSaul WoldNEWenhancementMedium2.5
12137kernel_devsrc: occasional incorrect permissionsSaul WoldACCEPTEDnormalMedium2.5
12162ERROR: do_kernel_metadata: Could not locate BSP definitionAlejandro HernandezNEWnormalMedium+2.5 M1
12169wic cp allows me to cp a file into a wic partition, it should let me cp one out as well.Saul WoldNEWenhancementLowFuture
12170Add mkfs.ext support to busybox on poky-tinyAlejandro HernandezACCEPTEDenhancementMedium2.5 M1
12187not audio- play (wav) with HDMI, 2.4California SullivanNEWnormalMedium2.5
12188Make wic the default image type for genericx86 and genericx86-64Alejandro HernandezACCEPTEDenhancementMedium2.5 M1
12189wic cp should support recursive copiesSaul WoldNEWenhancementMedium+2.5 M2
12190unreproduceable total system crash while doing wic cp,wic rm, wic lsSaul WoldNEWnormalLowFuture
12214[TC 1059] test_parselogs failed om MMAX64 (Turbot, WIC image) : usb 1-3: device descriptor read/64, error -71California SullivanNEWnormalMedium2.5
12217Support F2FSTodor MinchevNEWenhancementMedium2.5
12224wic image created for qemux86-64 stalls on undefined video mode number: 318California SullivanNEWnormalMedium2.5
12278lttng-modules fails do_fetch/do_compileCalifornia SullivanNEWnormalMedium+2.3.3
12304nightly-oe-selftest failing on do_image_ext4 stepSaul WoldIN PROGRESS REVIEWnormalMedium2.5
12320Enable multiple kernels and multiple kernel command lines in systemd-boot, grub-efi menuSaul WoldNEWenhancementMedium2.5
12346meta-intel: ISO installer silently fails to install if booted in legacy modeCalifornia SullivanACCEPTEDmajorHigh2.4.1
 83      
Personal tools