FAQ

関連記事

• Arch 用語集
• Arch User Repository#FAQ
• 一般的なトラブルシューティング

ここで解決されない問題等については，The Arch Way，Arch Linux が参考になります．そこでは Arch Linux に関するより多くの情報が扱われています．

一般

Arch Linux って何ですか?

Arch Linux を参照してください。

私は Arch を使うべきですか?

あなたが The Arch Way の理念に賛同し、'do-it-yourself' なアプローチを受け入れることができて、そして、シンプルで、エレガントで、高いカスタマイズ性を持ち、最先端の汎用 GNU/Linux ディストリビューションをお探しなら、Arch が気に入るかもしれません。

私は Arch を使うべきではありませんか?

あなたが The Arch Way の理念に賛同できず、'do-it-yourself' な GNU/Linux ディストリビューションを使う能力や時間がない、あるいはそれを求めていないなら、Arch はあなた向けではないかもしれません。

また、以下のような方も Arch を使いたいとは思わないでしょう:

• x86_64 および i686 以外のアーキテクチャのサポートが必要な方。
• GNU で定義されたフリーウェアのみを提供するディストリビューションを使うことに強いこだわりのある方。
• オペレーティングシステム自身が構成設定を行うべきであり、"箱から出してすぐ使える" べきであり、インストールメディア上でソフトウェアやデスクトップ環境のデフォルト設定が完全になされているべきであるとお考えの方。
• 最先端で、ローリングリリースな GNU/Linux を求めていない方。
• 今使っている OS に満足している方。

Arch はどのディストリビューションベースなんですか?

Arch は独自に開発され、他のいかなる GNU/Linux ディストリビューションもベースとしていません。Arch を製作する以前、Judd Vinet は Per Lidén による優れた最小主義ディストリビューションである CRUX を賞賛し使用していました。当初は CRUX と同様のアイデアに触発された Arch ですが、スクラッチビルドされており、pacman は C 言語で開発されました。

Arch はどのアーキテクチャをサポートしていますか?

i686 と x86_64 (別名 amd64) アーキテクチャをサポートしています。

Arch は ARM CPU をサポートしていますか?

いいえ、ただし Arch Linux ARM プロジェクトによって Arch Linux が ARM プラットフォームに移植されています。

当方全くの GNU/Linux ビギナーなのですが、Arch を使って大丈夫でしょうか?

これに関してはかなりの議論があります。Arch はある程度熟練した GNU/Linux ユーザーを対象にしていますが、やる気のある初心者には Arch こそもってこいだ、と考えるような人もいます。もしあなたが初心者で、それでもなお Arch を使おうとしているのであれば、あなたは十分な時間を費やして学ぶことに喜びを覚えるようでなければなりません。また Arch が全く "Do-It-Yourself" なディストリビューションとして設計されている、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。質問をする前にまず自分で調査するようにしてください。Google やフォーラム、そして素晴らしいドキュメントが用意されている Arch Wiki の検索を活用しましょう (以下のFAQも参照してください)。以上のことさえ実践していれば、それほど困難なことはありません。また、多くの人が同じ基本的質問に何度も繰り返して答えさせられることに嫌気がさしているのだ、ということも理解しておいてください。あなたは今まさにその当事者なのです。伊達や酔狂でこのような文書が作成され、入門者に利用してもらえるよう設置されているわけではありません。途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。

要通読:ビギナーズガイド

Arch を使うにはとても手間暇がかかるし、コミュニティはといえば、なにかと言うと RTFM って言うし。

Arch は特定のユーザベースを対象にして設計され、利用されています。おそらくそれがあなたには合っていないのでしょう。上のセクションも参照してください。

Arch はどの用途向けに設計されていますか? サーバですか? デスクトップですか? ワークステーションですか?

Arch は特定の用途向けに設計されているわけではありません。むしろ、特定の "ユーザ" 向けに設計されています。Arch はなんでも自分でやることを楽しみ、各自のニーズに応じたシステムを構築するためにそれをよりよく活用する、やる気のあるユーザを対象にしています。したがって、その目的はユーザの思いのままであり、Arch は事実上あらゆる用途で使用できます。多くの人々が Arch をデスクトップとワークステーション両方で使用しています。そしてもちろん、archlinux.org は Arch で動いています。

Arch はホント好きなんだけどね．開発チームがXの機能さえ実装してくれればなぁ．

