| Summary: | Symlinks overridden when building multitple kernels | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Marc Ferland <marc.ferland> | ||||||||
| Component: | kernel | Assignee: | Bruce Ashfield <bruce.ashfield> | ||||||||
| Status: | IN PROGRESS DESIGN --- | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | Medium+ | CC: | ccasciato, randy.macleod, richard.purdie, tom.zanussi | ||||||||
| Version: | 2.6.3 | ||||||||||
| Target Milestone: | 6.99 | ||||||||||
| Hardware: | Other | ||||||||||
| OS: | arm | ||||||||||
| Whiteboard: | |||||||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||||||
| Attachments: |
|
||||||||||
|
Description
Marc Ferland
2019-03-29 16:44:31 UTC
Can you elaborate on your kernel recipe, configuration, etc ? What mechanism are the images using to select the two different kernel configurations ? Generally speaking, if your layers are available, or the more information you can supply, the better the turn around. Since I don't have a setup for building this (at least not for anything that uses device trees), there's quite a bit of setup and ways to do this .. so I can't currently reproduce the problem. Sure. I just did a quick test using the folowing layers (latest HEAD on master branch): meta-freescale: 3d7696d9c33bfc72d4d4df77322a92837ab3971b meta-openembedded: 0435c9e193f53193a8f0043ddc287d061f72f250 poky: 8217b477a10d608fe37f1151c12996a594c0fba8 Configured my MACHINE to: MACHINE = "imx6qdlsabresd" And then compiled core-image-minimal followed by linux-mfgtool. So basically: bitbake core-image-minimal bitbake linux-mfgtool core-image-minimal pulls on linux-fslc-imx while linux-mfgtool is just a derivative of linux-imx. Both kernels will be built but the second command will ultimately override all the symlinks of the first one. I guess I could have just: bitbake virtual/kernel bitbake linux-mfgtool and the results would have been the same. I also diffed the deploy directory listing between calls and got (excerpt): ... -rw-r--r-- 2 vagrant vagrant 50K Apr 8 14:51 imx6dl-sabresd--4.9-1.0.x+git0+953c6e30c9-r0-imx6qdlsabresd-20190408132901.dtb +-rw-r--r-- 2 vagrant vagrant 50K Apr 8 15:07 imx6dl-sabresd--4.9.123-r0-imx6qdlsabresd-20190408145613.dtb -rw-r--r-- 2 vagrant vagrant 51K Apr 8 14:51 imx6dl-sabresd-btwifi--4.9-1.0.x+git0+953c6e30c9-r0-imx6qdlsabresd-20190408132901.dtb -lrwxrwxrwx 2 vagrant vagrant 85 Apr 8 14:51 imx6dl-sabresd-btwifi.dtb -> imx6dl-sabresd-btwifi--4.9-1.0.x+git0+953c6e30c9-r0-imx6qdlsabresd-20190408132901.dtb -lrwxrwxrwx 2 vagrant vagrant 85 Apr 8 14:51 imx6dl-sabresd-btwifi-imx6qdlsabresd.dtb -> imx6dl-sabresd-btwifi--4.9-1.0.x+git0+953c6e30c9-r0-imx6qdlsabresd-20190408132901.dtb -lrwxrwxrwx 2 vagrant vagrant 78 Apr 8 14:51 imx6dl-sabresd.dtb -> imx6dl-sabresd--4.9-1.0.x+git0+953c6e30c9-r0-imx6qdlsabresd-20190408132901.dtb +-rw-r--r-- 2 vagrant vagrant 51K Apr 8 15:07 imx6dl-sabresd-btwifi--4.9.123-r0-imx6qdlsabresd-20190408145613.dtb +lrwxrwxrwx 2 vagrant vagrant 67 Apr 8 15:07 imx6dl-sabresd-btwifi.dtb -> imx6dl-sabresd-btwifi--4.9.123-r0-imx6qdlsabresd-20190408145613.dtb +lrwxrwxrwx 2 vagrant vagrant 67 Apr 8 15:07 imx6dl-sabresd-btwifi-imx6qdlsabresd.dtb -> imx6dl-sabresd-btwifi--4.9.123-r0-imx6qdlsabresd-20190408145613.dtb +lrwxrwxrwx 2 vagrant vagrant 60 Apr 8 15:07 imx6dl-sabresd.dtb -> imx6dl-sabresd--4.9.123-r0-imx6qdlsabresd-20190408145613.dtb ... Created attachment 4462 [details]
deploy directory listing after core-image-minimal
Created attachment 4463 [details]
deploy directory listing after linux-mfgtool
Thanks for the details. I'll have a look. I also hit this bug. It is occurring because kernel-devicetree.bbclass does not deploy into a subdir like kernel.bbclass does when KERNEL_PACKAGE_NAME is set. kernel-devicetree.bbclass needs to do what kernel.bbclass does with KERNEL_DEPLOYSUBDIR. We are post feature freeze, once the features merge, this can be looked at for the release. But chances are it won't make the fall release. Created attachment 4558 [details]
example patch
I don't think this is a new feature, but instead a bug in the alternate kernel package feature.
What we need is a something the attached patch.
This is a bug fix so it's okay to merge for M4. Martin, can you send the patch to the list please? Someone else should grab the bug from me .. I won't be working on it for M4. This is an old one, but lets bump it again. Bulk move as requesting during YP BB meeting. Parked in 6.99 to minimize bumping. |