問題ID：28687
- フォーラムは新サイトへ移行しました。
- このフォーラムではゲスト投稿が禁止されています
akira1979
居住地: 大阪
投稿数: 4
居住地: 大阪
投稿数: 4
【問題】
カーネルのソースに対して現在のカーネル設定を引き継いだコンフィギュレーションを行い、ビルドして現在のシステムにインストールしたい。
実行するべき make オプションの順序として正しいものを選びなさい。
【答え】
mrproper, oldconfig, all, modules_install, install
上記のようになっていますが、mrproperで.configを含めて削除してしまうと、oldconfigで現在の設定を引き継ぐ為の設定ファイルが存在しなくなると思うのですが、正しいのでしょうか？
以前の古い.configファイルを別ディレクトリに残していて、それをコピーしてくれば設定を引き継ぐことができると思いますが…
もし、上記のような背景もない場合、mrproperではなく、cleanを使用するのが正しいと思うのですが、どうなのでしょう？
カーネルのソースに対して現在のカーネル設定を引き継いだコンフィギュレーションを行い、ビルドして現在のシステムにインストールしたい。
実行するべき make オプションの順序として正しいものを選びなさい。
【答え】
mrproper, oldconfig, all, modules_install, install
上記のようになっていますが、mrproperで.configを含めて削除してしまうと、oldconfigで現在の設定を引き継ぐ為の設定ファイルが存在しなくなると思うのですが、正しいのでしょうか？
以前の古い.configファイルを別ディレクトリに残していて、それをコピーしてくれば設定を引き継ぐことができると思いますが…
もし、上記のような背景もない場合、mrproperではなく、cleanを使用するのが正しいと思うのですが、どうなのでしょう？
staff_meg
投稿数: 427
投稿数: 427
akira1979さん
ご指摘の点を修正致しました。
ご報告、誠にありがとうございました。
ご指摘の点を修正致しました。
ご報告、誠にありがとうございました。
akira1979
居住地: 大阪
投稿数: 4
居住地: 大阪
投稿数: 4
疑問が解消されてすっきりしました。
ご対応ありがとうございました。
ご対応ありがとうございました。
sokura
投稿数: 4
投稿数: 4
未だに当該問題IDの問題文と解答に変化がないように見受けられますが、どうなのでしょうか？
mrしてoldconfigしたいなら事前に.configデータを退避させておく必要があるかと思いますし、それならそもそもcleanしてoldconfigで済むのではと思います。
mrしてoldconfigしたいなら事前に.configデータを退避させておく必要があるかと思いますし、それならそもそもcleanしてoldconfigで済むのではと思います。
arashi1977
居住地: 広島
投稿数: 1715
居住地: 広島
投稿数: 1715
引用：今どきだと.configを退避させなくても稼働中のものから適切なの参照してくれるはずですが…
手元のCentOS7ではこんな感じになりました。
mrしてoldconfigしたいなら事前に.configデータを退避させておく必要があるかと思いますし、それならそもそもcleanしてoldconfigで済むのではと思います。
手元のCentOS7ではこんな感じになりました。
$ cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
$ uname -r
3.10.0-1062.4.1.el7.x86_64
$ curl https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.6.11.tar.xz -O
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 106M 100 106M 0 0 34.3M 0 0:00:03 0:00:03 --:--:-- 34.3M
$ tar xJf linux-5.6.11.tar.xz
$ cd linux-5.6.11
$ make oldconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/confdata.o
HOSTCC scripts/kconfig/expr.o
LEX scripts/kconfig/lexer.lex.c
YACC scripts/kconfig/parser.tab.[ch]
HOSTCC scripts/kconfig/lexer.lex.o
HOSTCC scripts/kconfig/parser.tab.o
HOSTCC scripts/kconfig/preprocess.o
HOSTCC scripts/kconfig/symbol.o
HOSTCC scripts/kconfig/util.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
#
# using defaults found in /boot/config-3.10.0-1062.4.1.el7.x86_64
#
/boot/config-3.10.0-1062.4.1.el7.x86_64:692:warning: symbol value 'm' invalid for CPU_FREQ_STAT
/boot/config-3.10.0-1062.4.1.el7.x86_64:936:warning: symbol value 'm' invalid for NF_CT_PROTO_GRE
/boot/config-3.10.0-1062.4.1.el7.x86_64:964:warning: symbol value 'm' invalid for NF_NAT_REDIRECT
/boot/config-3.10.0-1062.4.1.el7.x86_64:967:warning: symbol value 'm' invalid for NF_TABLES_INET
/boot/config-3.10.0-1062.4.1.el7.x86_64:1134:warning: symbol value 'm' invalid for NF_TABLES_IPV4
/boot/config-3.10.0-1062.4.1.el7.x86_64:1138:warning: symbol value 'm' invalid for NF_TABLES_ARP
/boot/config-3.10.0-1062.4.1.el7.x86_64:1179:warning: symbol value 'm' invalid for NF_TABLES_IPV6
/boot/config-3.10.0-1062.4.1.el7.x86_64:1556:warning: symbol value 'm' invalid for NET_DEVLINK
/boot/config-3.10.0-1062.4.1.el7.x86_64:2713:warning: symbol value 'm' invalid for ISDN_CAPI
/boot/config-3.10.0-1062.4.1.el7.x86_64:3658:warning: symbol value 'm' invalid for LIRC
*
* Restart config...
*
*
* General setup
*
Compile also drivers which will not load (COMPILE_TEST) [N/y/?] (NEW)
sokura
投稿数: 4
投稿数: 4
.configを退避させる必要は無いとのご意見、ありがとうございます。
ですが、今回の私の投稿内容の趣旨は、.configを退避させる必要があるかないかではなく、元々の投稿主である方のご指摘に対してスタッフと思われる方が「修正致しました」とあるにも関わらず、依然として問題文や解説に変更が見受けられない事に対する疑問への追求となります。
ですから、私に対して「.configを退避させる必要は無い」との見解を述べていただく事は、問題の根本的な解決には至らないと考えます。
問題ID：28687の解説を読む限りでは「いまどきは.configを退避させずとも望む処理が可能であり、mrproper→oldconfigの流れで正しい」と判断出来る要素が見当たらないように思えるのです。
ですが、今回の私の投稿内容の趣旨は、.configを退避させる必要があるかないかではなく、元々の投稿主である方のご指摘に対してスタッフと思われる方が「修正致しました」とあるにも関わらず、依然として問題文や解説に変更が見受けられない事に対する疑問への追求となります。
ですから、私に対して「.configを退避させる必要は無い」との見解を述べていただく事は、問題の根本的な解決には至らないと考えます。
問題ID：28687の解説を読む限りでは「いまどきは.configを退避させずとも望む処理が可能であり、mrproper→oldconfigの流れで正しい」と判断出来る要素が見当たらないように思えるのです。
arashi1977
居住地: 広島
投稿数: 1715
居住地: 広島
投稿数: 1715
引用：あれ、意図が違っていたのですね。前の投稿で
引用：解説では
引用：があるので、今の設問と正答選択肢でも別におかしくないと思っていたところでの上記の発言（解説と同じことを言っている）だったので、なにか違うことを話題にされようとしていたのかと思ってしまいました。
お詫びします。
なおこの問題に関する私の認識としては、問題文の
引用：「カーネルのソース」が「以前ビルドを行ったツリー」と同じものとは言い切れない（私の実例のように新たに取得したソースツリーの場合もある）ので「clean→oldconfig」では不適当かもしれない、と考えていました。
※もっとも、選択肢には「clean」ターゲットは入っていないのでこの問題の回答を考えるには不要かなというところでもありますが
今回の私の投稿内容の趣旨は、.configを退避させる必要があるかないかではなく、元々の投稿主である方のご指摘に対してスタッフと思われる方が「修正致しました」とあるにも関わらず、依然として問題文や解説に変更が見受けられない事に対する疑問への追求となります。
ですから、私に対して「.configを退避させる必要は無い」との見解を述べていただく事は、問題の根本的な解決には至らないと考えます。
引用：
mrしてoldconfigしたいなら事前に.configデータを退避させておく必要があるかと思いますし、それならそもそもcleanしてoldconfigで済むのではと思います。
引用：
2. 設定を行う
設定はカーネルをコンパイル（ビルド）する前に行ないます。
この問題では「現在のカーネル設定を引き継」いで使うとのことなので、現在のカーネルをビルドしたときの設定を .config として現在のディレクトリにコピーしておき、make oldconfig を実行します。
お詫びします。
なおこの問題に関する私の認識としては、問題文の
引用：
カーネルのソースに対して現在のカーネル設定を引き継いだコンフィギュレーションを行い、ビルドして現在のシステムにインストールしたい。
※もっとも、選択肢には「clean」ターゲットは入っていないのでこの問題の回答を考えるには不要かなというところでもありますが
sokura
投稿数: 4
投稿数: 4
重ね重ねご意見ありがとうございます。
改めて色々調べて自分の認識を確認し、まとめます。
まず最初の認識としては
mrproperを実行する＝oldconfigで参照するファイルすら削除される
なのでoldconfigが実行出来ることが疑問でした
つまり「現在のカーネルをビルドした時の設定」とやらもmrproperは削除するのではないのかと考えていました。
その理由としては、問題28687のページの参考URL先のmrproperの説明として
「カーネルコンフィグレーションで生成した全てのファイルを削除する」とあるからです。
ですが、oldconfigが参照する.configは、/boot配下にあるファイルのコピーであり
mrproperで削除されるのはあくまでカーネルソースが展開される/usr/src/linux内のファイルのみであるとするなら合点がいきます。
これならmrproperで全て削除しても、/bootのコンフィグデータを持ってくればoldconfigが可能であり、現在の内容で問題ないかのように見えます。
ですが、そうなると別の疑問が浮かびます。それは、「現在のカーネル設定を引き継ぐ」のに何故「make clean」では誤りなのか
という点です。
現在の設定を引き継ぐ以上、.configを削除する必要はなく、mrproperで全削除してわざわざ/boot配下のコンフィグデータをコピーして.configを作成することは二度手間です。
もし「不要なものを残したままビルドを行うよりは、二度手間でも全削除して改めて.configをコピーすればよい」という方針であるなら
そもそもcleanの存在意義とはなんでしょうかとなりますし、じゃあcleanとmrproperはどう使い分ければ良いのだろうと考えていました。
なので現在の設定を引き継ぐにも関わらず、どうして.configを消去しているんだろうと考えておりましたが、ここでやっと大変なことに気付いてしまいました。
仰る通り、選択肢にcleanありませんね・・・。
よく見たらclearでした
そりゃこの選択肢の中ではmrproperから始まる選択肢が正しいとなりますね・・・。
ずーーっとcleanだと思っていて、何故cleanが誤りなんだろうと考えていました。
なんということでしょう。
笑ってもらって構いません。
私の投稿をご覧になっている方にはご迷惑をおかけし、申し訳ありませんでした。
私の勘違いでした。
そして更によく見るとclearの選択肢はその後の流れも、install→modules_installとなっていてこの点でも誤りということが分かりますね。
なんということでしょう。
私の投稿をご覧になっている方にはご迷惑をおかけし、大変申し訳ありませんでした。
ですが、解答が間違っていないことは理解したものの「現在の設定を引き継ぐのにcleanではなくmrproperを実行する手順を解答としている」
明確な理由が不明なことには変わりません。
「mrproperでは削除されるがcleanでは削除されないファイル」というのは.config以外にもあるのでしょうか。
それならまだ理解出来ますが。
改めて色々調べて自分の認識を確認し、まとめます。
まず最初の認識としては
mrproperを実行する＝oldconfigで参照するファイルすら削除される
なのでoldconfigが実行出来ることが疑問でした
つまり「現在のカーネルをビルドした時の設定」とやらもmrproperは削除するのではないのかと考えていました。
その理由としては、問題28687のページの参考URL先のmrproperの説明として
「カーネルコンフィグレーションで生成した全てのファイルを削除する」とあるからです。
ですが、oldconfigが参照する.configは、/boot配下にあるファイルのコピーであり
mrproperで削除されるのはあくまでカーネルソースが展開される/usr/src/linux内のファイルのみであるとするなら合点がいきます。
これならmrproperで全て削除しても、/bootのコンフィグデータを持ってくればoldconfigが可能であり、現在の内容で問題ないかのように見えます。
ですが、そうなると別の疑問が浮かびます。それは、「現在のカーネル設定を引き継ぐ」のに何故「make clean」では誤りなのか
という点です。
現在の設定を引き継ぐ以上、.configを削除する必要はなく、mrproperで全削除してわざわざ/boot配下のコンフィグデータをコピーして.configを作成することは二度手間です。
もし「不要なものを残したままビルドを行うよりは、二度手間でも全削除して改めて.configをコピーすればよい」という方針であるなら
そもそもcleanの存在意義とはなんでしょうかとなりますし、じゃあcleanとmrproperはどう使い分ければ良いのだろうと考えていました。
なので現在の設定を引き継ぐにも関わらず、どうして.configを消去しているんだろうと考えておりましたが、ここでやっと大変なことに気付いてしまいました。
仰る通り、選択肢にcleanありませんね・・・。
よく見たらclearでした
そりゃこの選択肢の中ではmrproperから始まる選択肢が正しいとなりますね・・・。
ずーーっとcleanだと思っていて、何故cleanが誤りなんだろうと考えていました。
なんということでしょう。
笑ってもらって構いません。
私の投稿をご覧になっている方にはご迷惑をおかけし、申し訳ありませんでした。
私の勘違いでした。
そして更によく見るとclearの選択肢はその後の流れも、install→modules_installとなっていてこの点でも誤りということが分かりますね。
なんということでしょう。
私の投稿をご覧になっている方にはご迷惑をおかけし、大変申し訳ありませんでした。
ですが、解答が間違っていないことは理解したものの「現在の設定を引き継ぐのにcleanではなくmrproperを実行する手順を解答としている」
明確な理由が不明なことには変わりません。
「mrproperでは削除されるがcleanでは削除されないファイル」というのは.config以外にもあるのでしょうか。
それならまだ理解出来ますが。
arashi1977
居住地: 広島
投稿数: 1715
居住地: 広島
投稿数: 1715
この手の話で、昔を思い出しました。
sokura さんがご存知の話だったら、読み飛ばしてください。
昔はインターネット接続回線の帯域が細く、カーネルそのものを毎回取ってくるのは正直きつかったんですよね。例えばlinux-2.0.23.tar.gzなんて5.7MBもあったんです。インターネット接続が28.8kbpsだったので、4KB/秒、上記のカーネルアーカイブ取ってくるだけで24分もかかって結構辛いので、パッチファイルを取ってくるのが一般的でした（patch-2.0.23.gzは18KBなので10秒かからない）。
ところが、パッチを当てるパターンだと、アーカイブから展開したまっさらな状態と違ってどこにどんなゴミファイルが残ってるかわかりません（例えばパッチ前の退避ファイルだとか）。そういう事があるので、基本的にはパッチを当てたあとはおまじないのようにこのコマンドを叩いてたものです。
この辺は、昔のHOWTOにも書いてあります。
http://archive.linux.or.jp/JF/JFdocs/Kernel-HOWTO-4.html
今でもmrproperを実行するのは割と推奨されてるはずです。
引用：はい、config以外にも削除する対象が変わります。
カーネルソースの直下にあるMakefileでmrproperとか探してもらうと以下のような行を見つけることができます。
ざっくりいうと
- cleanはほとんどのファイルを削除、ただし外部モジュールのビルドに必要なものは残す
- mrproperは設定とビルドによって生成されるファイルをすべて削除
- distcleanはエディタのバックアップファイルやパッチの残りかすやらそういったのも削除
って感じです。
違いは以下の記事にも載ってます。
https://www.atmarkit.co.jp/ait/articles/0808/28/news129_2.html
sokura さんがご存知の話だったら、読み飛ばしてください。
昔はインターネット接続回線の帯域が細く、カーネルそのものを毎回取ってくるのは正直きつかったんですよね。例えばlinux-2.0.23.tar.gzなんて5.7MBもあったんです。インターネット接続が28.8kbpsだったので、4KB/秒、上記のカーネルアーカイブ取ってくるだけで24分もかかって結構辛いので、パッチファイルを取ってくるのが一般的でした（patch-2.0.23.gzは18KBなので10秒かからない）。
ところが、パッチを当てるパターンだと、アーカイブから展開したまっさらな状態と違ってどこにどんなゴミファイルが残ってるかわかりません（例えばパッチ前の退避ファイルだとか）。そういう事があるので、基本的にはパッチを当てたあとはおまじないのようにこのコマンドを叩いてたものです。
make mrproper && make dep && make clean && cp ../.config . && make oldconfig
この辺は、昔のHOWTOにも書いてあります。
http://archive.linux.or.jp/JF/JFdocs/Kernel-HOWTO-4.html
今でもmrproperを実行するのは割と推奨されてるはずです。
引用：
「mrproperでは削除されるがcleanでは削除されないファイル」というのは.config以外にもあるのでしょうか。
それならまだ理解出来ますが。
カーネルソースの直下にあるMakefileでmrproperとか探してもらうと以下のような行を見つけることができます。
###
# Cleaning is done on three levels.
# make clean Delete most generated files
# Leave enough to build external modules
# make mrproper Delete the current configuration, and all generated files
# make distclean Remove editor backup files, patch leftover files and the like
- cleanはほとんどのファイルを削除、ただし外部モジュールのビルドに必要なものは残す
- mrproperは設定とビルドによって生成されるファイルをすべて削除
- distcleanはエディタのバックアップファイルやパッチの残りかすやらそういったのも削除
って感じです。
違いは以下の記事にも載ってます。
https://www.atmarkit.co.jp/ait/articles/0808/28/news129_2.html
sokura
投稿数: 4
投稿数: 4
なるほど。cleanとmrproperの結構な違い、過去の技術的背景、理解致しました。
おかげさまで、引っかかっていた部分はほぼ解消出来たと思っています。
色々と答えてくださって、本当にありがとうございました。感謝致します。
おかげさまで、引っかかっていた部分はほぼ解消出来たと思っています。
色々と答えてくださって、本当にありがとうございました。感謝致します。