ちょっと待った．ちゃんと The Arch Way は，読みましたか？ あなたはその機能/対処方法を提示してみたのですか？ それはミニマリズムや，利便性に先んじるコードの整合性と言ったArchの哲学と一致するでしょうか？ どうぞ積極的に参加してください．あなた自身がコードや解決策を提示することでコミュニティに貢献しましょう．もし，コミュニティや開発チームから認められれば，あなたのコードはマージされるかも知れません．Archコミュニティはコードやツールの提供，シェアによって活性化していきます．

いつ新しいメジャー・リリースが出るんでしょうか?

Arch Linux におけるメジャーリリースは各月の前半頃に公開されますが、これはインストールおよびレスキュー用のライブ環境で、base グループとその他いくつかの パッケージが含まれています。

ローリングリリースモデルは、ひとつのコマンド操作によってあらゆる Arch Linux のシステムを最新かつ最先端に保つものです。このことから、Arch におけるメジャーリリースというのはさほど重要な意味を持つものではないと言えます、なぜと言ってローリングリリースシステムは、パッケージがアップデートされるや否や、すぐさま最新のメジャーリリースを旧バージョンにしてしまうわけですから。最新の Arch Linux のメジャーリリースを手に入れたいと思っても、再インストールなどする必要はありません。単にコマンド pacman -Syu を実行するだけで、あなたのシステムは新規インストールしたのと同様に最新になります。また同じ理由から、新しい Arch Linux のリリースというのは、一般的に理解されているような、真新しくてエキサイティングな機能を満載したものにはなりません。そうした真新しくエキサイティングな機能群のリリースは、必要に応じたパッケージのアップデートによってもたらされるものであり、それは pacman -Syu のコマンドによって即座に反映されるのです。

Arch Linux は堅牢なディストリなのでしょうか? しょっちゅう壊れたりしませんか?

一言で言うと、それは概ね「あなた次第」だということです。

自分の Arch システムをシンプルな基本環境の上に構築するのはあなたであり，システムの成長をコントロールしていくのもあなたなのです。当然、多くのカスタマイズパッケージや、色とりどりのツールキット、デスクトップ環境などを統合して巨大に膨れ上がったシステムでは、スリムでよりシンプルなそれに比べてアップストリームの変更による影響を受けやすく、より多くの設定の問題に悩まされることになります。UNIX に関する一般的な知識や、上手なシステム管理、適切なアップグレードの実施といったものは、システムを堅牢にしていく上で非常に大きな役割を担います。Arch のパッケージの大部分はパッチを施されていないのだ、ということにも留意してください。大部分の問題はおおよそアップストリームに起因するものです。

従って、ローリングリリースで構築された個人のシステムの堅牢性に関して、最終的な責任を負うのはユーザー自身です。ユーザーがいつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手は直ちに差し伸べられることでしょう。この点に関して、Arch が他のディストリビューションから異なっているのは、Arch が本当に "Do-it-yourself" なディストロであることでしょう。破損についてクレームをつけるのは見当違いであり、非生産的です。なぜといって、アップストリームでの変更に関して Arch 開発チームは責任を負いかねるからです。

Archのレビュー記事がもっと必要だ(宣伝が必要だ)．

現状でもう十分な量のArchについての記事が書かれています．Archの目標は巨大になることではなく、シンプルさと，コードの整合性に焦点を絞った，エレガントで，最小かつ最新のディストリビューションを提供することなのです．Archが対象とするユーザー・ベース自体が自然と発展しています．

Archの開発者がもっと必要だ．

そうかも知れませんね．もっと柔軟にあなたの時間を使って貢献してください！ フォーラムや，IRC，メーリングリストなどに参加すれば，成すべきことがわかるはずです．まずは、Community Contributions サブフォーラムに参加してみてください．

他のOSに比べてインターネットの速度が遅いんだけど、どうして?

ネットワークは正しく設定されていますか? Beginners' Guide の Hostname やネットワークの設定の項を参照してください。

また、Arch ではデフォルトでトラフィックシェーピングが有効になっていないことも注意してださい。従って、ネットワーク帯域を活用するプログラムによって改善する可能性があります。Shorewall や Vuurmuur などのファイアウォール (これらは iproute2 のスクリプトでもあります) によってネットワークレイヤーのシェーピングを行うことができます。

なんで Arch は RAM を全部使っちゃうわけ?

そもそも、使わない RAM は無駄な RAM です。

新米ユーザの方の多くは、Linux カーネルのメモリの扱い方がそれの使われ方と必ずしも同じにはならないことに気がつきます。RAM 上のデータへのアクセスはディスクに比べ非常に高速なので、カーネルは最近アクセスされたデータをメモリ上にキャッシュします。キャッシュされたデータは利用可能なメモリを使い果たした時のみクリアされ、新しいデータは必要に応じてロードされます。

