Gentoo Linux mips ハンドブック: Gentoo をインストールする
はじめに
ようこそ
Gentoo へようこそ! Gentoo は、ほぼすべてのアプリケーションまたはニーズに応じて自動的に最適化してカスタマイズできる、Linux ベースの自由なオペレーティングシステムです。Gentoo は自由なソフトウェアのエコシステムの上に成り立っており、内部をユーザに隠匿することがありません。
オープンさ
Gentoo の主要なツールはシンプルなプログラミング言語から構成されています。Gentoo のパッケージ管理システムである Portage は、Python で書かれています。Portage のためにパッケージ定義を提供する ebuild は、bash で書かれています。Gentoo ユーザは、Gentoo のすべての部分のソースコードを自由に確認、変更、向上させることができます。
デフォルトでは、バグ修正または Gentoo 内での相互運用性のために必要なときだけ、パッケージにパッチが当てられます。上流のプロジェクトが提供するソースコードをバイナリ形式にコンパイルすることによって、パッケージがインストールされます (コンパイル済みバイナリパッケージにも対応はしていますが)。Gentoo の設定はテキストアフィルによって行われます。
上述の理由などから: オープンさは設計原則として組み込まれています。
選択
選択もまた Gentoo の設計原則のひとつです。
Gentoo のインストール中、ハンドブック全体を通して選択は明らかにされます。システム管理者は、完全にサポートされているふたつの init システム (Gentoo 自身による OpenRC と Freedesktop.org の systemd)、ストレージディスクのためのパーティション構造、そのディスクで使うファイルシステム、ターゲットシステムのプロファイル、USE フラグを利用した、グローバルな (システム全体の) レベルまたはパッケージ単位レベルでの機能の削除と追加、ブートローダ、ネットワーク管理ユーティリティ、などなど非常に多くのことに関して選択権を持っています。
開発思想として、Gentoo 開発者はユーザを特定のシステムプロファイルまたはデスクトップ環境を押し付けることが無いように努めています。GNU/Linux のエコシステム内で提供されるものは、Gentoo でもおそらく利用可能です。そうでない場合は、是非確認させてください。新しいパッケージのリクエストのためには、バグレポートを開くか、自身の ebuild リポジトリを作成してください。
性能
Gentoo はソースベースのオペレーティングシステムなので、新しいコンピュータ命令セットアーキテクチャにも移植することができ、かつインストールされたすべてのパッケージを調整された状態にすることができます。この強みはもうひとつの Gentoo の設計原則、性能の表れでもあります。
Gentoo のインストールとカスタマイズを完了することができれば、システム管理者はソースコードからコンパイルして調整されたオペレーティングシステムを得られます。Portage の make.conf ファイル内に含まれている仕組みを通じて、オペレーティングシステム全体をバイナリレベルで調整することができます。のぞむなら、パッケージ単位またはパッケージグループ単位での調整も行えます。実際のところ、すべての機能は USE フラグを利用して追加または削除することができます。
これらの設計原則が Gentoo をユニークにしているものであることを、ハンドブック読者が理解していることは、きわめて重要です。この優れた性能、多数の選択肢、そして究極のオープンさを強調しているため、Gentoo を使用するときは、注意力、熟慮、そして明確な意図を持って行うべきです。
インストール作業の順序
Gentoo のインストール作業工程は、次章以降で説明する10のステップに分けられます。それぞれの段階を適切に完了させましょう。
ステップ | 結果 |
---|---|
1 | Gentoo をインストール可能な作業環境にします。 |
2 | Gentoo をインストールするためのインターネット接続の準備が完了します。 |
3 | インストールする Gentoo をホストするハードディスクを初期化します。 |
4 | インストールする環境を準備し、新たな環境にユーザーが chroot 可能にします。 |
5 | Gentoo をインストールする全ての場合に共通する中核的なパッケージをインストールします。 |
6 | Linux カーネルをインストールします。 |
7 | Gentoo システムの設定ファイルの大部分が作成されます。 |
8 | 必要なシステムツールをインストールします。 |
9 | 適切なブートローダーもインストールし設定します。 |
10 | インストールしたての Gentoo Linux 環境に繰り出す準備が完了します。 |
このハンドブックでは、一定の選択肢を提示したときには必ず、賛否両論の併記に努めます。デフォルトの選択肢で進める記載をした際にも(見出しに「デフォルト:」と記載)、他に取りうる選択肢も記載します(見出しに「代替案:」と記載)。決して、「デフォルトは Gentoo のお勧めだ」と考えないでください。デフォルトはあくまでも、多くのユーザーが採用すると思われる選択肢にすぎません。
ときには、追加可能な手順が続くことがあります。そのような手順は「追加可能:」と記載します。つまりこの手順は、Gentoo のインストール自体には必須ではありません。とはいえ、以前にした決断によっては必須になる追加手順もあります。その際には、その追加手順の説明の直前に、この旨を明記するとともに、原因となった決断をした時期も記載します。
Gentoo のインストール方法
Gentoo は、さまざまな方法でインストールすることができます。ダウンロードしてインストールすることも、起動可能なISOイメージのような公式インストールメディアからインストールすることもできます。インストールメディアは USB メモリにインストールすることも、ネットワークブートすることもできます。さらには、インストール済の異なるディストリビューション環境や、(例えば Knoppix のような)Gentoo 以外のブータブルディスクといった非公式メディアからインストールすることも可能です。
この文書が扱っているのは、公式の Gentoo インストールメディアを用いる方法と、場合によってはネットワークブートによる方法です。
Gentoo 以外の起動可能なメディアを用いる場合などの、ほかのインストール方法については、代替のインストールガイドを読んでください。
また、我々が提供している Gentoo インストールのヒントとトリックという文書も役にたつかもしれません。
トラブルがあったときは
インストール中に (またはインストールを説明しているハンドブックに) 何か問題を見つけたら、バグトラッキングシステムで既知のバグとして報告されていないかどうか、確認してみてください。 もし無いようであれば、私たちが対応できるように、その問題をバグ報告してください。 その (あなたが報告した) バグを担当する開発者たちを恐れないでください。取って喰われるようなことは (滅多に) ありませんから。
あなたが今読んでいる文書は、特定のアーキテクチャ向けということになっていますが、 他のアーキテクチャの情報も、その中に紛れ込んでしまっているかもしれない、ということを一応、先に言っておきます。これはGentooハンドブックの多くの部分が、全てのアーキテクチャに共通のテキストを使用していることに因ります (重複作業を減らすため)。混乱しないように、このような参照は最小限に抑えています。
その問題が、ユーザーの問題 (文書をよく読んだにもかかわらず起きたあなたのミス) なのか、ソフトウェアの問題 (インストール/文書をよくテストしたにもかかわらず起きた私たちのミス) なのか、はっきりしないときには、irc.libera.chat の #gentoo (webchat) チャンネルに気軽に参加してみてください。そんなときじゃなくても全然かまわないんですけどね。
そういえば、Gentoo について何か分からないことがあったら、よくある質問を見てみてください。Gentoo Forums 上にある FAQs もあります。
ハードウェア要件
CPU (Big Endian port) | MIPS3, MIPS4, MIPS5 or MIPS64-class CPU |
---|---|
CPU (Little Endian port) | MIPS4, MIPS5 or MIPS64-class CPU |
Memory | 128 MB |
Disk space | 3.0 GB (excluding swap space) |
Swap space | At least 256 MB |
For more information, read MIPS Hardware Requirements.
Installation notes
On many architectures, the processor has gone through several generations, each newer generation builds on the foundation of the previous one. MIPS is no exception. There are several generations of CPU covered under the MIPS architecture. In order to choose the right netboot image stage tarball and CFLAGS appropriately, it is necessary to be aware of which family the system's CPU belongs in. These families are referred to as the Instruction Set Architecture.
MIPS ISA | 32/64-bit | CPUs Covered |
---|---|---|
MIPS 1 | 32-bit | R2000, R3000 |
MIPS 2 | 32-bit | R6000 |
MIPS 3 | 64-bit | R4000, R4400, R4600, R4700 |
MIPS 4 | 64-bit | R5000, RM5000, RM7000 R8000, R9000, R10000, R12000, R14000, R16000 |
MIPS 5 | 4-bit | None As Yet |
MIPS32 | 32-bit | AMD Alchemy series, 4kc, 4km, many others... There are a few revisions in the MIPS32 ISA. |
MIPS64 | 64-bit | Broadcom SiByte SB1, 5kc ... etc... There are a few revisions in the MIPS64 ISA. |
The MIPS5 ISA level was designed by Silicon Graphics back in 1994, but never actually got used in a real life CPU. It lives on as part of the MIPS64 ISA.
The MIPS32 and MIPS64 ISAs are a common source of confusion. The MIPS64 ISA level is actually a superset of the MIPS5 ISA, so it includes all instructions from MIPS5 and earlier ISAs. MIPS32 is the 32-bit subset of MIPS64, it exists because most applications only require 32-bit processing.
Also, another important concept to grasp is the concept of endianness. Endianness refers to the way that a CPU reads words from main memory. A word can be read as either big endian (most significant byte first), or little endian (least significant byte first). Intel x86 machines are generally Little endian, whilst Apple and Sparc machines are Big Endian. On MIPS, they can be either. To separate them apart, we append el to the architecture name to denote little endian.
Architecture | 32/64-bit | Endianness | Machines covered |
---|---|---|---|
mips | 32-bit | Big Endian | Silicon Graphics |
mipsel | 32-bit | Little Endian | Cobalt Servers |
mips64 | 64-bit | Big Endian | Silicon Graphics |
mips64el | 64-bit | Little Endian | Cobalt Servers |
For those willing to learn more about ISAs, the following websites may be of assistance:
- Linux/MIPS Website: MIPS ISA
- Linux/MIPS Website: Endianness
- Linux/MIPS Website: Processors
- Wikipedia: Instruction Set
Netbooting overview
In this section, we'll cover what is needed to successfully network boot a Silicon Graphics workstation or Cobalt Server appliance. This is just a brief guide, it is not intended to be thorough, for more information, it is recommended to read the Diskless nodes article.
Depending on the machine, there is a certain amount of hardware that is needed in order to successfully netboot and install Linux.
- In General:
- DHCP/BOAMD Alchemy series, 4kc, 4km, many others... There are a few revisions in the MIPS32 ISA.OTP server (ISC DHCPd recommended)
- Patience -- and lots of it
- For Silicon Graphics workstations:
- TFTP server (tftp-hpa recommended)
- When the serial console needs to be used:
- MiniDIN8 --> RS-232 serial cable (only needed for IP22 and IP28 systems)
- Null-modem cable
- VT100 or ANSI compatible terminal capable of 9600 baud
- For Cobalt Servers (NOT the original Qube):
- NFS server
- Null-modem cable
- VT100 or ANSI compatible terminal capable of 115200 baud
SGI machines use a MiniDIN 8 connector for the serial ports. Apparently Apple modem cables work just fine as serial cables, but with Apple machines being equipped with USB & internal modems, these are getting harder to find. One wiring diagram is available from the Linux/MIPS Wiki, and most electronics stores should stock the plugs required.
For the terminal, this could be a real VT100/ANSI terminal, or it could be a PC running terminal emulation software (such as HyperTerminal, Minicom, seyon, Telex, xc, screen - whatever your preference). It doesn't matter what platform this machine runs - just so long as it has one RS-232 serial port available, and appropriate software.
This guide does NOT cover the original Qube. The original Qube server appliance lacks a serial port in its default configuration, and therefore it is not possible to install Gentoo onto it without the aid of a screwdriver and a surrogate machine to do the installation.
Setting up TFTP and DHCP
As mentioned earlier -- this is not a complete guide, this is a bare-bones config that will just get things rolling. Either use this when starting a setup from scratch, or use the suggestions to amend an existing setup to support netbooting.
It is worth noting that the servers used need not be running Gentoo Linux, they could very well be using FreeBSD or any Unix-like platform. However, this guide will assume to be using Gentoo Linux. If desired, it is also possible to run TFTP/NFS on a separate machine to the DHCP server.
The Gentoo/MIPS Team cannot help with setting up other operating systems as netboot servers.
First Step -- configuring DHCP. In order for the ISC DHCP daemon to respond to BOOTP requests (as required by the SGI & Cobalt BOOTROM) first enable dynamic BOOTP on the address range in use; then set up an entry for each client with pointers to the boot image.
root #
emerge --ask net-misc/dhcp
Once installed, create the /etc/dhcp/dhcpd.conf file. Here's a bare-bones config to get started.
# Tell dhcpd to disable dynamic DNS.
# dhcpd will refuse to start without this.
ddns-update-style none;
# Create a subnet:
subnet 192.168.10.0 netmask 255.255.255.0 {
# Address pool for our booting clients. Don't forget the 'dynamic-bootp' bit!
pool {
range dynamic-bootp 192.168.10.1 192.168.10.254;
}
# DNS servers and default gateway -- substitute as appropriate
option domain-name-servers 203.1.72.96, 202.47.56.17;
option routers 192.168.10.1;
# Tell the DHCP server it's authoritative for this subnet.
authoritative;
# Allow BOOTP to be used on this subnet.
allow bootp;
}
With that setup, one can then add any number of clients within the subnet clause. We will cover what to put in later in this guide.
Next step - Setting up TFTP server. It is recommended to use tftp-hpa as it is the only TFTP daemon known to work correctly. Proceed by installing it as shown below:
root #
emerge --ask net-ftp/tftp-hpa
This will create /tftproot to store the netboot images. Move this elsewhere if necessary. For the purposes of this guide, it is assumed that it is kept in the default location.
Netbooting on SGI stations
Downloading a netboot image
Depending on the system the installation is meant for, there are several possible images available for download. These are all labelled according to the system type and CPU they are compiled for. The machine types are as follows:
Codename | Machines |
---|---|
IP22 | Indy, *Indigo 2, Challenge S |
IP26 | *Indigo 2 Power |
IP27 | Origin 200, Origin 2000 |
IP28 | *Indigo 2 Impact |
IP30 | Octane |
IP32 | O2 |
Indigo 2 - It is a common mistake to mix up the IRIS Indigo (IP12 w/ R3000 CPU or IP20 with a R4000 CPU, neither of which run Linux), the Indigo 2 (IP22, which runs Linux fine), the R8000-based Indigo 2 Power (which doesn't run Linux at all) and the R10000-based Indigo 2 Impact (IP28, which is highly experimental). Please bear in mind that these are different machines.
Also in the filename, r4k refers to R4000-series processors, r5k for R5000, rm5k for the RM5200 and r10k for R10000. The images are available on the Gentoo mirrors.
DHCP configuration for an SGI client
After downloading the file, place the decompressed image file in the /tftproot/ directory. (Use bzip2 -d to decompress). Then edit the /etc/dhcp/dhcpd.conf file and add the appropriate entry for the SGI client.
subnet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx {
# ... usual stuff here ...
# SGI Workstation... change 'sgi' to your SGI machine's hostname.
host sgi {
# MAC Address of SGI Machine. Normally this is written on the back
# or base of the machine.
hardware ethernet 08:00:69:08:db:77;
# TFTP Server to download from (by default, same as DHCP server)
next-server 192.168.10.1;
# IP address to give to the SGI machine
fixed-address 192.168.10.3;
# Filename for the PROM to download and boot
filename "/gentoo-r4k.img";
}
}
Kernel options
We're almost done, but there's a couple of little tweaks still to be done. Pull up a console with root privileges.
Disable "Path Maximum Transfer Unit", otherwise SGI PROM won't find the kernel:
root #
echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
Set the port range usable by the SGI PROM:
root #
echo "2048 32767" > /proc/sys/net/ipv4/ip_local_port_range
This should be sufficient to allow the Linux server to play nice with SGI's PROM.
Starting the daemons
At this point, start the daemons.
root #
/etc/init.d/dhcp start
root #
/etc/init.d/in.tftpd start
If nothing went wrong in that last step then everything is all set to power on the workstation and proceed with the guide. If the DHCP server isn't firing up for whatever reason, try running dhcpd on the command line and see what it says - if all is well, it should just fork into the background, otherwise it will display 'exiting.' just below its complaint.
An easy way to verify if the tftp daemon is running is to type the following command and confirm the output:
root #
netstat -al | grep ^udp
udp 0 0 *:bootpc *:* udp 0 0 *:631 *:* udp 0 0 *:xdmcp *:* udp 0 0 *:tftp *:* <-- (look for this line)
Netbooting the SGI station
Okay, everything is set, DHCP is running as is TFTP. Now it is time to fire up the SGI machine. Power the unit on - when "Running power-on diagnostics" comes on the screen, either click "Stop For Maintenance" or press Escape. A menu similar to the following will show up.
Running power-on diagnostics
System Maintenance Menu 1) Start System 2) Install System Software 3) Run Diagnostics 4) Recover System 5) Enter Command Monitor Option?
Type in 5 to enter the command monitor. On the monitor, start the BootP process:
>>
bootp(): root=/dev/ram0
From this point, the machine should start downloading the image, then, roughly 20 seconds later, start booting Linux. If all is well, a busybox ash shell will be started as shown below and the installation of Gentoo Linux can continue.
init started: BusyBox v1.00-pre10 (2004.04.27-02:55+0000) multi-call binary
Gentoo Linux; http://www.gentoo.org/
Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL
Gentoo/MIPS Netboot for Silicon Graphics Machines
Build Date: April 26th, 2004
* To configure networking, do the following:
* For Static IP:
* /bin/net-setup <IP Address> <Gateway Address> [telnet]
* For Dynamic IP:
* /bin/net-setup dhcp [telnet]
* If you would like a telnetd daemon loaded as well, pass "telnet"
* As the final argument to /bin/net-setup.
Please press Enter to activate this console.
Troubleshooting
If the machine is being stubborn and refusing to download its image, it can be one of two things:
- The instructions were not followed correctly, or
- It needs a little gentle persuasion (No, put that sledge hammer down!)
Here's a list of things to check:
- dhcpd is giving the SGI Machine an IP Address. There should be some messages about a BOOTP request in the system logs. tcpdump is also useful here.
- Permissions are set properly in the tftp folder (typically /tftproot/ - should be world readable)
- Check system logs to see what the tftp server is reporting (errors perhaps)
If everything on the server is checked, and timeouts or other errors occur on the SGI machine, try typing this into the console.
>>
resetenv
>>
unsetenv netaddr
>>
unsetenv dlserver
>>
init
>>
bootp(): root=/dev/ram0
Netbooting on Cobalt stations
Overview of the netboot procedure
Unlike the SGI machines, Cobalt servers use NFS to transfer their kernel for booting. Boot the machine by holding down the left & right arrow buttons whilst powering the unit on. The machine will then attempt to obtain an IP number via BOOTP, mount the /nfsroot/ directory from the server via NFS, then try to download and boot the file vmlinux_raq-2800.gz (depending on the model) which it assumes to be a standard ELF binary.
Downloading a Cobalt netboot image
Inside http://distfiles.gentoo.org/experimental/mips/historical/netboot/cobalt/ the necessary boot images for getting a Cobalt up and running are made available. The files will have the name nfsroot-KERNEL-COLO-DATE-cobalt.tar - select the most recent one and unpack it to / as shown below:
root #
tar -C / -xvf nfsroot-2.6.13.4-1.19-20051122-cobalt.tar
NFS server configuration
Since this machine uses NFS to download its image, it is necessary to export /nfsroot/ on the server. Install the net-fs/nfs-utils package:
root #
emerge --ask net-fs/nfs-utils
Once that is done, place the following in the /etc/exports file.
/nfsroot *(ro,sync)
Now, once that is done, start the NFS server:
root #
/etc/init.d/nfs start
If the NFS server was already running at the time, tell it to take another look at its exports file using exportfs.
root #
exportfs -av
DHCP configuration for a Cobalt machine
Now, the DHCP side of things is relatively straightforward. Add the following to the /etc/dhcp/dhcpd.conf file.
subnet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx {
# ... usual stuff here ...
# Configuration for a Cobalt Server
# Set the hostname here:
host qube {
# Path to the nfsroot directory.
# This is mainly for when using the TFTP boot option on CoLo
# You shouldn't need to change this.
option root-path "/nfsroot";
# Cobalt server's ethernet MAC address
hardware ethernet 00:10:e0:00:86:3d;
# Server to download image from
next-server 192.168.10.1;
# IP address of Cobalt server
fixed-address 192.168.10.2;
# Location of the default.colo file relative to /nfsroot
# You shouldn't need to change this.
filename "default.colo";
}
}
Starting daemons
Now start the daemons. Enter the following:
root #
/etc/init.d/dhcp start
root #
/etc/init.d/nfs start
If nothing went wrong in that last step all should be set to power on the workstation and proceed with the guide. If the DHCP server isn't firing up for whatever reason, try running dhcpd on the command line and see what it tells - if all is well, it should just fork into the background, otherwise it will show 'exiting.' just below its complaint.
Netbooting the Cobalt machine
Now it is time to fire up the Cobalt machine. Hook up the null modem cable, and set the serial terminal to use 115200 baud, 8 bits, no parity, 1 stop bit, VT100 emulation. Once that is done, hold down the left and right arrow buttons whilst powering the unit on.
The back panel should display "Net Booting", and some network activity should be visible, closely followed by CoLo kicking in. On the rear panel, scroll down the menu until the "Network (NFS)" option then press Enter. Notice that the machine starts booting on the serial console.
...
elf: 80080000 <-- 00001000 6586368t + 192624t elf: entry 80328040 net: interface down CPU revision is: 000028a0 FPU revision is: 000028a0 Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes. Primary data cache 32kB 2-way, linesize 32 bytes. Linux version 2.4.26-mipscvs-20040415 (root@khazad-dum) (gcc version 3.3.3... Determined physical RAM map: memory: 08000000 @ 00000000 (usable) Initial ramdisk at: 0x80392000 (3366912 bytes) On node 0 totalpages: 32768 zone(0): 32768 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: console=ttyS0,115200 root=/dev/ram0 Calibrating delay loop... 249.85 BogoMIPS Memory: 122512k/131072k available (2708k kernel code, 8560k reserved, 3424k dat)
A busybox ash shell will pop up as shown below, from which the Gentoo Linux installation can continue.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 280k freed
init started: BusyBox v1.00-pre10 (2004.04.27-02:55+0000) multi-call binary
Gentoo Linux; http://www.gentoo.org/
Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL
Gentoo/MIPS Netboot for Cobalt Microserver Machines
Build Date: April 26th, 2004
* To configure networking, do the following:
* For Static IP:
* /bin/net-setup <IP Address> <Gateway Address> [telnet]
* For Dynamic IP:
* /bin/net-setup dhcp [telnet]
* If you would like a telnetd daemon loaded as well, pass "telnet"
* As the final argument to /bin/net-setup.
Please press Enter to activate this console.
Troubleshooting
If the machine is being stubborn and refusing to download its image, it can be one of two things:
- the instructions have not been followed correctly, or
- it needs a little gentle persuasion. (No, put that sledge hammer down!)
Here's a list of things to check:
- dhcpd is giving the Cobalt Machine an IP Address. Notice messages about a BOOTP request in the system logs. tcpdump is also useful here.
- Permissions are set properly in the /nfsroot/ folder (should be world readable).
- Make sure the NFS server is running and exporting the /nfsroot/ directory. Check this using exportfs -v on the server.
インストール CD を用いる
On Silicon Graphics machines, it is possible to boot from a CD in order to install operating systems. (This is how one installs IRIX for instance) Recently, images for such bootable CDs to install Gentoo have been made possible. These CDs are designed to work in the same way.
At the moment the Gentoo/MIPS Live CD will only work on the SGI Indy, Indigo 2 and O2 workstations equipped with R4000 and R5000-series CPUs, however other platforms may be possible in future.
The Live CD images can be found under the experimental/mips/livecd/ directory on a Gentoo mirror.
These CDs are highly experimental at this time. They may or may not work at this time. Please report success or failures either on Bugzilla, this forum thread or in the #gentoo-mips IRC channel.
</noinclude>
ネットワークの自動構成
もしかすると、もう機能していますか?
もしあなたのシステムが、IPv6 ルータか DHCP サーバを持つ Ethernet ネットワークに接続されているなら、おそらくシステムのネットワークは自動的に構成されているでしょう。追加の高度な構成が必要でない場合は、インターネット接続をテストすることができます。
DHCP を使う
DHCP (Dynamic Host Configuration Protocol) は、ネットワークの構成を支援し、IPアドレス、ネットワークマスク、ルート、DNS サーバ、NTP サーバ等を含む、さまざまなパラメータのための構成を自動で提供することができます。
DHCP は、クライアントがリースを要求するために、同一のレイヤ 2 (Ethernet) セグメント上でサーバが実行中である必要があります。DHCP はよく RFC1918 (プライベート) ネットワーク上で使用されますが、ISP からパブリック IP 情報を取得するためにも使用されます。
公式 Gentoo ブートメディアは起動時に dhcpcd を自動的に実行します。この挙動は、ブートメディアのカーネルコマンドラインに
nodhcp
引数を追加することで、無効化することができます。すでに実行されていない場合は、以下で dhcpcd を enp1s0 に対して開始することができます:
root #
dhcpcd enp1s0
DHCP サーバが提供するホスト名とドメイン名をシステムで使うようにと、ネットワーク管理者から要求されている場合もあるでしょう。そのような場合には:
root #
dhcpcd -HD enp1s0
dhcpcd を停止するには、-x を使用することができます:
root #
dhcpcd -x
sending signal Term to pid 10831 waiting for pid 10831 to exit
ネットワークのテスト
デフォルトルートが適切に構成されていることは、インターネット接続の重要な構成要素です。ルート構成は以下で確認できます:
root #
ip route
default via 192.168.0.1 dev enp1s0
デフォルトルートが定義されていないと、インターネット接続は利用できず、追加の構成が必要になります。
基本的なインターネット接続は ping で確認することができます:
root #
ping -c 3 1.1.1.1
ホスト名ではなく、既知の IP アドレスに ping することから始めるとよいでしょう。これにより、DNS の問題を他の基本的なインターネット接続の問題から切り分けることができます。
外向きの HTTPS アクセスと DNS 解決は、次で確認することができます:
root #
curl --location gentoo.org --output /dev/null
curl がエラーを報告したり、他のテストが失敗したりしない場合は、インストールプロセスをディスクの準備から続けることができます。
curl がエラーを報告するのに、インターネットへの ping が機能する場合は、DNS を構成する必要があるかもしれません。
インターネット接続が確立されていない場合は、まずインターフェース情報を検証すべきです。そして:
- net-setup を使用してネットワーク構成を支援することができます。
- アプリケーション固有の構成が必要かもしれません。
- 手動でのネットワーク構成を試すことができます。
インターフェースの情報を取得する
そのままの状態でネットワークが機能していない場合は、インターネット接続を有効化するために追加の段階を踏む必要があります。一般的に、最初の段階はホストのネットワークインターフェースを列挙することです。
sys-apps/iproute2 パッケージに含まれる ip コマンドは、システムネットワークの情報の問い合わせと、構成のために使用することができます。
link 引数を使用して、ネットワークインターフェースのリンクを表示することができます:
root #
ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 4: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether e8:40:f2:ac:25:7a brd ff:ff:ff:ff:ff:ff
address 引数を使用して、デバイスのアドレス情報を問い合わせることができます:
root #
ip address
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<pre> link/ether e8:40:f2:ac:25:7a brd ff:ff:ff:ff:ff:ff inet 10.0.20.77/22 brd 10.0.23.255 scope global enp1s0 valid_lft forever preferred_lft forever inet6 fe80::ea40:f2ff:feac:257a/64 scope link valid_lft forever preferred_lft forever
このコマンドの出力は、システム上の各ネットワークインターフェースごとの情報を含んでいます。エントリはデバイスのインデックス番号で始まり、デバイス名 (enp1s0) が続きます。
lo (loopback) 以外のインターフェースが表示されない場合は、ネットワークハードウェアに問題があるか、そのインターフェースのためのドライバがカーネルにロードされていないかです。どちらの状況も、このハンドブックの対象範囲を外れています。#gentoo (webchat) に助けを求めてください。
一貫性のために、このハンドブックではメインのネットワークインターフェース名は enp1s0 であると仮定します。
predictable network interface names へ移行した結果、システム上のインターフェース名は古い命名規則による eth0 とはかなり違うものになっているかもしれません。現代的な Gentoo ブートメディアは、eno0 や ens1 や enp5s0 などで始まるインターフェース名を使用します。
追加可能: アプリケーション固有の構成
以下の手法は一般的に必要ではありませんが、インターネット接続のために追加の構成が必要な状況では、役に立つことがあります。
web プロキシを設定する
web プロキシを経由してインターネットにアクセスしている場合は、Portage が対応している各プロトコルごとに正しくプロキシにアクセスできるように、プロキシ情報を定義する必要があります。Portage は wget および rsync の取得手法を介してパッケージをダウンロードするために、http_proxy、ftp_proxy、および RSYNC_PROXY 環境変数を参照します。
links など、特定のテキストモード web ブラウザも、web プロキシ設定を定義する環境変数を利用することができます。特に、HTTPS アクセスのために https_proxy 環境変数も定義する必要があるでしょう。Portage は追加の実行時パラメータを渡さなくても影響を受けますが、links にはプロキシ設定のパラメータを設定する必要があるでしょう。
ほとんどの場合、プロキシサーバのホスト名を使って環境変数を定義するだけで十分です。以下の例では、プロキシサーバのホスト名は proxy.gentoo.org、ポート番号は 8080 であるとしましょう。
以下のコマンド中の
#
記号はコメントです。これらは説明のためだけに追加されているもので、コマンドを入力するときに打ち込む必要はありません。HTTP プロキシ (HTTP と HTTPS 通信のため) を定義するには:
root #
export http_proxy="http://proxy.gentoo.org:8080" # Portage と Links に適用されます
root #
export https_proxy="http://proxy.gentoo.org:8080" # Links にのみ適用されます
HTTP プロキシが認証を必要とする場合は、次の構文でユーザ名とパスワードを設定してください:
root #
export http_proxy="http://username:password@proxy.gentoo.org:8080" # Portage と Links に適用されます
root #
export https_proxy="http://username:password@proxy.gentoo.org:8080" # Links にのみ適用されます
プロキシサポートのためには以下のパラメータを使用して links を開始します:
user $
links -http-proxy ${http_proxy} -https-proxy ${https_proxy}
Portage と links のために FTP プロキシを定義するには:
root #
export ftp_proxy="ftp://proxy.gentoo.org:8080" # Portage と Links に適用されます
FTP プロキシのためには以下のパラメータを使用して links を開始します:
user $
links -ftp-proxy ${ftp_proxy}
Portage のために RSYNC プロキシを定義するには:
root #
export RSYNC_PROXY="proxy.gentoo.org:8080" # Portage に適用されます; Links は rsync プロキシをサポートしていません
ADSL のために pppoe-setup を使う
インターネットアクセスのために PPPoE が必要な場合、Gentoo ブートメディアには ppp 構成を簡単にするための pppoe-setup スクリプトが含まれています。
セットアップの中で、pppoe-setup は以下のことを聞いてくるでしょう:
- ADSL モデムに接続されている Ethernet インターフェースの名前。
- PPPoE ユーザ名とパスワード。
- DNS サーバの IP。
- ファイアウォールが必要かどうか。
root #
pppoe-setup
root #
pppoe-start
失敗した場合は、/etc/ppp/pap-secrets または /etc/ppp/chap-secrets の証明書を検証すべきです。証明書が正しい場合は、PPPoE Ethernet インターフェースの選択を確認すべきです。
PPTP を使う
PPTP サポートが必要なら、インストール CD が提供する pptpclient を使用することができますが、使用の前に構成を行う必要があります。
/etc/ppp/pap-secrets または /etc/ppp/chap-secrets を編集して、正しいユーザ名/パスワードの組み合わせを設定してください:
root #
nano /etc/ppp/chap-secrets
必要ならば/etc/ppp/options.pptpを修正してください:
root #
nano /etc/ppp/options.pptp
構成が完了したら、pptp を (options.pptp で設定できないオプションがあれば、それもいっしょに付けて) 実行し、サーバに接続します:
root #
pptp <server ipv4 address>
WEP を構成する
WEP が唯一の選択肢でない限り、WEP を使用しないでください。WEP は基本的に、オープンネットワーク上に何のセキュリティも提供しません。
iw コマンドは以下のアーキテクチャ上でのみ利用可能です: amd64、x86、arm、arm64、ppc、ppc64、および riscv。
無線(802.11)カードを使っている場合には、まず第一に無線の設定をする必要があります。無線カードの現在の設定を確認するためには、iwを使うことができます。iwはこのようなものを表示するでしょう:
root #
iw dev wlp9s0 info
Interface wlp9s0 ifindex 3 wdev 0x1 addr 00:00:00:00:00:00 type managed wiphy 0 channel 11 (2462 MHz), width: 20 MHz (no HT), center1: 2462 MHz txpower 30.00 dBm
現在の接続を確認するには:
root #
iw dev wlp9s0 link
Not connected.
または
root #
iw dev wlp9s0 link
Connected to 00:00:00:00:00:00 (on wlp9s0) SSID: GentooNode freq: 2462 RX: 3279 bytes (25 packets) TX: 1049 bytes (7 packets) signal: -23 dBm tx bitrate: 1.0 MBit/s
無線カードのデバイス名は、wlp9s0 の代わりに wlan0 または ra0 のような名前かもしれません。正しいデバイス名を調べるには、ip link を実行してください。
ほとんどのユーザにとって、接続するのに必要な設定は、ESSID(無線ネットワーク名とも言います)と、場合によってはWEPキー、この2つだけです。
- まず、インターフェースがアクティブになっていることを確認してください:
root #
ip link set dev wlp9s0 up
- GentooNodeという名前のオープンネットワークに接続するには:
root #
iw dev wlp9s0 connect -w GentooNode
- 16進WEPキーを使って接続するには、キーの前に
d:
を付けてください:
root #
iw dev wlp9s0 connect -w GentooNode key 0:d:1234123412341234abcd
- ASCII WEPキーで接続するには:
root #
iw dev wlp9s0 connect -w GentooNode key 0:some-password
無線ネットワークが WPA または WPA2 で設定されている場合には、wpa_supplicant を使う必要があります。Gentoo Linux でのネットワーク設定のさらなる情報については、Gentoo ハンドブックの無線ネットワークの章を読んでください。
iw dev wlp9s0 link を使って、無線の設定ができたか確認してください。無線が機能したら、次節(ネットワーク用語を理解する)に示す、IP レベルのネットワークオプションの設定に進むか、先に示した net-setup ツールを使ってください。
net-setup を使用する
自動ネットワーク構成が成功しない場合、Gentoo ブートメディアはネットワーク構成を支援するスクリプトを提供しています。net-setup を使用して、無線ネットワーク情報と静的 IP を構成することができます。
root #
net-setup enp1s0
net-setup はネットワーク環境についていくつかの質問をし、その情報を使用して wpa_supplicant または静的アドレッシングを構成するでしょう。
インターネットと IP の基礎
ここまでのすべてが失敗した場合、ネットワークは手動で構成しなくてはなりません。これは特に難しくはありませんが、よく考えて行うべきです。この節は、用語を明確にし、手動でのインターネット接続に関連する基礎的なネットワークの概念を紹介するためのものです。
CPE (Carrier Provided Equipment) には、ルータ、アクセスポイント、モデム、DHCP サーバ、および DNS サーバの機能を、単一のユニットに組み合わせているものがあります。具体的な機器とデバイスの機能の区別を付けることは重要です。
インターフェースとアドレス
ネットワークインターフェースは、ネットワークデバイスの論理的な表現です。インターフェースは、ネットワーク上の他のデバイスと通信するためにアドレスを必要とします。単一のアドレスだけが必要である一方で、複数のアドレスを単一のインターフェースに割り当てることもできます。これはデュアルスタック (IPv4 + IPv6) 構成で特に有用です。
一貫性のために、この入門では、インターフェースは enp1s0 で、アドレス 192.168.0.2 を使用すると仮定します。
IP アドレスは任意に設定することができます。その結果、複数のデバイスが同一の IP アドレスを使用する設定にすることができてしまいますが、これはアドレスの競合につながります。アドレスの競合は DHCP または SLAAC を使用して回避すべきです。
IPv6 は、アドレス構成のために典型的には StateLess Address AutoConfiguration (SLAAC) を使用します。ほとんどの場合、手動で IPv6 アドレスを設定することはバッドプラクティスです。特定のアドレスサフィックスが好ましい場合は、インターフェース識別トークンを使用することができます。
ネットワークと CIDR
アドレスが選択された後、デバイスは、どのように他のデバイスと通信すればよいかを、どのようにして知るのでしょうか?
IP アドレスはネットワークと関連付けられています。IP ネットワークは、連続した論理的なアドレスの範囲です。
ネットワークのサイズを区別するために、Classless Inter-Domain Routing、略して CIDR 記法が使用されます。
- CIDR 値はよく / で始まる表記をされ、ネットワークのサイズを表現します。
- ネットワークのサイズを計算するためには 2 ^ (32 - CIDR) の公式が使用できます。
- ネットワークのサイズが計算できたら、利用できるノード数はそこから 2 を引かなくてはなりません。
- ネットワークの最初の IP はネットワークアドレスで、最後の IP は典型的にはブロードキャストアドレスです。これらのアドレスは特別であり、通常のホストによって使用することはできません。
最もよく使用される CIDR 値は /24、および /32 です。それぞれ 254 ノードと単一ノードを表現します。
/24 の CIDR は事実上のデフォルトのネットワークサイズです。これはサブネットマスク 255.255.255.0 に対応し、最後の 8 ビットはネットワーク上のノードのための IP アドレスとして予約されます。
記法: 192.168.0.2/24 は次のように解釈することができます:
- アドレスは 192.168.0.2
- ネットワーク 192.168.0.0 上にある
- ネットワークはサイズ 254 (2 ^ (32 - 24) - 2) を持つ
- 使用できる IP は 192.168.0.1 - 192.168.0.254 の範囲内にある
- ブロードキャストアドレス 192.168.0.255 を持つ
- ほとんどの場合、ネットワーク上の最後のアドレスはブロードキャストアドレスとして使用されますが、これは変更することができます。
この構成を利用することで、デバイスは同一ネットワーク (192.168.0.0) 上のホストと通信できるようになるはずです。
インターネット
デバイスがネットワークに参加した後、デバイスは、どのようにインターネット上のデバイスと通信すればよいかを、どのようにして知るのでしょうか?
ローカルネットワークの外のデバイスと通信するには、ルーティングを使用しなくてはなりません。ルータは、単純に他のデバイスのためにトラフィックを転送するネットワークデバイスです。デフォルトルートまたはゲートウェイという用語は、典型的には、現在のネットワーク上で外部ネットワークへのアクセスのために使用されるデバイスを指します。
ゲートウェイは、ネットワーク上の最初または最後の IP にするのが標準的です。
インターネットに接続されたルータが 192.168.0.1 で利用可能である場合、それをデフォルトルートとして使用して、インターネットアクセスを得ることができます。
まとめると:
- インターフェースは、CIDR 値などの、アドレスとネットワーク情報を使って構成しなくてはなりません。
- ローカルネットワークアクセスは、同一ネットワーク上のルータへのアクセスに使用されます。
- デフォルトルートが構成されたら、外部のネットワークに向けたトラフィックはゲートウェイに転送され、インターネットへのアクセスが得られます。
ドメインネームシステム
IP を覚えるのは困難です。ドメイン名と IP アドレスの間のマッピングを行えるように、ドメインネームシステムが作成されました。
Linux システムは、DNS 解決のために使用されるネームサーバを定義するために、/etc/resolv.conf を使用します。
多くのルータは DNS サーバとしても機能します。ローカルの DNS サーアを使用することで、プライバシーを向上させ、キャッシュによって問い合わせを高速化することができます。
多くの ISP は DNS サーバを運営していて、これは通常は DHCP を介してゲートウェイに広告されます。ローカル DNS サーバを使用することで問い合わせの遅延が改善されることが多いですが、ほとんどの公開 DNS サーバは同じ結果を返すでしょうから、サーバの使用は好みによるところが大きいです。
手動でのネットワーク設定
インターフェースアドレス構成
手動で IP アドレスを構成するときは、ローカルネットワークトポロジを考慮する必要があります。IP アドレスは任意に設定することはできません; 衝突があるとネットワーク障害を発生させる場合があります。
enp1s0 にアドレス 192.168.0.2 と CIDR /24 を持たせるように構成するには:
root #
ip address add 192.168.0.2/24 dev enp1s0
このコマンドの先頭の部分は ip a と省略できます。
デフォルトルート構成
インターフェースに対してアドレスとネットワーク情報を構成することで link ルートが構成され、そのネットワークセグメントとの通信が可能になるでしょう:
root #
ip route
192.168.0.0/24 dev enp1s0 proto kernel scope link src 192.168.0.2
このコマンドは ip r と省略できます。
次で default ルートを 192.168.0.1 に設定することができます:
root #
ip route add default via 192.168.0.1
DNS 構成
ネームサーバ情報は典型的には DHCP を使用して取得されますが、/etc/resolv.conf に nameserver
エントリを追加することで、手動で設定することもできます。
dhcpcd が実行中の場合、/etc/resolv.conf への変更は保持されないでしょう。
ps x | grep dhcpcd
で状態を確認することができます。nano は Gentoo ブートメディアに含まれており、/etc/resolv.conf を編集するために使用できます:
root #
nano /etc/resolv.conf
キーワード nameserver
に続いて DNS サーバの IP アドレスを含む行が、定義された順で問い合わせられます:
nameserver 9.9.9.9
nameserver 149.112.112.112
nameserver 1.1.1.1
nameserver 1.0.0.1
DNS のステータスは、ドメイン名に対して ping することで確認できます:
root #
ping -c 3 gentoo.org
ブロックデバイスの概要
ブロックデバイス
Gentoo Linuxの、そしてLinux一般の、ブロックデバイス、パーティション、Linuxファイルシステムを含めた、ディスクやファイルシステム中心の考え方について詳しく見てみましょう。ディスクの入出力とファイルシステムについて理解することで、インストールのためのパーティションとファイルシステムを構築できるようになります。
まずはブロックデバイスについて見ていきます。SCSIドライブやシリアルATAドライブは両方とも/dev/sdaや/dev/sdb、/dev/sdcなどのようなデバイスハンドルとしてラベル付されます。更にモダンなマシンでは、PCI ExpressベースのNVMeソリッドステートディスクは、/dev/nvme0n1、/dev/nvme0n2などのようなデバイスハンドルを持ちます。
下の表は、各種のブロックデバイスがシステム上のどこにあるかを判断するのに役立つでしょう:
デバイスの種類 | デフォルトのデバイスハンドル | 編集者メモと、考慮すべき点 |
---|---|---|
IDE、SATA、SAS、SCSI、または USB フラッシュメモリ | /dev/sda | 2007 年頃から現在までに製造されたハードウェアで見られます。このデバイスハンドルはおそらく Linux 上でもっともよく使用されているものでしょう。この種のデバイスは SATA バス、SCSI、USB バスを介してブロックストレージとして接続されます。例えば、最初の SATA デバイス上の最初のパーティションは /dev/sda1 という名前になります。 |
NVM Express (NVMe) | /dev/nvme0n1 | ソリッドステートテクノロジとして最新の NVMe ドライブは PCI Express バスに接続され、一般市場でもっとも高速な転送速度を持っています。2014 年頃以降のシステムは NVMe ハードウェアのサポートを備えているかもしれません。最初の NVMe デバイスの最初のパーティションは /dev/nvme0n1p1 という名前になります。 |
MMC、eMMC、および SD カード | /dev/mmcblk0 | embedded MMC デバイス、SD カード、そして他の種類のメモリーカードはデータ用のストレージとして有用です。つまり、多くのシステムはこれらの種類のデバイスからのブートを許可していないかもしれません。これらのデバイスに Linux をインストールして常用するのはおすすめできません。それらの典型的な設計意図である、ファイルの交換用に使うものと考えてください。この種のストレージは短期的なファイルバックアップまたはスナップショットとして使用すると便利かもしれません。 |
上のブロックデバイスは、ディスクへの抽象的なインターフェースを表しています。ユーザープログラムはこれらのブロックデバイスを用いて、デバイスが SATA、SCSI、もしくは他のものであるかどうかを心配することなしにディスクと通信することができます。プログラムは容易にディスク上の記憶領域を、ランダムアクセスできる 4096 バイト (4K) ごとの連続領域としてアドレッシングできます。
パーティション
Although it is theoretically possible to use a full disk to house your Linux system, this is almost never done in practice. Instead, full disk block devices are split up in smaller, more manageable block devices. These are called partitions.
パーティション構成の設計
パーティション数とサイズ
ディスクのパーティションレイアウトの設計は、システムに対する要求と、デバイスに適用されるファイルシステムに大きく依存します。多数のユーザがいる場合、セキュリティを向上し、バックアップの作成とその他のメンテナンスを容易にするために、/home を分離されたパーティションに配置することが推奨されます。もし メールサーバとして動作する場合は、/var を分離されたパーティションとし、すべてのメールを /var ディレクトリに保存すべきでしょう。ゲームサーバでは、ほとんどのゲームサーバソフトウェアは /opt にインストールされるので、/opt を分離されたパーティションとすることができます。これらが推奨される理由は最初の /home ディレクトリと同様で、セキュリティ、バックアップ、そしてメンテナンスです。
Gentoo では多くの場合、/usr と /var は相対的に大きい容量を確保すべきです。/usr にはシステム上で利用可能なアプリケーションの大部分と、Linux カーネルソース (/usr/src 配下) が配置されます。デフォルトでは、/var には Gentoo ebuild リポジトリが (/var/db/repos/gentoo 配下に) 配置され、ファイルシステム依存ではあるものの通常 650 MiB ほどのディスク容量を消費します。この推定容量には /var/cache/distfiles と /var/cache/binpkgs ディレクトリは含まれていません。これらはそれぞれ、ソースファイルとバイナリパッケージ (使用している場合) を格納するディレクトリで、システムに追加すればするほど大きくなっていきます。
適切なパーティションの数とサイズは、システムを取り巻く環境と、トレードオフを考慮することで大きく変わります。パーティションやボリュームを分離することには下記の利点があります:
- それぞれのパーティションまたはボリュームに対して、最も性能が高いファイルシステムを選択できます
- ゾンビプロセスがパーティションまたはボリュームに継続的に書き込みをした場合でも、システム全体の空き領域を使い切ることはありません
- 必要ならば、複数のチェックを並行して実行することで、ファイルシステムチェックの時間を短縮できます (複数のパーティションよりも複数のディスクの方が効果を実感できます)
- リードのみ、
nosuid
(setuidビット無効)、noexec
(実行ビット無効)等のマウントオプションによって、セキュリティが向上します
しかし、複数パーティションにはデメリットもあります:
- もし適切に設定されていないと、あるパーティションが空き領域をたくさん持ち、別のパーティションにはまったく空き領域がなくなるといったことが起こり得ます。
- /usr/ を独立したパーティションにすると、他のブートスクリプトが動作する前にパーティションをマウントするために、initramfs を使ってブートする必要があるかもしれません。initramfs の生成と保守はこのハンドブックのスコープの範囲外ですので、慣れていない方が /usr を独立したパーティションとすることは推奨しません。
- SCSI や SATA では仕様上の制約により、GPT ラベルを使用しない限りは 15 個までしかパーティションを作れません。
サービスおよび init システムとして systemd を使うつもりのインストールでは、/usr ディレクトリはルートファイルシステムの一部とするか、または initramfs によりマウントされるようにして、ブート時に利用できるようにしなくてはなりません。
スワップ領域について
RAM サイズ | サスペンド対応時 | ハイバネーション対応時 |
---|---|---|
2 GB 以下 | 2 * RAM | 3 * RAM |
2 から 8 GB | RAM 容量 | 2 * RAM |
8 から 64 GB | 最小 8 GB、最大 16 GB | 1.5 * RAM |
64 GB 以上 | 最小 8 GB | ハイバネーションは推奨されません! 非常に大きな容量のメモリを持つシステムでは、ハイバネーションは推奨されません。可能ではありますが、正しくハイバネーションするためには、メモリの内容全体をディスクに書き込まなくてはなりません。数十 GB (またはそれ以上!) のデータをディスクに書き出すのには、回転式ディスクを使用する場合は特に、非常に長い時間がかかることがあります。この状況ではサスペンドするのが最善です。 |
スワップ領域のサイズについて完璧な値というものはありません。スワップ領域の目的は、メインメモリ(RAM)が逼迫した際、カーネルにディスク領域を提供するためにあります。スワップ領域があれば、カーネルは最近最も使われていないメモリページをディスクに書き出し(スワップもしくはページアウト)、現在のタスクのために RAM 上に置かれたメモリを開放します。もちろん、もしディスクにスワップされたページが急に必要になった場合は、これらのページはメモリに戻す(ページイン)必要があります。これには、RAM から読み込むより相当長い時間がかかります(メインメモリと比較してディスクはとても遅いためです)。
システムがメモリを大量に消費するアプリケーションを実行しないとき、またシステムが多くの RAM を持っているときは、それほど大きいスワップ領域は必要ではありません。しかし、ハイバネーションの際に、スワップ領域はメモリの内容すべてを保存するために使われる(サーバシステムよりも、デスクトップやラップトップシステムでよくあることです)ことに留意してください。システムにハイバネーションのサポートが必要な場合は、メモリの全体量以上のサイズのスワップ領域が必要です。
RAM 容量が 4GB より少ない場合の一般的なルールとして、スワップ領域のサイズは内部メモリ (RAM) の 2 倍であることが推奨されます。複数のハードディスクを備えるシステムでは、並列して読み込み/書き込み操作が行えるように、それぞれのディスクに 1 つずつスワップパーティションを作成するのが賢い方法です。スワップ空間内のデータにアクセスしなくてはならないときに、ディスクがより高速にスワップできるほど、システムもより高速に動作するでしょう。回転式ディスクとソリッドステートディスクを比較すると、ソリッドステートハードウェア上にスワップを置いたほうが高いパフォーマンスが発揮できます。
スワップパーティションの代わりに、スワップファイルを使用することができることも特筆に値します。これは主にディスク容量が非常に限られたシステムで役に立つものです。
fdisk を用いる
SGI machines: Creating an SGI disk label
All disks in an SGI System require an SGI Disk Label, which serves a similar function as Sun & MS-DOS disklabels -- It stores information about the disk partitions. Creating a new SGI Disk Label will create two special partitions on the disk:
- SGI Volume Header (9th partition): This partition is important. It is where the bootloader will reside, and in some cases, it will also contain the kernel images.
- SGI Volume (11th partition): This partition is similar in purpose to the Sun Disklabel's third partition of "Whole Disk". This partition spans the entire disk, and should be left untouched. It serves no special purpose other than to assist the PROM in some undocumented fashion (or it is used by IRIX in some way).
The SGI Volume Header must begin at cylinder 0. Failure to do so means a failure to boot from the disk.
The following is an example excerpt from an fdisk session. Read and tailor it to personal preference...
root #
fdisk /dev/sda
Switch to expert mode:
Command (m for help):
x
With m the full menu of options is displayed:
Expert command (m for help):
m
Command action b move beginning of data in a partition c change number of cylinders d print the raw data in the partition table e list extended partitions f fix partition order g create an IRIX (SGI) partition table h change number of heads m print this menu p print the partition table q quit without saving changes r return to main menu s change number of sectors/track v verify the partition table w write table to disk and exit
Build an SGI disk label:
Expert command (m for help):
g
Building a new SGI disklabel. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content will be irrecoverably lost.
Return to the main menu:
Expert command (m for help):
r
Take a look at the current partition layout:
Command (m for help):
p
Disk /dev/sda (SGI disk label): 64 heads, 32 sectors, 17482 cylinders Units = cylinders of 2048 * 512 bytes ----- partitions ----- Pt# Device Info Start End Sectors Id System 9: /dev/sda1 0 4 10240 0 SGI volhdr 11: /dev/sda2 0 17481 35803136 6 SGI volume ----- Bootinfo ----- Bootfile: /unix ----- Directory Entries -----
If the disk already has an existing SGI Disklabel, then fdisk will not allow the creation of a new label. There are two ways around this. One is to create a Sun or MS-DOS disklabel, write the changes to disk, and restart fdisk. The second is to overwrite the partition table with null data via the following command:
dd if=/dev/zero of=/dev/sda bs=512 count=1
Resizing the SGI volume header
This step is often needed, due to a bug in fdisk. For some reason, the volume header isn't created correctly, the end result being it starts and ends on cylinder 0. This prevents multiple partitions from being created. To get around this issue... read on.
Now that an SGI Disklabel is created, partitions may now be defined. In the above example, there are already two partitions defined. These are the special partitions mentioned above and should not normally be altered. However, for installing Gentoo, we'll need to load a bootloader, and possibly multiple kernel images (depending on system type) directly into the volume header. The volume header itself can hold up to eight images of any size, with each image allowed eight-character names.
The process of making the volume header larger isn't exactly straight-forward; there's a bit of a trick to it. One cannot simply delete and re-add the volume header due to odd fdisk behavior. In the example provided below, we'll create a 50MB Volume header in conjunction with a 50MB /boot/ partition. The actual layout of a disk may vary, but this is for illustrative purposes only.
Create a new partition:
Command (m for help):
n
Partition number (1-16): 1 First cylinder (5-8682, default 5): 51 Last cylinder (51-8682, default 8682): 101
Notice how fdisk only allows Partition #1 to be re-created starting at a minimum of cylinder 5? If we attempted to delete & re-create the SGI Volume Header this way, this is the same issue we would have encountered. In our example, we want /boot/ to be 50MB, so we start it at cylinder 51 (the Volume Header needs to start at cylinder 0, remember?), and set its ending cylinder to 101, which will roughly be 50MB (+/- 1-5MB).
Delete the partition:
Command (m for help):
d
Partition number (1-16): 9
Now recreate it:
Command (m for help):
n
Partition number (1-16): 9 First cylinder (0-50, default 0): 0 Last cylinder (0-50, default 50): 50
If unsure how to use fdisk have a look down further at the instructions for partitioning on Cobalts. The concepts are exactly the same -- just remember to leave the volume header and whole disk partitions alone.
Once this is done, create the rest of your partitions as needed. After all the partitions are laid out, make sure to set the partition ID of the swap partition to 82, which is Linux Swap. By default, it will be 83, Linux Native.
Partitioning Cobalt drives
On Cobalt machines, the BOOTROM expects to see a MS-DOS MBR, so partitioning the drive is relatively straightforward -- in fact, it's done the same way as done for an Intel x86 machine. However there are some things you need to bear in mind.
- Cobalt firmware will expect /dev/sda1 to be a Linux partition formatted EXT2 Revision 0. EXT2 Revision 1 partitions will NOT WORK! (The Cobalt BOOTROM only understands EXT2r0)
- The above said partition must contain a gzipped ELF image, vmlinux.gz in the root of that partition, which it loads as the kernel
For that reason, it is recommended to create a ~20MB /boot/ partition formatted EXT2r0 upon which to install CoLo & kernels. This allows the user to run a modern filesystem (EXT3 or ReiserFS) for the root filesystem.
In the example, it is assumed that /dev/sda1 is created to mount later as a /boot/ partition. To make this /, keep the PROM's expectations in mind.
So, continuing on... To create the partitions type fdisk /dev/sda at the prompt. The main commands to know are these:
o: Wipe out old partition table, starting with an empty MS-DOS partition table
n: New Partition
t: Change Partition Type
Use type 82 for Linux Swap, 83 for Linux FS
d: Delete a partition
p: Display (print) Partition Table
q: Quit -- leaving old partition table as is.
w: Quit -- writing partition table in the process.
root #
fdisk /dev/sda
The number of cylinders for this disk is set to 19870. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK)
Start by clearing out any existing partitions:
Command (m for help):
o
Building a new DOS disklabel. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content won't be recoverable. The number of cylinders for this disk is set to 19870. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
Now verify the partition table is empty using the p command:
Command (m for help):
p
Disk /dev/sda: 10.2 GB, 10254827520 bytes 16 heads, 63 sectors/track, 19870 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks Id System
Create the /boot partition:
Command (m for help):
n
Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-19870, default 1): Last cylinder or +size or +sizeM or +sizeK (1-19870, default 19870): +20M
When printing the partitions, notice the newly created one:
Command (m for help):
p
Disk /dev/sda: 10.2 GB, 10254827520 bytes 16 heads, 63 sectors/track, 19870 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks Id System /dev/sda1 1 40 20128+ 83 Linux
Let's now create an extended partition that covers the remainder of the disk. In that extended partition, we'll create the rest (logical partitions):
Command (m for help):
n
Command action e extended p primary partition (1-4) e Partition number (1-4): 2 First cylinder (41-19870, default 41): Using default value 41 Last cylinder or +size or +sizeM or +sizeK (41-19870, default 19870): Using default value 19870
Now we create the / partition, /usr, /var, et.
Command (m for help):
n
Command action l logical (5 or over) p primary partition (1-4) l First cylinder (41-19870, default 41):<Press ENTER> Using default value 41 Last cylinder or +size or +sizeM or +sizeK (41-19870, default 19870): +500M
Repeat this as needed.
Last but not least, the swap space. It is recommended to have at least 250MB swap, preferrably 1GB:
Command (m for help):
n
Command action l logical (5 or over) p primary partition (1-4) l First cylinder (17294-19870, default 17294): <Press ENTER> Using default value 17294 Last cylinder or +size or +sizeM or +sizeK (1011-19870, default 19870): <Press ENTER> Using default value 19870
When checking the partition table, everything should be ready - one thing notwithstanding.
Command (m for help):
p
Disk /dev/sda: 10.2 GB, 10254827520 bytes 16 heads, 63 sectors/track, 19870 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks ID System /dev/sda1 1 21 10552+ 83 Linux /dev/sda2 22 19870 10003896 5 Extended /dev/sda5 22 1037 512032+ 83 Linux /dev/sda6 1038 5101 2048224+ 83 Linux /dev/sda7 5102 9165 2048224+ 83 Linux /dev/sda8 9166 13229 2048224+ 83 Linux /dev/sda9 13230 17293 2048224+ 83 Linux /dev/sda10 17294 19870 1298776+ 83 Linux
Notice how #10, the swap partition is still type 83? Let's change that to the proper type:
Command (m for help):
t
Partition number (1-10): 10 Hex code (type L to list codes): 82 Changed system type of partition 10 to 82 (Linux swap)
Now verify:
Command (m for help):
p
Disk /dev/sda: 10.2 GB, 10254827520 bytes 16 heads, 63 sectors/track, 19870 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks ID System /dev/sda1 1 21 10552+ 83 Linux /dev/sda2 22 19870 10003896 5 Extended /dev/sda5 22 1037 512032+ 83 Linux /dev/sda6 1038 5101 2048224+ 83 Linux /dev/sda7 5102 9165 2048224+ 83 Linux /dev/sda8 9166 13229 2048224+ 83 Linux /dev/sda9 13230 17293 2048224+ 83 Linux /dev/sda10 17294 19870 1298776+ 82 Linux Swap
We write out the new partition table:
Command (m for help):
w
The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks.
ファイルシステムを作成する
SSD または NVMe ドライブを使用する場合は、ファームウェアアップグレードがあるかどうか確認するのが賢明です。特に一部の Intel SSDs (600p および 6000p) は、XFS の I/O 使用量パターンによって誘発されるデータ破損の可能性のためのファームウェアアップグレードが必要です。この問題はファームウェアレベルのもので、XFS ファイルシステムの欠陥ではありません。smartctl ユーティリティはデバイスのモデルとファームウェアバージョンを確認するのに役立ちます。
はじめに
パーティションが作成できたら、その上にファイルシステムを作成します。次の節ではLinuxがサポートする各種ファイルシステムを紹介します。どのファイルシステムを使うかをすでに決めているなら、パーティションにファイルシステムを適用するへ進みましょう。そうでなければ、次の節を読んで利用可能なファイルシステムについて知るのがよいでしょう。
ファイルシステム
Linux は多くのファイルシステムをサポートしていますが、それらの多くは特定の目的をもって配備するのが賢明なものです。特定のファイルシステムのみが mips アーキテクチャ上で安定して動作するとされています - 重要なパーティションに実験的なファイルシステムを選択するときは、事前にファイルシステムのサポート状況を十分に知っておくことを推奨します。XFS はすべてのプラットフォームで、すべての目的で推奨されるファイルシステムです。以下は、網羅的ではないリストです:
- btrfs
- 次世代のファイルシステムです。スナップショット、チェックサムによる自己修復、透過的圧縮、サブボリューム、RAID の統合などの先進的な機能を提供します。RAID 5/6 とクオータグループは、btrfs のすべてのバージョンで安全ではありません。
- ext4
- ext4 は reflink などの現代的な機能を欠いてはいるものの、信頼性があり、全目的、全プラットフォームで使用できるファイルシステムです。
- f2fs
- Flash-Friendly File System はもともと、Samsung によって NAND フラッシュメモリで利用するために作られました。Gentoo を microSD カードや USB スティックや他のフラッシュベースの記憶装置にインストールする際にはすばらしい選択でしょう。
- XFS
- メタデータジャーナリングのあるファイルシステムで、堅牢な機能セットを持ち、スケーラビリティに最適化されています。新しい機能を取り入れながら継続的にアップグレードされ続けています。唯一の欠点は、現在対応中ではあるものの、 XFS パーティションはまだ縮小できないという点です。XFS の特筆すべき点として reflink とコピーオンライト (CoW) に対応しており、これは Gentoo システム上ではユーザが実施するコンパイル量の多さから特に有用です。XFS は全目的、全プラットフォームで利用できる、おすすめの現代的なファイルシステムです。パーティションは少なくとも 300MB ある必要があります。
- VFAT
- 別名 FAT32。Linux でサポートされていますが、標準的な UNIX パーミッションの設定をサポートしていません。ほとんど、他の OS (Microsoft Windows または Apple macOS) との相互運用性/交換のために使われていますが、いくつかのシステムブートローダーファームウェア (たとえば UEFI) でも必要になります。UEFI システムを使用している場合は、システムをブートするためには VFAT でフォーマットされた EFI システムパーティションが必要になるでしょう。
- NTFS
- この "New Technology" ファイルシステムは、Windows NT 3.1 以降の Microsoft Windows のフラッグシップファイルシステムです。VFAT と同様、BSD や Linux が正しく動作するために必要な UNIX パーミッション設定や拡張属性を保持しないため、ほとんどの場合ルートファイルシステムとして使うべきではありません。Microsoft Windows とデータ交換の相互運用のためにのみ使うべきです (のみの強調に注意してください)。
ファイルシステムについてのより広範な情報は、コミュニティによって維持されているファイルシステムの記事で見つけることができます。
パーティションにファイルシステムを適用する
再起動する前に、選択したファイルシステムに関連するユーザ空間ユーティリティを emerge しておいてください。インストールプロセスの終わりのあたりでまた、そうするように再通知します。
パーティションまたはボリュームの上にファイルシステムを作成するには、ファイルシステムごとに異なるユーザースペースのユーティリティが利用可能です。下表でファイルシステムの名前をクリックすると、それぞれに追加の情報が得られます:
ファイルシステム | 作成コマンド | live 環境内にある? | パッケージ |
---|---|---|---|
btrfs | mkfs.btrfs | はい | sys-fs/btrfs-progs |
ext4 | mkfs.ext4 | はい | sys-fs/e2fsprogs |
f2fs | mkfs.f2fs | はい | sys-fs/f2fs-tools |
xfs | mkfs.xfs | はい | sys-fs/xfsprogs |
vfat | mkfs.vfat | はい | sys-fs/dosfstools |
NTFS | mkfs.ntfs | はい | sys-fs/ntfs3g |
ハンドブックではインストールプロセスの一部として新しいパーティションを使用することを推奨しますが、重要なこととして、mkfs コマンドを実行すると、パーティションに含まれるすべてのデータは消去されることに注意してください。必要な場合は、新しいファイルシステムを作成する前に、中に存在する任意のデータが適切にバックアップされていることを確認してください。
例えば、パーティション構造例の通りに、ルートパーティション (/dev/sda5) を xfs として設定するには、次のコマンドが使えます:
root #
mkfs.xfs /dev/sda5
EFI システムパーティションのファイルシステム
EFI システムパーティション (/dev/sda1) は FAT32 としてフォーマットする必要があります:
root #
mkfs.vfat -F 32 /dev/sda1
レガシー BIOS ブートパーティションのファイルシステム
MBR/DOS ディスクラベルを持ち、レガシー BIOS を利用してブートするシステムは、ブートローダがサポートする任意のファイルシステムフォーマットを使用することができます。
例えば、XFS でフォーマットするには:
root #
mkfs.xfs /dev/sda1
小さな ext4 パーティション
ext4 ファイルシステムを (8 GiB 未満の) 小さいパーティションに使用する場合は、十分な inode 数を確保できるように適切なオプションを指定してファイルシステムを作成するべきです。これは -T small
オプションを使用して指定することができます:
root #
mkfs.ext4 -T small /dev/<device>
こうすることで「inode あたりのバイト数」が 16kB から 4kB に減るので、ファイルシステムに 4 倍の inode 数を確保できます。
スワップパーティションを有効にする
mkswapはスワップパーティションを初期化するために使われるコマンドです:
root #
mkswap /dev/sda10
スワップパーティションを有効化するには、swaponを使います:
root #
swapon /dev/sda10
この「有効化」の手順は、このスワップパーティションが live 環境内に新しく作成されたという理由から必要になっているものです。システムのリブート後は、スワップパーティションが fstab またはその他のマウント機構で適切に定義されている限り、スワップ領域は自動的に有効化されるでしょう。
ルートパーティションのマウント
以前に開始したインストール手順を完了しなかった場合は、ハンドブックのこの時点からインストールを再開することができます。このリンクを permalink として使用してください: インストールの再開はここから。
一部の live 環境は、Gentoo のルートパーティションのために提案されているマウントポイント (/mnt/gentoo) や、パーティショニングの節で作成された追加のパーティションのためのマウントポイントを持たないかもしれません:
root #
mkdir --parents /mnt/gentoo
EFI インストールの場合、ESP はルートパーティションの場所の下にマウントすべきです:
root #
mkdir --parents /mnt/gentoo
以前の手順で作成した追加の (カスタムの) パーティションがあれば、mkdir コマンドを使用して、追加で必要なマウントポイントの作成を続けてください。
マウントポイントが作成できたら、mount コマンドで、パーティションにアクセスできるようにしましょう。
ルートパーティションをマウントしてください:
root #
mount /dev/sda5 /mnt/gentoo
必要に応じて、mount コマンドを使用して、追加の (カスタムの) パーティションのマウントを続けてください。
もし/tmp/を別のパーティションに置く必要があるなら、マウントしたあと権限の変更を忘れずに行ってください:
root #
chmod 1777 /mnt/gentoo/tmp
このあと解説の中で、proc ファイルシステム (仮想的なカーネルとのインターフェース) が、他のカーネル擬似ファイルシステムと同様にマウントされますが、まず最初は、Gentoo stage ファイルを展開する必要があります。
stage ファイルを選択する
デスクトップ (グラフィカル) OS 環境を目的にするユーザは、それがサポートされているアーキテクチャでは、名前に
desktop
の項を持つ stage ファイルを使用することが推奨されます。これらのファイルは sys-devel/llvm や dev-lang/rust-bin などのパッケージと、USE フラグのチューニングを含んでおり、インストール時間を大きく改善します。stage ファイルは Gentoo インストールの種として機能します。stage ファイルはリリースエンジニアリングチームによって Catalyst を使用して生成されます。stage ファイルは、特定のプロファイルを基礎としており、ほぼ完全なシステムを含んでいます。
stage ファイルを選択するときには、所望のシステムの種別に応じたプロファイルターゲットを持つもの選ぶことが重要です。
インストールが確立された後にメジャープロファイルを変更することは、技術的には可能ですが、変更にはかなりの労力と熟慮が必要で、このインストールマニュアルの範囲外です。init システムの切り換えは難しいですが、
no-multilib
から multilib
への切り換えは Gentoo と低レベルツールチェーンについての深い知識を必要とします。大部分のユーザは、'advanced' な tarball を選択する必要は無いはずです。これらは、典型的でないあるいは高度な、ソフトウェアもしくはハードウェアのためのものです。
OpenRC
OpenRC は依存関係に基づく init システム (カーネルが起動した後にシステムサービスを開始するためのシステム) で、通常は /sbin/init にある、システムが提供する init プログラムとの互換性を保っています。Gentoo に由来するオリジナルの init システムですが、他の一部の Linux ディストリビューションや BSD システムでも採用されています。
OpenRC はデフォルトでは /sbin/init ファイルの代替としては機能せず、Gentoo の init スクリプトとは完全な互換性があります。つまり、Gentoo ebuild リポジトリにはデーモンを起動するソリューションがあるということです。
systemd
systemd は SysV スタイルの init と rc の、Linux システム向けの現代的な代替です。Linux ディストリビューションの大多数では、第一の init システムとして使用されています。systemd は Gentoo で完全にサポートされており、その意図した目的に合うように動作します。もし systemd インストールパスについて、何かがハンドブックから欠けているようであれば、助けを求める前に systemd の記事 を確認してください。
multilib (32 ビットと 64 ビット)
すべてのアーキテクチャが multilib オプションを持っているわけではありません。多くは、ネイティブコードでしか動作しません。multilib が最もよく適用されているのは amd64 です。
multilib プロファイルは、可能な場合は 64 ビットのライブラリを使用し、互換性のために厳密に必要な場合のみ 32 ビットのライブラリにフォールバックします。これは将来のカスタマイズのために大きな柔軟性をもたらすので、ほとんどのシステムにとってすばらしい選択肢となります。
multilib
ターゲットを使用すると、no-multilib
と比較して、後でプロファイルを切り換えるのが簡単になります。非 multilib (64 ビットのみ)
非 mutilib を必要とする明確な理由がなく、単に Gentoo を使いたいというケースでは、非 multilib を選択すべきではありません。
no-multilib
から mutilib
システムへの変更は、Gentoo の深い知識と低レベルのツールチェーンが必要です (これはおそらく私たちの Toolchain developers を身震いさせるでしょう)。これは気の弱い人への警告ではなく、このガイドの範囲外になるということです。システムのベースとして非 multilib の tarball を選択することで、32 ビットソフトウェアの無い、完全な 64 ビット環境を構築できます。これは事実上、multilib
プロファイルへの変更を (技術的には可能ではありますが) 面倒なものにします。
stage ファイルをダウンロードする
stage ファイルをダウンロードする前に、インストールのために使用されるマウントポイントにカレントディレクトリを設定すべきです:
root #
cd /mnt/gentoo
日時を設定する
stage アーカイブは一般的には HTTPS を使用して取得され、これには比較的正確なシステム時刻の設定が必要です。時刻がずれているとダウンロードができないことがあるほか、インストール後に大きくシステム時刻を修正すると、予測不可能なエラーを発生させることがあります。
date を使って、現在の日付と時刻を検証することができます:
root #
date
Mon Oct 3 13:16:22 PDT 2021
表示された日時が 2、3 分以上ずれている場合は、以下に示す方法のうちいずれかに従って更新してください。
自動
時計のずれを修正するためには、手動でシステム時計を設定するよりも、典型的には NTP を使用するのがより簡単でより信頼できるでしょう。
net-misc/chrony の一部である chronyd は、システム時計を UTC と更新するために、次のようにして使用することができます:
root #
chronyd -q
動作するリアルタイムクロック (RTC) を持たないシステムは、システム開始のたびに、そしてその後は定期的に、システム時計を同期しなくてはなりません。RTC を持つシステムでも、バッテリが故障して時計のずれが蓄積することがあるため、これは有用です。
標準的な NTP のトラフィックは認証されていません。ネットワークから取得した時刻データを検証することは重要です。
手動
NTP へのアクセスが利用できない場合は、date を使用してシステム時計を手動で設定することができます。
すべての Linux システムでは UTC で時刻を設定することが推奨されます。あとでシステムのタイムゾーンを定義して、時刻を表示するときのオフセットを変更します。
時刻を設定するためには、以下の引数フォーマットが使用されます: MMDDhhmmYYYY
構文 (Month (月)、Day (日)、hour (時)、minute (分)、Year (年))。
例えば、2021年の10月3日 13時16分に設定するには、以下を実行してください:
root #
date 100313162021
グラフィカルブラウザ
完全なグラフィカルウェブブラウザがある環境を使っているひとには、stage ファイルの URL をメインウェブサイトのダウンロードセクションからコピーするのに何の問題も無いでしょう。単純に適切なタブを選択して、stage ファイルへのリンクを右クリックして、Copy Link してクリップボードにリンクをコピーして、コマンドライン上で wget ユーティリティにリンクをペーストして、stage ファイルをダウンロードします:
root #
wget <PASTED_STAGE_FILE_URL>
コマンドラインブラウザ
伝統的な読者や'古参'の Gentoo ユーザで、コマンドラインのみで作業をする人たちは、グラフィカル環境を必要としないメニュー形式のブラウザである links (www-client/links) を使うほうを好むかもしれません。stage をダウンロードするために、Gentoo ミラーリストに飛んでください。
root #
links https://www.gentoo.org/downloads/mirrors/
linksでHTTPプロキシを使うには、-http-proxy
オプションにプロキシのURLを渡してください。
root #
links -http-proxy proxy.server.com:8080 https://www.gentoo.org/downloads/mirrors/
links に似た lynx (www-client/lynx) というブラウザもあります。links と同じくグラフィカル環境を必要としませんが、メニューはありません。
root #
lynx https://www.gentoo.org/downloads/mirrors/
プロキシを定義する必要があるならば、http_proxyやftp_proxy変数をexportしてください。
root #
export http_proxy="http://proxy.server.com:port"
root #
export ftp_proxy="http://proxy.server.com:port"
ミラーリストから、近くのミラーを選んでください。通常はHTTPミラーで十分ですが、他のプロトコルも使えます。releases/mips/autobuilds/ ディレクトリに移動してください。入手可能なすべてのstageファイルが列挙されています。ファイルは、サブアーキテクチャにちなんだ名前のサブティレクトリの中にあることもあります。ファイルを選び、dを押してダウンロードしてください。
stage ファイルのダウンロードが完了したら、整合性を検証して stage ファイルのコンテンツが正当か確認することができます。興味のあるひとは次節へ進んでください。
stage ファイルの検証と確認に興味が無いひとは、q を押すことでコマンドラインブラウザを終了して、stage ファイルを展開する節へすぐに進むことができます。
検証して確認する
今では、ほとんどの stage は init システムの種類に応じて明示的に (openrc または systemd と) 接尾辞が付けられていますが、アーキテクチャによっては、これらがまだ無いものもあります。
Minimal インストール CD のときと同じく、stage ファイルを検証して確認するためのファイルもダウンロードすることができます。これらの手順は飛ばしてもかまいませんが、ダウンロードしたファイルの整合性を気にするユーザのためにこれらのファイルが提供されています。これらの追加のファイルはミラーディレクトリのルートの下から取得できます。ハードウェアアーキテクチャとシステムプロファイルごとの適切な場所にブラウザで移動して、関連する .CONTENTS.gz、.DIGESTS、そして .sha256 ファイルをダウンロードしてください。
root #
wget https://distfiles.gentoo.org/releases/
- .CONTENTS.gz - stage ファイル内のファイル一覧を含む圧縮ファイル。
- .DIGESTS - stage ファイルの、複数の暗号学的ハッシュアルゴリズムを用いたチェックサムを含みます。
- .sha256 - stage ファイルの、PGP で署名された SHA256 チェックサムを含みます。このファイルはすべての stage ファイルで取得できるとは限りません。
openssl、sha256sum、または sha512sum などの暗号ツールおよびユーティリティを使用し、その出力を提供された .DIGESTS ファイルに含まれるチェックサムと比較することができます。
例えば、openssl で SHA512 チェックサムを検証するには:
root #
openssl dgst -r -sha512 stage3-mips-<release>-<init>.tar.xz
dgst
は openssl コマンドにメッセージダイジェストのサブコマンドを使うように指示し、-r
はダイジェスト出力を coreutils フォーマットで印字し、-sha512
は SHA512 ダイジェストを選択します。
openssl で BLAKE2B512 チェックサムを検証するには:
root #
openssl dgst -r -blake2b512 stage3-mips-<release>-<init>.tar.xz
チェックサムコマンドの出力を、.DIGESTS ファイルに含まれているハッシュとファイル名の値の組み合わせと比較してください。これらの値の組み合わせはチェックサムコマンドの出力と一致している必要があります。一致していない場合、ダウンロードしたファイルが破損しているため、削除して再ダウンロードするべきです。
sha256sum ユーティリティを使用して、関連する .sha256 ファイルに含まれる SHA256 ハッシュを検証するには:
root #
sha256sum --check stage3-mips-<release>-<init>.tar.xz.sha256
--check
オプションは sha256sum に期待されるファイルと対応するハッシュのリストを読み込ませ、各ファイルごとに、正しく計算できれば "OK" を、そうでない場合は "FAILED" を印字するように指示します。
ISO ファイルと同様に、tarball が改竄されていないことを確認するために、gpg を使って .tar.xz ファイルの電子署名を検証することもできます。
公式 Gentoo live イメージに関しては、自動化されたリリースのために sec-keys/openpgp-keys-gentoo-release パッケージが PGP 署名鍵を提供しています。鍵を検証に使用するためには、まずユーザのセッションに鍵をインポートする必要があります:
root #
gpg --import /usr/share/openpgp-keys/gentoo-release.asc
非公式 live イメージでは、live 環境内で gpg と wget を提供していれば、Gentoo 鍵を含むバンドルを取得してインポートすることができます:
root #
wget -O - https://qa-reports.gentoo.org/output/service-keys.gpg | gpg --import
tarball の署名と、追加で関連するチェックサムファイルを検証してください:
root #
gpg --verify stage3-mips-<release>-<init>.tar.xz.asc
root #
gpg --verify stage3-mips-<release>-<init>.tar.xz.DIGESTS
root #
gpg --verify stage3-mips-<release>-<init>.tar.xz.sha256
検証に成功した場合は、上のコマンドの出力に "Good signature from" が含まれるでしょう。
リリースメディアに署名するのに使用された OpenPGP 鍵のフィンガープリントは、リリースメディアの署名ページで確認できます。
stage ファイルをインストールする
stage ファイルのダウンロードと検証が完了したら、tar を使用してこれを展開することができます:
root #
tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-owner
展開する前に、オプションを確認してください:
x
展開 (extract)。アーカイブから内容を展開するように tar に指示します。p
パーミッションを保持します (preserve permissions)。v
詳細な出力 (verbose output)。f
ファイル (file)。入力アーカイブの名前を tar に提供します。--xattrs-include='*.*'
アーカイブに保存されている拡張属性をすべての名前空間について保持します。--numeric-owner
(たとえ冒険的なユーザが公式 Gentoo live 環境を使わずにインストール作業をしている場合であっても) tarball から展開されるファイルのユーザ ID とグループ ID が Gentoo リリースエンジニアリングチームの意図通りになるようにします。
これでステージファイルは展開されました。この続きはコンパイルオプションを設定するで。
コンパイルオプションを設定する
はじめに
システムを最適化するために、Portage(Gentooの公式なパッケージマネージャ)の挙動に影響する変数を設定できます。これらの変数はすべて環境変数として(exportを使って)設定できますが、export による設定は永続的なものではありません。
シェルのプロファイルまたは rc ファイルを利用して変数を export することは技術的には可能ですが、これは基本的なシステム管理の方法としてはベストプラクティスではありません。
Portage は実行時に make.conf を読み、ファイルに保存された値に基づいて実行時の振る舞いを変えます。make.conf は Portage の第一の設定ファイルと見ることができますので、その内容には注意して取り扱ってください。
/mnt/gentoo/usr/share/portage/config/make.conf.exampleに、すべての利用可能な変数のリストが、コメント付きで記載されています。make.conf についてのさらなるドキュメンテーションは、man -LC 5 make.conf を実行することで確認できます。(訳注: 日本語版は 10 年以上更新されていません。
-LC
を付けて最新の英語版を参照してください。)Gentoo のインストールを成功させるために最低限設定する必要がある変数は、以降で示すものだけです。
これから詳しく見ていく最適化変数を設定するために、エディタ(このガイドではnanoを使います)を起動してください。
root #
nano /mnt/gentoo/etc/portage/make.conf
make.conf.example ファイルを読めば、記述形式は分かるでしょう。コメント行は #
で始まり、他の行は「変数="内容"
」の形式で変数を定義します。これらの変数のうちのいくつかについて、次の節で見ていきます。
CFLAGS と CXXFLAGS
CFLAGSとCXXFLAGS変数はそれぞれ、GCC CコンパイラとC++コンパイラのための最適化フラグを定義します。この2つの変数は通常ここで定義されますが、真に最高のパフォーマンスを発揮するためには、このフラグはプログラム毎に別々に設定する必要があるでしょう。すべてのプログラムは異なるからです。しかし、それでは管理が大変なので、make.confファイルでこれらのフラグを定義します。
make.confでは、一般にシステムの応答が速くなるように最適化フラグを設定するべきです。この変数に実験的な設定を書かないでください。過剰な最適化はプログラムの挙動をおかしくすることがあり、クラッシュや誤動作の元となります。
ハンドブックではすべての最適化オプションを説明することはしません。すべてを理解するためには、GNU オンラインマニュアルや GCC info ページ (info gcc) を読んでください。make.conf.example ファイルにはたくさんの設定例と情報が含まれているので、これを読むこともお忘れなく。
最初の設定は-march=
または-mtune=
フラグです。これはターゲットアーキテクチャの名前を指定します。可能な選択肢はmake.conf.exampleファイル内にコメントとして書かれています。nativeを指定すると、コンパイラは(Gentooをインストールしようとしている)現在のシステムのアーキテクチャをターゲットとして選択してくれるので、よく使われます。
ふたつめの設定は-O
フラグ(ゼロではなく大文字のオー)です。これはgcc最適化クラスフラグを指定します。可能なクラスは、s(サイズ最適化)、0(ゼロ、最適化無し)、1、2、3(速度最適化)です。速度最適化については、各クラスは1段階前のクラスが持つものと同じフラグに加えて、追加のフラグを持ちます。-O2
は推奨されるデフォルト設定です。-O3
をシステム全体で使うと問題を起こすことが知られているので、-O2
にとどめることをおすすめします。
他によく使われる最適化フラグには-pipe
があります。これは、コンパイルステージ間での連絡方法として、一時ファイルではなくパイプを使うよう指定します。生成されるコードには影響しませんが、より多くのメモリを使うようになります。メモリの少ないシステムでは、gccが強制終了するかもしれません。そのような場合には、このフラグは使わないでください。
-fomit-frame-pointer
を使うと、必要の無い場合にはフレームポインタをレジスタに保持しなくなります。これはアプリケーションのデバッグ時に深刻な影響を与えるかもしれません。
CFLAGS と CXXFLAGS 変数を定義するときには、最適化フラグは 1 つの文字列として結合してください。stage ファイルアーカイブに含まれるデフォルト値で十分でしょう。以下に例を示します:
# すべての言語において設定するコンパイラフラグ
COMMON_FLAGS="-mabi=32 -mips4 -pipe -O2"
# 同じ設定を両方の変数に使用
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
各種コンパイルオプションがどのようにシステムに影響するかについては GCC の最適化 の記事に詳しい情報がありますが、初心者がシステムの最適化を始めるには Safe CFLAGS の記事のほうがもっと実践的な場所かもしれません。
MAKEOPTS
MAKEOPTS 変数は、パッケージのインストール時にどれだけ並行してコンパイルを走らせるかを定義します。Portage バージョン 3.0.31[1] 時点において、未定義のままの場合、Portage のデフォルトの挙動では MAKEOPTS の jobs の値は nproc が返すスレッド数と同じ数に設定されます。
さらに Portage 3.0.53 の時点では[2]、未定義のままの場合、Portage のデフォルトの挙動では MAKEOPTS の load-average の値は nproc が返すスレッド数と同じ数に設定されます。
CPU のスレッド数か、システム全体の RAM 容量を 2 GiB で割った数のうち、小さい方を選択するのがよい選択とされています。
ジョブ数を大きくすると、メモリ使用量にきわめて大きな影響を及ぼします。目安は、指定したジョブ数の各ジョブに対し、最低 2 GiB の RAM が割り当てられるようにすることです (つまり、例えば
-j6
は最低でも 12 GiB を要求します)。メモリが枯渇しないようにするには、利用可能なメモリ容量に合うようにジョブ数を減らしてください。並列 emerge を使用する (
--jobs
) と、実効的なジョブ数が指数関数的に (make ジョブ数 × emerge ジョブ数まで) 増大することがあります。これに対しては、localhost-only distcc 構成によって、ホスト当たりのコンパイラインスタンス数を制限することで対処することができます。# 未定義のままの場合、Portage のデフォルトの挙動は以下の通りです:
# - MAKEOPTS の jobs 値を `nproc` が返すスレッド数と同じ数に設定する
# - MAKEOPTS の load-average 値を `nproc` が返すスレッド数よりわずかに大きい数に設定する (減衰された値であるため)
# '4' をシステムに応じて適切に (min(RAM/2GB, スレッド数) 置き換えるか、未設定のままにしておいてください。
MAKEOPTS="-j4 -l5"
さらなる詳細については man 5 make.conf 内で MAKEOPTS を検索してください。
よーい、ドン!
好みの設定に合わせて /mnt/gentoo/etc/portage/make.conf を変更し、保存してください。nano では Ctrl+o で変更を保存して、Ctrl+x で終了できます。
参照
chroot する
DNS 情報をコピーする
新しい環境に入る前に一つだけやるべきことが残っています。それは/etc/resolv.confに記載されているDNS情報をコピーすることです。これは新しい環境に入った後でネットワークを使うために必要です。/etc/resolv.confは、そのネットワークのネームサーバーの情報を含んでいます。
この情報をコピーするときは、cpコマンドに--dereference
オプションを付与することを推奨します。これは/etc/resolv.confがシンボリックリンクのときに、シンボリックリンクをコピーするのではなく、シンボリックリンクのリンク先の実ファイルをコピーします。そうしないと新しい環境でシンボリックリンクが存在しないファイルを指し示すでしょう(新しい環境では、元の環境でリンク先に指定していたファイルはほぼ利用できません)。
root #
cp --dereference /etc/resolv.conf /mnt/gentoo/etc/
必要なファイルシステムをマウントする
もう少しで、Linux ルートは新しい場所に変わります。
使えるようにしなければならないファイルシステムは以下の通りです。
- /proc/ は Linux カーネルから情報を引き出すための擬似ファイルシステムです。一見通常ファイルに見えますが、ファイルとしての実体はありません。
- /sys/ は /proc/ 同様、擬似ファイルシステムです。{{Path|/proc/} }より構造化されており、一度は /proc/ を置き換えることを目的としていました。
- /dev/ は、すべてのデバイスファイルを含む通常のファイルシステムです。一部は Linux のデバイス管理機構 (通常は udev) により管理されています。
- /run/ は一時ファイルシステムです。PID ファイルやロックなど、実行時に生成されるファイルのために使用されます。
/proc/は、/mnt/gentoo/proc/にマウントされるでしょう。他はbindマウントされます。後者は、例えば/mnt/gentoo/sys/は事実/sys/となります(同じファイルシステムへの2番目のエントリです)。ここで/mnt/gentoo/proc/はファイルシステムの新しいエントリ(インスタンスとも言えるでしょう)となります。
Gentoo のインストールメディアを使用している場合は、このステップは単に arch-chroot /mnt/gentoo として置き換えることができます。
root #
mount --types proc /proc /mnt/gentoo/proc
root #
mount --rbind /sys /mnt/gentoo/sys
root #
mount --make-rslave /mnt/gentoo/sys
root #
mount --rbind /dev /mnt/gentoo/dev
root #
mount --make-rslave /mnt/gentoo/dev
root #
mount --bind /run /mnt/gentoo/run
root #
mount --make-slave /mnt/gentoo/run
インストールの後半で出てくるsystemdを使う場合、
--make-rslave
が必要です。Gentoo以外のインストールメディアを使う場合、これだけでは十分ではない場合があります。いくつかのディストリビューションは/run/shm/へのシンボリックリンクとして/dev/shmを作りますが、これはchroot後に無効になってしまいます。これに対応するためには、/dev/shm/をtmpfsとして適切にマウントしておくことが必要です:
root #
test -L /dev/shm && rm /dev/shm && mkdir /dev/shm
root #
mount --types tmpfs --options nosuid,nodev,noexec shm /dev/shm
そして確実にモード1777に設定してください:
root #
chmod 1777 /dev/shm /run/shm
新しい環境に入る
ようやく、すべてのパーティションが初期化され、ベース環境がインストールされました。chroot を実行して新しいインストール環境に入りましょう。これは、セッションの root (アクセスできる最も上位レベルの場所) を、現状のインストール環境 (インストール CD もしくは他のインストールメディア) から、インストール対象システム (つまり初期化されたパーティション) に変更することを意味しています。これが change root もしくは chroot の意味です。
chrootは次の3ステップで実行されます。
- chroot コマンド、または利用可能であれば arch-chroot コマンドによって、最上位ディレクトリを (インストールメディアの) / から (パーティションをマウントしている) /mnt/gentoo/ に変更する。
- /etc/profile のいくつかの設定を source コマンドでリロードする。
- chroot 環境であることを忘れないようするために、シェルのプロンプトを変更する。
root #
chroot /mnt/gentoo /bin/bash
root #
source /etc/profile
root #
export PS1="(chroot) ${PS1}"
この時から、すべての操作は新しい Gentoo Linux 環境で実行されます。
これ以降の時点で Gentoo インストールを中断しても、インストール作業をこのステップから「再開」することができるようになっているはずです。ディスクをまたパーティショニングする必要はありません!ただ単にルートパーティションをマウントして、上のステップを DNS 情報をコピーするところから実行すれば、作業中の環境に再び入ります。ブートローダの問題を解決するのにもこれが役に立ちます。さらなる情報は chroot の記事にあります。
ブートローダのための準備をする
新しい環境に入ることができたら、次はこの新しい環境をブートローダのために準備する必要があります。ブートローダをインストールするときには、正しいパーティションがマウントされていることが重要になるでしょう。
UEFI システム
UEFI システムでは、 が FAT32 ファイルシステムでフォーマットされ、EFI システムパーティション (ESP) として使用されます。(まだ作成されていない場合は) 新しく ディレクトリを作成して、そこに ESP をマウントしてください:
root #
mkdir
root #
mount
DOS/レガシー BIOS システム
DOS/レガシー BIOS システムでは、ブートローダは /boot ディレクトリにインストールされるので、次のようにマウントしてください:
root #
mount /dev/sda1 /boot
Portage を設定する
Web から Gentoo ebuild リポジトリのスナップショットをインストールする
次にGentoo ebuildリポジトリのスナップショットをインストールします。このスナップショットには、インストール可能なパッケージの情報、システム管理者が選択するプロファイルの一覧、パッケージやプロファイルごとのお知らせなどをPortageに伝えるファイルが含まれます。
ここで紹介するemerge-webrsyncは、HTTP/FTPプロトコル以外でのダウンロードがファイアウォールで制限されるような環境や、ネットワーク帯域を節約したい場合にお薦めです。これらの制約がなければ、この手順は省いて次のセクションに進んでも構いません。
次のコマンドで、毎日更新される最新のスナップショットをGentooのミラーサイトから取得し、インストールします:
root #
emerge-webrsync
この作業中、emerge-webrsync は /var/db/repos/gentoo/ がない旨のメッセージを出すかもしれません。これは想定内で、心配することはありません。このディレクトリは自動的に作成されます。
この時点で、Portageはいくつかのアップデートが推奨されていることを通知するかもしれません。これは、stageファイルでインストールされたシステム関連のパッケージについて、より新しいバージョンが利用可能であることを示しています。今回新しいリポジトリスナップショットがインストールされたことで、Portageがそれを認識したのです。このメッセージは今のところは無視して、Gentooのインストールが完了してから対応しても問題ありません。
任意自由選択: ミラーサーバーを選択する
ソースコードを短時間でダウンロードするために、高速で、地理的に近いミラーを選択することをおすすめします。Portage は make.conf の中の GENTOO_MIRRORS 変数に指定されたミラー群を使用します。Gentoo のミラー一覧をブラウザで開き、インストール対象のマシンに物理的に近い一つまたは複数のミラーを選択することができます (これらは高い頻度で最も高速になり得ます)。
mirrorselect というツールが、より手っ取り早く適したミラーを検索して選択するための素晴らしいテキストインターフェースを提供しています。単に選択したいミラーにカーソルを合わせて Spacebar を押し、一つまたは複数のミラーを選択してください。
root #
emerge --ask --verbose --oneshot app-portage/mirrorselect
root #
mirrorselect -i -o >> /etc/portage/make.conf
または、アクティブなミラーの一覧はオンラインでも確認できます。
任意自由選択: Gentoo ebuild リポジトリを更新する
Gentoo ebuildリポジトリを最新版にアップデートできます。先のemerge-webrsyncコマンドはほぼ最新の(通常は24時間以内に作成される)スナップショットをインストールするため、このステップは本当に任意です。
最新(一時間以内)のパッケージ更新があるかもしれません。その更新を取り込むためにemerge --syncを実行しましょう。このコマンドはGentoo ebuildリポジトリ(先程emerge-webrsyncコマンドで取得したもの)をアップデートするためにrsyncプロトコルを使用します。
root #
emerge --sync
アップデートの時間を短縮するために、特定のフレームバッファもしくはシリアルコンソール等の遅いターミナルでは、--quiet
オプションを使うことをお薦めします。
root #
emerge --sync --quiet
ニュースを読む
Gentoo ebuildリポジトリの更新時、Portage が次のような情報メッセージを出すことがあります。
* IMPORTANT: 2 news items need reading for repository 'gentoo'.
* Use eselect news to read news items.
ニュース項目は、Gentoo ebuild リポジトリを通じて、ユーザーに重要なメッセージを通知するためのコミュニケーション手段です。これらニュース項目を管理するためにeselect newsを使用します。eselectはGentooに固有のユーティリティで、システム管理のための共通の管理インターフェースを提供します。この場合、eselectはnews
モジュールを使うことを指示されます。
news
モジュールに対しては、主に3つの操作が使用されます。
list
を指定すると、現在有効なニュースアイテムの概要が表示されます。read
を指定すると、そのニュースアイテムを読むことができます。purge
を指定すると、一度購読したニュースを削除することができます。これにより、それらのニュースを二度と目にすることはないでしょう。
root #
eselect news list
root #
eselect news read
ニュースリーダーに関するほとんどの情報はマニュアルページを通じて得ることができます。
root #
man news.eselect
適切なプロファイルを選ぶ
デスクトッププロファイルはデスクトップ環境のためだけのものではありません。i3 や sway のようなミニマルなウィンドウマネージャにも適しています。
プロファイルはあらゆるGentooシステムの基礎を構成します。プロファイルはUSE、CFLAGS等の重要な変数の初期値を決めるだけではありません。プロファイルは、パッケージのバージョンを決まった範囲に固定する役目を持っています。プロファイルはGentooのPortage開発者によって完全にメンテナンスされています。
現在使用中のプロファイルを確認するには、eselect を profile
モジュールを指定して実行してください:
root #
eselect profile list
Available profile symlink targets: [1] default/linux/mips/23.0 * [2] default/linux/mips/23.0/desktop [3] default/linux/mips/23.0/desktop/gnome [4] default/linux/mips/23.0/desktop/kde
コマンドの出力は一例で、常に更新されています。
systemd を使用するには、名前に "systemd" を含んだプロファイルを選択してください。逆もまた然りです。
いくつかのアーキテクチャでは、デスクトップ体験のために共通して必要なソフトウェアパッケージを含む、デスクトップ向けのサブプロファイルが見られるでしょう。
プロファイルのアップグレードは軽々と行われるものではありません。初期プロファイルを選択する時、確実に stage ファイルがはじめに使用していたものと同じバージョン(例えば 23.0)を使用してください。新しいプロファイルのバージョンは、移行方法を含むニュース項目を通して発表されます; 新しいプロファイルに移行する前にはその説明に注意して従うようにしてください。
mipsアーキテクチャで利用可能なプロファイルを確認後、別のプロファイルを選択できます。
root #
eselect profile set 2
developer
サブプロファイルはGentoo Linux開発向けの固有のプロファイルであり、通常のユーザーが使用するものではありません。追加可能: バイナリパッケージホストを追加する
2023 年 12 月より、Gentoo のリリースエンジニアリングチームは、バイナリパッケージ (binpkg) の取得とインストールをコミュニティ全体が利用できるように、公式のバイナリパッケージホスト (略して "binhost") を提供しています。[1]
バイナリパッケージホストを追加することで、Portage は、暗号論的に署名されたコンパイル済みパッケージをインストールすることができるようになります。多くの場合、バイナリパッケージホストを追加することでパッケージインストールのための平均時間が大幅に減少するため、古い、遅い、あるいは低消費電力のシステム上で Gentoo を動かすときには、大きな利益が得られるでしょう。
リポジトリの構成
binhost のためのリポジトリ構成設定は Portage の /etc/portage/binrepos.conf/ ディレクトリ内に見つけられ、これは Gentoo ebuild リポジトリの節で言及した構成設定と同じように動作します。
バイナリホストを定義するときに検討すべき重要な側面が 2 つあります:
sync-uri
の値の中のアーキテクチャおよびプロファイルターゲットは非常に重要であり、対応するコンピュータアーキテクチャ (この場合は mips) と、適切なプロファイルを選択するの節で選択されたシステプロファイルに合わせるべきです。- 一般的に、高速で地理的に近いミラーを選択することで、取得時間が短縮されるでしょう。任意自由選択: ミラーサーバーを選択するの節で言及している mirrorselect ツールを確認するか、URL 値を知ることができるオンラインのミラーリストを確認してください。
[binhost]
priority = 9999
sync-uri = https://distfiles.gentoo.org/releases/<arch>/binpackages/<profile>/x86-64/
バイナリパッケージをインストールする
Portage はデフォルトではソースコードからパッケージをコンパイルするでしょう。以下の方法で、バイナリパッケージを使用するように指示することができます:
- emerge コマンドを呼び出すときに
--getbinpkg
オプションを渡すことができます。このバイナリパッケージインストール方法は、特定のバイナリパッケージのみをインストールするために有用です。 - /etc/portage/make.conf ファイルを通して提示される Portage の FEATURES 変数を介して、システムのデフォルトを変更する。この設定変更を適用すると、Portage は要求されたパッケージをバイナリパッケージホストに問い合わせ、結果が見つからない場合にはローカルでコンパイルする方法にフォールバックするようになるでしょう。
例えば、Portage に利用可能なバイナリパッケージを常にインストールさせるには:
# FEATURES 変数内の値のリストに getbinpkg を追加してください
FEATURES="${FEATURES} getbinpkg"
# 署名を要求する
FEATURES="${FEATURES} binpkg-request-signature"
Portage が検証のために必要なキーリングをセットアップするために、getuto も実行してください:
root #
getuto
さらなる Portage の機能についてはハンドブックの次の章で取り扱います。
追加可能: USE 変数を設定する
USEは、Gentooがユーザに提供する最もパワフルな変数の一つです。多くのプログラムに対して、決められた追加機能を含めたり、もしくは含めずにコンパイルすることが可能です。例えば、いくつかのプログラムはGTK+サポートもしくはQtサポートを有効にしてコンパイルできます。別のプログラムにはSSLサポートを含めたり、もしくは含めずにコンパイルすることが可能です。いくつかのプログラムはX11サポート(Xサーバー)の代わりに、フレームバッファサポート(svgalib)と共にコンパイルできます。
多くのディストリビューションでは、各種のサポートを最大限含むようにコンパイルします。これはプログラムサイズと起動時間を増大させます。多くの依存関係を発生させることは言うまでもありません。Gentoo では、ユーザーはパッケージをコンパイルする時のオプションを定義できます。ここで USE が登場します。
USE変数を使って、ユーザーはコンパイルオプションにマップされるキーワードを指定します。例えば、ssl
キーワードはSSLをサポート可能なプログラムでSSLを有効にしてコンパイルします。-X
キーワードはXサーバーのサポートを含まない(最初のマイナス記号で指定)ようにコンパイルします。gnome gtk -kde -qt5
は、GNOME(とGTK+)サポートを有効にして、KDE(とQt)サポートを無効にします。これにより、(もし、アーキテクチャがGNOMEをサポートしていれば)システムはGNOME向けに最大限調整されます。
デフォルトの USE の設定は、システムによって使用される Gentoo プロファイルの make.defaults ファイルに記述されています。Gentoo はシステムプロファイルをサポートするために、複雑な継承システムを使用していますが、インストール作業中はこれについて深くは触れないことにします。現在有効な USE 設定を知るためのもっとも簡単な方法は、emerge --info を実行して USE で始まる行を抜き出すことです:
root #
emerge --info | grep ^USE
USE="X acl alsa amd64 berkdb bindist bzip2 cli cracklib crypt cxx dri ..."
上記の例は出力のほとんどを省略しています。実際には、USE 変数のリストはずっとずっと長いものです。
使用可能な USE フラグの完全な説明は、/var/db/repos/gentoo/profiles/use.desc にあります。
root #
less /var/db/repos/gentoo/profiles/use.desc
lessコマンドでは、↑キーと↓キーを使ってスクロールすることができます。qを押すと終了します。
例として、DVD、ALSA、CD書き込みをサポートしたKDEベースのUSE設定を示します。
root #
nano /etc/portage/make.conf
USE="-gtk -gnome qt5 kde dvd alsa cdr"
/etc/portage/make.conf で USE の値を定義すると、その値はシステムの USE フラグリストに追加されます。USE フラグは、リスト中の値の前に - マイナス記号を追加することで、グローバルに削除することができます。例えば、X グラフィカル環境のサポートを無効化するには、-X
を設定することでこれを行えます:
USE="-X acl alsa"
-*
を指定することで、make.conf 内で指定したもの以外のすべての USE 値を無効化することができますが、これはまったくおすすめできない、賢明でないことです。Ebuild の開発者たちは、競合を防止するため、セキュリティを向上させるため、エラーを回避するため等の理由によって、デフォルトの USE フラグを選択して ebuild で指定しています。すべての USE フラグを無効化することはデフォルトの振る舞いを否定し、重大な問題を引き起こすことがあります。CPU_FLAGS_*
一部のアーキテクチャ (AMD64/X86、ARM、PPC を含みます) には、CPU_FLAGS_<ARCH> (<ARCH> は関連するシステムアーキテクチャ名に置き換えてください) と呼ばれる USE_EXPAND 変数があります。
混乱しないで! AMD64 と X86 のシステムは共通のアーキテクチャを一部共有しているので、AMD64 システムのための正しい変数名は CPU_FLAGS_X86 です。
これは、通常手書きなどで書かれた特定のアセンブリコードや intrinsics 等を含めるようにビルドを構成するために使用されるもので、特定の CPU 機能のために最適化されたコードを出力するようにコンパイラに指示する (-march=
等) のとは異なります。
COMMON_FLAGS を希望に応じて設定するのに加えて、この変数も設定すべきでしょう。
これをセットアップするにはいくつかのステップが必要です:
root #
emerge --ask --oneshot app-portage/cpuid2cpuflags
興味があるなら、出力を自分で確認してみてください:
root #
cpuid2cpuflags
そして、出力を package.use にコピーしてください:
root #
echo "*/* $(cpuid2cpuflags)" > /etc/portage/package.use/00cpu-flags
VIDEO_CARDS
利用できる GPU に応じて、VIDEO_CARDS USE_EXPAND 変数を適切に構成するとよいでしょう。コンソールのみのシステムの場合は、VIDEO_CARDS を設定する必要はありません。
以下は適切に設定された VIDEO_CARDS 変数の例です。使用するドライバの名前の部分は置き換えてください。
VIDEO_CARDS="amdgpu radeonsi"
各種 GPU ごとの詳細は、AMDGPU、Intel、Nouveau (オープンソース)、または NVIDIA (プロプライエタリ) の記事で読むことができます。
追加可能: ACCEPT_LICENSE 変数を設定する
Gentoo Linux Enhancement Proposal 23 (GLEP 23) 以降、システム管理者が「インストールするソフトウェアをライセンスの観点から制限」[2]できるようにする機構が作られました。「OSI によって承認されていないソフトウェアをまったく持たないシステムを求める人もいれば、どのライセンスを暗黙に受諾しているのか単に気になるという人もいます。」[3]Gentoo システム上で実行するソフトウェアの種類をより細かく制御したいという動機から、ACCEPT_LICENSE 変数が生まれました。
インストールのプロセス中に、Portage は、要求されたパッケージが、システム管理者による受諾できるライセンスの決定を満たしているか判断するために、ACCEPT_LICENSE 変数に設定された値を考慮します。ここで問題があります: Gentoo ebuild リポジトリは数千もの ebuild からなり、数百もの異なるソフトウェアライセンスを持っています……。これは、新しいソフトウェアライセンスが出るたびに、システム管理者は個別にいちいち受諾を求められるということでしょうか? ありがたいことに、そうではありません; GLEP 23 はこの問題に対する解決策である、ライセンスグループの概念も規定しています。
システム管理上の利便性のために、法的に類似したソフトウェアライセンスをまとめて分類しています。ライセンスグループの定義はここで確認することができ、Gentoo Licenses プロジェクトによって管理されています。ライセンスグループは構文上 @
記号が先頭に付けられ、一方で個々のライセンスはそうではないため、ACCEPT_LICENSE 変数内で容易に区別が付くようになっています。
よく使用されるライセンスグループには以下のものが含まれます:
名前 | 説明 |
---|---|
@GPL-COMPATIBLE |
フリーソフトウェア財団によって承認された、GPLと両立するライセンス (GPL compatible license) 群 [a_license 1] |
@FSF-APPROVED |
FSF (訳注: フリーソフトウェア財団) によって承認された自由ソフトウェアライセンス群 (@GPL-COMPATIBLE を含みます)
|
@OSI-APPROVED |
Open Source Initiative によって承認されたライセンス群 [a_license 2] |
@MISC-FREE |
おそらく自由ソフトウェアであるその他のライセンス群。言い換えると、自由ソフトウェアの定義[a_license 3]に従っているものの、FSF や OSI によって承認されていないライセンス |
@FREE-SOFTWARE |
@FSF-APPROVED 、@OSI-APPROVED 、および @MISC-FREE を組み合わせたもの。
|
@FSF-APPROVED-OTHER |
FSF が承認した「自由な文書」および「ソフトウェアや文書以外の実用の著作物のライセンス」 (フォントを含む) |
@MISC-FREE-DOCS |
自由の定義[a_license 4]に従っているが、@FSF-APPROVED-OTHER の一覧には載っていない、自由な文書およびその他の著作物。
|
@FREE-DOCUMENTS |
@FSF-APPROVED-OTHER および @MISC-FREE-DOCS を組み合わせたもの。
|
@FREE |
利用、共有、改変、および改変の共有の自由を持つ、すべてのライセンスからなるメタ集合。 @FREE-SOFTWARE および @FREE-DOCUMENTS を組み合わせたもの。
|
@BINARY-REDISTRIBUTABLE |
少なくともソフトウェアのバイナリ形式での自由な再配布を認めているライセンス群。@FREE を含みます。
|
@EULA |
あなたの権利を取り去ろうとするライセンス契約。これらは "all-rights-reserved" や明示的な承諾を必要とするものよりも拘束的です |
システム全体で現在設定されている、受諾可能なライセンスの値は、以下で確認できます:
user $
portageq envvar ACCEPT_LICENSE
@FREE
この出力で分かる通り、デフォルト値は、@FREE
カテゴリに分類されるソフトウェアのみをインストールできるようになっています。
システム全体に関して、特定のライセンスまたはライセンスグループを以下の場所で定義することができます:
- 選択されたプロファイルによって、システム全体で - これはデフォルト値を設定します。
- /etc/portage/make.conf ファイルによって、システム全体で。システム管理者はこのファイルで、プロファイルのデフォルト値を無視することができます。
- /etc/portage/package.license ファイルによって、パッケージ単位で。
- /etc/portage/package.license/ ディレクトリのファイルによって、パッケージ単位で。
/etc/portage/make.conf で、プロファイルによってシステム全体のデフォルトとなっているライセンス設定を無視することができます:
# プロファイルの ACCEPT_LICENSE のデフォルト値を無視する
ACCEPT_LICENSE="-* @FREE @BINARY-REDISTRIBUTABLE"
必要であれば、次のファイル例を含むディレクトリで示すように、パッケージごとに受諾するライセンスを定義することもできます。package.license ディレクトリが存在しない場合は作成しておく必要があります:
root #
mkdir /etc/portage/package.license
各 Gentoo パッケージに対するソフトウェアライセンスの詳細は、関連する ebuild の LICENSE 変数内に保存されています。パッケージによっては複数のパッケージを持つことがあり、そのため単一のパッケージに対して、受諾できるライセンスを複数指定する必要がある場合もあります。
app-arch/unrar unRAR
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
sys-firmware/intel-microcode intel-ucode
ebuild の LICENSE 変数は Gentoo の開発者やユーザにとってのガイドラインでしかありません。これは法的声明ではなく、これが現実を反映する保証はありません。ソフトウェアパッケージのライセンスに関する、ebuild 開発者の解釈だけを信用しないようにすることをおすすめします; パッケージそのものを、システムにインストールされるすべてのファイルを含めて徹底的にチェックしてください。
追加可能: @world 集合の更新
システムの @world 集合の更新は省略可能です。以下の追加手順のいずれかまたは両方が行われていない限り、おそらく機能的な変更は発生しないでしょう:
- プロファイルのターゲットが、stage ファイルを選択したときのものと異なっている。
- インストールされたパッケージに追加の USE フラグが設定されている。
「Gentoo インストールタイムアタック」を行っているなら、@world 集合の更新は、システムを新しい Gentoo 環境内に再起動させた後の時点まで安全に後回しにすることができます。
タイムアタックをしているのでなければ、パッケージ、プロファイル、現時点での USE フラグの変更に関して、Portage に更新を行わせることができます:
root #
emerge --ask --verbose --update --deep --newuse @world
古いパッケージを削除する
システム更新後は、古くなったパッケージを削除するために、常に depclean しておくのが重要です。削除されることになるパッケージの中に、個人的に使用していて残すべきものが無いか確認するために、 emerge --depclean --pretend の出力を注意深く確認してください。depclean されそうなパッケージを残すためには、emerge --noreplace foo を使用してください。
root #
emerge --ask --pretend --depclean
問題なければ、実際の depclean を進めてください:
root #
emerge --ask --depclean
非 desktop の stage ファイルから、デスクトップ環境プロファイルターゲットを選択した場合、@world 更新プロセスはインストール時間を格段に長くしてしまうかもしれません。時間に追われている人は次の経験則が成り立つでしょう。「名前が短く、特定のシステムを示さないプロファイルの @world 集合を選択する」。「もっとも一般的な @world 集合は、より少ないパッケージのアップデートですむ」。例えば:
タイムゾーン
このステップは musl libc を使う場合は適用されません。それがどういう意味か分からない場合は、このステップを実行すべきです。
/usr/share/zoneinfo/Etc/GMT* のタイムゾーンは、その名前が期待されるゾーンを示していないため、避けましょう。たとえば、GMT-8 は実際には GMT+8 となります。
タイムゾーンを選択します。/usr/share/zoneinfo/から利用可能なタイムゾーンを探してください:
root #
ls -l /usr/share/zoneinfo
total 352 drwxr-xr-x 2 root root 1120 Jan 7 17:41 Africa drwxr-xr-x 6 root root 2960 Jan 7 17:41 America drwxr-xr-x 2 root root 280 Jan 7 17:41 Antarctica drwxr-xr-x 2 root root 60 Jan 7 17:41 Arctic drwxr-xr-x 2 root root 2020 Jan 7 17:41 Asia drwxr-xr-x 2 root root 280 Jan 7 17:41 Atlantic drwxr-xr-x 2 root root 500 Jan 7 17:41 Australia drwxr-xr-x 2 root root 120 Jan 7 17:41 Brazil -rw-r--r-- 1 root root 2094 Dec 3 17:19 CET -rw-r--r-- 1 root root 2310 Dec 3 17:19 CST6CDT drwxr-xr-x 2 root root 200 Jan 7 17:41 Canada drwxr-xr-x 2 root root 80 Jan 7 17:41 Chile -rw-r--r-- 1 root root 2416 Dec 3 17:19 Cuba -rw-r--r-- 1 root root 1908 Dec 3 17:19 EET -rw-r--r-- 1 root root 114 Dec 3 17:19 EST -rw-r--r-- 1 root root 2310 Dec 3 17:19 EST5EDT -rw-r--r-- 1 root root 2399 Dec 3 17:19 Egypt -rw-r--r-- 1 root root 3492 Dec 3 17:19 Eire drwxr-xr-x 2 root root 740 Jan 7 17:41 Etc drwxr-xr-x 2 root root 1320 Jan 7 17:41 Europe ...
root #
ls -l /usr/share/zoneinfo/Europe/
total 256 -rw-r--r-- 1 root root 2933 Dec 3 17:19 Amsterdam -rw-r--r-- 1 root root 1742 Dec 3 17:19 Andorra -rw-r--r-- 1 root root 1151 Dec 3 17:19 Astrakhan -rw-r--r-- 1 root root 2262 Dec 3 17:19 Athens -rw-r--r-- 1 root root 3664 Dec 3 17:19 Belfast -rw-r--r-- 1 root root 1920 Dec 3 17:19 Belgrade -rw-r--r-- 1 root root 2298 Dec 3 17:19 Berlin -rw-r--r-- 1 root root 2301 Dec 3 17:19 Bratislava -rw-r--r-- 1 root root 2933 Dec 3 17:19 Brussels ...
選択したタイムゾーンが Europe/Brussels の場合は以下となります。
OpenRC
設定したいタイムゾーン名を /etc/timezone に記述します:
root #
echo "Europe/Brussels" > /etc/timezone
最後に、sys-libs/timezone-data パッケージを設定しましょう - これは /etc/timezone のエントリを元に、/etc/localtime をアップデートします:
root #
emerge --config sys-libs/timezone-data
/etc/localtime は、システムの C ライブラリが、自身が属するタイムゾーンを知るために使われます。
systemd
systemd を使用している場合は、多少異なるアプローチをとります。シンボリックリンクを生成します:
root #
ln -sf ../usr/share/zoneinfo/Europe/Brussels /etc/localtime
その後 systemd が起動してから、タイムゾーンとそれに関連する設定を timedatectl コマンドで設定することができます。
ロケールの設定
このステップは musl libc を使う場合は適用されません。それがどういう意味か分からない場合は、このステップを実行すべきです。
ロケールの生成
ほとんどのユーザは、一つもしくは二つのロケールを必要とします。
ロケールはシステムで使用する言語を指定するだけではなく、単語のソート順や日付、時間等のルールにも使用されます。ロケールは大文字小文字を区別するので、記載とまったく同じように表現する必要があります。利用可能なロケールの一覧は /usr/share/i18n/SUPPORTED ファイルで確認できます。
サポートされるシステムロケールは、/etc/locale.gen ファイルに定義する必要があります。
root #
nano /etc/locale.gen
次のロケールの例では、英語(米国)とドイツ語(ドイツ)を(UTF-8のような)文字コードと共に指定しています。
en_US ISO-8859-1
en_US.UTF-8 UTF-8
de_DE ISO-8859-1
de_DE.UTF-8 UTF-8
多くのアプリケーションは適切にビルドするのに少なくとも UTF-8 を必要とします。
次に locale-gen コマンドを実行します。このコマンドは /etc/locale.gen ファイルに記載されているすべてのロケールを生成します。
root #
locale-gen
現在使用可能なすべてのロケールを確認するためには、locale -aを実行してください。
systemd を使用しているシステムでは、localectl を使用できます。localectl set-locale ... または localectl list-locales のように。
ロケールの選択
この時点で、システム全体で有効になるロケールを設定できます。eselect を locale
モジュールと共に使いましょう。
eselect locale listを実行すると、利用可能なターゲットが表示されます。
root #
eselect locale list
Available targets for the LANG variable: [1] C [2] C.utf8 [3] en_US [4] en_US.iso88591 [5] en_US.utf8 [6] de_DE [7] de_DE.iso88591 [8] de_DE.utf8 [9] POSIX [ ] (free form)
eselect locale set <番号> を実行することで、適切なロケールを選択することができます:
root #
eselect locale set 2
手動で設定する場合は、/etc/env.d/02locale ファイルと、systemd の場合は /etc/locale.conf ファイルも編集してください。
LANG="de_DE.UTF-8"
LC_COLLATE="C.UTF-8"
ロケールを設定すると、後でカーネルをビルドしたり、他のソフトをコンパイルしたりするときに警告やエラーを回避できるでしょう。
ここで、環境をリロードします。
root #
env-update && source /etc/profile && export PS1="(chroot) ${PS1}"
ロケール選択プロセス全体にわたる、さらなるガイドについては、ローカライゼーションガイドと UTF-8 ガイドもお読みください。
参照
任意自由選択: ファームウェアとマイクロコードのインストール
ファームウェア
Linux ファームウェア
カーネルコンフィグの節へ進む前に知っておいたほうが良いこととして、一部のハードウェアデバイスは、それを適切に動作させるために追加の (時として FOSS ライセンスに準拠しない) ファームウェアをインストールする必要がある、ということがあります。これはデスクトップとラップトップの両方で広く見られる、無線ネットワークインターフェースで必要になることが多いです。AMD、Nvidia、Intel などのベンダによる最近のビデオチップも、完全に機能させるには外部のファームウェアが必要になることが多いです。最近のハードウェアデバイスのためのファームウェアの多くは sys-kernel/linux-firmware パッケージ内で見つかるかもしれません。
最初のシステムリブートの前に、もし必要だった場合にファームウェアを使えるようにしておくために、sys-kernel/linux-firmware パッケージをインストールしておくことが推奨されます:
root #
emerge --ask sys-kernel/linux-firmware
一部のファームウェアパッケージのインストールには、関連するファームウェアライセンスを受諾する必要があることがよくあります。必要であれば、ライセンスの受諾についてはハンドブックのライセンスの取り扱いの節を確認してください。
モジュールとしてビルド (M) されたカーネルシンボルは、カーネルにロードされたときに、関連するファームウェアファイルをファイルシステムからロードすることに注意してください。モジュールとしてロードされるシンボルに関しては、デバイスのファームウェアファイルをカーネルのバイナリイメージに含める必要はありません。
マイクロコード
個別のグラフィックスハードウェアやネットワークインターフェースに加えて、CPU もまたファームウェアアップデートを必要とすることがあります。こうしたファームウェアは典型的にはマイクロコードと呼ばれます。新しいリビジョンのマイクロコードは、動作の不安定さ、セキュリティ上の懸念、その他の CPU ハードウェアのさまざまなバグに対するパッチとして、必要になることがあります。
AMD CPU に対するマイクロコードアップデートは、先述の sys-kernel/linux-firmware パッケージとともに配布されます。Intel CPU に対するマイクロコードは sys-firmware/intel-microcode パッケージ内で見つかりますので、これを個別にインストールする必要があります。マイクロコードアップデートを適用する方法についてのさらなる情報は、マイクロコードの記事を確認してください。
カーネルのコンフィギュレーションとコンパイル
これで、カーネルソースを設定、コンパイルする準備が整いました。インストールの目的に応じてカーネルの管理のためのアプローチを 3 通り紹介しますが、インストール完了後はいつでも別のアプローチを採用し直すことができます。
簡単なものから込み入ったものへ、順に並べると:
- 完全自動アプローチ: ディストリビューションカーネル
- ディストリビューションカーネルは、Linux カーネル、関連するモジュール、および (必須ではありませんがデフォルトでは有効化されている) initramfs ファイルを、設定、自動でビルド、インストールするために利用されます。将来のカーネル更新はパッケージマネージャを介して扱われるため、他のシステムパッケージとまったく同様に完全に自動で行われます。カスタマイズが必要な場合はカスタムのカーネルコンフィグファイルを提供することも可能です。これが最も簡単なプロセスで、すぐ動作するものが手に入りシステム管理者による関与を最小にできるため、新規の Gentoo ユーザには完璧です。
- 完全手動アプローチ
- 新しいカーネルのソースがシステムパッケージマネージャを通じてインストールされます。カーネルは eselect kernel と無数の make コマンドを利用して、手動で設定、ビルド、インストールされます。将来のカーネル更新はカーネルファイルの設定、ビルド、インストールの手動プロセスを繰り返して行います。これが最も込み入ったプロセスですが、カーネル更新プロセスに関して最大限の制御を行えます。
- ハイブリッドアプローチ: Genkernel
- 新しいカーネルのソースがシステムパッケージマネージャを通じてインストールされます。システム管理者は Linux カーネル、関連するモジュール、および (必須ではありませんがデフォルトでは有効化されていない) initramfs ファイルを、設定、ビルド、インストールするために Gentoo の genkernel ツールを使用することができます。カスタマイズが必要な場合はカスタムのカーネルコンフィグファイルを提供することも可能です。将来のカーネル設定、コンパイル、インストールには、アップデートのたびに eselect kernel、genkernel、およびもし必要であれば他のコマンドを実行する形で、システム管理者による関与が必要です。
すべてのディストリビューションが構築されるその中心にあるのが Linux カーネルです。カーネルレイヤーはユーザのプログラムとハードウェアの間に存在します。ハンドブックではカーネルソースについていくつかの可能な選択肢を提供しますが、より詳しい説明付きで、より完全なカーネルソースのリストは、カーネルの概要のページで見ることができます。
/boot または EFI システムパーティションへのカーネルイメージのコピー、initramfs や Unified カーネルイメージの生成、ブートローダの設定の更新など、カーネルインストールのタスクは、installkernel で自動化することができます。先に進める前に、sys-kernel/installkernel をインストールして設定するとよいかもしれません。さらなる情報については下のカーネルインストールの節を参照してください。
カーネルソースのインストール
この節の内容は、これ以降の部分で示す genkernel (ハイブリッド) アプローチか、マニュアルカーネル管理のアプローチを採用したときのみ関係があります。
sys-kernel/installkernel の使用は厳密には必須ではありませんが、強く推奨されます。このパッケージがインストールされるとき、カーネルのインストールプロセスが installkernel に委任されます。これにより、複数の異なるカーネルバージョンを併存させてインストールすることができ、後でハンドブック内で説明するカーネルインストールに関連する複数のタスクの管理と自動化も可能になります。以下でインストールしてください:
root #
emerge --ask sys-kernel/installkernel
mips ベースのシステムにカーネルを手動でインストールしてコンパイルする場合には、Gentoo はsys-kernel/mips-sources パッケージを推奨しています。
適切なカーネルソースを選択して、emerge でインストールします:
root #
emerge --ask sys-kernel/mips-sources
このコマンドはカーネルソースを /usr/src/ の下に、カーネルバージョン毎のパスを分けてインストールします。選択されたカーネルソースパッケージに対して symlink USE フラグが有効化されていなければ、シンボリックリンクは自動で作成されません。
現在実行しているカーネルに対応するソースを指すように、/usr/src/linux シンボリックリンクを維持することは慣例となっています。しかし、このシンボリックリンクはデフォルトでは作成されないでしょう。シンボリックリンクを作成する簡単な方法は、eselect の kernel モジュールを利用することです。
シンボリックリンクの目的と、それを管理する方法についてのさらなる情報は、Kernel/Upgrade を参照してください。
まず、インストールされているカーネルを一覧表示します:
root #
eselect kernel list
Available kernel symlink targets: [1] linux-6.6.21-gentoo
linux シンボリックリンクを作成するには、次を使用してください:
root #
eselect kernel set 1
root #
ls -l /usr/src/linux
lrwxrwxrwx 1 root root 12 Oct 13 11:04 /usr/src/linux -> linux-6.6.21-gentoo
別の方法: マニュアル設定
はじめに
再掲ですが、この節はカーネルソースがインストールされていることを前提とします。適切なカーネルソースを取得していることを確認してから、ここに戻ってきてこの節の手順を進めてください。
カーネルのマニュアル設定は一般的に、システム管理者がしなければならない最も難しい手続きのひとつと見なされています。これは真実ではありません。カーネルを数回設定してみれば、それが難しいと言われていたことなど忘れてしまうでしょう!
しかし、一つだけ真実があります。カーネルをマニュアルで設定する時、ハードウェア情報を知ることはとても役に立ちます。ほとんどの情報は、lspciコマンドを含むsys-apps/pciutilsをインストールすることで得られます。
root #
emerge --ask sys-apps/pciutils
chroot環境では、lspciが出力していると思われる(pcilib: cannot open /sys/bus/pci/devicesのような)pcilibの警告は、無視しても構いません。
システム情報を得るための別の方法は、lsmodを使ってインストールCDが使っているカーネルモジュールを把握することです。その情報は何を有効にすべきかとてもよいヒントを与えてくれるでしょう。
では、カーネルソースがあるディレクトリに移動して、make menuconfigを実行しましょう。このコマンドはメニューベースの設定画面を起動します。
root #
cd /usr/src/linux
root #
make menuconfig
Linux カーネルの設定はとても多くのセクションを持っています。まず最初にいくつかの必須オプションを述べましょう(そうでない場合、Gentoo は動作しない、もしくは追加の処置なしには正しく動作しません)。 Gentoo wiki の Gentoo カーネルコンフィギュレーションガイドには、さらに役立つ記述があるでしょう。
必須オプションを有効にする
もし sys-kernel/gentoo-sources を使用する場合は、Gentoo 固有のコンフィギュレーションオプションを有効化することを強く推奨します。これらは、正しく機能するために必要な最小限のカーネルの機能が有効化されることを確実にします:
Gentoo Linux --->
Generic Driver Options --->
[*] Gentoo Linux support
[*] Linux dynamic and persistent device naming (userspace devfs) support
[*] Select options required by Portage features
Support for init systems, system and service managers --->
[*] OpenRC, runit and other script based systems and managers
[*] systemd
通常、最後の 2 行の選択は init システムの選択(OpenRC か systemd か)に依存します。両方の init システムへのサポートを有効化しても害はありません。
もし sys-kernel/vanilla-sources を使用する場合は、この init システムに関する追加の選択項目は利用できないでしょう。サポートを有効化することは可能ですが、このハンドブックの範囲からは外れることです。
典型的なシステムコンポーネントへのサポートを有効化する
システムのブートに必須となるドライバ (SATA コントローラ、NVMe ブロックデバイスサポート、ファイルシステムサポート等) は、モジュールではなく、カーネルの一部としてコンパイルしなければなりません。そうしないと、システムがまったくブートできない場合があります。
次に正確なプロセッサタイプを選択します。このとき、もし使えるのであればMCE機能を有効にすることが推奨されます。これによりハードウェアの異常が通知されるようになるでしょう。いくつかのアーキテクチャ(x86_64)で、これらのエラーはdmesgでは確認できませんが、/dev/mcelogにログが残ります。この機能を有効にするためにapp-admin/mcelogパッケージが必要になります。
また、Maintain a devtmpfs file system to mount at /devを選択することで、必須となるデバイスファイルがブートプロセスの初期段階で使えるようになります (CONFIG_DEVTMPFS と CONFIG_DEVTMPFS_MOUNT):
Device Drivers --->
Generic Driver Options --->
[*] Maintain a devtmpfs filesystem to mount at /dev
[*] Automount devtmpfs at /dev, after the kernel mounted the rootfs
SCSI ディスクサポートが有効になっているか確認してください(CONFIG_BLK_DEV_SD):
Device Drivers --->
SCSI device support --->
<*> SCSI device support
<*> SCSI disk support
Device Drivers --->
<*> Serial ATA and Parallel ATA drivers (libata) --->
[*] ATA ACPI Support
[*] SATA Port Multiplier support
<*> AHCI SATA support (ahci)
[*] ATA BMDMA support
[*] ATA SFF support (for legacy IDE and PATA)
<*> Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support (ata_piix)
基本的な NVMe サポートが有効になっているか確認してください:
Device Drivers --->
<*> NVM Express block device
Device Drivers --->
NVME Support --->
<*> NVM Express block device
以下の追加の NVMe サポートを有効化しても害はありません:
[*] NVMe multipath support
[*] NVMe hardware monitoring
<M> NVM Express over Fabrics FC host driver
<M> NVM Express over Fabrics TCP host driver
<M> NVMe Target support
[*] NVMe Target Passthrough support
<M> NVMe loopback device support
<M> NVMe over Fabrics FC target driver
< > NVMe over Fabrics FC Transport Loopback Test driver (NEW)
<M> NVMe over Fabrics TCP target support
次にFile Systemsで、システムが使用するファイルシステムに必要なサポートを選択しましょう。ルートファイルシステムに使われるファイルシステムをモジュールとしてコンパイルしてはいけません。モジュールにした場合、システムがパーティションをマウントできないおそれがあります。また、ここでVirtual memoryと/proc file systemも選択してください。システムの必要に応じて以下の選択肢から1個以上を選択してください:
File systems --->
<*> Second extended fs support
<*> The Extended 3 (ext3) filesystem
<*> The Extended 4 (ext4) filesystem
<*> Btrfs filesystem support
<*> XFS filesystem support
DOS/FAT/NT Filesystems --->
<*> MSDOS fs support
<*> VFAT (Windows-95) fs support
Pseudo Filesystems --->
[*] /proc file system support
[*] Tmpfs virtual memory file system support (former shm fs)
もしインターネットに接続するために、PPPoEもしくはダイヤルアップモデムを使う場合、次のオプションを有効にしてください (CONFIG_PPP, CONFIG_PPP_ASYNC, and CONFIG_PPP_SYNC_TTY):
Device Drivers --->
Network device support --->
<*> PPP (point-to-point protocol) support
<*> PPP over Ethernet
<*> PPP support for async serial ports
<*> PPP support for sync tty ports
2つの圧縮オプションは選択しても差し支えありませんが、必須というわけでもありません。PPP over Ethernetオプションも同様です。これはカーネルモードのPPPoEをするために設定された時だけにpppによって使用されるものです。
カーネルにネットワークカード(イーサネットもしくはワイヤレス)のサポートを組み込むことを忘れてはいけません。
多くのシステムではマルチコアを使用できます。Symmetric multi-processing supportを有効にすることは重要です (CONFIG_SMP):
Processor type and features --->
[*] Symmetric multi-processing support
マルチコアシステムでは、それぞれのコアが1プロセッサとカウントされます。
USB接続の入力装置(キーボードやマウス)などのUSBデバイスを使用する場合、以下を必ず有効にしてください:
Device Drivers --->
HID support --->
-*- HID bus support
<*> Generic HID driver
[*] Battery level reporting for HID devices
USB HID support --->
<*> USB HID transport layer
[*] USB support --->
<*> xHCI HCD (USB 3.0) support
<*> EHCI HCD (USB 2.0) support
<*> OHCI HCD (USB 1.1) support
<*> Unified support for USB4 and Thunderbolt --->
省略可能: 署名済みカーネルモジュール
自動的にカーネルモジュールに署名するためには、CONFIG_MODULE_SIG_ALL を有効化してください:
[*] Enable loadable module support
-*- Module signature verification
[*] Automatically sign all modules
Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->
お望みであれば任意でハッシュアルゴリズムを変更してください。
すべてのモジュールが有効な署名で署名されていることを強制するためには、CONFIG_MODULE_SIG_FORCE も有効化してください:
[*] Enable loadable module support
-*- Module signature verification
[*] Require modules to be validly signed
[*] Automatically sign all modules
Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->
カスタム鍵を使用するためには、CONFIG_MODULE_SIG_KEY にこの鍵の場所を指定してください。指定されていない場合は、カーネルビルドシステムが鍵を生成するでしょう。それに任せずに手動で鍵を生成することが推奨されます。これは、以下で行えます:
root #
openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pem
OpenSSL は鍵を生成するユーザについて、いくつかの質問をしてくるでしょう。これらの質問にできる限り詳細に答えることが推奨されます。
鍵を安全な場所に保存してください。少なくとも、鍵は root ユーザによってのみ読み込み可能であるべきです。以下でこれを検証してください:
root #
ls -l kernel_key.pem
-r-------- 1 root root 3164 Jan 4 10:38 kernel_key.pem
もしこれが上と何か違うものを出力する場合は、パーミッションを以下で訂正してください:
root #
chown root:root kernel_key.pem
root #
chmod 400 kernel_key.pem
-*- Cryptographic API --->
Certificates for signature checking --->
(/path/to/kernel_key.pem) File name or PKCS#11 URI of module signing key
linux-mod-r1.eclass
を利用する他のパッケージによってインストールされた外部カーネルモジュールにも署名するには、グローバルに modules-sign USE フラグを有効化してください:
USE="modules-sign"
# 任意で、カスタム署名鍵を使用する場合。
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # 鍵 MODULES_SIGN_KEY が証明書を含まない場合のみ必須です
MODULES_SIGN_HASH="sha512" # デフォルトは sha512 です
MODULES_SIGN_KEY と MODULES_SIGN_CERT は異なるファイルにすることもできます。この例では、OpenSSL によって生成される pem ファイルには鍵とそれに伴う証明書の両方を含んでいるため、両変数は同じ値に設定されています。
省略可能: カーネルイメージに署名する (セキュアブート)
(セキュアブートが有効化されたシステムで使用するために) カーネルイメージに署名する場合には、以下のカーネルコンフィグオプションを設定することが推奨されます:
General setup --->
Kexec and crash features --->
[*] Enable kexec system call
[*] Enable kexec file based system call
[*] Verify kernel signature during kexec_file_load() syscall
[*] Require a valid signature in kexec_file_load() syscall
[*] Enable ""image"" signature verification support
[*] Enable loadable module support
-*- Module signature verification
[*] Require modules to be validly signed
[*] Automatically sign all modules
Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->
Security options --->
[*] Integrity subsystem
[*] Basic module for enforcing kernel lockdown
[*] Enable lockdown LSM early in init
Kernel default lockdown mode (Integrity) --->
[*] Digital signature verification using multiple keyrings
[*] Enable asymmetric keys support
-*- Require all keys on the integrity keyrings be signed
[*] Provide keyring for platform/firmware trusted keys
[*] Provide a keyring to which Machine Owner Keys may be added
[ ] Enforce Machine Keyring CA Restrictions
ただし ""image"" はアーキテクチャ固有のイメージ名に対するプレースホルダです。これらのオプションは上から順に、kexec の呼び出し時にカーネルイメージが署名されていることを強制し (kexec はカーネルをその場で置き換えることを許可します)、カーネルモジュールが署名されていることを強制し、integrity ロックダウンモードを有効化し (実行時にカーネルを変更することを防止します)、各種キーチェーンを有効化します。
圧縮されたカーネルの展開をネイティブにサポートしていないアーキテクチャ (例: arm64 および riscv) では、カーネルは自身の展開プログラム (zboot) とともにビルドしなくてはなりません:
Device Drivers --->
Firmware Drivers --->
EFI (Extensible Firmware Interface) Support --->
[*] Enable the generic EFI decompressor
カーネルのコンパイル後は、次の節で説明する通り、カーネルイメージに署名しなくてはなりません。まず app-crypt/sbsigntools をインストールして、次にカーネルイメージに署名してください:
root #
emerge --ask app-crypt/sbsigntools
root #
sbsign /usr/src/linux-x.y.z/path/to/kernel-image --cert /path/to/kernel_key.pem --key /path/to/kernel_key.pem --out /usr/src/linux-x.y.z/path/to/kernel-image
この例では、カーネルイメージに署名するために、モジュールに署名するために生成されたのと同じ鍵が使用されています。カーネルイメージに署名するために、2 個目の別の鍵を生成して使用することも可能です。前節と同じ OpenSSL コマンドをもう一度使用することができます。
それではインストールを続行してください。
他のパッケージによってインストールされる EFI 実行可能形式に自動的に署名するには、グローバルに secureboot USE フラグを有効化してください:
USE="modules-sign secureboot"
# 任意で、カスタム署名鍵を使用するために。
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # MODULES_SIGN_KEY が証明書を含まない場合のみ必須です。
MODULES_SIGN_HASH="sha512" # デフォルトは sha512 です
# 任意で、セキュアブートを有効化してブートするために。署名鍵は同一でも別でも構いません。
SECUREBOOT_SIGN_KEY="/path/to/kernel_key.pem"
SECUREBOOT_SIGN_CERT="/path/to/kernel_key.pem"
SECUREBOOT_SIGN_KEY と SECUREBOOT_SIGN_CERT は異なるファイルにすることもできます。この例では、OpenSSL によって生成される pem ファイルには鍵とそれに伴う証明書の両方を含んでいるため、両変数は同じ値に設定されています。
systemd の
ukify
を使用して Unified カーネルイメージを生成する場合は、カーネルイメージは unified カーネルイメージに含められる前に自動的に署名されるので、手動で署名する必要はありません。
設定を準備する
On the Origin 200/2000, Indigo2 Impact (R10000), Octane/Octane2 and O2, a 64-bit kernel is required to boot these systems. For these machines, emerge sys-devel/kgcc64 to create a cross-compiler for building 64-bit kernels.
Many of the systems supported have sample default .config files hiding in amongst the kernel source. Not all systems have configs distributed in this way. Those that do, can be configured using the commands mentioned in the table below.
System | Configure command |
---|---|
Cobalt Servers | make cobalt_defconfig |
Indy, Indigo2 (R4k), Challenge S | make ip22_defconfig |
Origin 200/2000 | make ip27_defconfig |
Indigo2 Impact (R10k) | make ip28_defconfig |
O2 | make ip32_defconfig |
All of the Gentoo installation images provide a kernel config option as part of the image itself, accessible as /proc/config.gz. This may be used in many cases. It is best though if the kernel source matches closely the kernel that is currently running. To extract it, simply run it through zcat as shown below.
root #
zcat /proc/config.gz > .config
This kernel config is set up for a netboot image. That is, it will expect to find a root filesystem image somewhere nearby, either as a directory for initramfs, or a loopback device for initrd. When executing make menuconfig, don't forget to go into General Setup and disable the options for initramfs.
設定をカスタマイズする
Once a configuration is found, download it into the kernel source directory, and rename it to .config. From there, run make oldconfig to bring everything up to date according to the instructions above, and customize the configuration before compiling.
root #
cd /usr/src/linux
root #
cp /path/to/example-config .config
root #
make oldconfig
Just press the ENTER (or Return) key at each prompt to accept the defaults for now ...
root #
make menuconfig
In the Kernel Hacking section, there is an option named "Are You Using A Cross Compiler?". This tells the kernel Makefiles to prepend "mips-linux-" (or mipsel-linux ... etc) to gcc and as commands when compiling the kernel. This should be turned off, even if cross-compiling. Instead, if a cross-compiler needs to be called, specify the prefix using the CROSS_COMPILE variable as shown in the next section.
There is a known issue with JFS and ALSA on Octane systems where the ALSA fails to work. Given the experimental nature of JFS on MIPS, it is recommended that people avoid using JFS for the time being.
コンパイルおよびインストール
カーネルのコンフィグレーションが完了し、コンパイルとインストールをする時がきました。コンフィグレーションを終了させ、コンパイル作業を開始しましょう:
64 ビットマシンでは、CROSS_COMPILE=mips64-unknown-linux-gnu- (または、リトルエンディアンシステムでは mips64el-... ) を指定することで 64 ビットコンパイラーを使用します。
ネイティブにコンパイルするには:
root #
make vmlinux modules modules_install
Cross-compiling on target machine, adjust the mips64-unknown-linux-gnu- accordingly:
root #
make vmlinux modules modules_install CROSS_COMPILE=mips64-unknown-linux-gnu-
When compiling on another machine, such as an x86 box, use the following commands to compile the kernel & install modules into a specific directory to be transferred to the target machine.
root #
make vmlinux modules CROSS_COMPILE=mips64-unknown-linux-gnu-
root #
make modules_install INSTALL_MOD_PATH=/somewhere
When compiling a 64-bit kernel for the Indy, Indigo2 (R4k), Challenge S and O2, use the vmlinux.32 target instead of vmlinux. Otherwise, the machine will not be able to boot. This is to work around the PROM not understanding the ELF64 format.
root #
make vmlinux.32
make -jX
とすることで、ビルドを並行処理させることができます( X には、並行処理を許可するビルドプロセスの数を指定します。 /etc/portage/make.conf の説明中の、 MAKEOPTS 変数についてと同様です。上記の場合は vmlinux.32 が最終的なカーネルとして生成されます。
カーネルのコンパイルが終了したら、カーネルのイメージを /boot/ にコピーしましょう。
On Cobalt servers, the bootloader will expect to see a compressed kernel image. Remember to gzip -9 the file once it is in /boot/.
root #
cp vmlinux /boot/kernel-6.6.21-gentoo
Cobalt サーバー用では、カーネルイメージを圧縮します:
root #
gzip -9v /boot/kernel-6.6.21-gentoo
別の方法: Genkernel
再掲ですが、この節はカーネルソースがインストールされていることを前提とします。適切なカーネルソースを取得していることを確認してから、ここに戻ってきてこの節の手順を進めてください。
Genkernel は、Genkernel だけが満たすことができるニーズを持つ場合のみ検討されるべきです。そうでない場合は、ディストリビューションカーネルを使用するか自身で手動でコンパイルすることで Gentoo システムの維持がずっと単純になるので、そうすることが推奨されます。genkernel のほうが管理しづらい理由の例のひとつは、sys-kernel/installkernel との統合の欠如です。これは、Genkernel を使用する場合には Unified カーネルイメージを手動で作成する必要があるなどのように、他の手法によって提供されるのと同じレベルの自動化を得られないだろうということを意味します。
Genkernel はジェネリックカーネルコンフィギュレーションファイルを提供し、カーネルと initramfs をコンパイルし、生成されたバイナリを適切な場所にインストールします。これによりシステムの初回起動のための最小限かつジェネリックなハードウェアサポートが得られ、さらなる更新の制御と、将来のカーネル設定のカスタマイズが可能になります。
注意: システム管理者はカーネルの保守のために genkernel を使うことで、システムのカーネル、initramfs、その他のオプションに関する更新をより制御できるようになります。その一方で、将来的に新しいソースがリリースされてカーネル更新を実施するときには、時間と労力をかけた献身が確実に必要となるでしょう。システム任せのカーネル保守アプローチを求めているのなら、ディストリビューションカーネルを使用するべきです。
もう一点明確にしておくと、genkernel が自動的に実行中のハードウェアのためにカスタマイズされたカーネルコンフィギュレーションを生成すると信じているなら、それは誤解です。genkernel は、大部分の汎用的なハードウェアをサポートするように事前に決定されたカーネルコンフィギュレーションを使用して、カーネル、関連するモジュール、そして initramfs ファイルをアセンブルしてインストールするために必要な make コマンドを、自動で操作します。
バイナリ再配布可能なソフトウェアのライセンスグループ
linux-firmware パッケージが以前にインストールされているなら、インストールの節に進んでください。
前提条件として、sys-kernel/genkernel パッケージの firwmare
USE フラグがデフォルトで有効化されているため、パッケージマネージャは sys-kernel/linux-firmware パッケージを取り込もうとするでしょう。linux-firmware をインストールする前に、バイナリ再配布可能なソフトウェアライセンスを受諾する必要があります。
このライセンスグループは、/etc/portage/make.conf ファイル内で ACCEPT_LICENSE の値として @BINARY-REDISTRIBUTABLE
を追加することで、すべてのパッケージに対してシステム全体で受諾することができます。/etc/portage/package.license/linux-firmware ファイルで個別の受諾を追加することで、linux-firmware パッケージのみに対して受諾することもできます。
必要であれば、ハンドブックのベースシステムのインストールの章で利用可能な、ソフトウェアライセンスを受諾する方法を再確認して、受け入れられるソフトウェアライセンスのために変更を加えてください。
分析麻痺に陥ってきたなら、次のようにすればよいでしょう:
root #
mkdir /etc/portage/package.license
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
インストール
説明や前提条件はさておき、sys-kernel/genkernel パッケージをインストールしてください:
root #
emerge --ask sys-kernel/genkernel
生成
genkernel all を実行してカーネルソースをコンパイルしましょう。ただ、genkernel は多種多様に異なるコンピュータアーキテクチャのために、幅広いハードウェアをサポートするカーネルを生成するため、コンパイルが完了するまでにかなりの時間がかかることがあるということに注意しましょう。
もしルートパーティションまたはボリュームが ext4 または XFS 以外のファイルシステムを使用している場合、おそらく genkernel --menuconfig all を使ってマニュアルでカーネルを設定し、その特定のファイルシステムのためのサポートを (モジュールとしてファイルシステムをビルドするのではなく) カーネルに組み込む必要があるでしょう。
LVM2 のユーザは以下の genkernel コマンドの引数に
--lvm
を加えるべきです。root #
genkernel --mountboot --install all
genkernel が完了したら、カーネルと初期 RAM ファイルシステム (initramfs) が生成され、/boot ディレクトリにインストールされていることでしょう。関連するモジュールは /lib/modules ディレクトリにインストールされるでしょう。initramfs は、(live ディスクイメージ環境でそうであるように) ハードウェアの自動検出を行うために、カーネルをロードした後すぐに開始されます。
root #
ls /boot/vmlinu* /boot/initramfs*
root #
ls /lib/modules
カーネルのインストール
Installkernel
Installkernel は、カーネルのインストール、initramfs の生成、unified カーネルイメージの生成、そして何よりもブートローダの設定を自動化するために、使用することができます。sys-kernel/installkernel はこれを達成するための 2 通りの道を実装しています: Debian に由来する伝統的な installkernel と、 systemd の kernel-install です。どちらを選ぶべきかは、何よりもシステムのブートローダによって変わります。デフォルトでは、systemd プロファイルでは systemd の kernel-install が使用される一方、それ以外のプロファイルでは伝統的な installkernel がデフォルトです。
よく分からない場合は、下の「伝統的なレイアウト」のサブ節に従ってください。
systemd-boot
ブートローダとして systemd-boot (旧 gummiboot) を使用している場合は、systemd の kernel-install を使用しなくてはなりません。そのため、sys-kernel/installkernel に対して systemd および systemd-boot USE フラグが有効化されていることを確認して、systemd-boot のための関連するパッケージをインストールしてください。
OpenRC システムでは:
sys-apps/systemd-utils boot kernel-install
sys-kernel/installkernel systemd systemd-boot
root #
emerge --ask sys-apps/systemd-utils
systemd システムでは:
sys-apps/systemd boot
sys-kernel/installkernel systemd-boot
root #
emerge --ask sys-apps/systemd
GRUB
GRUB を使用する場合は、systemd の kernel-install または伝統的な Debian installkernel のいずれかを使用することができます。systemd USE フラグはこれらの実装の切り換えを行います。カーネルをインストールするときに自動的に grub-mkconfig を実行するためには、grub USE フラグを有効化してください。
sys-kernel/installkernel grub
root #
emerge --ask sys-kernel/installkernel
伝統的なレイアウト、その他のブートローダ (lilo 等)
grub、systemd-boot および uki USE フラグが有効化されていない場合、(LILO などのための) 伝統的な /boot レイアウトがデフォルトで使用されます。さらなる操作は必要ありません。
initramfs をビルドする
場合によっては、initramfs (初期 RAM ファイルシステム、initial ram-based file system) をビルドする必要があることがあります。最もよくある理由は、(/usr/ または /var/ などの) 重要のファイルシステムの場所が別のパーティション上にあるときです。initramfs を使用することで、これらのパーティションを initramfs 内で利用可能なツールを使用してマウントすることができます。Project:Distribution Kernel のデフォルトの構成は initramfs を必要とします。
initramfs がないと、ファイルシステムのマウントに責任を持つツールが、マウントされていないファイルシステム上にある情報を必要とするために、システムが正しくブートしないリスクがあります。initramfs は、カーネルがブートした直後、ただし制御が init ツールに移される前に使用されるアーカイブ内に、必要なファイルを持ち込みます。その後、initramfs 上のスクリプトは、システムがブートを継続する前に、パーティションが正しくマウントされていることを確実にします。
genkernel を使用する場合は、カーネルおよび initramfs の両方をビルドするために使用するべきです。initramfs の生成のみのために genkernel を使用する場合、genkernel に
--kernel-config=/path/to/kernel.config
を渡すことが重要です。さもないと、生成された initramfs は手動でビルドされたカーネルとともに機能しないことがあります。手動でビルドされたカーネルは、ハンドブックのサポートの範囲外であることに注意してください。さらなる情報についてはカーネルコンフィギュレーションの記事を参照してください。Installkernel は、dracut USE フラグが有効化されている場合、カーネルのインストール時に initramfs を自動的に生成することができます:
sys-kernel/installkernel dracut
または、initramfs を生成するために dracut を手動で呼び出してもかまいません。まず sys-kernel/dracut をインストールして、次に initramfs を生成させてください:
root #
emerge --ask sys-kernel/dracut
root #
dracut --kver=6.6.21-gentoo
initramfs は /boot/ に保存されるでしょう。結果のファイルは単に initramfs で始まるファイルを一覧表示することで確認できます:
root #
ls /boot/initramfs*
省略可能: Unified カーネルイメージをビルドする
Unified カーネルイメージ (UKI) は、まず何よりもカーネル、そして initramfs、それとカーネルコマンドラインを単一の実行可能形式に合成したものです。カーネルコマンドラインは unified カーネルイメージ内に埋め込まれるので、unified カーネルイメージを生成する前に指定するべきです (下を参照してください)。セキュアブートを有効化してブートする場合、ブートローダまたはファームウェアによってブート時に提供されるあらゆるカーネルコマンドライン引数は無視されることに注意してください。
unified カーネルイメージはスタブローダを必要とします。現時点で唯一利用可能なのは systemd-stub です。これを有効化するには:
systemd システムでは:
sys-apps/systemd boot
OpenRC システムでは:
sys-apps/systemd-utils boot kernel-install
Installkernel は、それぞれ対応するフラグを有効化することで、dracut または ukify のいずれかを使用して自動的に unified カーネルイメージを生成することができます。生成された unified カーネルイメージを EFI システムパーティション (ESP) 上の $ESP/EFI/Linux ディレクトリにインストールするために、uki USE フラグも有効化すべきです。
dracut を使用する場合は:
sys-kernel/installkernel dracut uki
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"
ukify を使用する場合は:
sys-apps/systemd ukify # For systemd systems
sys-apps/systemd-utils ukify # For OpenRC systems
sys-kernel/installkernel dracut ukify uki
some-kernel-command-line-arguments
dracut は initramfs と unified カーネルイメージの両方を生成することができる一方で、ukify は後者しか生成できないので、initramfs は dracut を使用して個別に生成しなくてはならないことに注意してください。
ジェネリック Unified カーネルイメージ
ビルド済みの sys-kernel/gentoo-kernel-bin は任意で、ほとんどの systemd ベースのシステムをブートすることができるジェネリックな initramfs を含む、ビルド済みのジェネリック unified カーネルイメージをインストールすることができます。これは、generic-uki USE フラグを有効化して、installkernel をカスタムの initramfs または unified カーネルイメージを生成しないように設定することで、インストールすることができます:
sys-kernel/gentoo-kernel-bin generic-uki
sys-kernel/installkernel -dracut -ukify uki
セキュアブート
sys-kernel/gentoo-kernel-bin によって任意に配布されているジェネリック Unified カーネルイメージは事前署名済みです。ローカルで生成された unified カーネルイメージに署名する方法は dracut または ukify のどちらを使用するかで異なります。鍵と証明書の場所は /etc/portage/make.conf 内で指定された SECUREBOOT_SIGN_KEY および SECUREBOOT_SIGN_CERT と同一であるべきということに注意してください。
dracut を使用する場合は:
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"
uefi_secureboot_key="/path/to/kernel_key.pem"
uefi_secureboot_cert="/path/to/kernel_key.pem"
ukify を使用する場合は:
[UKI]
SecureBootPrivateKey=/path/to/kernel_key.pem
SecureBootCertificate=/path/to/kernel_key.pem
外部のカーネルモジュールを再ビルドする
linux-mod-r1.eclass
を介して他のパッケージによってインストールされた外部のカーネルモジュールは、新しいカーネルバージョンごとに、再ビルドしなくてなりません。ディストリビューションカーネルを使用している場合は、dist-kernel フラグをグローバルに有効化することで、これを自動化することができます。
*/* dist-kernel
外部のカーネルモジュールは手動で再ビルドすることもできます:
root #
emerge --ask @module-rebuild
カーネルモジュール
利用可能なカーネルモジュールを一覧表示する
ハードウェアモジュールを手作業で列挙する必要はありません。ほとんどの場合、udev は接続を検出したハードウェアのモジュールを自動でロードします。ですが、自動でロードされるであろうモジュールを列挙することは特に有害ではありません。モジュールが二度ロードされることはありません。モジュールの状態は、ロードされているかいないか、どちらかしかありません。時として変なハードウェアは、ドライバをロードするのにこうした手助けが必要になることがあります。
/etc/modules-load.d/*.conf ファイルに、ブート時に毎回ロードしなければならないモジュールを、1 行ごとに 1 モジュールのフォーマットで追加することができます。モジュールに追加のオプションを与える必要があれば、ここではなく /etc/modprobe.d/*.confファイルで設定すべきです。
特定のカーネルバージョンで利用可能なすべてのモジュールを把握するためには、次の find コマンドを実行してください。"<kernel version>" を検索したいカーネルのバージョンで適切に置き換えることを忘れないでください:
root #
find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko' | less
特定のカーネルモジュールのロードを強制する
3c59x.ko モジュール (これは特定の 3Com ネットワークカードファミリのためのドライバです) をロードするようにカーネルに強制するには、/etc/modules-load.d/network.conf 内にモジュール名を記載してください。
root #
mkdir -p /etc/modules-load.d
root #
nano -w /etc/modules-load.d/network.conf
モジュールの .ko ファイル拡張子はロード機構にとって重要ではなく、設定ファイルから除かれるということに注意してください:
3c59x
では、システムの設定に進み、インストールを続けましょう。
ファイルシステムの情報
ファイルシステムラベルと UUID
MBR(BIOS)とGPTの両方が、ファイルシステムラベルとファイルシステムUUIDをサポートしています。これらの属性は、ブロックデバイスを探しマウントするために使用されるmountコマンドの代用として、/etc/fstab内で定義することができます。ファイルシステムラベルやファイルシステムUUIDはそれぞれLABELとUUID接頭辞で識別され、blkidコマンドで確認することができます:
root #
blkid
もし、パーティション内のファイルシステムが消滅すると、ファイルシステムのラベルとUUIDの値は後に変更されるか除去されます。
一意性のため、MBRスタイルのパーティションテーブルを使用している読者は、/etc/fstab内で、マウント可能なボリュームを定義するのにラベルよりもUUIDを用いることを推奨します。
LVM ボリューム上に置かれたファイルシステムの UUID と、LVM ボリュームの LVM スナップショットの UUID は同じなので、LVM ボリュームをマウントするために UUID を使用するのは避けるべきです。
パーティションラベルと UUID
GPT ディスクラベルへのサポートを持つシステムでは、/etc/fstab でパーティションを定義するための '堅牢' な追加の選択肢が提供されます。パーティション自体にどのファイルシステムが使用されているかにかかわらず、ブロックデバイスの個々のパーティションを識別するのにパーティションラベルやパーティションの UUID を使うことができます。パーティションラベルとパーティションの UUID は PARTLABEL、PARTUUID 接頭辞で識別され、これらは端末で blkid コマンドを実行することで簡単に確認できます。
Discoverable Partition Specification の UUID を使用する amd64 EFI システムでの出力は、次のようになるでしょう:
root #
blkid
/dev/sr0: BLOCK_SIZE="2048" UUID="2023-08-28-03-54-40-00" LABEL="ISOIMAGE" TYPE="iso9660" PTTYPE="PMBR" /dev/loop0: TYPE="squashfs" /dev/sda2: PARTUUID="0657fd6d-a4ab-43c4-84e5-0933c84b4f4f" /dev/sda3: PARTUUID="1cdf763a-5b4c-4dbf-99db-a056c504e8b2" /dev/sda1: PARTUUID="c12a7328-f81f-11d2-ba4b-00a0c93ec93b"
パーティションラベルも絶対にとは言えないのに対し、fstab で UUID を使ったパーティション指定を使えば、たとえ将来ファイルシステムが変更されたり、再度書き込まれたりしても、ブートローダーがボリューム検出に迷うことはありません。従来のブロックデバイスファイル (/dev/sd*N) を使った指定は、SATA ブロックデバイスの追加または削除が日常的に行われるシステムでは危険です。
ブロックデバイスのファイル名は様々な要素 (ディスクがどんな順番でいくつ接続されているかを含む) によって変化します。またファイル名の順番についても、初期起動プロセス中にカーネルがどのデバイスを最初に検知するかによって変化します。つまり、システム管理者がディスクの順序を頻繁にいじったりしない限りは、デフォルトのブロックデバイスファイルを使うのがシンプルで素直な方法です。
fstab について
Linuxでは、システムで使用するすべてのパーティションは/etc/fstabに記載されていなければなりません。このファイルは、これらパーティションのマウントポイント(これらはファイルシステムに存在しなければなりません)、どのようにマウントされるべきか、また特別なオプション(自動マウントかそうでないか、ユーザー権限でマウントできるかどうか等)を定義します。
fstab ファイルを作成する
If the init system being used is systemd, the partition UUIDs conform to the Discoverable Partition Specification as given in Preparing the disks, and the system uses UEFI, then creating an fstab can be skipped, since systemd auto-mounts partitions that follow the spec.
/etc/fstabファイルは表のように記述します。それぞれの行はホワイトスペース(一つまたは複数のスペース、タブ、もしくはその 2 種の組み合わせ)で区切られる 6 つのフィールドを持ちます。それぞれのフィールドの意味は以下の通りです。
- 最初のフィールドはマウントされるブロックスペシャルデバイスやリモートファイルシステムを示します。デバイスファイルへのパスや、ファイルシステムラベルやファイルシステムUUID,そしてパーティションラベルやパーティションUUIDを含む、いくつかの種類のデバイスIDがブロックスペシャルデバイスノードとして使用可能です。
- 2番目のフィールドはそのパーティションがマウントされるマウントポイントを示します。
- 3番目のフィールドはそのパーティションのファイルシステムの種類を示します。
- 4番目のフィールドは、そのパーティションをマウントするmountコマンドが使用するオプションを示します。すべてのファイルシステムは、固有のマウントオプションを持っています。システム管理者はマウントコマンドのmanページ(man mount)を参照することですべてのオプションを確認できます。複数のマウントオプションを記述する場合はカンマで区切ります。
- 5番目のフィールドはそのパーティションをdumpでダンプするかどうかを示しています。このフィールドは通常
0
(ゼロ)のままにしておいてかまいません。 - 6番目のフィールドは、直前のシャットダウンが正常に完了しなかったときに、fsckが各パーティションをどの順番でチェックするか示しています。ルートファイルシステムは
1
であるべきです。残りのファイルシステムは2
(ファイルシステムチェックが不要であれば0
)に設定しましょう。
Gentoo stage ファイルに含まれるデフォルトの /etc/fstab ファイルは有効な fstab ではなく、関連する値を入力するために使用できるテンプレートです。
root #
nano /etc/fstab
DOS/レガシー BIOS システム
では、/boot パーティションをどのように記述すればよいか見てみましょう。これは一つの例です。実際はインストール手順の最初に決めたパーティション構成通りに修正しなければなりません。 mips のパーティション構成の例として、/boot は通常は /dev/sda1 パーティションになり、推奨されるファイルシステムである xfs を使います。このパーティションはブート中にチェックされなければならないので、fstab は以下のようになるでしょう:
# 整形上の差異や、「ディスクの準備」ステップで作成する追加のパーティションについては、適宜修正してください
/dev/sda1 /boot ext2 defaults 0 2
システム管理者によっては、セキュリティを向上させるために /boot パーティションを自動的にマウントしたくないかもしれません。その場合は defaults
を noauto
で置き換えてください。これは、そのパーティションを使いたいときは都度手動でマウントしなければならないことを意味します。
実際のパーティション構成にあわせたルールや、CD-ROMドライブのためのルールを追加してください。他にパーティションやドライブがあれば、それも忘れずに追加しておきましょう。
以下は、より詳細な/etc/fstabの例です。
# 整形上の差異や、「ディスクの準備」ステップで作成する追加のパーティションについては、適宜修正してください
/dev/sda1 /boot ext2 defaults 0 2
/dev/sda10 none swap sw 0 0
/dev/sda5 / xfs defaults,noatime 0 1
/dev/cdrom /mnt/cdrom auto noauto,user 0 0
UEFI システム
以下は UEFI ファームウェアを介してブートするシステムでの /etc/fstab ファイルの例です:
# 整形上の差異や、「ディスクの準備」ステップで作成する追加のパーティションについては、適宜修正してください
0 2
/dev/sda10 none sw 0 0
/dev/sda5 / xfs defaults,noatime 0 1
/dev/cdrom /mnt/cdrom auto noauto,user 0 0
DPS UEFI PARTUUID
以下は、UEFI ファームウェア向けに GPT ディスクラベルと Discoverable Partition Specification (DPS) の UUID を使用してフォーマットされたディスクのための、/etc/fstab ファイルの例です:
# 整形上の差異や、「ディスクの準備」ステップで作成する追加のパーティションについては、適宜修正してください。
# この例は Discoverable Partition Specification (DSP) UUID が設定された GPT ディスクラベルを示しています:
PARTUUID=c12a7328-f81f-11d2-ba4b-00a0c93ec93b 0 2
PARTUUID=0657fd6d-a4ab-43c4-84e5-0933c84b4f4f none sw 0 0
PARTUUID= / xfs defaults,noatime 0 1
3番目のフィールドでauto
を使う場合、mountコマンドはそのパーティションのファイルシステムが何かを推測します。これは様々なファイルシステムを使う可能性があるリムーバルメディアで推奨されます。4番目のuser
オプションで、ルート権限を持たないユーザーがCDをマウントできるようになります。
パフォーマンスを改善するために、多くのユーザーはマウントオプションとして noatime
オプションを付け加えたいと考えるでしょう。アクセス時間が記録されないので、結果としてより高速なシステムになります (一般的にこの記録はほとんど必要ありません)。ソリッドステートドライブ (SSD) を持つシステムでもこれはおすすめです。代わりに lazytime
もまた考慮に値するかもしれません。
パフォーマンスを低下させるため、/etc/fstab 内で
discard
マウントオプションを定義させるのは推奨されません。cron または timer (systemd) のようなジョブスケジューラを使用して、定期的にブロックの破棄をスケジュールするほうが、一般的により良い方法です。さらなる情報については、Periodic fstrim jobs を確認してください。再度/etc/fstabを確認して、保存、エディタを終了します。
ネットワーク接続のための情報
重要な注意点として、このセクションは読者がシステムをローカルエリアネットワークに手っ取り早く参加させることができるように、提供しています。
OpenRC を動かしているシステムについては、ネットワーク設定のためのより詳細なリファレンスが、ハンドブックの終わりのほうの高度なネットワーク設定のセクションでカバーされています。より詳細なネットワーク要件のあるシステムは一度そちらへ飛んで、それからここに戻ってきて残りのインストール作業を続ける必要があるかもしれません。
より詳細な systemd のネットワーク設定については、systemd の記事のネットワークの箇所を確認してください。
ホスト名
さて、PCには名前をつけなければいけません。至極簡単に思えますが多くのシステム管理者はホスト名として適切な名前を付けるのに苦労しています。事を早く進めるために、選んだ名前は後で変更できることを知っておいてください。判りやすいように、ここでは単にマシンをtuxと呼ぶことにします。
ホスト名を設定する (OpenRC または systemd)
root #
echo tux > /etc/hostname
systemd
現在実行中の systemd についてシステムのホスト名を設定するには、hostnamectl ユーティリティを使うことができます。しかしながらインストールプロセス中は、systemd-firstboot コマンドを代わりに使う必要があります (後でハンドブックの該当箇所を参照してください)。
ホスト名を "tux" に設定するためには、次のようにします:
root #
hostnamectl hostname tux
hostnamectl --help または man 1 hostnamectl を実行することで、ヘルプを確認してください。
ネットワーク
ネットワークインターフェースを構成するために利用できる選択肢は多く存在します。この節ではそのうち一部の方法だけをカバーします。必要な構成に最適と思われるものをひとつ選んでください。
dhcpcd での DHCP (どんな init システムでも)
多くの LAN ネットワークは DHCP サーバは運用しています。その場合は、dhcpcd プログラムを使用して IP アドレスを取得するのがおすすめです。
インストールするには:
root #
emerge --ask net-misc/dhcpcd
OpenRC システム上で、サービスを有効化して開始するには:
root #
rc-update add dhcpcd default
root #
rc-service dhcpcd start
systemd システム上で、サービスを有効化するには:
root #
systemctl enable dhcpcd
これらのステップが完了したら、次にシステムが起動したときに、dhcpcd が DHCP サーバから IP アドレスを取得するはずです。さらなる詳細については Dhcpcd の記事を確認してください。
netifrc (OpenRC)
ネットワークを設定する
Gentoo Linux をインストールしている間、ネットワークが使えるように設定されています。しかし、それは live 環境のためのネットワーク設定であり、インストールされた環境のためのものではありません。では、インストールされた Gentoo Linux のネットワークを設定しましょう。
bonding、ブリッジ、802.1Q VLAN、無線ネットワークに間するより詳細な情報は、追加のネットワーク設定セクションを参照してください。
すべてのネットワーク設定は/etc/conf.d/netにあります。直接的ではありますが、おそらく直感で理解できる構文ではありません。しかし恐れることはありません。すべては以下で説明されます。/usr/share/doc/netifrc-*/net.example.bz2に、多くの異なる設定に対して完全にコメントが付与された例が記載されています。
最初に net-misc/netifrc をインストールします。
root #
emerge --ask --noreplace net-misc/netifrc
DHCPはデフォルトで使用されます。DHCPを動かすために、DHCPクライアントをインストールしなければなりません。これは Installing Necessary System Toolsで説明されます。
もし、特別なDHCPのオプションを設定している、もしくはDHCPをまったく使いたくない等の理由で、ネットワーク接続をしなければならないときは、/etc/conf.d/netを編集します。
root #
nano /etc/conf.d/net
IPアドレスとルーティングを設定するのはconfig_eth0とroutes_eth0です。
ここではネットワークインターフェイスがeth0であると仮定していますが、これはシステムによって違います。もし、最近のインストールメディアから起動しているのであれば、インストール時と同じインターフェイス名が使われると思ってよいでしょう。より詳しい情報はネットワークインターフェースの命名セクションを参照してください。
config_eth0="192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255"
routes_eth0="default via 192.168.0.1"
DHCPを使う場合は、config_eth0を設定してください。
config_eth0="dhcp"
さらなる設定オプションのリストについては、/usr/share/doc/netifrc-*/net.example.bz2を参照してください。もし特定のDHCPを設定しなければならないときは、DHCPクライアントのmanページも必ず読みましょう。
もし、システムが複数のネットワークインターフェースを持っている場合は、config_eth1、config_eth2、…に対して上記の手順を繰り返してください。
設定を保存し、エディタを終了しましょう。
起動時に自動でネットワーク接続する
ブート時にネットワークインターフェースを有効にする場合は、デフォルトランレベルにそれらを追加する必要があります。
root #
cd /etc/init.d
root #
ln -s net.lo net.eth0
root #
rc-update add net.eth0 default
もし、複数のネットワークインターフェースがある場合は、net.eth0と同じ方法で、適切なnet.*ファイルを作成しなければなりません。
もし、ブート後、ネットワークインターフェース名(現在、このドキュメントではeth0
と記述)が間違っていた場合、次の手順で修正してください。
- 正しいインターフェース名で/etc/conf.d/netファイルを更新します。(例えば
eth0
をenp3s0
またはenp5s0
と修正) - 新しいシンボリックリンクを作成。(例えば/etc/init.d/net.enp3s0)
- 古いシンボリックリンクを消去。(rm /etc/init.d/net.eth0)
- 新しいスクリプトをデフォルトランレベルに追加。
- rc-update del net.eth0 defaultで古いスクリプトを消去。
hosts ファイル
次の重要なステップは、この新しいシステムのネットワーク環境内の他のホストについて、システムに教えることかもしれません。ネットワークホスト名は /etc/hosts で定義することができます。ホスト名をここに追加することで、ネームサーバでは解決できないホストについて、ホスト名から IP アドレスを解決できるようになります。
root #
nano /etc/hosts
# 以下は本システムの定義です。必ず設定されなければなりません。
127.0.0.1 tux.homenetwork tux localhost
# ネットワーク上にあるその他のホストの定義です。任意設定です。
192.168.0.5 jenny.homenetwork jenny
192.168.0.6 benny.homenetwork benny
設定をセーブし、エディタを終了しましょう。
システム情報
root パスワード
passwdコマンドでルートのパスワードを設定します。
root #
passwd
後で、日常の作業のための一般ユーザーアカウントを作成します。
init と boot 設定
OpenRC
Gentoo で OpenRC を使用しているときは、OpenRC はシステムのサービス、スタートアップ、シャットダウンの設定に /etc/rc.conf を使います。/etc/rc.conf を開いて、ファイル中のすべてのコメントを楽しみましょう。設定をレビューして、必要な箇所を変更してください。
root #
nano /etc/rc.conf
次に、キーボードを設定するために/etc/conf.d/keymapsを開いて、正しいキーボードを選択、設定します。
root #
nano /etc/conf.d/keymaps
keymap変数に特に注意してください。もしキーマップを間違えた場合、キーボードを叩くたびに、奇妙な現象が起こるでしょう。
最後に、クロック設定をするために/etc/conf.d/hwclockを編集します。個々の好みに合わせて設定できます。
root #
nano /etc/conf.d/hwclock
もし、ハードウェアクロックがUTCになっていない場合、このファイルにclock="local"
を記述しなければなりません。そうでない場合、クロックスキューが発生するでしょう。
systemd
まず、システムが正しく起動できるようにするために、systemd-machine-id-setup と systemd-firstboot を順に実行することをおすすめします。これは、新しい systemd 環境への最初のブートのために、システムのさまざまなコンポーネントが正しく設定されるように準備します。次のオプションを渡すことで、ロケール、タイムゾーン、ホスト名、root パスワード、そして root シェル値を設定するための、ユーザへのプロンプトを含めます。加えて、システムにランダムなマシン ID を割り当てます:
root #
systemd-machine-id-setup
root #
systemd-firstboot --prompt
次に、インストールされているすべてのユニットファイルをプリセットのポリシー値にリセットするため、ユーザは systemctl を実行すべきです:
root #
systemctl preset-all --preset-mode=enable-only
完全にプリセットにするには次で行えますが、これまでのプロセスで既に設定したすべてのサービスもリセットするかもしれません:
root #
systemctl preset-all
live 環境からインストール先の最初のブートへのシームレスな移行を確実に行うために、これらの 2 ステップは有用でしょう。
システムロガー
OpenRC
同じ機能が複数のパッケージによって提供されるツールがいくつかあります。そういったツールはstage3アーカイブには含まれていません。どのパッケージをインストールしたいのかをあなた次第で選んでください。
まずシステムにロギング機構を提供するツールを決定しましょう。UnixとLinuxでは歴史をかけて素晴らしいログ機能を発展させてきました -- お望みならログファイルにシステムで起こった全てを記録できます。
Gentooでは複数のシステムロガーから使いたいものを選択することができます。このうちのいくつかを紹介します。
- app-admin/sysklogdは、システムのログを取得するための伝統的なデーモンを集めたものです。デフォルトのログ設定をそのまま使ってもうまく働くので、このパッケージは初心者にはいい選択肢です。
- app-admin/syslog-ngは、進化したシステムロガーです。1つの大きなファイルにログを取る以上のことをするには、何らかの設定が必要です。更に上級のユーザは、ロギングの発展性に基いてこのパッケージを選択できます。スマートなロギングのためには追加の設定が必要になることに注意してください。
- app-admin/metalogは、高度な設定ができるシステムロガーです。
Gentoo ebuild リポジトリにはまだまだ他のシステムロガーがあることでしょう。日毎に利用可能なパッケージは増えていますから。
もし syslog-ng を使おうと思っているなら、後で logrotate をインストールして設定しましょう。syslog-ng にはログファイルをローテーションする機構がありません。一方で、より新しいバージョン (>= 2.0) の sysklogd は自身でログローテーションを行います。
選択したシステムログツールをインストールするには、それを emerge してください。OpenRC では、rc-update を使ってデフォルトのランレベルにスクリプトを追加してください。次の例では app-admin/sysklogd をインストールして、それをシステムの syslog ユーティリティとして有効化します:
root #
emerge --ask app-admin/sysklogd
root #
rc-update add sysklogd default
systemd
ここまで OpenRC ベースのシステムのためにロギング機構の選択肢を提示しましたが、一方 systemd には systemd-journald という組み込みのロガーが含まれています。systemd-journald サービスは、上のシステムロガーの節で概説したロギング機能のほとんどを取り扱うことができます。つまり、システムマネージャおよびサービスマネージャとして systemd を実行するシステムのほとんどでは、追加の syslog ユーティリティを追加する部分を問題無く省略することができます。
journalctl を利用したシステムログの検索、閲覧についての詳細は、man journalctl を参照してください。
中央ホストへログを転送する場合などさまざまな理由により、systemd ベースのシステム上で冗長なシステムロギング機構を含めたいことがあるかもしれません。これはハンドブックの典型的想定読者にとっては一般的な事態ではなく、高度なユースケースであるとみなします。そのため、ハンドブックでは取り扱いません。
任意自由選択: cronデーモン
OpenRC
cronデーモンは入れても入れなくてもよく、システムに必須ではありませんが、インストールしておくのが賢明でしょう。
cron デーモンは、予定された間隔を空けてコマンドを実行します。間隔は毎日、毎週、毎月、毎火曜日、隔週、などで設定できます。賢明なシステム管理者は、定型的なシステム管理タスクを、cron デーモンを活用して自動化するでしょう。
すべての cron デーモンは予定されたタスクのための高いレベルの粒度をサポートしており、また通常は、予定されたタスクが期待通り完了しなかった場合に、e メール等の形式で通知を送信する機能を含んています。
Gentoo ではいくつもの cron デーモンを提供しています:
- sys-process/cronie - cronie はオリジナルの cron をベースとしていて、PAM と SELinux を使用できるなど、セキュリティと設定の改良がなされています。
- sys-process/dcron - この軽量な cron デーモンは、利便性を損わない範囲で、簡潔で安全であることを目標としています。
- sys-process/fcron - cron および anacron の機能を含めて拡張されたコマンドスケジューラ。
- sys-process/bcron - 安全な操作を念頭に入れて設計された、比較的新しい cron システム。これを実現するために、システムは複数の独立したプログラムに分けられていて、それぞれが独立したタスクに責任を持ち、プログラム間の通信は厳密に制御されています。
cronie
次の例では sys-process/cronie を使用します:
root #
emerge --ask sys-process/cronie
電源投入時に自動で cronie を開始するために、cronie を default システムランレベルに追加してください:
root #
rc-update add cronie default
代替案: dcron
root #
emerge --ask sys-process/dcron
cron エージェントとして dcron を使う場合、初期設定のための追加コマンドが必要です。
root #
crontab /etc/crontab
代替案: fcron
root #
emerge --ask sys-process/fcron
スケジュールされたタスクハンドラとして fcron を選択した場合、追加で emerge ステップが必要です:
root #
emerge --config sys-process/fcron
代替案: bcron
bcron は組み込みの特権分離を持つ、新しい cron エージェントです。
root #
emerge --ask sys-process/bcron
systemd
システムロギングと同様に、sysmted ベースのシステムには予定されたタスクのためのサポートが、タイマーという形ですぐ使える状態で含まれています。systemd タイマーはシステムレベルでもユーザレベルでも実行することができ、伝統的な cron デーモンが提供するものと同じ機能を含んでいます。冗長な可能性が必要でない限り、cron デーモンのような追加のタスクスケジューラをインストールすることは通常は不要で、問題無く省略することができます。
任意自由選択: ファイルのインデックスを作成
より高速なファイル検索のためにファイルシステム中の各ファイルのインデックスを作成するときは、sys-apps/mlocateをインストールしてください。
root #
emerge --ask sys-apps/mlocate
任意自由選択: リモートシェルアクセス
opensshd のデフォルト設定は、リモートユーザとして root にログインすることを許可していません。必要であれば非 root ユーザを作成して、インストール完了後にアクセスできるように適切に設定するか、root を許可するように /etc/ssh/sshd_config を修正してください。
インストール後、システムにリモートからアクセスできるようにするためには、ブート時に sshd を開始するように設定する必要があります。
OpenRC
OpenRC で sshd init スクリプトを default ランレベルに追加するには:
root #
rc-update add sshd default
(たとえばリモートサーバで)シリアルコンソールからアクセスしなければならない場合、agetty を設定する必要があります。
/etc/inittab のシリアルコンソールの部分のコメントを外してください:
root #
nano -w /etc/inittab
# SERIAL CONSOLES s0:12345:respawn:/sbin/agetty 9600 ttyS0 vt100 s1:12345:respawn:/sbin/agetty 9600 ttyS1 vt100
systemd
SSH サーバを有効化するには、次を実行してください:
root #
systemctl enable sshd
シリアルコンソールサポートを有効化するには、次を実行してください:
root #
systemctl enable getty@tty1.service
省略可能: シェル補完
Bash
Bash は Gentoo システムのデフォルトのシェルですので、補完拡張をインストールすることでシステムの管理を効率的かつ便利にすることができます。app-shells/bash-completion パッケージは、Gentoo に固有のコマンドや多くの共通のコマンドとユーティリティで利用できる補完をインストールします:
root #
emerge --ask app-shells/bash-completion
インストール後は、各コマンドのための bash 補完を eselect を通じて管理することができます。さらなる詳細については、bash の記事の Shell completion integrations のセクションを参照してください。
時刻同期
システム時刻を同期する方法を利用することは重要です。これは通常 NTP プロトコルおよびソフトウェアによってなされます。Chrony など、NTP プロトコルを使用する他の実装もあります。
例えば、Chrony をセットアップするには:
root #
emerge --ask net-misc/chrony
OpenRC
OpenRC では、次を実行してください:
root #
rc-update add chronyd default
systemd
systemd では、次を実行してください:
root #
systemctl enable chronyd.service
代わりに systemd ユーザは、デフォルトでインストールされている、よりシンプルな systemd-timesyncd NTP クライアントを利用したいかもしれません。
root #
systemctl enable systemd-timesyncd.service
ファイルシステムツール
使っているファイルシステムよって、(ファイルシステムの整合性をチェックしたり、ファイルシステムを (再) フォーマットするために) 必須のファイルシステムツールをインストールする必要があるかもしれません。ext4 ユーザ空間ツール(sys-fs/e2fsprogs) は @system 集合の一部としてインストール済みであることに注意してください。
次の表は、インストールされた環境に特定のファイルシステムのツールが必要な場合、どのツールをインストールすべきかを示します。
ファイルシステム | パッケージ |
---|---|
XFS | sys-fs/xfsprogs |
ext4 | sys-fs/e2fsprogs |
VFAT (FAT32, ...) | sys-fs/dosfstools |
Btrfs | sys-fs/btrfs-progs |
ZFS | sys-fs/zfs |
JFS | sys-fs/jfsutils |
nvme 等のデバイスとともに適切にスケジューラを動作させるためには、sys-block/io-scheduler-udev-rules をインストールするのがおすすめです:
root #
emerge --ask sys-block/io-scheduler-udev-rules
Gentooのファイルシステムについてのさらなる情報は、ファイルシステムの記事を参照してください。
ネットワークツール
もし、以前のシステムの設定のステップでネットワークが構成されていて、それでネットワーク設定が完了している場合は、この 'ネットワークツール' のセクションは飛ばして問題ありません。その場合はブートローダーの設定に進みましょう。
DHCP クライアントをインストールする
多くのユーザはネットワークに接続するために DHCP クライアントが必要になるでしょう。もし DHCP クライアントがひとつもインストールされていない場合、ネットワークに接続できないことになり、これにより DHCP クライアントを後でダウンロードすることができなくなってしまいます。
DHCP クライアントは、netifrc スクリプトを使用して、一つ以上のネットワークインターフェースのために自動的に IP アドレスを取得します。net-misc/dhcpcdがお薦めです (dhcpcd も参照してください):
root #
emerge --ask net-misc/dhcpcd
任意自由選択: PPPoE クライアントのインストール
もしインターネットに接続するためにPPPを使うのであれば、net-dialup/pppパッケージをインストールします。
root #
emerge --ask net-dialup/ppp
任意自由選択: 無線ネットワークツールのインストール
もしシステムをワイヤレス・ネットワークに接続させるつもりならば、オープンネットワークあるいはWEPネットワークを使用するためにnet-wireless/iwパッケージを、あるいはWPAまたはWPA2ネットワークを使用するためにnet-wireless/wpa_supplicantパッケージをインストールしてください。iwはまた、ワイヤレス・ネットワークの検出のための便利で基本的な診断ツールでもあります。
root #
emerge --ask net-wireless/iw net-wireless/wpa_supplicant
次はブートローダーの設定です。
arcload for Silicon Graphics machines
arcload was written for machines that require 64-bit kernels, and therefore can't use arcboot (which can't easily be compiled as a 64-bit binary). It also works around peculiarities that arise when loading kernels directly from the volume header. To proceed with the installation, start with:
root #
emerge arcload dvhtool
Once this has finished, find the arcload binary inside /usr/lib/arcload/. Now, two files exist:
- sashARCS: The 32-bit binary for Indy, Indigo2 (R4k), Challenge S and O2 systems
- sash64: The 64-bit binary for Octane/Octane2, Origin 200/2000 and Indigo2 Impact systems
Use dvhtool to install the appropriate binary for the system into the volume header:
For Indy/Indigo2/Challenge S/O2 users:
root #
dvhtool --unix-to-vh /usr/lib/arcload/sashARCS sashARCS
For Indigo2 Impact/Octane/Octane2/Origin 200/Origin 2000 users:
root #
dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64
The name sashARCS or sash64 does not have to be used, unless the operation is installing to the volume header of a bootable CD. For normal boot from hard-disk, it can be named whatever the user wants.
Now just use dvhtool to verify they are in the volume header:
root #
dvhtool --print-volume-directory
----- directory entries ----- Entry #0, name "sash64", start 4, bytes 55859
The arc.cf file has a C-like syntax. For the full detail on how one configures it, see the arcload page on the Linux/MIPS wiki. In short, define a number of options, which are enabled and disabled at boot time using the OSLoadFilename variable.
# ARCLoad Configuration
# Some default settings...
append "root=/dev/sda5";
append "ro";
append "console=ttyS0,9600";
# The main definition. ip28 may be changed if desired.
ip28 {
# Definition for a "working" kernel
# Select this by setting OSLoadFilename="ip28(working)"
working {
description "SGI Indigo2 Impact R10000\n\r";
image system "/working";
}
# Definition for a "new" kernel
# Select this by setting OSLoadFilename="ip28(new)"
new {
description "SGI Indigo2 Impact R10000 - Testing Kernel\n\r";
image system "/new";
}
# For debugging a kernel
# Select this by setting OSLoadFilename="ip28(working,debug)"
# or OSLoadFilename="ip28(new,debug)"
debug {
description "Debug console";
append "init=/bin/bash";
}
}
Starting with arcload-0.5, arc.cf and kernels may reside either in the volume header, or on a partition. To utilize this newer feature, place the files in the /boot/ partition (or / if the boot partition is not separate). arcload uses the filesystem driver code from the popular grub bootloader, and thus supports the same range of filesystems.
root #
dvhtool --unix-to-vh arc.cf arc.cf
root #
dvhtool --unix-to-vh /usr/src/linux/vmlinux new
CoLo for Cobalt MicroServers
Installing CoLo
On Cobalt servers, these machines have a much less capable firmware installed on chip. The Cobalt BOOTROM is primitive, by comparison to the SGI PROM, and has a number of serious limitations.
- There's a 675kB (approximate) limit on kernels. The current size of Linux 2.4 makes it nearly impossible to make a kernel this size. Linux 2.6 and 3.x is totally out of the question.
- 64-bit kernels are not supported by the stock firmware (although these are highly experimental on Cobalt machines at this time)
- The shell is basic at best
To overcome these limitations, an alternative firmware, called CoLo (Cobalt Loader) was developed. This is a BOOTROM image that can either be flashed into the chip inside the Cobalt server, or loaded from the existing firmware.
This guide will go through setting up CoLo so that it is loaded by the stock firmware. This is the only truly safe, and recommended way to set up CoLo.
If wanted, these can be flashed into the server to totally replace the original firmware -- however, you are entirely on your own in that endeavour. Should anything go wrong, physically remove the BOOTROM and reprogram it with the stock firmware. If this sounds scary -- then DO NOT flash the machine. Gentoo takes no responsibility for whatever happens if this advice is ignored.
Now to install CoLo. Start by emerging the package:
root #
emerge --ask sys-boot/colo
With that installed, take a look inside the /usr/lib/colo/ directory to find two files:
- colo-chain.elf - the "kernel" for the stock firmware to load.
- colo-rom-image.bin - a ROM image for flashing into the BOOTROM.
Start by mounting /boot/ and dumping a compressed copy of colo-chain.elf in /boot/ where the system expects it.
root #
gzip -9vc /usr/lib/colo/colo-chain.elf > /boot/vmlinux.gz
Configuring CoLo
Now, when the system first boots up, it'll load CoLo which will spit up a menu on the back LCD. The first option (and default that is assumed after roughly 5 seconds) is to boot to the hard disk. The system would then attempt to mount the first Linux partition it finds, and run the script default.colo. The syntax is fully documented in the CoLo documentation (have a peek at /usr/share/doc/colo-X.YY/README.shell.gz -- where X.YY is the version installed), and is very simple.
Just a tip: when installing kernels, it is recommended to create two kernel images, kernel.gz.working -- a known working kernel, and kernel.gz.new -- a kernel that's just been compiled. It is possible to use symlinks to point to the curent "new" and "working" kernels, or just rename the kernel images.
#:CoLo:#
mount hda1
load /kernel.gz.working
execute root=/dev/sda5 ro console=ttyS0,115200
CoLo will refuse to load a script that does not begin with the
#:CoLo:#
line. Think of it as the equivalent of saying #!/bin/sh
in shell scripts.It is also possible to ask a question, such as which kernel & configuration to boot, with a default timeout. The following configuration does exactly this, asks the user which kernel they wish to use, and executes the chosen image. vmlinux.gz.new and vmlinux.gz.working may be actual kernel images, or just symlinks pointing to the kernel images on that disk. The 50 argument to select specifies that it should proceed with the first option ("Working") after 50/10 seconds.
#:CoLo:#
lcd "Mounting hda1"
mount hda1
select "Which Kernel?" 50 Working New
goto {menu-option}
var image-name vmlinux.gz.working
goto 3f
@var image-name vmlinux.gz.working
goto 2f
@var image-name vmlinux.gz.new
@lcd "Loading Linux" {image-name}
load /{image-name}
lcd "Booting..."
execute root=/dev/sda5 ro console=ttyS0,115200
boot
See the documentation in /usr/share/doc/colo-VERSION for more details.
Setting up for serial console
Okay, the Linux installation as it stands now, would boot fine, but assumes the user will be logged in at a physical terminal. On Cobalt machines, this is particularly bad -- there's no such thing as a physical terminal.
Those who do have the luxury of a supported video chipset may skip this section if they wish.
First, pull up an editor and hack away at /etc/inittab. Further down in the file, notice the following:
# SERIAL CONSOLE
#c0:12345:respawn:/sbin/agetty 9600 ttyS0 vt102
# TERMINALS
c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux
# What to do at the "Three Finger Salute".
ca:12345:ctrlaltdel:/sbin/shutdown -r now
First, uncomment the c0 line. By default, it's set to use a terminal baud rate of 9600 bps. On Cobalt servers, this may be changed to 115200 to match the baud rate decided by the BOOT ROM. The following is how that section looks then. On a headless machine (e.g. Cobalt servers), it is also recommended to comment out the local terminal lines (c1 through to c6) as these have a habit of misbehaving when they can't open /dev/ttyX.
# SERIAL CONSOLE
c0:12345:respawn:/sbin/agetty 115200 ttyS0 vt102
# TERMINALS -- These are useless on a headless qube
#c1:12345:respawn:/sbin/agetty 38400 tty1 linux
#c2:12345:respawn:/sbin/agetty 38400 tty2 linux
#c3:12345:respawn:/sbin/agetty 38400 tty3 linux
#c4:12345:respawn:/sbin/agetty 38400 tty4 linux
#c5:12345:respawn:/sbin/agetty 38400 tty5 linux
#c6:12345:respawn:/sbin/agetty 38400 tty6 linux
Now, lastly... tell the system, that the local serial port can be trusted as a secure terminal. The file to change at is /etc/securetty. It contains a list of terminals that the system trusts. Simply stick in two more lines, permitting the serial line to be used for root logins.
root #
echo 'ttyS0' >> /etc/securetty
Lately, Linux also calls this /dev/tts/0 -- so add this too:
root #
echo 'tts/0' >> /etc/securetty
Tweaking the SGI PROM
Setting generic PROM settings
With the bootloader installed, after rebooting (which will occur shortly), go to the System Maintenance Menu and select Enter on Command Monitor (5) similar to the initial netbooting of the system.
1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor
Provide the location of the Volume Header:
>>
setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8)
Automatically boot Gentoo:
>>
setenv AutoLoad Yes
Set the timezone:
>>
setenv TimeZone EST5EDT
Use the serial console - graphic adapter users should have "g" instead of "d1" (one):
>>
setenv console d1
Set the serial console baud rate. This is optional, 9600 is the default setting, although one may use rates up to 38400 if that is desired:
>>
setenv dbaud 9600
Now, the next settings depend on how the system is booted.
Settings for direct volume-header booting
This is covered here for completeness. It's recommended that users look into installing arcload instead.
This only works on the Indy, Indigo2 (R4k) and Challenge S.
Set the root device to Gentoo's root partition, such as /dev/sda3:
>>
setenv OSLoadPartition <root device>
To list the available kernels, type "ls".
>>
setenv OSLoader <kernel name>
>>
setenv OSLoadFilename <kernel name>
Declare the kernel parameters to pass:
>>
setenv OSLoadOptions <kernel parameters>
To try a kernel without messing with kernel parameters, use the boot -f PROM command:
root #
boot -f new root=/dev/sda5 ro
Settings for arcload
arcload uses the OSLoadFilename option to specify which options to set from arc.cf. The configuration file is essentially a script, with the top-level blocks defining boot images for different systems, and inside that, optional settings. Thus, setting OSLoadFilename=mysys(serial) pulls in the settings for the mysys block, then sets further options overridden in serial.
In the example file above, one system block is defined, ip28 with working, new and debug options available. Next, define the PROM variables:
Select arcload as the bootloader:- sash64 or sashARCS:
>>
setenv OSLoader sash64
Use the "working" kernel image, defined in "ip28" section of arc.cf:
>>
setenv OSLoadFilename ip28(working)
Starting with arcload-0.5, files no longer need to be placed in the volume header -- they may be placed in a partition instead. To tell arcload where to look for its configuration file and kernels, one must set the OSLoadPartition PROM variable. The exact value here will depend on where the disk resides on the SCSI bus. Use the SystemPartition PROM variable as a guide -- only the partition number should need to change.
Partitions are numbered starting at 0, not 1 as is the case in Linux.
To load from the volume header -- use partition 8:
>>
setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(8)
Otherwise, specify the partition and filesystem type:
>>
setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(0)[ext2]
システムのリブート
chroot環境を出て、全てのパーティションをアンマウントします。次に、最終かつ真のテストを実行するためのマジカルコマンドrebootを入力しましょう。
(chroot) livecd #
exit
livecd~#
cd
livecd~#
umount -l /mnt/gentoo/dev{/shm,/pts,}
livecd~#
umount -R /mnt/gentoo
livecd~#
reboot
live イメージを取り出すのを忘れないでください。そうしないと新しくインストールされた Gentoo ではなく、live イメージが再度ブート対象になってしまうかもしれません!
リブートして新しい Gentoo 環境に入ることができたら、最終章のインストールの締めくくりに進むのがよいでしょう。
ユーザー管理
日常的な使用のためのユーザを追加する
Unix/Linux システム上で root として作業するのは危険であり、できるだけ避けるべきです。そのため、日常的に使用するための標準のユーザアカウントを、一つまたは複数追加することを、強くお勧めします。
グループは、そのグループに所属するメンバーができることを定義します。次の表はいくつかの重要なグループを示します。
グループ | 説明 |
---|---|
audio | ユーザアカウントがオーディオデバイスにアクセスできるようにします。 |
cdrom | ユーザアカウントが光学デバイスに直接アクセスできるようにします。 |
cron | ユーザアカウントが cron による時間ベースのジョブスケジューリングにアクセスできるようにします。メモ: systemd サービスシステムを実行するシステム上のユーザアカウントは、cron ジョブの代わりに systemd タイマとユーザサービスファイルを使用することができます。 |
floppy | ユーザアカウントが、フロッピードライブとして知られる、古代の機械的デバイスに直接アクセスできるようにします。このグループは現代的なシステムでは通常は使用されません。 |
portage | ユーザアカウントが、Portage グループでのみ利用可能な特定の資源にアクセスできるようにします。これは Gentoo の開発とトラブルシューティング目的のために有用です。 |
usb | ユーザアカウントが USB デバイスにアクセスできるようにします。 |
video | ユーザアカウントが、ビデオキャプチャのためのハードウェアと、ハードウェアアクセラレーションにアクセスできるようにします。 |
wheel | ユーザアカウントが su (substitute user) コマンドを使うことができるようにし、root アカウントや他のアカウントに切り換えることを許可します。root アカウントを持つシングルユーザシステムでは、メインの標準ユーザをこのグループに追加するのが良い考えでしょう。 |
例えば wheel、users、audio の 3 グループに所属する larry というユーザを作成するには、最初に root としてログインし (root だけがユーザを作ることができます)、useradd を実行します:
Login:
root
Password: (rootのパスワードを入力してください)
標準ユーザアカウントにパスワードを設定するときに、root ユーザに設定したものと同一または似ているパスワードを使用することを避けるのは、セキュリティ上の良いプラクティスです。
ハンドブックの著者としては、少なくとも 16 文字の長さを持ち、システム上の他のどのユーザとも異なる値を持つパスワードを使用することを推奨します。
root #
useradd -m -G users,wheel,audio -s /bin/bash larry
root #
passwd larry
Password: (larryのパスワードを入力してください) Re-enter password: (確認のためにもう一度パスワードを入力してください)
一時的に権限を昇格する
もし、root で何か作業をする場合は、一時的に root 権限を得るために su - を使います。別の方法は sudo (app-admin/sudo) または doas (app-admin/doas) ユーティリティを使用することです。これらは (正しく設定されれば) とても安全です。
root ログインを無効化する
潜在的な脅威アクターが root としてログインできないようにするために、root パスワードの削除および/または root ログインの無効化によって、セキュリティを向上させることができます。
root ログインを無効化するには:
root #
passwd -l root
root パスワードを削除して、ログインを無効化するには:
root #
passwd -dl root
ディスクのクリーンアップ
インストール用配布物の削除
Gentoo のインストールとリブートが完了し、インストールがすべてうまくいっていれば、stage ファイルやその他のインストール用配布物 - DIGEST、CONTENT、*.asc (PGP 署名) ファイルなど - は安全に削除することができます。
ファイルは / ディレクトリに置かれているので、以下のコマンドで削除することができます:
root #
rm /stage3-*.tar.*
次にすることは?
次に何をすればいいかわかりませんか?探索する道が多くあります。Gentooには多くの可能性と共にユーザーが存在します。それゆえ、このwikiや他のGentooに関連するサブドメイン群(下の Gentoo オンラインを見てください)を探索するため、多くのドキュメント化された機能を使うことができます(記述量は多くないのですが…)。
さらなるドキュメント
重要な注意事項として、Gentoo で採用できる選択肢の多さから、このハンドブックが提供するドキュメントの範囲は一部に限られています。ハンドブックの主眼は、Gentoo システムを構築して基本的な管理活動を行えるようにすることに置いています。ハンドブックはあえて、グラフィカル環境、セキュリティ強化 (hardening) についての詳細、その他重要な管理タスクについての指示を除外しています。とはいえ、基本的な機能に関して読者を助けるため、ハンドブックのセクションをまだいくつか用意しています。
読者は絶対に、ハンドブックの Gentoo の操作を読むべきです。これにはソフトウェアをどのように最新の状態にしておくのか、追加のソフトウェアパッケージをどのようにインストールするのか、USE フラグや Gentoo の OpenRC 初期システムの詳細や、インストール後の Gentoo システムを扱うことに関する他の様々な有益なトピックについてが説明されています。
ハンドブック以外では、コミュニティから追加提供されるドキュメントを見つけるために、Gentoo wiki の他のコーナーを探索したいと思うでしょう。Gentoo wiki チームは、documentation topic overview を提供しています。これは、この Wiki にある記事のセレクションをカテゴリー別に一覧にしています。例えば、システムをよりあなたの国に適したものとするためには、ローカライゼーションガイドを参照します(特に英語を第二外国語として話すユーザにとって便利なものです)。
デスクトップ用途で利用したい多数派のユーザは、日常的に使用するためのグラフィカル環境をセットアップすることになるでしょう。対応しているデスクトップ環境 (DE) とウィンドウマネージャ (WM) については、コミュニティによって維持されている 'メタ' 記事が多数存在します。それぞれの DE が必要なセットアップ作業は微妙に異なっているため、ブートストラップ作業の複雑性が増えることに注意してください。
その他にも、Gentoo 上で利用可能なソフトウェアについての俯瞰的な概要を提供するメタ記事が多数存在します。
Gentoo オンライン
読者は、すべての公式の Gentoo オンラインサイトが Gentoo の行動規範によって治められていることに注意するべきです。Gentoo のコミュニティで活動することは特権で、権利ではありません。そしてユーザは、行動規範が理由があるために存在することを知っていると見なされます。
Libera.Chatが運営するInternet Relay Chat(IRC)ネットワークと、メーリングリストを除いて、ほとんどのGentooのウェブサイトは質問をしたり、議論を開始したり、バグを報告するために、サイト単位でアカウントを必要とします。
フォーラムと IRC
私たちのGentoo forumsや多くのInternet Relay Chat Channelsの一つに参加することはウェルカムです。新規のGentooのインストールの最中に遭遇した問題が、過去に発見されたか、またその後いくつかのフィードバックの後に解決したかをフォーラムで調べるのは簡単です。初めてのGentoo故に他のユーザがインストールの問題を経験する可能性は驚くべきものです。ユーザはGentooサポートチャンネルで手助けを求める前に、フォーラムやwikiを調べるよう勧められています。
メーリングリスト
フォーラムやIRCでアカウントを作成するよりはむしろ、メール上でサポートやフィードバックを求めるほうがいいというコミュニティメンバーのために、いくつかのメーリングリストが利用可能です。ユーザは特定のメーリングリストを購読するために説明に従う必要があります。
バグ
時々、wikiを見たり、フォーラム内を探したり、IRCチャンネルやメーリングリストにサポートを求めても、問題に対する既知の解決策がない場合があります。一般的にこれは、GentooのBugzillaサイトにバグを公開する合図です。
開発ガイド
Gentooの開発についてより多くのことを学びたいと考えている読者は、開発ガイドを見ると良いでしょう。このガイドにはebuildの書き方、eclassの扱い方についての説明や、Gentooの開発の背後にある、多くの一般概念の定義が載っています.
締めくくり
Gentooは堅固で、柔軟でそして素晴らしく維持されたディストリビューションです。開発者コミュニティは、Gentooをどのようにさらによりよいディストリビューションにするかについてのフィードバックを聞けることを嬉しく思います。
確認として書いておきますが、このハンドブックに対するすべてのフィードバックは、ガイドライン(ハンドブックのはじめにあるどうやってハンドブックを改善しますか?のセクションに詳細があります)に従っているべきです。
We look forward to seeing how our users will choose to implement Gentoo to fit their unique use cases and needs.
Warning: Display title "Gentoo Linux mips ハンドブック: Gentoo をインストールする" overrides earlier display title "ハンドブック:MIPS/フル/インストール".