source: chapter07/kernfs.xml

trunk
Last change on this file was ce11e97, checked in by Xi Ruoyao <xry111@…>, 3 months ago

kernfs: Use a separate devpts filesystem for chroot environment

IIRC we switched from separate devpts to bind mount, and matched the UID
of tester with the host UID owning the TTY, to satisify the Bash test
suite. But now we are always using UID 101 for tester and expect to
spawn a PTY for Bash test suite (so when building LFS in a TTY owned by
the root user of the host tester won't be UID 0). Thus we can switch
back to a separate devpts mount which is cleaner and safer.

And we are already using a separate devpts mount in Chapter 11.

  • Property mode set to 100644
File size: 5.0 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
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 userspace utilize various file
18 systems created 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 these 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 the directories on which these virtual 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 an LFS system, the kernel automatically
33 mounts the <systemitem class="filesystem">devtmpfs</systemitem>
34 file system on the
35 <filename class="directory">/dev</filename> directory; the kernel
36 creates device nodes on that virtual file system during the boot process,
37 or when a device is first detected or accessed. The udev daemon may
38 change the ownership or permissions of the device nodes created by the
39 kernel, and create new device nodes or symlinks, to ease the work of
40 distro maintainers and 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.</para>
45
46 <para>But some host kernels lack &devtmpfs; support; these
47 host distros use different methods to create the content of
48 <filename class="directory">/dev</filename>.
49 So the only host-agnostic way to populate the
50 <filename class="directory">$LFS/dev</filename> directory is
51 by bind mounting the host system's
52 <filename class="directory">/dev</filename> directory. A bind mount is
53 a special type of mount that makes a directory subtree or a file
54 visible at some other location. Use the following
55 command to do this.</para>
56
57<screen><userinput>mount -v --bind /dev $LFS/dev</userinput></screen>
58
59 </sect2>
60
61 <sect2 id="ch-tools-kernfsmount">
62 <title>Mounting Virtual Kernel File Systems</title>
63
64 <para>Now mount the remaining virtual kernel file systems:</para>
65
66 <!-- Do not put any option after $LFS/${mountpoint} or jhalfs cannot
67 handle it! -->
68
69<screen><userinput>mount -vt devpts devpts -o gid=5,mode=0620 $LFS/dev/pts
70mount -vt proc proc $LFS/proc
71mount -vt sysfs sysfs $LFS/sys
72mount -vt tmpfs tmpfs $LFS/run</userinput></screen>
73
74 <variablelist>
75 <title>The meaning of the mount options for devpts:</title>
76
77 <varlistentry>
78 <term><parameter>gid=5</parameter></term>
79 <listitem>
80 <para>This ensures that all devpts-created device nodes are owned by
81 group ID 5. This is the ID we will use later on for the <systemitem
82 class="groupname">tty</systemitem> group. We use the group ID instead
83 of a name, since the host system might use a different ID for its
84 <systemitem class="groupname">tty</systemitem> group.</para>
85 </listitem>
86 </varlistentry>
87
88 <varlistentry>
89 <term><parameter>mode=0620</parameter></term>
90 <listitem>
91 <para>This ensures that all devpts-created device nodes have mode 0620
92 (user readable and writable, group writable). Together with the
93 option above, this ensures that devpts will create device nodes that
94 meet the requirements of grantpt(), meaning the Glibc
95 <command>pt_chown</command> helper binary (which is not installed by
96 default) is not necessary.</para>
97 </listitem>
98 </varlistentry>
99
100 </variablelist>
101
102 <para>In some host systems, <filename>/dev/shm</filename> is a
103 symbolic link to a directory, typically
104 <filename class="directory">/run/shm</filename>.
105 The /run tmpfs was mounted above so in this case only a
106 directory needs to be created with the correct permissions.</para>
107
108 <para>In other host systems <filename>/dev/shm</filename> is a mount point
109 for a tmpfs. In that case the mount of /dev above will only create
110 /dev/shm as a directory in the chroot environment. In this situation
111 we must explicitly mount a tmpfs:</para>
112
113<screen><userinput>if [ -h $LFS/dev/shm ]; then
114 install -v -d -m 1777 $LFS$(realpath /dev/shm)
115else
116 mount -vt tmpfs -o nosuid,nodev tmpfs $LFS/dev/shm
117fi</userinput></screen>
118
119 </sect2>
120
121</sect1>
Note: See TracBrowser for help on using the repository browser.