この混乱のもっとも一般的な原因は、おそらく free コマンドにあるでしょう:

$ free -m

             total       used       free     shared    buffers     cached
Mem:          1009        741        267          0        104        359
-/+ buffers/cache:        278        731
Swap:         1537          0       1537

-/+ buffers/cache: の行に注目してください —— メモリ量の表現は、実際には「現在使用中」と「利用可能」なメモリ量であり、「未使用」なのではありません。

上記の例では、1GB の RAM を積んだラップトップで、アイドル状態のターミナルとウェブブラウザを開いただけでその 741MB を使用しています! しかし、上記の "-/+ buffers/cache:" で始まる行を見てください。「現在使用中」なのは 278MB に過ぎません。実際には 731MB は新しいデータのために「利用可能」なのです。一見すると、「使用中」メモリの内の 104MB がバッファデータであり、359MB がキャッシュデータであるかのように見えてしまいますが、それぞれは必要なときにクリアされます。全メモリ中の 267MB のみが真の意味で「free」なのです。

もしあなたの好奇心が刺激されたなら、こちらの素晴らしい記事も読んでみてください。

こちらのウェブサイトでもこの混乱を整理して説明しています: http://www.linuxatemyram.com/

わたしのディスクの空き領域はどこへ行ってしまったの?

その答えはあなたのシステムによって変わります。こちらに優れたユーティリティの一覧がありますので試してみてください。

パッケージ管理

ファイル〇〇はどのパッケージに含まれていますか?

pkgfile コマンドで確認できます。

例:

$ pkgfile glxinfo

extra/mesa-demos

Xのパッケージにエラーがあったんだけど，どうしたらいいの？

まず，そのエラーはそもそもArch開発チームが修正できるものなのかどうかを見極めなければなりません．そうでない場合が往々にしてあります(例えばFirefoxのクラッシュは大抵の場合Mozillaチームのミスです)．これをアップストリーム・エラーと言います．もしArchの問題であるならば以下の手順を参考に対処してください．:

1. フォーラムに情報がないか探してみましょう．誰かが同じ問題について発言していないかチェックしてください．
2. 詳細な情報を書いたバグレポートを投函してください．
3. もしお望みならば，フォーラムに質問を投げてみてもよいでしょう．その際，問題の詳細と，あなたが既にバグ・レポートを送った旨を明記してください．それによって同じエラーに関する報告が大量に投函されるようなケースを回避できます．

Archのパッケージにはもっと適切な命名規則が必要だ。".pkg.tar.gz" とか ".pkg.tar.xz" なんて長すぎるし、ややこしい。

これに関しては、Arch のメーリングリスト上で議論されています。.pac のような拡張子を提案する人もいますが、現段階では、パッケージの拡張子を変更する具体的な計画はありません。Arch 開発者の一人である Tobias Kieslich の発言は示唆的です。「事実 package は gzip や xz で圧縮された tarball ファイルなわけじゃないか! だいたい tar が扱えるアプリケーションなら何だって開くことができるし、覗いて弄ることだってできるんだしさ。もっと言えば、mime-type なんてたいがいのアプリケーションが問題なく自動判別できるだろ?」

Pacman には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ．

バージョン3.0.0以降、pacman は libalpm ("Arch Linux Package Management" library) のフロントエンドになっています。このライブラリは代替のフロントエンドの開発を可能にしています (例えばGUIフロントエンドのような)。

どうして Pacman にはオフィシャルの GUI フロントエンドがないの？

The Arch Way，Arch Linux を読んでください．強いて言うならArch開発者チームが提供しようと思わないからです．ユーザー達が開発したものの中からご自由に選択して使ってください．Pacman GUI フロントエンドには選りすぐりがリストアップされています．

Pacman に X の機能を付けるべきだ！

The Arch Way，Arch Linuxを読んでください．Archの哲学は「シンプルたれ」です．もしあなたがご自身のアイデアにメリットがあると考え，それがくだんのシンプルのお題目を毀損しないものなら，是非フォーラムに投げて議論してください．また，フォーラムをちゃんとチェックしてしかるべきです．ここは重要だと思われる機能について要望を出す，まさにそのための場所なのです．

