ArchWiki - 利用者の投稿記録 [ja]

LXD

2022-12-21T00:29:14Z

Pedgin: /* Setup for unpriviledged containers */

[[Category:仮想化]]
[[en:LXD]]
{{Related articles start}}
{{Related|Linux Containers}}
{{Related articles end}}
'''[https://linuxcontainers.org/lxd/ LXD]''' はコンテナ(LXC経由)および仮想マシン([[QEMU]]経由)のマネージャー/ハイパーバイザーです。

== セットアップ ==
=== 必要なソフトウェア ===
{{Pkg|lxd}} パッケージをインストールして、{{ic|lxd.service}} を[[systemd#ユニットを使う|有効]]にします。

==== 他のインストール方法 ====

{{AUR|snapd}} パッケージをインストールしてから以下のコマンドを実行することで [[snapd]] を使って LXD をインストールできます:

# snap install lxd

=== Setup for unpriviledged containers ===
It is recommended to use unpriviledged containers (See [[Linux_Containers#Privileged_containers_or_unprivileged_containers]] for an explanation of the difference).

For this, modify both {{ic|/etc/subuid}} and {{ic|/etc/subgid}} (if these files are not present, create them) to contain the mapping to the containerized uid/gid pairs for each user who shall be able to run the containers. The example below is simply for the root user (and systemd system unit):

You can either use {{ic|usermod}} as follows:

{{ic|usermod -v 1000000-1000999999 -w 1000000-1000999999 root}}

Or modify the above mentioned files directly as follows:

{{hc|/etc/subuid|
root:1000000:1000000000
}}

{{hc|/etc/subgid|
root:1000000:1000000000
}}

Now, every container will be started {{ic|unprivileged}} by default.

For the alternative, see [[#Privileged containers|howto set up privileged containers]].

=== LXD の設定 ===
LXD を使うにはストレージプールと (インターネットを使いたい場合) ネットワークを設定する必要があります。以下のコマンドを root で実行してください:
# lxd init

=== 非特権ユーザーとして LXD にアクセス ===

デフォルトでは LXD デーモンは {{ic|lxd}} グループのユーザーからのアクセスを許可するので、ユーザーをグループに追加してください:

# usermod -a -G lxd <user>

== 使用方法 ==

LXD consists of two parts:
* the daemon (the ''lxd'' binary)
* the client (the ''lxc'' binary)

{{Note | lxc is not LXC; the naming is a bit confusing, you can read the [https://discuss.linuxcontainers.org/t/comparing-lxd-vs-lxc/24 forum post on comparing LXD vs LXC] regarding the difference.}}

The client is used to control one or multiple daemon(s).

The client can also be used to control remote LXD servers.

=== Overview of commands ===
You can get an overview of all available commands by typing:

$ lxc

=== Create a container ===
You can create a container with {{ic| lxc launch}}, for example:

$ lxc launch ubuntu:20.04

Container are based on images, that are downloaded from image servers or remote LXD servers. 
You can see the list of already added servers with:

$ lxc remote list

You can list all images on a server with {{ic| lxc image list}}, for example:

$ lxc image list images:

This will show you all images on one of the default servers: [https://images.linuxcontainers.org images.linuxcontainers.org]

You can also search for images by adding terms like the distribution name:

$ lxc image list images:debian

Launch a container with an image from a specific server with:

$ lxc launch servername:imagename

For example:

$ lxc launch images:centos/8/amd64 centos

To create an amd64 Arch container:

$ lxc launch images:archlinux/current/amd64 arch

=== Create a virtual machine ===
Just add the flag {{ic|--vm}} to {{ic|lxc launch}}:

$ lxc launch ubuntu:20.04 --vm

{{Note|
* For now virtual machines support less features than containers (see [https://linuxcontainers.org/lxd/advanced-guide/#difference-between-containers-and-virtual-machines Difference between containers and virtual machines] for example).
* Only {{ic|cloud}} variants of the official images enable the lxd-agent out-of-the-box (which is needed for the usual lxc commands like {{ic|lxc exec}}). You can search for cloud images with {{ic|lxc image list images: cloud}} or {{ic|lxc image list images: distribution-name cloud}}. If you use other images or encounter problems take a look at [[#lxd-agent_inside_a_virtual_machine]].
}}

=== Use and manage a container or VM ===

See [https://linuxcontainers.org/lxd/getting-started-cli/#instance-management Instance managament in the official Getting Started Guide of LXD].

=== Container/VM configuration (optional) ===

You can add various options to instances (containers and VMs). 
See [https://linuxcontainers.org/lxd/advanced-guide/#configuration-of-instances Configuration of instances in the official Advanced Guide of LXD] for details.

== ヒントとテクニック ==

=== Access the containers by name on the host ===

This assumes that you are using the default bridge, that it is named lxdbr0 and that you are using [[systemd-resolved]].

# systemd-resolve --interface lxdbr0 --set-domain '~lxd' --set-dns $(lxc network get lxdbr0 ipv4.address | cut -d / -f 1)

You can now access the containers by name:

$ ping ''containername''.lxd

==== Other solution ====

It seems that the systemd-resolve solution stops working after some time.

Another solution is to create a {{ic|/etc/systemd/network/lxd.network}} that contains (replace x and y to match your bridge IP):

[Match]
Name=lxdbr0
[Network]
DNS=10.x.y.1
Domains=~lxd
IgnoreCarrierLoss=yes
[Address]
Address=10.x.y.1/24
Gateway=10.x.y.1

And then [[enable]] and [[start]] {{ic|systemd-networkd.service}}.

=== Use Wayland and Xorg applications ===

{{Note| Always consider security implications, as some of the described methods may weaken the seperation between container and host. }}

There are multiple methods to use GUI applications inside containers.

You can find an overview in the official Forum of LXD: https://discuss.linuxcontainers.org/t/overview-gui-inside-containers/8767

==== Method 1: Use the host's Wayland or Xorg Server ====
{{Note| Using Xorg might weaken the seperation between container and host, because Xorg allows applications to access other applications windows. So container applications might have access to host applications windows. 
Use Wayland instead (but be aware that Xorgs downsides also apply to XWayland).}}

'''Summary:''' In this method we grant containers access to the host's sockets of Wayland (+XWayland) or Xorg.

'''1. Add the following devices to a containers profile.'''

See also: [https://linuxcontainers.org/lxd/docs/master/instances#device-types LXD-Documentation regarding Devices]

General device for the GPU:

mygpu:
type: gpu

{{Note| The path under "listen" is different, because /run and /tmp folders might be overridden, see: https://github.com/lxc/lxd/issues/4540 }}

Device for the Wayland Socket: 
'''Notes:''' 
* Adjust the Display (wayland-0) accordingly.
* Add the folders in /mnt and /tmp inside the container, if they don't already exist.

Waylandsocket:
bind: container
connect: unix:/run/user/1000/wayland-0
listen: unix:/mnt/wayland1/wayland-0
uid: "1000"
gid: "1000"
security.gid: "1000"
security.uid: "1000"
mode: "0777"
type: proxy

Device for the Xorg (or XWayland) Socket: 
'''Note:''' Adjust the Display Number accordingly (for example X1 instead of X0).

Xsocket:
bind: container
connect: unix:/tmp/.X11-unix/X0
listen: unix:/mnt/xorg1/X0
uid: "1000"
gid: "1000"
security.gid: "1000"
security.uid: "1000"
mode: "0777"
type: proxy

'''2. Link the sockets to the right location inside the container.'''

'''Note:''' These Scripts need to be run after each start of the container; you can automate this with systemd for example.

Shell-Script to link the Wayland socket:

#!/bin/sh
mkdir /run/user/1000
ln -s /mnt/wayland1/wayland-0 /run/user/1000/wayland-0

Link the Xorg (or XWayland) socket:

#!/bin/sh
ln -s /mnt/xorg1/X0 /tmp/.X11-unix/X0

'''3. Add Environment variables to the users config inside the container.'''

'''Note:''' Adjust the Display Numbers and/or the filename (.profile) accordingly.

For Wayland:

$ echo "export XDG_RUNTIME_DIR=/run/user/1000" >> ~/.profile
$ echo "export WAYLAND_DISPLAY=wayland-0" >> ~/.profile
$ echo "export QT_QPA_PLATFORM=wayland" >> ~/.profile

For Xorg (or XWayland):

$ echo "export DISPLAY=:0" >> .profile

Reload the .profile:

$ . .profile

=== Privileged containers ===

{{Note | Privileged containers are not isolated from the host! 
The root user in the container is the root user on the host. 
Use unprivileged containers instead whenever possible. }}

If you want to set up a privileged container, you must provide the config key {{ic|1=security.privileged=true}}.

Either during container creation:

$ lxc launch ubuntu:20.04 ubuntu -c security.privileged=true

Or for an already existing container, you may edit the configuration:

{{hc|$ lxc config edit ubuntu|
name: ubuntu
profiles:
- default
config:
...
security.privileged: "true"
...
}}

== トラブルシューティング ==

=== lxd-agent inside a virtual machine ===

Inside some virtual machine images the {{ic|lxd-agent}} is not enabled by default. 
In this case you have to enable it manually, for example by mounting a {{ic|9p}} network share. This requires console access with a valid user.

1. Login with {{ic|lxc console}}: 
Replace {{ic|virtualmachine-name}} accordingly.

$ lxc console virtualmachine-name

Login as root:
{{Note | On some systems you have to setup a root password first to be able to login as root. You can use [https://linuxcontainers.org/lxd/advanced-guide/#cloud-init cloud-init] for this for example.}}

$ su root

Mount the network share:

$ mount -t 9p config /mnt/

Go into the folder and run the install script (this will enable the lxd-agent inside the VM):

$ cd /mnt/
$ ./install.sh

After sucessful install, reboot with:

$ reboot

Afterwards the {{ic|lxd-agent}} is available and {{ic|lxc exec}} should work.

=== カーネルコンフィグの確認 ===
デフォルトで Arch Linux のカーネルは Linux Containers とフロントエンドの LXD が動くようにコンパイルされています。カスタムカーネルを使っている場合やカーネルオプションを変更している場合、LXD が動かない場合があります。コンテナを実行できるようにカーネルが設定されているか確認してください:
$ lxc-checkconfig

=== Resource limits are not applied when viewed from inside a container ===

Install {{Pkg|lxcfs}} and [[start]] {{ic|lxcfs.service}}.

lxd will need to be restarted. [[Enable]] {{ic|lxcfs.service}} for the service to be started at boot time.

=== Starting a virtual machine fails ===

If you see the error: {{ic|Error: Required EFI firmware settings file missing: /usr/share/ovmf/x64/OVMF_VARS.ms.fd}}

Arch Linux does not distribute secure boot signed ovmf firmware, to boot virtual machines you need to disable secure boot for the time being.

$ lxc launch ubuntu:18.04 test-vm --vm -c security.secureboot=false

This can also be added to the default profile by doing:

$ lxc profile set default security.secureboot=false

=== No IPv4 with systemd-networkd ===

Starting with version version 244.1, systemd detects if {{ic|/sys}} is writable by containers. If it is, udev is automatically started and breaks IPv4 in unprivileged containers. See [https://github.com/systemd/systemd-stable/commit/96d7083c5499b264ecebd6a30a92e0e8fda14cd5 commit bf331d8] and [https://discuss.linuxcontainers.org/t/no-ipv4-on-arch-linux-containers/6395 discussion on linuxcontainers].

On containers created past 2020, there should already be a {{ic|systemd.networkd.service}} override to work around this issue, create it if it is not:

{{hc|1=/etc/systemd/system/systemd-networkd.service.d/lxc.conf|2=
[Service]
BindReadOnlyPaths=/sys
}}

You could also work around this issue by setting {{ic|1=raw.lxc: lxc.mount.auto = proc:rw sys:ro}} in the profile of the container to ensure {{ic|/sys}} is read-only for the entire container, although this may be problematic, as per the linked discussion above.

== アンインストール ==

[[Stop]] and disable {{ic|lxd.service}} and {{ic|lxd.socket}}. Then [[uninstall]] the {{Pkg|lxd}} package.

If you uninstalled the package without disabling the service, you might have a lingering broken symlink at {{ic|/etc/systemd/system/multi-user.wants/lxd.service}}.

If you want to remove all data:

# rm -r /var/lib/lxd

If you used any of the example networking configuration, you should remove those as well.

== 参照 ==

* [https://lxd.readthedocs.io 公式ドキュメント]
* [https://linuxcontainers.org/lxd/ LXD 公式ホームページ]
* [https://github.com/lxc/lxd LXD の GitHub ページ]

LXD

2022-12-21T00:22:17Z

Pedgin: /* ヒントとテクニック */ insert === Privileged containers ===

[[Category:仮想化]]
[[en:LXD]]
{{Related articles start}}
{{Related|Linux Containers}}
{{Related articles end}}
'''[https://linuxcontainers.org/lxd/ LXD]''' はコンテナ(LXC経由)および仮想マシン([[QEMU]]経由)のマネージャー/ハイパーバイザーです。

== セットアップ ==
=== 必要なソフトウェア ===
{{Pkg|lxd}} パッケージをインストールして、{{ic|lxd.service}} を[[systemd#ユニットを使う|有効]]にします。

==== 他のインストール方法 ====

{{AUR|snapd}} パッケージをインストールしてから以下のコマンドを実行することで [[snapd]] を使って LXD をインストールできます:

# snap install lxd

=== Setup for unpriviledged containers ===
It is recommended to use unpriviledged containers (See [[Linux_Containers#Privileged_containers_or_unprivileged_containers]] for an explanation of the difference).

For this, modify both {{ic|/etc/subuid}} and {{ic|/etc/subgid}} (if these files are not present, create them) to contain the mapping to the containerized uid/gid pairs for each user who shall be able to run the containers. The example below is simply for the root user (and systemd system unit):

You can either use {{ic|usermod}} as follows:

{{ic|usermod -v 1000000-1000999999 -w 1000000-1000999999 root}}

Or modify the above mentioned files directly as follows:

{{hc|/etc/subuid|
root:1000000:1000000000
}}

{{hc|/etc/subgid|
root:1000000:1000000000
}}

Now, every container will be started {{ic|unprivileged}} by default.

For the alternative see [[#Priviledged_containers | howto set up priviledged containers]].

=== LXD の設定 ===
LXD を使うにはストレージプールと (インターネットを使いたい場合) ネットワークを設定する必要があります。以下のコマンドを root で実行してください:
# lxd init

=== 非特権ユーザーとして LXD にアクセス ===

デフォルトでは LXD デーモンは {{ic|lxd}} グループのユーザーからのアクセスを許可するので、ユーザーをグループに追加してください:

# usermod -a -G lxd <user>

== 使用方法 ==

LXD consists of two parts:
* the daemon (the ''lxd'' binary)
* the client (the ''lxc'' binary)

{{Note | lxc is not LXC; the naming is a bit confusing, you can read the [https://discuss.linuxcontainers.org/t/comparing-lxd-vs-lxc/24 forum post on comparing LXD vs LXC] regarding the difference.}}

The client is used to control one or multiple daemon(s).

The client can also be used to control remote LXD servers.

=== Overview of commands ===
You can get an overview of all available commands by typing:

$ lxc

=== Create a container ===
You can create a container with {{ic| lxc launch}}, for example:

$ lxc launch ubuntu:20.04

Container are based on images, that are downloaded from image servers or remote LXD servers. 
You can see the list of already added servers with:

$ lxc remote list

You can list all images on a server with {{ic| lxc image list}}, for example:

$ lxc image list images:

This will show you all images on one of the default servers: [https://images.linuxcontainers.org images.linuxcontainers.org]

You can also search for images by adding terms like the distribution name:

$ lxc image list images:debian

Launch a container with an image from a specific server with:

$ lxc launch servername:imagename

For example:

$ lxc launch images:centos/8/amd64 centos

To create an amd64 Arch container:

$ lxc launch images:archlinux/current/amd64 arch

=== Create a virtual machine ===
Just add the flag {{ic|--vm}} to {{ic|lxc launch}}:

$ lxc launch ubuntu:20.04 --vm

{{Note|
* For now virtual machines support less features than containers (see [https://linuxcontainers.org/lxd/advanced-guide/#difference-between-containers-and-virtual-machines Difference between containers and virtual machines] for example).
* Only {{ic|cloud}} variants of the official images enable the lxd-agent out-of-the-box (which is needed for the usual lxc commands like {{ic|lxc exec}}). You can search for cloud images with {{ic|lxc image list images: cloud}} or {{ic|lxc image list images: distribution-name cloud}}. If you use other images or encounter problems take a look at [[#lxd-agent_inside_a_virtual_machine]].
}}

=== Use and manage a container or VM ===

See [https://linuxcontainers.org/lxd/getting-started-cli/#instance-management Instance managament in the official Getting Started Guide of LXD].

=== Container/VM configuration (optional) ===

You can add various options to instances (containers and VMs). 
See [https://linuxcontainers.org/lxd/advanced-guide/#configuration-of-instances Configuration of instances in the official Advanced Guide of LXD] for details.

== ヒントとテクニック ==

=== Access the containers by name on the host ===

This assumes that you are using the default bridge, that it is named lxdbr0 and that you are using [[systemd-resolved]].

# systemd-resolve --interface lxdbr0 --set-domain '~lxd' --set-dns $(lxc network get lxdbr0 ipv4.address | cut -d / -f 1)

You can now access the containers by name:

$ ping ''containername''.lxd

==== Other solution ====

It seems that the systemd-resolve solution stops working after some time.

Another solution is to create a {{ic|/etc/systemd/network/lxd.network}} that contains (replace x and y to match your bridge IP):

[Match]
Name=lxdbr0
[Network]
DNS=10.x.y.1
Domains=~lxd
IgnoreCarrierLoss=yes
[Address]
Address=10.x.y.1/24
Gateway=10.x.y.1

And then [[enable]] and [[start]] {{ic|systemd-networkd.service}}.

=== Use Wayland and Xorg applications ===

{{Note| Always consider security implications, as some of the described methods may weaken the seperation between container and host. }}

There are multiple methods to use GUI applications inside containers.

You can find an overview in the official Forum of LXD: https://discuss.linuxcontainers.org/t/overview-gui-inside-containers/8767

==== Method 1: Use the host's Wayland or Xorg Server ====
{{Note| Using Xorg might weaken the seperation between container and host, because Xorg allows applications to access other applications windows. So container applications might have access to host applications windows. 
Use Wayland instead (but be aware that Xorgs downsides also apply to XWayland).}}

'''Summary:''' In this method we grant containers access to the host's sockets of Wayland (+XWayland) or Xorg.

'''1. Add the following devices to a containers profile.'''

See also: [https://linuxcontainers.org/lxd/docs/master/instances#device-types LXD-Documentation regarding Devices]

General device for the GPU:

mygpu:
type: gpu

{{Note| The path under "listen" is different, because /run and /tmp folders might be overridden, see: https://github.com/lxc/lxd/issues/4540 }}

Device for the Wayland Socket: 
'''Notes:''' 
* Adjust the Display (wayland-0) accordingly.
* Add the folders in /mnt and /tmp inside the container, if they don't already exist.

Waylandsocket:
bind: container
connect: unix:/run/user/1000/wayland-0
listen: unix:/mnt/wayland1/wayland-0
uid: "1000"
gid: "1000"
security.gid: "1000"
security.uid: "1000"
mode: "0777"
type: proxy

Device for the Xorg (or XWayland) Socket: 
'''Note:''' Adjust the Display Number accordingly (for example X1 instead of X0).

Xsocket:
bind: container
connect: unix:/tmp/.X11-unix/X0
listen: unix:/mnt/xorg1/X0
uid: "1000"
gid: "1000"
security.gid: "1000"
security.uid: "1000"
mode: "0777"
type: proxy

'''2. Link the sockets to the right location inside the container.'''

'''Note:''' These Scripts need to be run after each start of the container; you can automate this with systemd for example.

Shell-Script to link the Wayland socket:

#!/bin/sh
mkdir /run/user/1000
ln -s /mnt/wayland1/wayland-0 /run/user/1000/wayland-0

Link the Xorg (or XWayland) socket:

#!/bin/sh
ln -s /mnt/xorg1/X0 /tmp/.X11-unix/X0

'''3. Add Environment variables to the users config inside the container.'''

'''Note:''' Adjust the Display Numbers and/or the filename (.profile) accordingly.

For Wayland:

$ echo "export XDG_RUNTIME_DIR=/run/user/1000" >> ~/.profile
$ echo "export WAYLAND_DISPLAY=wayland-0" >> ~/.profile
$ echo "export QT_QPA_PLATFORM=wayland" >> ~/.profile

For Xorg (or XWayland):

$ echo "export DISPLAY=:0" >> .profile

Reload the .profile:

$ . .profile

=== Privileged containers ===

{{Note | Privileged containers are not isolated from the host! 
The root user in the container is the root user on the host. 
Use unprivileged containers instead whenever possible. }}

If you want to set up a privileged container, you must provide the config key {{ic|1=security.privileged=true}}.

Either during container creation:

$ lxc launch ubuntu:20.04 ubuntu -c security.privileged=true

Or for an already existing container, you may edit the configuration:

{{hc|$ lxc config edit ubuntu|
name: ubuntu
profiles:
- default
config:
...
security.privileged: "true"
...
}}

== トラブルシューティング ==

=== lxd-agent inside a virtual machine ===

Inside some virtual machine images the {{ic|lxd-agent}} is not enabled by default. 
In this case you have to enable it manually, for example by mounting a {{ic|9p}} network share. This requires console access with a valid user.

1. Login with {{ic|lxc console}}: 
Replace {{ic|virtualmachine-name}} accordingly.

$ lxc console virtualmachine-name

Login as root:
{{Note | On some systems you have to setup a root password first to be able to login as root. You can use [https://linuxcontainers.org/lxd/advanced-guide/#cloud-init cloud-init] for this for example.}}

$ su root

Mount the network share:

$ mount -t 9p config /mnt/

Go into the folder and run the install script (this will enable the lxd-agent inside the VM):

$ cd /mnt/
$ ./install.sh

After sucessful install, reboot with:

$ reboot

Afterwards the {{ic|lxd-agent}} is available and {{ic|lxc exec}} should work.

=== カーネルコンフィグの確認 ===
デフォルトで Arch Linux のカーネルは Linux Containers とフロントエンドの LXD が動くようにコンパイルされています。カスタムカーネルを使っている場合やカーネルオプションを変更している場合、LXD が動かない場合があります。コンテナを実行できるようにカーネルが設定されているか確認してください:
$ lxc-checkconfig

=== Resource limits are not applied when viewed from inside a container ===

Install {{Pkg|lxcfs}} and [[start]] {{ic|lxcfs.service}}.

lxd will need to be restarted. [[Enable]] {{ic|lxcfs.service}} for the service to be started at boot time.

=== Starting a virtual machine fails ===

If you see the error: {{ic|Error: Required EFI firmware settings file missing: /usr/share/ovmf/x64/OVMF_VARS.ms.fd}}

Arch Linux does not distribute secure boot signed ovmf firmware, to boot virtual machines you need to disable secure boot for the time being.

$ lxc launch ubuntu:18.04 test-vm --vm -c security.secureboot=false

This can also be added to the default profile by doing:

$ lxc profile set default security.secureboot=false

=== No IPv4 with systemd-networkd ===

Starting with version version 244.1, systemd detects if {{ic|/sys}} is writable by containers. If it is, udev is automatically started and breaks IPv4 in unprivileged containers. See [https://github.com/systemd/systemd-stable/commit/96d7083c5499b264ecebd6a30a92e0e8fda14cd5 commit bf331d8] and [https://discuss.linuxcontainers.org/t/no-ipv4-on-arch-linux-containers/6395 discussion on linuxcontainers].

On containers created past 2020, there should already be a {{ic|systemd.networkd.service}} override to work around this issue, create it if it is not:

{{hc|1=/etc/systemd/system/systemd-networkd.service.d/lxc.conf|2=
[Service]
BindReadOnlyPaths=/sys
}}

You could also work around this issue by setting {{ic|1=raw.lxc: lxc.mount.auto = proc:rw sys:ro}} in the profile of the container to ensure {{ic|/sys}} is read-only for the entire container, although this may be problematic, as per the linked discussion above.

== アンインストール ==

[[Stop]] and disable {{ic|lxd.service}} and {{ic|lxd.socket}}. Then [[uninstall]] the {{Pkg|lxd}} package.

If you uninstalled the package without disabling the service, you might have a lingering broken symlink at {{ic|/etc/systemd/system/multi-user.wants/lxd.service}}.

If you want to remove all data:

# rm -r /var/lib/lxd

If you used any of the example networking configuration, you should remove those as well.

== 参照 ==

* [https://lxd.readthedocs.io 公式ドキュメント]
* [https://linuxcontainers.org/lxd/ LXD 公式ホームページ]
* [https://github.com/lxc/lxd LXD の GitHub ページ]

LXD

2022-12-21T00:11:20Z

Pedgin: /* Setup for unpriviledged containers */ 英語版から転載（記事が古い）

[[Category:仮想化]]
[[en:LXD]]
{{Related articles start}}
{{Related|Linux Containers}}
{{Related articles end}}
'''[https://linuxcontainers.org/lxd/ LXD]''' はコンテナ(LXC経由)および仮想マシン([[QEMU]]経由)のマネージャー/ハイパーバイザーです。

== セットアップ ==
=== 必要なソフトウェア ===
{{Pkg|lxd}} パッケージをインストールして、{{ic|lxd.service}} を[[systemd#ユニットを使う|有効]]にします。

==== 他のインストール方法 ====

{{AUR|snapd}} パッケージをインストールしてから以下のコマンドを実行することで [[snapd]] を使って LXD をインストールできます:

# snap install lxd

=== Setup for unpriviledged containers ===
It is recommended to use unpriviledged containers (See [[Linux_Containers#Privileged_containers_or_unprivileged_containers]] for an explanation of the difference).

For this, modify both {{ic|/etc/subuid}} and {{ic|/etc/subgid}} (if these files are not present, create them) to contain the mapping to the containerized uid/gid pairs for each user who shall be able to run the containers. The example below is simply for the root user (and systemd system unit):

You can either use {{ic|usermod}} as follows:

{{ic|usermod -v 1000000-1000999999 -w 1000000-1000999999 root}}

Or modify the above mentioned files directly as follows:

{{hc|/etc/subuid|
root:1000000:1000000000
}}

{{hc|/etc/subgid|
root:1000000:1000000000
}}

Now, every container will be started {{ic|unprivileged}} by default.

For the alternative see [[#Priviledged_containers | howto set up priviledged containers]].

=== LXD の設定 ===
LXD を使うにはストレージプールと (インターネットを使いたい場合) ネットワークを設定する必要があります。以下のコマンドを root で実行してください:
# lxd init

=== 非特権ユーザーとして LXD にアクセス ===

デフォルトでは LXD デーモンは {{ic|lxd}} グループのユーザーからのアクセスを許可するので、ユーザーをグループに追加してください:

# usermod -a -G lxd <user>

== 使用方法 ==

LXD consists of two parts:
* the daemon (the ''lxd'' binary)
* the client (the ''lxc'' binary)

{{Note | lxc is not LXC; the naming is a bit confusing, you can read the [https://discuss.linuxcontainers.org/t/comparing-lxd-vs-lxc/24 forum post on comparing LXD vs LXC] regarding the difference.}}

The client is used to control one or multiple daemon(s).

The client can also be used to control remote LXD servers.

=== Overview of commands ===
You can get an overview of all available commands by typing:

$ lxc

=== Create a container ===
You can create a container with {{ic| lxc launch}}, for example:

$ lxc launch ubuntu:20.04

Container are based on images, that are downloaded from image servers or remote LXD servers. 
You can see the list of already added servers with:

$ lxc remote list

You can list all images on a server with {{ic| lxc image list}}, for example:

$ lxc image list images:

This will show you all images on one of the default servers: [https://images.linuxcontainers.org images.linuxcontainers.org]

You can also search for images by adding terms like the distribution name:

$ lxc image list images:debian

Launch a container with an image from a specific server with:

$ lxc launch servername:imagename

For example:

$ lxc launch images:centos/8/amd64 centos

To create an amd64 Arch container:

$ lxc launch images:archlinux/current/amd64 arch

=== Create a virtual machine ===
Just add the flag {{ic|--vm}} to {{ic|lxc launch}}:

$ lxc launch ubuntu:20.04 --vm

{{Note|
* For now virtual machines support less features than containers (see [https://linuxcontainers.org/lxd/advanced-guide/#difference-between-containers-and-virtual-machines Difference between containers and virtual machines] for example).
* Only {{ic|cloud}} variants of the official images enable the lxd-agent out-of-the-box (which is needed for the usual lxc commands like {{ic|lxc exec}}). You can search for cloud images with {{ic|lxc image list images: cloud}} or {{ic|lxc image list images: distribution-name cloud}}. If you use other images or encounter problems take a look at [[#lxd-agent_inside_a_virtual_machine]].
}}

=== Use and manage a container or VM ===

See [https://linuxcontainers.org/lxd/getting-started-cli/#instance-management Instance managament in the official Getting Started Guide of LXD].

=== Container/VM configuration (optional) ===

You can add various options to instances (containers and VMs). 
See [https://linuxcontainers.org/lxd/advanced-guide/#configuration-of-instances Configuration of instances in the official Advanced Guide of LXD] for details.

== ヒントとテクニック ==

=== Access the containers by name on the host ===

This assumes that you are using the default bridge, that it is named lxdbr0 and that you are using [[systemd-resolved]].

# systemd-resolve --interface lxdbr0 --set-domain '~lxd' --set-dns $(lxc network get lxdbr0 ipv4.address | cut -d / -f 1)

You can now access the containers by name:

$ ping ''containername''.lxd

==== Other solution ====

It seems that the systemd-resolve solution stops working after some time.

Another solution is to create a {{ic|/etc/systemd/network/lxd.network}} that contains (replace x and y to match your bridge IP):

[Match]
Name=lxdbr0
[Network]
DNS=10.x.y.1
Domains=~lxd
IgnoreCarrierLoss=yes
[Address]
Address=10.x.y.1/24
Gateway=10.x.y.1

And then [[enable]] and [[start]] {{ic|systemd-networkd.service}}.

=== Use Wayland and Xorg applications ===

{{Note| Always consider security implications, as some of the described methods may weaken the seperation between container and host. }}

There are multiple methods to use GUI applications inside containers.

You can find an overview in the official Forum of LXD: https://discuss.linuxcontainers.org/t/overview-gui-inside-containers/8767

==== Method 1: Use the host's Wayland or Xorg Server ====
{{Note| Using Xorg might weaken the seperation between container and host, because Xorg allows applications to access other applications windows. So container applications might have access to host applications windows. 
Use Wayland instead (but be aware that Xorgs downsides also apply to XWayland).}}

'''Summary:''' In this method we grant containers access to the host's sockets of Wayland (+XWayland) or Xorg.

'''1. Add the following devices to a containers profile.'''

See also: [https://linuxcontainers.org/lxd/docs/master/instances#device-types LXD-Documentation regarding Devices]

General device for the GPU:

mygpu:
type: gpu

{{Note| The path under "listen" is different, because /run and /tmp folders might be overridden, see: https://github.com/lxc/lxd/issues/4540 }}

Device for the Wayland Socket: 
'''Notes:''' 
* Adjust the Display (wayland-0) accordingly.
* Add the folders in /mnt and /tmp inside the container, if they don't already exist.

Waylandsocket:
bind: container
connect: unix:/run/user/1000/wayland-0
listen: unix:/mnt/wayland1/wayland-0
uid: "1000"
gid: "1000"
security.gid: "1000"
security.uid: "1000"
mode: "0777"
type: proxy

Device for the Xorg (or XWayland) Socket: 
'''Note:''' Adjust the Display Number accordingly (for example X1 instead of X0).

Xsocket:
bind: container
connect: unix:/tmp/.X11-unix/X0
listen: unix:/mnt/xorg1/X0
uid: "1000"
gid: "1000"
security.gid: "1000"
security.uid: "1000"
mode: "0777"
type: proxy

'''2. Link the sockets to the right location inside the container.'''

'''Note:''' These Scripts need to be run after each start of the container; you can automate this with systemd for example.

Shell-Script to link the Wayland socket:

#!/bin/sh
mkdir /run/user/1000
ln -s /mnt/wayland1/wayland-0 /run/user/1000/wayland-0

Link the Xorg (or XWayland) socket:

#!/bin/sh
ln -s /mnt/xorg1/X0 /tmp/.X11-unix/X0

'''3. Add Environment variables to the users config inside the container.'''

'''Note:''' Adjust the Display Numbers and/or the filename (.profile) accordingly.

For Wayland:

$ echo "export XDG_RUNTIME_DIR=/run/user/1000" >> ~/.profile
$ echo "export WAYLAND_DISPLAY=wayland-0" >> ~/.profile
$ echo "export QT_QPA_PLATFORM=wayland" >> ~/.profile

For Xorg (or XWayland):

$ echo "export DISPLAY=:0" >> .profile

Reload the .profile:

$ . .profile

== トラブルシューティング ==

=== lxd-agent inside a virtual machine ===

Inside some virtual machine images the {{ic|lxd-agent}} is not enabled by default. 
In this case you have to enable it manually, for example by mounting a {{ic|9p}} network share. This requires console access with a valid user.

1. Login with {{ic|lxc console}}: 
Replace {{ic|virtualmachine-name}} accordingly.

$ lxc console virtualmachine-name

Login as root:
{{Note | On some systems you have to setup a root password first to be able to login as root. You can use [https://linuxcontainers.org/lxd/advanced-guide/#cloud-init cloud-init] for this for example.}}

$ su root

Mount the network share:

$ mount -t 9p config /mnt/

Go into the folder and run the install script (this will enable the lxd-agent inside the VM):

$ cd /mnt/
$ ./install.sh

After sucessful install, reboot with:

$ reboot

Afterwards the {{ic|lxd-agent}} is available and {{ic|lxc exec}} should work.

=== カーネルコンフィグの確認 ===
デフォルトで Arch Linux のカーネルは Linux Containers とフロントエンドの LXD が動くようにコンパイルされています。カスタムカーネルを使っている場合やカーネルオプションを変更している場合、LXD が動かない場合があります。コンテナを実行できるようにカーネルが設定されているか確認してください:
$ lxc-checkconfig

=== Resource limits are not applied when viewed from inside a container ===

Install {{Pkg|lxcfs}} and [[start]] {{ic|lxcfs.service}}.

lxd will need to be restarted. [[Enable]] {{ic|lxcfs.service}} for the service to be started at boot time.

=== Starting a virtual machine fails ===

If you see the error: {{ic|Error: Required EFI firmware settings file missing: /usr/share/ovmf/x64/OVMF_VARS.ms.fd}}

Arch Linux does not distribute secure boot signed ovmf firmware, to boot virtual machines you need to disable secure boot for the time being.

$ lxc launch ubuntu:18.04 test-vm --vm -c security.secureboot=false

This can also be added to the default profile by doing:

$ lxc profile set default security.secureboot=false

=== No IPv4 with systemd-networkd ===

Starting with version version 244.1, systemd detects if {{ic|/sys}} is writable by containers. If it is, udev is automatically started and breaks IPv4 in unprivileged containers. See [https://github.com/systemd/systemd-stable/commit/96d7083c5499b264ecebd6a30a92e0e8fda14cd5 commit bf331d8] and [https://discuss.linuxcontainers.org/t/no-ipv4-on-arch-linux-containers/6395 discussion on linuxcontainers].

On containers created past 2020, there should already be a {{ic|systemd.networkd.service}} override to work around this issue, create it if it is not:

{{hc|1=/etc/systemd/system/systemd-networkd.service.d/lxc.conf|2=
[Service]
BindReadOnlyPaths=/sys
}}

You could also work around this issue by setting {{ic|1=raw.lxc: lxc.mount.auto = proc:rw sys:ro}} in the profile of the container to ensure {{ic|/sys}} is read-only for the entire container, although this may be problematic, as per the linked discussion above.

== アンインストール ==

[[Stop]] and disable {{ic|lxd.service}} and {{ic|lxd.socket}}. Then [[uninstall]] the {{Pkg|lxd}} package.

If you uninstalled the package without disabling the service, you might have a lingering broken symlink at {{ic|/etc/systemd/system/multi-user.wants/lxd.service}}.

If you want to remove all data:

# rm -r /var/lib/lxd

If you used any of the example networking configuration, you should remove those as well.

== 参照 ==

* [https://lxd.readthedocs.io 公式ドキュメント]
* [https://linuxcontainers.org/lxd/ LXD 公式ホームページ]
* [https://github.com/lxc/lxd LXD の GitHub ページ]

カーネル/Arch build system

2022-12-20T04:44:43Z

Pedgin: PKGBUILD へのパッチ内容を英文Wiki記述の2022年8月25日時点の記述に変更。

[[Category:カーネル]]
[[de:Eigenen Kernel erstellen]]
[[en:Kernels/Arch Build System]]
[[it:Kernels/Arch Build System]]
[[ru:Kernels/Arch Build System]]
[[zh-hans:Kernels/Arch Build System]]
[[Arch Build System]] を使うことで、公式の {{Pkg|linux}} パッケージをベースにカスタムカーネルを作成することができます。このコンパイル方法は全体のプロセスを自動化でき、よくテストされたパッケージに基づいています。PKGBUILD を編集することでカスタムカーネルの設定やパッチの追加が可能です。

==材料の入手==

[[makepkg]] を使用するため、以下のベストプラクティスに従ってください。例えば、makepkg を root あるいは sudo で実行することはできません。したがって、まずはホームディレクトリに {{ic|build}} ディレクトリを作成してください:
$ mkdir build
$ cd build/

{{Pkg|asp}} パッケージと {{Grp|base-devel}} パッケージグループを [[インストール]] します。

カスタマイズを開始するには、クリーンなカーネルが必要です。[[Arch Build System#Git を使って PKGBUILD ソースを取得|Git を使って PKGBUILD ソースを取得]] といくつかのファイルをビルドディレクトリにコピーしてください。

$ asp update linux
$ asp export linux

この時点で、ディレクトリツリーは以下のようになります（他にもいくつかファイルがあるかもしれません）

{{bc|~/build/linux/-+
+--config
\__PKGBUILD
}}

その後、必要なファイル (例:カスタム設定ファイル、パッチなど) をそれぞれのソースから取得します。

==PKGBUILD の修正==
PKGBUILD {{ic|pkgbase}} をあなたのカスタムパッケージの名前に変えて下さい、例えば:
pkgbase=linux-custom

PKGBUILD によっては {{ic|linux.install}} の名前も {{ic|pkgbase}} にあわせて変更する必要があります (例: {{Pkg|linux-hardened}})。

{{Warning|{{ic|linux}} を {{ic|provides}} 配列に '''追加しないでください''' カスタムカーネルは、そのカーネルに対して構築されたバイナリモジュールと互換性がないため、その依存関係を満たすことはできません。同様に、同様の理由で、ヘッダーパッケージの {{ic|provides}} 配列に {{ic|linux-headers}} を追加しないでください。}}

=== ドキュメントの作成を避ける ===

長い [https://wiki.archlinux.jp/index.php/%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB/%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%AB/Arch_Build_System#.E3.82.B3.E3.83.B3.E3.83.91.E3.82.A4.E3.83.AB コンパイル] 作業の大部分は、ドキュメントの作成に費やされています。 2022年8月25日の時点で、PKGBUILDへの次のパッチはその作成を回避します。

{{bc|1=
63c63
< make htmldocs all
---
> make all
195c195
< pkgname=("$pkgbase" "$pkgbase-headers" "$pkgbase-docs")
---
> pkgname=("$pkgbase" "$pkgbase-headers")
}}
このパッチは行#63 と行#195 を変更します。 PKGBUILD ファイルが正しく適用されない場合は、手動で編集する必要がある場合があります。

=== prepare() の変更 ===

{{ic|prepare()}} 関数では、[[パッケージにパッチを適用#パッチの適用|パッチの適用]] やカーネルビルドの設定を変更することができます。

もし、いくつかの設定を変更する必要があるなら、ソースの設定ファイルを編集することができます。

また、GUI ツールを使ってオプションを調整することもできます。PKGBUILD の prepare() 関数に {{ic|make olddefconfig}} とコメントし、好きなツールを追加してください。
{{hc|PKGBUILD|
...
msg2 "Setting config..."
cp ../config .config
#make olddefconfig

make nconfig # new CLI menu for configuration
#make menuconfig # CLI menu for configuration
#make xconfig # X-based configuration
#make oldconfig # using old config from previous kernel version
# ... or manually edit .config
make prepare
...
}}

{{Warning|systemd には特定のユースケース (例: UEFI) の場合や特定の systemd の機能 (例: bootchart) を使用するために、設定する必要があるカーネルコンフィグが多数存在します。正しく設定しないとシステムの調子がおかしくなったり全く使えなくなったりします。必須あるいは推奨されているカーネルコンフィグのリストは {{ic|/usr/share/doc/systemd/README}} に書かれています。コンパイルする前によく確認してください。必要なコンフィグはときどき変わっています。Arch では基本的に公式カーネルを使用することになっているので、要件が変わってもアナウンスはされません。新しいバージョンの systemd をインストールする前に、リリースノートをチェックして使用しているカスタムカーネルが新しい systemd の要件を満たしているか確認してください。}}

===新しいチェックサムを生成===
[https://wiki.archlinux.jp/index.php/%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB/%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%AB/Arch_Build_System#prepare.28.29_.E3.81.AE.E5.A4.89.E6.9B.B4 Changing prepare()] は、{{ic|$_srcname/.config}} への変更の可能性を示唆しています。このパスはパッケージファイルのダウンロードが終了した場所ではないため、そのチェックサムは makepkg によってチェックされませんでした(実際の場所は {{ic|$_srcname/../../config}} をチェックしてください)

makepkg を実行する前に、ダウンロードした {{ic|config}} を別の設定ファイルに置き換えた場合は、 [インストール] {{Pkg|pacman-contrib}} パッケージ。
次のコマンドを実行すると、新しいチェックサムが生成されます。
$ updpkgsums

== コンパイル ==

普通のパッケージと同じビルドコマンド ({{ic|makepkg}}) を使ってカーネルをコンパイルします。

カーネルパラメータの設定に (menuconfig などの) インタラクティブなプログラムを選んだ場合は、コンパイル中に設定を行ってください。

$ makepkg -s

{{ic|-s}} パラメータによって xml やドキュメントなど最近のカーネルが必要とする依存パッケージがダウンロードされます。

{{Note|
* カーネルソースは [https://www.kernel.org/signature.html#kernel-org-web-of-trust PGP 署名] が付いており、makepkg は署名を検証します。詳しくは [[Makepkg#署名チェック]]を見てください。
* マルチコアのシステムでは[[Makepkg#MAKEFLAGS|複数のコンパイルジョブを同時に実行する]]ことでコンパイル時間を大幅に削減することが可能です。}}

==インストール==
''makepkg'' が終わったら {{ic|linux.install}} ファイルの変数が変わっているのが見て取れるはずです。

後は、pacman (もしくは pacman に代わるプログラム) で通常通りにパッケージをインストールするだけです。カスタムカーネルで必要となる ([[NVIDIA#カスタムカーネル|nvidia]] ドライバーをインストールするときなど) カーネルヘッダーを先にインストールすると良いでしょう:
# pacman -U ''kernel-headers_package''
# pacman -U ''kernel_package''

==ブートローダー==
これであなたのカスタムカーネルのフォルダとファイルが作成されました、例: {{ic|/boot/vmlinuz-linux-test}}。あなたのカーネルをテストするには、[[ブートローダー]]の設定ファイルを更新してカスタムカーネルに対応する新しいエントリ ('default' や 'fallback') を追加してください。''PKGBUILD の pkgbase'' でカーネルの名前を変更した場合は pacman でインストールする前に ''$build/pkg/kernel/etc'' の {{ic|initramfs.img}} の名前を変える必要があります。そうすれば標準のカーネルとカスタムカーネルを選択できるようになります。

== アップデート ==
更新したい arch kernel source を持っていると仮定すると、そのための一つの方法は https://git.archlinux.org/linux.git を使うことです。以下では、カーネルソースの最上位ディレクトリを ~/build/linux/ とします。

一般に、arch は2つのローカル git リポジトリを持つ arch kernel source を設定します。archlinux-linux/ にあるのは、git://git.archlinux.org/linux.git を指しているローカルの裸の git リポジトリです。もう一つは '''src/'''archlinux-linux/ にあり、最初のリポジトリから取り出します。可能なローカルパッチとビルドについては、 '''src/'''archlinux-linux/ を参照してください。 archlinux-linux/ と '''src/'''archlinux-linux/ ディレクトリの名前が異なることに注意してください。

$ cd ~/build/linux/archlinux-linux/

この例では、archlinux-linux/ にローカルにインストールされた bare git リポジトリソースの HEAD が最初に指されています
{{bc|
$ git log --oneline --max-count 1 HEAD
4010b622f1d2 Merge branch 'dax-fix-5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm}}
v5.2.5-arch1とv5.2.6-arch1の間のどこかにあります。
$ git fetch --verbose
取得した新しいタグを出力するため、最新の archlinux タグである v5.2.7-arch1 をフェッチしたことがわかります。新しいタグが取得されなかった場合、利用可能な新しい archlinux ソースはありません。

これで、実際のビルドが行われる場所でソースを更新できます。
{{bc|
$ cd ~/build/linux/src/archlinux-linux/
$ git checkout master
$ git pull
$ git fetch --tags --verbose
$ git branch --verbose 5.2.7-arch1 v5.2.7-arch1
$ git checkout 5.2.7-arch1
}}

次のような方法で状況が進んでいることを確認できます
{{bc|1=
$ git log --oneline 5.2.7-arch1 --max-count=7
13193bfc03d4 '''Arch Linux kernel v5.2.7-arch1'''
9475c6772d05 netfilter: nf_tabf676926c7f60les: fix module autoload for redir
498d650048f6 iwlwifi: Add support for SAR South Korea limitation
bb7293abdbc7 iwlwifi: mvm: disable TX-AMSDU on older NICs
f676926c7f60 ZEN: Add CONFIG for unprivileged_userns_clone
5e4e503f4f28 add sysctl to disallow unprivileged CLONE_NEWUSER by default
5697a9d3d55f '''Linux 5.2.7'''
}}
これは、ArchLinux カーネル v5.2.7-arch1 と Linux5.2.7 の間のいくつかの特定の archlinux パッチを示しています。ここで重要なのは、 ArchLinux カーネル v5.2.7-arch1 と Linux5.2.7 です。明らかに、他のバージョンには他のパッチがある可能性があります。そのため、 {{ic|--max-count}} の 7 を調整する必要があります。同様に、f676926c7f60などのコミット識別子やカーネルバージョンは、他のバージョンでは異なります。

最新の PKGBUILD、および archlinux カーネル構成ファイルは、 {{ic|asp}} コマンドで取得できます。

{{bc|
$ cd ~/build/linux/
$ asp update linux
$ asp export linux
}}

{{note|{{ic|asp}} コマンドは、新しい archlinux ソースタグがあっても Linux ファイルを更新しない場合があります。考えられる理由は、archlinuxlinux ファイルが archlinuxlinux ソースより遅れていることです。}}
ここで、 {{ic|~/build/linux/linux/*}} にある [https://wiki.archlinux.jp/index.php/Vim#.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.81.AE.E3.83.9E.E3.83.BC.E3.82.B8_.28vimdiff.29 Vim#Mergingfiles] を {{ic|~/build/linux/}} に配置する必要があります。マージは手動で、または [https://wiki.archlinux.jp/index.php/%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E4%B8%80%E8%A6%A7#Comparison.2C_diff.2C_merge Comparison、diff、merge] を使用して行うこともできます。 [https://wiki.archlinux.jp/index.php?title=%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB/%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%AB/Arch_Build_System&action=submit#prepare.28.29_.E3.81.AE.E5.A4.89.E6.9B.B4 #Changing prepare()] を確認し、 PKGBUILD::prepare() のシェルコマンドのすべてではないにしてもほとんどを手動で実行します。

この時点で、 {{ic|makepkg--verifysource}} は成功するはずです。 [https://wiki.archlinux.jp/index.php?title=%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB/%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%AB/Arch_Build_System&action=submit#.E3.82.B3.E3.83.B3.E3.83.91.E3.82.A4.E3.83.AB #コンパイル] の時には、 {{ic|makepkg}} --noextract オプションも追加してください、これによりソースが makepkg --nobuild によって抽出されたかのようにパッケージをビルドできるはずです。 [https://wiki.archlinux.jp/index.php?title=%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB/%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%AB/Arch_Build_System&action=submit#.E3.82.A4.E3.83.B3.E3.82.B9.E3.83.88.E3.83.BC.E3.83.AB #インストール] に戻ります。

=== クリーンアップ ===
マージした後、{{ic|~/build/linux/linux/}} を削除したい場合や。 {{ic|~/build/linux/src/archlinux}} は、より新しい更新がこの方法で行われた場合、{{ic|5.2.7-arch1}} の形式でブランチを蓄積します。これらは以下でで削除することができます

$ cd ~/build/linux/src/archlinux
$ git branch --delete --force --verbose 5.2.7-arch1

==参照==
* https://www.kernel.org/doc/html/latest/kbuild/kconfig.html and the parent directory