Linuxビルドを自動化したいのですが、最終的には非常に手動のステップのように見えるものを実行する必要があるところまで到達しました:make menuconfig
。これは、OSとカーネル構成の間で構成を同期するようですか?
cp git-tracked-config .config
make defconfig
make menuconfig # <- how to automate/script this?
make V=s
基本的に、ビルドスクリプトのmake menuconfig
の呼び出しを削除するにはどうすればよいですか?
余談ですが、これはmake menuconfigを呼び出さずに実行したときに発生するように見えるビルドエラーに対する反応です。
make[1]: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop.
おそらくメイクファイル自体が存在しないか、メイクファイルがそのルールを含むように生成/モーフィングされていないために、メイクファイルにルールが欠けているようですが、それは別の質問です。
これをすべてまとめるよりスマートな方法があるかもしれません。追跡していないけれどもすべき他の構成はありますか(oldconfigなど)?
Linuxカーネルビルドシステムは多くのビルドターゲットを提供します。それを知る最良の方法は、おそらくmake help
を実行することです。
Configuration targets:
config - Update current config utilising a line-oriented program
nconfig - Update current config utilising a ncurses menu based program
menuconfig - Update current config utilising a menu based program
xconfig - Update current config utilising a QT based front-end
gconfig - Update current config utilising a GTK based front-end
oldconfig - Update current config utilising a provided .config as base
localmodconfig - Update current config disabling modules not loaded
localyesconfig - Update current config converting local mods to core
silentoldconfig - Same as oldconfig, but quietly, additionally update deps
defconfig - New config with default from Arch supplied defconfig
savedefconfig - Save current config as ./defconfig (minimal config)
allnoconfig - New config where all options are answered with no
allyesconfig - New config where all options are accepted with yes
allmodconfig - New config selecting modules when possible
alldefconfig - New config with all symbols set to default
randconfig - New config with random answer to all options
listnewconfig - List new options
olddefconfig - Same as silentoldconfig but sets new symbols to their default value
kvmconfig - Enable additional options for guest kernel support
tinyconfig - Configure the tiniest possible kernel
Jimmijがコメントで言っているように、興味深い部分はoldconfig
関連ターゲットにあります。
個人的には、silentoldconfig
を使用することをお勧めします(.config
ファイルで何も変更されていない場合、または.config
ファイルを新しいカーネルで更新した場合はolddefconfig
。
merge_config.sh
構成フラグメント
$ cd linux
$ git checkout v4.9
$ make x86_64_defconfig
$ grep -E 'CONFIG_(DEBUG_INFO|GDB_SCRIPTS)[= ]' .config
# CONFIG_DEBUG_INFO is not set
$ # GDB_SCRIPTS depends on CONFIG_DEBUG_INFO in lib/Kconfig.debug.
$ cat <<EOF >.config-fragment
> CONFIG_DEBUG_INFO=y
> CONFIG_GDB_SCRIPTS=y
> EOF
$ # Order is important here. Must be first base config, then fragment.
$ ./scripts/kconfig/merge_config.sh .config .config-fragment
$ grep -E 'CONFIG_(DEBUG_INFO|GDB_SCRIPTS)[= ]' .config
CONFIG_DEBUG_INFO=y
CONFIG_GDB_SCRIPTS=y
プロセスの置換は残念ながら動作しません:
./scripts/kconfig/merge_config.sh Arch/x86/configs/x86_64_defconfig \
<( printf 'CONFIG_DEBUG_INFO=y\nCONFIG_GDB_SCRIPTS=y\n' )
理由: https://unix.stackexchange.com/a/164109/32558
merge_config.sh
は、make alldefconfig
ターゲットの単純なフロントエンドです。
クロスコンパイルする場合、merge_config.sh
を実行するときにArch
をエクスポートする必要があります。例:
export Arch=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
make defconfig
./scripts/kconfig/merge_config.sh .config .config-fragment
マージされた出力ファイルは、KCONFIG_CONFIG
環境変数を使用して明示的に指定できます。それ以外の場合は、.config
を上書きするだけです。
KCONFIG_CONFIG=some/path/.config ./scripts/kconfig/merge_config.sh .config .config-fragment
BuildrootはBR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES
で自動化します: https://stackoverflow.com/questions/1414968/how-do-i-configure-the-linux-kernel-within-buildroot
CentOSカーネルをアップグレードしたくて、複数のマシンでアップグレードする必要があったため、同じ問題が発生しました。ここで私の新しいCentOSカーネルツリーが/linux-5.1にあると仮定します(私はrootアカウントにログインしています)
cd /linux-5.1
make menuconfig
を実行して変更を加え、.config
に保存します/linux-5.1/.config
ファイルを開発サーバーにコピーします.config
ファイルを新しいマシンの/linux-5.1/.config
にコピーします。これが同じ窮地にいる誰かを助けることを願っています。