aboutsummaryrefslogtreecommitdiffstats
path: root/chapter07/kernfs.xml
Commit message (Collapse)AuthorAgeFilesLines
* Standardize spelling of "userspace".David Bryant2022-12-241-1/+1
|
* kernfs: reword the description of bind mountXi Ruoyao2022-11-181-2/+2
| | | | | | | | | | | "Duplicated copy" is wrong IMO. If you copy A to B, B won't be changed when you modify A. But if you bind mount A to B, B will reflect any change made to A. Again copy something from mount(2): A bind mount makes a file or a directory subtree visible at another point within the single directory hierarchy.
* kernfs: remove a false noteXi Ruoyao2022-11-181-2/+1
| | | | | | | | | | | | | | | | | | | | | Things are a little tricky: 1. If the host is "modern" (any desktop distro after 2013), the kernel supports devtmpfs and the host udev will do adjustments to the devtmpfs. All instances of devtmpfs shares the same content so we'll see the work of both the kernel and the host udev in chroot. 2. If the host is old but the kernel supports devtmpfs (i. e. the host is not using devtmpfs for its /dev), when we mount devtmpfs on $LFS/dev we'll see the work of the kernel in chroot, but not the work of udev. **Building LFS does not need any work of udev.** 3. If the host is very old and the kernel does not support devtmpfs at all, we can't mount devtmpfs. Mounting a devtmpfs will work for 1 and 2, while bind mounting will work for 1, 2, and 3. So we use bind mounting here. I don't want to squash all these details into the book, so just remove the false statement here.
* Corrected grammar, spelling, and idiom in chapter 7.David Bryant2022-11-161-21/+21
|
* kernfs: "device nodes" are in /dev, not "devices"Xi Ruoyao2022-10-011-1/+1
| | | | You cannot throw a NVIDIA GTX 690 into /dev :).
* kernfs: modernize the explanation for bind mounting /devXi Ruoyao2022-10-011-10/+21
| | | | | | | | | | | | | If you are using a "modern" distro (with devtmpfs and a modern udev implementation), a bind mounting is actually not needed because you can mount devtmpfs anyway. The only reason for bind mounting is to be compatible with old host distros where /dev is a directory containing many static device nodes, or is a tmpfs (not same as devtmpfs) popluated by bootscript or an old udev (modern udev implementations, including eudev and systemd-udev used by LFS, strictly requires a devtmpfs on /dev). So update the explanation to match the status quo.
* kernfs: technically, they are not needed for chrootXi Ruoyao2022-10-011-2/+2
| | | | | | | | | | | | | Chroot command itself does not require kernel VFS mounted. You can mount /proc, /sys, and /run after entering chroot with "mount -v -t proc proc /proc" etc. For /dev, if the host kernel supports devtmpfs, you can also mount /dev in chroot with "mount -v -t devtmpfs devtmpfs /dev". Even if the host does not support devtmpfs, it's still possible to mount /proc in chroot, then use "mount --bind /proc/1/dev /dev". It's just LFS editors decide to mount them before chroot. So reword some untrue assertions.
* Made grammatical corrections and stylistic changes to chapter 7.3.David Bryant2022-09-301-15/+17
| | | | | Added clarification; the virtual file systems expose certain information to programs in user space; chroot won't work without them.
* Adjust instructions for /dev/shm when creating virtual filesystems.Bruce Dubbs2022-09-201-0/+7
| | | | | | | | | | Some host create /dev/shm as a tmpfs. Some have is as a symlink to a location in another directory. This change handles both cases. The change to the sysV bootscripts now creates /dev/shm as a separate tmpfs from /run. This makes LFS sysV and systemd versions treat /dev/shm the same.
* kernfs: "Udev" -> "the kernel and Udev"Xi Ruoyao2022-03-081-1/+2
| | | | | devtmpfs already contains many device nodes created by the kernel once it's mounted, and Udev creates or renames nodes based on kernel work.
* kernfs: remove static node creation, and update the textXi Ruoyao2022-03-081-32/+13
| | | | | | | | | | | | | | | | | | This is to match the "new" way of device handling with devtmpfs (already widely used in recent ten years). In a normal booting process, the kernel mounts devtmpfs at very early stage. So the static nodes won't be used at all. The only situation where the kernel can't mount devtmpfs is "/dev is missing", but it means those two static nodes can't exist anyway, and a normal LFS system (without initramfs) won't boot in such a bad situation. Removing static /dev/console and /dev/null may cause trouble for those people or scripts chroot into LFS tree without mounting devtmpfs. But entering a chroot with only console and null in /dev is already problematic. For a reference, If a systemd service is started with PrivateDevices=true, systemd will create 18 nodes and symlinks to form a "minimal" /dev.
* Remove spaces at end o lines - chapter07Pierre Labastie2021-09-071-1/+1
|
* remove last ch-system-xxx id's in chapter 7Pierre Labastie2020-06-221-2/+2
| | | | git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@11980 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
* Update initial Chapter 7 pages for cross2 branchBruce Dubbs2020-06-111-5/+6
| | | | git-svn-id: http://svn.linuxfromscratch.org/LFS/branches/cross2@11918 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
* Initial commit of alternative cross LFSBruce Dubbs2020-06-071-0/+115
git-svn-id: http://svn.linuxfromscratch.org/LFS/branches/cross2@11897 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-12-29 08:26:15 +0000