source: chapter07/kernfs.xml@ 2bf32ff

11.3 11.3-rc1 12.0 12.0-rc1 12.1 12.1-rc1 bdubbs/gcc13 multilib renodr/libudev-from-systemd trunk xry111/arm64 xry111/arm64-12.0 xry111/clfs-ng xry111/loongarch xry111/loongarch-12.0 xry111/loongarch-12.1 xry111/mips64el xry111/pip3 xry111/rust-wip-20221008 xry111/update-glibc
Last change on this file since 2bf32ff was 2bf32ff, checked in by Xi Ruoyao <xry111@…>, 19 months ago

kernfs: "device nodes" are in /dev, not "devices"

You cannot throw a NVIDIA GTX 690 into /dev :).

  • Property mode set to 100644
File size: 4.9 KB
Line 
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
4 <!ENTITY % general-entities SYSTEM "../general.ent">
5 %general-entities;
6]>
7
8<sect1 id="ch-tools-kernfs">
9 <?dbhtml filename="kernfs.html"?>
10
11 <title>Preparing Virtual Kernel File Systems</title>
12
13 <indexterm zone="ch-tools-kernfs">
14 <primary sortas="e-/dev/">/dev/*</primary>
15 </indexterm>
16
17 <para>Applications running in user space utilize various file
18 systems exported by the kernel to communicate
19 with the kernel itself. These file systems are virtual: no disk
20 space is used for them. The content of the file systems resides in
21 memory. These file systems must be mounted in the $LFS directory tree
22 so the applications can find them in the chroot environment.</para>
23
24 <para>Begin by creating directories on which the file systems will be
25 mounted:</para>
26
27<screen><userinput>mkdir -pv $LFS/{dev,proc,sys,run}</userinput></screen>
28
29 <sect2 id="ch-tools-bindmount">
30 <title>Mounting and Populating /dev</title>
31
32 <para>During a normal boot of the LFS system, the kernel automatically
33 mounts the <systemitem class="filesystem">devtmpfs</systemitem>
34 filesystem on the
35 <filename class="directory">/dev</filename> directory; the kernel
36 creates device nodes on that virtual filesystem during the boot process
37 or when a device is first detected or accessed. The udev daemon may
38 change the owner or permission of the device nodes created by the
39 kernel, or create new device nodes or symlinks to ease the work of
40 distro maintainers or system administrators. (See
41 <xref linkend='ch-config-udev-device-node-creation'/> for details.)
42 If the host kernel supports &devtmpfs;, we can simply mount a
43 &devtmpfs; at <filename class='directory'>$LFS/dev</filename> and rely
44 on the kernel to populate it (the LFS building process does not need
45 the additional work onto &devtmpfs; by udev daemon).</para>
46
47 <para>But, some host kernels may lack &devtmpfs; support and these
48 host distros maintain the content of
49 <filename class="directory">/dev</filename> with different methods.
50 So the only host-agnostic way for populating
51 <filename class="directory">$LFS/dev</filename> is
52 bind mounting the host system's
53 <filename class="directory">/dev</filename> directory. A bind mount is
54 a special type of mount that allows you to create a mirror of a
55 directory or mount point at some other location. Use the following
56 command to do this:</para>
57
58<screen><userinput>mount -v --bind /dev $LFS/dev</userinput></screen>
59
60 </sect2>
61
62 <sect2 id="ch-tools-kernfsmount">
63 <title>Mounting Virtual Kernel File Systems</title>
64
65 <para>Now mount the remaining virtual kernel filesystems:</para>
66
67<screen><userinput>mount -v --bind /dev/pts $LFS/dev/pts
68mount -vt proc proc $LFS/proc
69mount -vt sysfs sysfs $LFS/sys
70mount -vt tmpfs tmpfs $LFS/run</userinput></screen>
71<!--
72 <variablelist>
73 <title>The meaning of the mount options for devpts:</title>
74
75 <varlistentry>
76 <term><parameter>gid=5</parameter></term>
77 <listitem>
78 <para>This ensures that all devpts-created device nodes are owned by
79 group ID 5. This is the ID we will use later on for the <systemitem
80 class="groupname">tty</systemitem> group. We use the group ID instead
81 of a name, since the host system might use a different ID for its
82 <systemitem class="groupname">tty</systemitem> group.</para>
83 </listitem>
84 </varlistentry>
85
86 <varlistentry>
87 <term><parameter>mode=0620</parameter></term>
88 <listitem>
89 <para>This ensures that all devpts-created device nodes have mode 0620
90 (user readable and writable, group writable). Together with the
91 option above, this ensures that devpts will create device nodes that
92 meet the requirements of grantpt(), meaning the Glibc
93 <command>pt_chown</command> helper binary (which is not installed by
94 default) is not necessary.</para>
95 </listitem>
96 </varlistentry>
97
98 </variablelist>
99-->
100 <para>In some host systems, <filename>/dev/shm</filename> is a
101 symbolic link to <filename class="directory">/run/shm</filename>.
102 The /run tmpfs was mounted above so in this case only a
103 directory needs to be created.</para>
104
105 <para>In other host systems <filename>/dev/shm</filename> is a mount point
106 for a tmpfs. In that case the mount of /dev above will only create
107 /dev/shm as a directory in the chroot environment. In this situation
108 we must explicitly mount a tmpfs:</para>
109
110<screen><userinput>if [ -h $LFS/dev/shm ]; then
111 mkdir -pv $LFS/$(readlink $LFS/dev/shm)
112else
113 mount -t tmpfs -o nosuid,nodev tmpfs $LFS/dev/shm
114fi</userinput></screen>
115
116 </sect2>
117
118</sect1>
Note: See TracBrowser for help on using the repository browser.