FAQ

関連記事

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

一般

Arch Linux って何ですか？

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

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

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

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

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

Arch は x86_64 (別名 amd64) アーキテクチャのみをサポートしています。i686 のサポートは2017年11月に切られました [1]。

There are unofficial ports for the i686 architecture [2] and ARM CPUs [3], each with their own community channels. [4]

Arch は Linux Foundation の標準ファイルシステム階層 (FHS) に準拠していますか？

Arch Linux は systemd サービスマネージャを使用するオペレーティングシステムのファイルシステム階層を遵守しています。ディレクトリの説明については file-hierarchy(7) を見てください。特に Arch では /bin, /sbin, /usr/sbin は /usr/bin のシンボリックリンクに、/lib と /lib64 は /usr/lib のシンボリックリンクになっています。

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

もしあなたが初心者で、それでもなお Arch を使おうとしているのであれば、あなたは十分な時間を費やして学ぶことに喜びを覚えるようでなければなりません。また Arch が全く "Do-It-Yourself" なディストリビューションとして設計されている、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。

質問をする前にまず自分で調査するようにしてください。Google やフォーラム、そして素晴らしいドキュメントが用意されている Arch Wiki の検索を活用しましょう。There is a reason these resources were made available to you in the first place. 途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。

Arch 用語集#RTFM や インストールガイド も見てください。

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

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

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

どうぞ積極的に参加してください．あなた自身がコードや解決策を提示することでコミュニティに貢献しましょう．もし，コミュニティや開発チームから認められれば，あなたのコードはマージされるかも知れません．Archコミュニティはコードやツールの提供，シェアによって活性化していきます．

いつ新しいリリースが出るんでしょうか？

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

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

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

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

現状でもう十分な量のArchについての記事が書かれています．Archの目標は巨大になることではなく; rather, organic, sustainable growth occurs naturally amongst the target user base.

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

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

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

ネットワークは正しく設定されていますか？ネットワーク設定のページを参照してください。

また、Arch ではデフォルトでトラフィックシェーピングが有効になっていないことも注意してださい。従って、it is possible that if a program on it somehow utilizes your internet connection to the full – regardless if it is over P2P or classic client-server connections – other local ones will find it clogged, resulting in severe lags and timeouts. Shorewall や Vuurmuur などのファイアウォール; there are also static scripts for iproute2 (such as this derivative of Wondershaper) によってネットワークレイヤーのシェーピングを行うことができます。

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

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

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

We could distinguish the difference from free command:

$ free -h

              total        used        free      shared  buff/cache   available
Mem:           2.8G        1.1G        283M        224M        1.4G        1.2G
Swap:          3.0G        881M        2.1G

It is important to note the difference between "free" and "available" memory. In the above example, a laptop with 2.8G of total RAM appears to be using most of it, with only 283M as free memory. However, 1.4G of it is "buff/cache". There is still 1.2G available for starting new applications, without swapping. See man free(1) for detail. The result of all this? Performance!

もしあなたの好奇心が刺激されたなら、こちらの素晴らしい記事も読んでみてください。こちらのウェブサイトでもこの混乱を整理して説明しています: http://www.linuxatemyram.com/

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

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

パッケージ管理

See the pacman, en2:pacman/Tips and tricks and en2:Official repositories pages for more answers.

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

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

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

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

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

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

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

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

If you think an idea has merit, you may choose to discuss it on pacman-dev. Also check https://bugs.archlinux.org/index.php?project=3 for existing feature requests.

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

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

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

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

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

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

Arch のようなディストリビューションの場合、すべてのパッケージで公式にサポートされているのは最新バージョンのみであることを意味します。過去のソフトウェアをサポートしないことで、パッケージメンテナはensuring that the newest versions work as expectedに割く時間をより多くとることができます。共有ライブラリの新しいバージョンがアップストリームからリリースされると、それはすぐにリポジトリに追加され、影響を受けるパッケージは新しいライブラリに合わせてリビルドされます。

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

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

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

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

いいえ、ありえません。例えば 3.5.x から 3.6.x といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、catalyst^AUR などの非サポートパッケージを使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。Users are responsible for updating any unsupported driver packages that they have installed.

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

Follow the en2:System maintenance#Upgrading the system section.

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

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

上流のプロジェクト X が新しいバージョンをリリースしています。Arch パッケージとして新しいバージョンにアップデートできるようになるまでにかかる時間は？

パッケージアップデートは準備ができ次第リリースされます。上流リリースがマイナーなバグ修正のみであれば数時間でパッケージがアップデートされることもありますし、メジャーアップデートであれば数週間後となることもあります。上流の新しいバージョンが Arch にリリースされるまでの時間はそのパッケージとパッケージメンテナによって変わります。一部のパッケージは testing リポジトリでしばらくテストされるため、パッケージが更新されるまでの時間が長い傾向にあります。パッケージメンテナは安定版のアップデートをリポジトリで素早く提供できるように尽力しています。公式リポジトリのパッケージが古くなっていることに気づいたら、パッケージウェブサイト から out-of-date フラグを立てて報告してください。

If I need an older version of an installed library, can I just symlink to the newer version?

If you are lucky, it might work, for a time. Regardless, it is not a proper solution, because:

• Libraries do not change versions randomly - the API/ABI will have likely changed (possibly with bits removed), and whether those changes affect the usage is just a matter of luck.
• The symlink would be untracked by a package manager. Newbies who immediately try to hack on system library files are in the greatest risk of making an unwanted change that they cannot diagnose/fix, which a package manager helps to guard against.
• A slight alternative of dumping the old library file into the filesystem, untracked, would be forgotten about, and not have potential security bugs noticed/patched.

Instead, e.g. use/write a compat package, which provides the required library version.

インストール

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

Arch used to have an installer with a text-based user interface called the Arch Installation Framework (AIF). After its last maintainer left, it was deprecated in favor of Arch Install Scripts. Arch ではインストールそのものを滅多に行わないため(read the rest of this article to know more about what rolling release means)、その優先度は開発者やユーザにとって高くありません。インストールガイドはコマンドラインから行う方式に全面的に改められました。

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

一般的な推奨事項を参照してください。

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

たくさんありますので、あなたに一番あったものを使えばいいのです。デスクトップ環境やウィンドウマネージャも参照してください。

他の「ミニマル」なディストリビューションと比べて Arch のどこがユニークなんですか？

See en2:Arch compared to other distributions.

64ビット

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

If your processor is x86_64 compatible, you will have the lm (long mode) flag in /proc/cpuinfo. For example,

$ grep -w lm /proc/cpuinfo

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

64ビットにする理由は？

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

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

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