もっとも，ある機能をPacmanやArch Linuxに追加するために一番良い方法は，あなた自身がそれを実装することです．そのパッチがオフィシャルに取り込まれるかどうかはわかりませんが，いずれにせよあなたの骨折りは他のユーザーによって吟味され，検討されるでしょう．

Arch には，安定版パッケージの branch が必要だ。

何事にも絶対はありません。これに関してはいくつかの議論があります:
https://bbs.archlinux.org/viewtopic.php?id=11288

また、より安定したサーバ運用のためのコミュニティプロジェクト ArchServer^{[リンク切れ 2014-04-04]} もあります。

数種のリポジトリがありますが，どんな違いがあるんでしょうか？

公式リポジトリ を参照してください．

X のパッケージをインストールしたんだけど，どうやって起動するの?

あなたが KDE や GNOME のようなデスクトップ環境を導入しているのなら、そのプログラムは自動的にメニューに登録されている筈です。ターミナルから起動しようとしていて、バイナリの名前がわからないというような場合は、次のコマンドで確認してください:

$ pacman -Qlq パッケージ名 | grep /usr/bin/

公式リポジトリにある共用ライブラリはそれぞれどうして一つのバージョンしか用意されてないんですか?

Debian などの一部のディストリビューションは、共用ライブラリパッケージにおいて libfoo1、libfoo2、libfoo3 といったように複数のバージョンを用意しています。この方法では同一のシステム上で異なるバージョンの libfoo ごとにアプリケーションのコンパイルが可能となります。

Debian と異なり、Arch はローリングリリースで最先端のディストリビューションです。最先端のディストリビューションの最大の特徴はそのリポジトリから最新バージョンのソフトウェアが入手可能であることです。Arch のようなディストリビューションの場合、すべてのパッケージで公式にサポートされているのは最新バージョンのみであることを意味します。過去のソフトウェアをサポートしないことで、パッケージメンテナは新しいバージョンの作業に割く時間をより多くとることができます。共有ライブラリの新しいバージョンがアップストリームからリリースされると、それはすぐにリポジトリに追加され、影響を受けるパッケージは新しいライブラリに合わせてリビルドされます。

もし、システム全体のアップグレード（pacman -Syu）で共用ライブラリがアップデートされたのにそれに依存するアプリケーションがアップデートされなかったらどうなりますか?

それは起こってはならないシナリオです。公式リポジトリに foobaz というアプリケーションがあり、libbaz という共用ライブラリの新バージョンを使用してビルドされているとして、それは libbaz のアップデートに合わせてアップデートされます。しかしもし、それがうまくいかない場合、そのパッケージ foobaz にはバージョン制限のある依存関係 (例: libbaz=1.5) が指定され、libbaz のアップグレードの際に pacman によってコンフリクトを理由に削除されます。

もし foobaz が、あなた自身でビルドした、あるいは AUR からインストールしたパッケージであった場合には、新バージョンの libbaz で foobaz をリビルドしてみてください。ビルドが失敗した場合には foobaz の開発者にそのバグを報告してください。

リポジトリのカーネルにメジャーアップデートがあったのに、ドライバが最新カーネル用にアップデートされないことはあり得ますか?

いいえ、ありえません。例えば 3.5.x から 3.6.x といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、catalyst^AUR などの非サポートパッケージを使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。非サポートパッケージは自身の責任において使用してください。

Arch はパッケージに署名を採用していますか?

はい、パッケージ署名は pacman バージョン 4 から実装されました。詳しい情報は pacman-key をご覧ください。

アップグレードの前にやっておいたほうがいい事はありますか?

それは Arch Linux にとってとても大事なことです。アップグレード時、Enter を叩く前に、公式サイトの Arch news (RSS で購読できます) と アナウンスメントメーリングリストを、あとできれば フォーラムやその他のメーリングリストもチェックしてください。なにがしかの特殊な作業が必要な場合にはそれについて説明されています。

パッケージのアップデートがリリースされているのに、pacman はシステムは最新だと出力する

pacman のミラーはすぐに同期されるわけではありません。アップデートが利用できるようになるまで24時間以上かかることもあります。アップデートが下りてくるのを待つか、別のミラーを使ってみて下さい。MirrorStatus で最新のミラーを確認できます。

インストール

Arch はもっと良いインストーラーを付けるべきだ。たとえば GUI インストーラーとか。

ローリングリリースモデルを採用している Arch ではインストールそのものを滅多に行わないため、その優先度は開発者やユーザにとって高くありません。インストールガイドおよびビギナーズガイドはコマンドラインから行う方式に全面的に改められました。それでもインストーラに興味のある方は Archboot の利用も検討してみてください。

