When /dev/shm is a symlink we need to create its target or some tests
will fail and Python 3 will be misconfigured. We wrote it as:
mkdir -pv $LFS/$(readlink $LFS/dev/shm)
But if $LFS/dev/shm is a relative symlink (say ../run/shm), we end up:
mkdir -pv /mnt/lfs/../run/shm
This command will create /mnt/run/shm, not $LFS/mnt/shm as we expected.
Twist it a little to make it work for both absolute symlinks and
relative symlinks.
Mistakenly removed the remote WIP branch while it's not fully merged
yet. Cherry-pick the discarded commit.
(cherry picked from commit 2f3f0e9e813f60a88e9f557842a7b9a50cdec50b)
Disable building nscd in glibc.
Update to iana-etc-20230929.
Update to vim-9.0.1968.
Update to openssl-3.1.3.
Update to meson-1.2.2.
Update to man-db-2.12.0.
Update to linux-6.5.5.
Update to kmod-31.
Update to kbd-2.6.3.
Update to gettext-0.22.2.
Update to bc-6.7.0.
Update to vim-1837.$
Update to zlib-1.3.$
Update to wheel-0.41.2 (Python Module).$
Update to util-linux-2.39.2.$
Update to sysvinit-3.08.$
Update to shadow-4.14.0.$
Update to Python-3.11.5.$
Update to procps-ng-4.0.4.$
Update to pkgconf-2.0.2.$
Update to mpfr-4.2.1.$
Update to kbd-2.6.2.$
Update to gzip-1.13.$
Update to coreutils-9.4.$
Specify the 'nobody-group' for systemd.$
Remove unused usb group.$
Update to vim-9.0.1452.
Update to iana-etc-20230405.
Update to zstd-1.5.5.
Update to Python-3.11.3.
Update to meson-1.1.0.
Update to man-pages-6.04.
Update to linux-6.2.11.
"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.
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.
Technically chroot command "tells" bash nothing. It basically calls
chroot("$LFS"), then chdir("/"), then
execve(["/usr/bin/env", "-i", ...]). The kernel also does not tell bash
something like "hey, the root is now $LFS" but just executes (almost) all
system calls from bash as-if $LFS is /.
The man page of chroot says:
DESCRIPTION
Run COMMAND with root directory set to NEWROOT.
Just use the same grammar construction here.
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.
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.
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.
Don't emphasis "static library" at all, to prevent anyone from thinking
"I need to use static libraries so I'll keep these .la files". And warn
that .la files are known to break BLFS packages.
