I can successfully build when in my buildroot's config pc_x86_bios_defconfig I set BR2_LINUX_KERNEL_USE_DEFCONFIG=y # BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG is not set # BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG is not set But when in pc_x86_bios_defconfig I do BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="$(BR2_EXTERNAL)/board/my_company/my_board/pc_x86_bios_kernel4.19.269_defconfig" All my settings from pc_x86_bios_defconfig will be ignored. Why? To build I use command see console.txt I get messages from buildroot see log2.txt To get my config files see my_external_tree.7z
Created attachment 9456 [details] my config files
There are several places where it could have gone wrong. * When you make changes to pc_x86_bios_defconfig this won't be taken into account at all unless you run `make pc_x86_bios_defconfig` again. * When you make changes manually in pc_x86_bios_defconfig, it's possible you made a mistake (e.g. missed a dependency). As a result, your changes may have been removed from the full .config. Check in the .config if those symbols are there. In general, it's best to run `make menuconfig; make savedefconfig` and review the changes, rather than editing the defconfig manually. * After you make changes to the configuration, the next build will not take into account changes, it will only build any *new* packages you added. In this case, since you changed the linux configuration, you can run `make linux-reconfigure` to refresh the configuration. In general you may need to do a clean build (`make clean; make`).
May be I have some mistakes? I do 1) make menuconfig -C buildroot And select Load "/mnt/ramdisk/my_external_tree/configs/pc_x86_bios_defconfig" And select Save "/mnt/ramdisk/my_external_tree/configs/pc_x86_bios_defconfig" 2) make clean -C buildroot make BR2_EXTERNAL=${MyBaseDir}/my_external_tree -C buildroot pc_x86_bios_defconfig I get "# configuration written to /mnt/ramdisk/buildroot/.config", so let's look into /mnt/ramdisk/buildroot/.config BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="$(BR2_EXTERNAL)/board/my_company/my_board/pc_x86_bios_kernel4.19.269_defconfig" BR2_TARGET_GENERIC_ISSUE="Welcome to Buildroot123" yes, "123" is my mark! Looks ok. But may be I have a mistake in /mnt/ramdisk/my_external_tree/board/my_company/my_board/pc_x86_bios_kernel4.19.269_defconfig ? I do make linux-menuconfig -C buildroot And select Load "/mnt/ramdisk/my_external_tree/board/my_company/my_board/pc_x86_bios_kernel4.19.269_defconfig" And select Save "/mnt/ramdisk/my_external_tree/board/my_company/my_board/pc_x86_bios_kernel4.19.269_defconfig" Now let's build: 3) # get absoletly new buildroot from git rm -Rf buildroot/ git clone https://github.com/buildroot/buildroot make BR2_EXTERNAL=${MyBaseDir}/my_external_tree -C buildroot pc_x86_bios_defconfig make -C buildroot And I see default values, "Welcome to Buildroot", not "Welcome to Buildroot123"... Why?
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="$(BR2_EXTERNAL)/board/my_company/my_board/pc_x86_bios_kernel4.19.269_defconfig" This is not correct ^^^ The external tree is referenced by $(BR2_EXTERNAL_XYZZY_PATH), where XYZZY is the name you specified in external.desc. You need to edit this file before setting up your project with $ make BR2_EXTERNAL= ... pc_x86_bios_defconfig, because this variable is transferred to your .config; check the first section of the file.
Created attachment 9461 [details] good buildroot and kernel configs for x86 This is working config with kernel 4.19.269 (based on pc_x86_64_bios_defconfig)
Not good works, see details https://bugs.busybox.net/show_bug.cgi?id=15271
There is apparently no Buildroot bug here, but instead: - Andrei you are manually editing the defconfig file. Don't do that, unless you are extremely familiar with Buildroot options. Please use "make menuconfig" to change the configuration. - As pointed out by Andreas, using $(BR2_EXTERNAL) will not work, you need to use $(BR2_EXTERNAL_xyz_PATH) where "xyz" is the name of your external as specified in the external.desc file. Since there's no Buildroot bug here, I'm closing this entry.