Arch をインストールしたんですが、シェルのログイン画面が表示されてます! どうすれば良いのでしょう?

ビギナーズガイドを参照してください。

デスクトップ環境やウィンドウマネージャはどれを使えばいいですか?

たくさんありますので、あなたに一番あったものを使えばいいのです。どのようなデスクトップ環境やウィンドウマネージャがあるかは、デスクトップ環境やウィンドウマネージャで説明されています。

Arch は「ミニマルな基本システムから構築していくディストリビューションで、ユーザが本当に望むものだけをインストールできる」ということをうたい文句にしていますが、これって他のディストリビューションでもできますよね? この点に関して一体 Arch のどこがユニークなんですか?

確かに一部のディストリビューションは Arch と近い設計理念を持っており、同じようにミニマルなインストール・メソッドを提供してるかも知れませんが、いくつかの相違は指摘しておかねばなりません:

1. Arch は骨の髄まで軽量でミニマルな環境を構築することを想定してデザインされています。
2. Arch はこのミニマルな基本システムから構築する以外に方法を提供していません。
3. ディストリビューション全体と同様、インストレーションに関しても原則的に K.I.S.S.("Keep It Simple and Stupid") の設計理念に基づいています。これによって Arch のベースシステムは、対象となるユーザーベースとの間に、これ以上はないというくらいの親和性を獲得しています。
4. サービス及びパッケージのインストールでは、手動あるいは対話式に構成設定を行わなければなりません。他のディストリビューションと異なり、サービスの構成や起動設定を自動で行ったりはしません。Arch の哲学は、そのような責任を扱う権利をユーザーから奪わず、ユーザの力量に任せることに重きをおいています。
5. Arch のパッケージングはミニマルであるよう設計されており、利用状況によっては必要となる“任意の”依存パッケージは自動インストールされません。それらはパッケージのインストール時に通知されるだけなので、結果的によりスリムなシステムになるのです。
6. Arch は完全なドキュメント群を提供しており、これによって各ユーザーのシステム構築のプロセスを一通り補助しています。

64ビット

私のプロセッサが x86_64 に対応しているかどうかを知る方法は？

Linux ユーザー

以下のコマンドを実行してください:

$ less /proc/cpuinfo

flags エントリーを探してください。 lm フラグがあったら、あなたのプロセッサーは x86_64 対応です。

もしくは以下のコマンドを実行してみることも出来ます:

$ grep -q "^flags.*\blm\b" /proc/cpuinfo && echo "x86_64" || echo "not x86_64"

Windows ユーザー

フリーウェアである CPU-Z を使って、64ビット互換があるかどうか確認できます。AMD の命令セットである AMD64 または Intel の命令セット EM64T は x86_64 のバイナリと互換性があります。

64ビットにする理由は？

多くの状況下で (32ビットに比べて) 高速であり、通常の i686 カーネルでは PAE が無効化されているために利用できないアドレス空間配置のランダム化 (ASLR) や 位置独立コード (PIC)、NX ビットを使用することによりセキュリティが向上することが挙げられます。もしコンピューターに 4GB 以上のメモリが載っている場合、32ビット OS では利用できない分のメモリも使用することができるので、ぜひ64ビットを使用するべきでしょう。

更に、64ビットの拡張をサポートしている新しい x86 CPU に対して、レガシーな32ビットの CPU をプログラマーがサポートしなくなってきているというのもあります。

以上の理由が32ビット環境を避けるべきという我々のアドバイスですが、カーネルやユーザースペース、個々のプログラムなど、64ビットの方が優れているものは他にもたくさんあり、全てをここに書き出す事は出来ません。

差異のレポートも見てください。32/64ビットのパッケージバージョンの比較を行うことが出来ます。

再インストールせずに i686 環境から x86_64 環境にアップグレード出来ますか？

できません。厳格に言えば、環境の移行とは、全てのパッケージを新しいアーキテクチャ向けに再インストールするということを意味します。ただし、新規インストールをすることなく、現在インストールされているシステムから、環境を移行することは可能です。このフォーラムスレッドの手順に従えば、設定やデータを失うことなく、32ビットから64ビットに移行できます。移行には外付けのハードドライブを使用するので注意してください。

もしくは、Arch64 インストール CD でシステムを起動し、ディスクをマウントして、32ビットバイナリ以外の、残しておきたいデータ (例えば /home や /etc など) をバックアップして、インストールします。

詳しくは再インストールせずにアーキテクチャを移行を読んでください。