From 4349661a7fdf7502916a3d4596a186ee7824307b Mon Sep 17 00:00:00 2001 From: David Bryant Date: Sat, 1 Oct 2022 17:03:20 -0500 Subject: [PATCH 1/6] Corrected grammatical errors and cleaned up English idiom. --- chapter08/pkgmgt.xml | 160 +++++++++++++++++++++---------------------- 1 file changed, 80 insertions(+), 80 deletions(-) diff --git a/chapter08/pkgmgt.xml b/chapter08/pkgmgt.xml index b925a976f..5d9477e80 100644 --- a/chapter08/pkgmgt.xml +++ b/chapter08/pkgmgt.xml @@ -11,13 +11,13 @@ Package Management Package Management is an often requested addition to the LFS Book. A - Package Manager allows tracking the installation of files making it easy to + Package Manager tracks the installation of files, making it easier to remove and upgrade packages. As well as the binary and library files, a package manager will handle the installation of configuration files. Before you begin to wonder, NO—this section will not talk about nor recommend any particular package manager. What it provides is a roundup of the more popular techniques and how they work. The perfect package manager for you may - be among these techniques or may be a combination of two or more of these + be among these techniques, or it may be a combination of two or more of these techniques. This section briefly mentions issues that may arise when upgrading packages. @@ -32,14 +32,14 @@ There are multiple solutions for package management, each having - its strengths and drawbacks. Including one that satisfies all audiences + its strengths and drawbacks. Finding one solution that satisfies all audiences is difficult. There are some hints written on the topic of package management. Visit the Hints Project and see if one of them - fits your need. + fits your needs. Upgrade Issues @@ -51,18 +51,18 @@ - If Linux kernel needs to be upgraded (for example, from - 5.10.17 to 5.10.18 or 5.11.1), nothing else need to be rebuilt. - The system will keep working fine thanks to the well-defined border - between kernel and userspace. Specifically, Linux API headers - need not to be (and should not be, see the next item) upgraded - alongside the kernel. You'll need to reboot your system to use the + If the Linux kernel needs to be upgraded (for example, from + 5.10.17 to 5.10.18 or 5.11.1), nothing else needs to be rebuilt. + The system will keep working fine thanks to the well-defined interface + between the kernel and user space. Specifically, Linux API headers + need not be (and should not be, see the next item) upgraded + along with the kernel. You will merely need to reboot your system to use the upgraded kernel. - If Linux API headers or Glibc needs to be upgraded to a newer - version, (e.g. from glibc-2.31 to glibc-2.32), it is safer to + If Linux API headers or glibc need to be upgraded to a newer + version, (e.g., from glibc-2.31 to glibc-2.32), it is safer to rebuild LFS. Though you may be able to rebuild all the packages in their dependency order, we do not recommend it. @@ -70,44 +70,44 @@ If a package containing a shared library is updated, and if the name of the library changes, then any packages dynamically - linked to the library need to be recompiled in order to link against the + linked to the library must be recompiled, to link against the newer library. (Note that there is no correlation between the package version and the name of the library.) For example, consider a package - foo-1.2.3 that installs a shared library with name libfoo.so.1. If you upgrade the package to - a newer version foo-1.2.4 that installs a shared library with name + foo-1.2.3 that installs a shared library with the name libfoo.so.1. Suppose you upgrade the package to + a newer version foo-1.2.4 that installs a shared library with the name libfoo.so.2. In this case, any packages that are dynamically linked to libfoo.so.1 need to be recompiled to link against libfoo.so.2 in order to - use the new library version. You should not remove the previous - libraries unless all the dependent packages are recompiled. + use the new library version. You should not remove the old + libraries until all the dependent packages have been recompiled. If a package containing a shared library is updated, - and the name of library doesn't change, but the version number of the + and the name of the library doesn't change, but the version number of the library file decreases (for example, - the name of the library is kept named + the library is still named libfoo.so.1, - but the name of library file is changed from + but the name of the library file is changed from libfoo.so.1.25 to libfoo.so.1.24), you should remove the library file from the previously installed version - (libfoo.so.1.25 in the case). - Or, a ldconfig run (by yourself using a command + (libfoo.so.1.25 in this case). + Otherwise, a ldconfig command (invokeed by yourself from the command line, or by the installation of some package) will reset the symlink libfoo.so.1 to point to - the old library file because it seems having a newer - version, as its version number is larger. This situation may happen if - you have to downgrade a package, or the package changes the versioning - scheme of library files suddenly. + the old library file because it seems to be a newer + version; its version number is larger. This situation may arise if + you have to downgrade a package, or if the authors change the versioning + scheme for library files. If a package containing a shared library is updated, - and the name of library doesn't change, but a severe issue + and the name of the library doesn't change, but a severe issue (especially, a security vulnerability) is fixed, all running programs linked to the shared library should be restarted. The following command, run as root after - updating, will list what is using the old versions of those libraries + the update is cmplete, will list which processes are using the old versions of those libraries (replace libfoo with the name of the library): @@ -115,33 +115,33 @@ tr -cd 0-9\\n | xargs -r ps u - If OpenSSH is being used for accessing - the system and it is linked to the updated library, you need to - restart sshd service, then logout, login again, - and rerun that command to confirm nothing is still using the + If OpenSSH is being used to access + the system and it is linked to the updated library, you must + restart the sshd service, then logout, login again, + and rerun the preceding ps command to confirm that nothing is still using the deleted libraries. If the systemd daemon (running as PID 1) is - linked to the updated library, you can restart it without reboot + linked to the updated library, you can restart it without rebooting by running systemctl daemon-reexec as the root user. - If a binary or a shared library is overwritten, the processes - using the code or data in the binary or library may crash. The - correct way to update a binary or a shared library without causing + If an executable program or a shared library is overwritten, the processes + using the code or data in that program or library may crash. The + correct way to update a program or a shared library without causing the process to crash is to remove it first, then install the new - version into position. The install command - provided by Coreutils has already - implemented this and most packages use it to install binaries and + version. The install command + provided by coreutils has already + implemented this, and most packages use that command to install binary files and libraries. This means that you won't be troubled by this issue most of the time. However, the install process of some packages (notably Mozilla JS - in BLFS) just overwrites the file if it exists and causes a crash, so + in BLFS) just overwrites the file if it exists; this causes a crash. So it's safer to save your work and close unneeded running processes - before updating a package. + before updating a package. @@ -152,36 +152,36 @@ The following are some common package management techniques. Before making a decision on a package manager, do some research on the various - techniques, particularly the drawbacks of the particular scheme. + techniques, particularly the drawbacks of each particular scheme. It is All in My Head! - Yes, this is a package management technique. Some folks do not find - the need for a package manager because they know the packages intimately - and know what files are installed by each package. Some users also do not + Yes, this is a package management technique. Some folks do not + need a package manager because they know the packages intimately + and know which files are installed by each package. Some users also do not need any package management because they plan on rebuilding the entire - system when a package is changed. + system whenever a package is changed. Install in Separate Directories - This is a simplistic package management that does not need any extra - package to manage the installations. Each package is installed in a + This is a simplistic package management technique that does not need a + special program to manage the packages. Each package is installed in a separate directory. For example, package foo-1.1 is installed in /usr/pkg/foo-1.1 and a symlink is made from /usr/pkg/foo to - /usr/pkg/foo-1.1. When installing - a new version foo-1.2, it is installed in + /usr/pkg/foo-1.1. When + a new version foo-1.2 comes along, it is installed in /usr/pkg/foo-1.2 and the previous symlink is replaced by a symlink to the new version. Environment variables such as PATH, LD_LIBRARY_PATH, MANPATH, INFOPATH and CPPFLAGS need to be expanded to - include /usr/pkg/foo. For more than a few packages, + include /usr/pkg/foo. If you install more than a few packages, this scheme becomes unmanageable. @@ -190,15 +190,15 @@ Symlink Style Package Management This is a variation of the previous package management technique. - Each package is installed similar to the previous scheme. But instead of - making the symlink, each file is symlinked into the + Each package is installed as in the previous scheme. But instead of + making the symlink via a generic package name, each file is symlinked into the /usr hierarchy. This removes the need to expand the environment variables. Though the symlinks can be - created by the user to automate the creation, many package managers have - been written using this approach. A few of the popular ones include Stow, + created by the user, many package managers use this approach, and + automate the creation of the symlinks. A few of the popular ones include Stow, Epkg, Graft, and Depot. - The installation needs to be faked, so that the package thinks that + The installation script needs to be fooled, so the package thinks it is installed in /usr though in reality it is installed in the /usr/pkg hierarchy. Installing in @@ -216,7 +216,7 @@ make install /usr/pkg/libfoo/1.1/lib/libfoo.so.1 instead of /usr/lib/libfoo.so.1 as you would expect. The correct approach is to use the - DESTDIR strategy to fake installation of the package. This + DESTDIR variable to direct the installation. This approach works as follows: ./configure --prefix=/usr @@ -224,8 +224,8 @@ make make DESTDIR=/usr/pkg/libfoo/1.1 install Most packages support this approach, but there are some which do not. - For the non-compliant packages, you may either need to manually install the - package, or you may find that it is easier to install some problematic + For the non-compliant packages, you may either need to install the + package manually, or you may find that it is easier to install some problematic packages into /opt. @@ -237,14 +237,14 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install the package. After the installation, a simple use of the find command with the appropriate options can generate a log of all the files installed after the timestamp file was created. A - package manager written with this approach is install-log. + package manager that uses this approach is install-log. Though this scheme has the advantage of being simple, it has two drawbacks. If, during installation, the files are installed with any timestamp other than the current time, those files will not be tracked by - the package manager. Also, this scheme can only be used when one package - is installed at a time. The logs are not reliable if two packages are - being installed on two different consoles. + the package manager. Also, this scheme can only be used when packages + are installed one at a time. The logs are not reliable if two packages are + installed simultaneously from two different consoles. @@ -262,12 +262,12 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install calls that modify the filesystem. For this approach to work, all the executables need to be dynamically linked without the suid or sgid bit. Preloading the library may cause some unwanted side-effects during - installation. Therefore, it is advised that one performs some tests to - ensure that the package manager does not break anything and logs all the + installation. Therefore, it's a good idea to perform some tests to + ensure that the package manager does not break anything, and that it logs all the appropriate files. - The second technique is to use strace, which - logs all system calls made during the execution of the installation + Another technique is to use strace, which + logs all the system calls made during the execution of the installation scripts. @@ -275,10 +275,10 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install Creating Package Archives In this scheme, the package installation is faked into a separate - tree as described in the Symlink style package management. After the + tree as previously described in the symlink style package management section. After the installation, a package archive is created using the installed files. - This archive is then used to install the package either on the local - machine or can even be used to install the package on other machines. + This archive is then used to install the package on the local + machine or even on other machines. This approach is used by most of the package managers found in the commercial distributions. Examples of package managers that follow this @@ -289,10 +289,10 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install package management for LFS systems is located at . - Creation of package files that include dependency information is - complex and is beyond the scope of LFS. + The creation of package files that include dependency information is + complex, and beyond the scope of LFS. - Slackware uses a tar based system for package + Slackware uses a tar-based system for package archives. This system purposely does not handle package dependencies as more complex package managers do. For details of Slackware package management, see another computer with the same architecture as the base system is as simple as using tar on the LFS partition that contains the root directory (about 250MB uncompressed for a base LFS build), copying - that file via network transfer or CD-ROM to the new system and expanding - it. From that point, a few configuration files will have to be changed. + that file via network transfer or CD-ROM / USB stick to the new system, and expanding + it. After that, a few configuration files will have to be changed. Configuration files that may need to be updated include: /etc/hosts, /etc/fstab, @@ -342,17 +342,17 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install - A custom kernel may need to be built for the new system depending on + A custom kernel may be needed for the new system, depending on differences in system hardware and the original kernel configuration. There have been some reports of issues when copying between similar but not identical architectures. For instance, the instruction set - for an Intel system is not identical with an AMD processor and later - versions of some processors may have instructions that are unavailable in + for an Intel system is not identical with the AMD processor's instructions, and later + versions of some processors may provide instructions that are unavailable with earlier versions. - Finally the new system has to be made bootable via Finally, the new system has to be made bootable via . From b3daf0157845b5a86e2b6aec8a859a0d75010a3c Mon Sep 17 00:00:00 2001 From: Pierre Labastie Date: Sun, 2 Oct 2022 09:49:12 +0200 Subject: [PATCH 2/6] Typos reported by "rhubarbpieguy" --- bootscripts/lfs/init.d/checkfs | 2 +- bootscripts/lfs/init.d/mountfs | 2 +- bootscripts/lfs/init.d/rc | 2 +- bootscripts/lfs/init.d/template | 2 +- bootscripts/lfs/lib/services/init-functions | 4 ++-- bootscripts/lfs/sysconfig/createfiles | 2 +- bootscripts/lfs/sysconfig/rc.site | 2 +- part3intro/toolchaintechnotes.xml | 2 +- 8 files changed, 9 insertions(+), 9 deletions(-) diff --git a/bootscripts/lfs/init.d/checkfs b/bootscripts/lfs/init.d/checkfs index 584921983..0903a0111 100644 --- a/bootscripts/lfs/init.d/checkfs +++ b/bootscripts/lfs/init.d/checkfs @@ -34,7 +34,7 @@ # Default-Start: S # Default-Stop: # Short-Description: Checks local filesystems before mounting. -# Description: Checks local filesystmes before mounting. +# Description: Checks local filesystems before mounting. # X-LFS-Provided-By: LFS ### END INIT INFO diff --git a/bootscripts/lfs/init.d/mountfs b/bootscripts/lfs/init.d/mountfs index ea413392e..cd9407dc0 100644 --- a/bootscripts/lfs/init.d/mountfs +++ b/bootscripts/lfs/init.d/mountfs @@ -55,7 +55,7 @@ case "${1}" in stop) # Don't unmount virtual file systems like /run log_info_msg "Unmounting all other currently mounted file systems..." - # Ensure any loop devies are removed + # Ensure any loop devices are removed losetup -D umount --all --detach-loop --read-only \ --types notmpfs,nosysfs,nodevtmpfs,noproc,nodevpts >/dev/null diff --git a/bootscripts/lfs/init.d/rc b/bootscripts/lfs/init.d/rc index 7dd503a07..dd855a71b 100644 --- a/bootscripts/lfs/init.d/rc +++ b/bootscripts/lfs/init.d/rc @@ -183,7 +183,7 @@ fi # Start all services marked as S in this runlevel, except if marked as # S in the previous runlevel -# it is the responsabily of the script to not try to start an already running +# it is the responsibility of the script to not try to start an already running # service for i in $( ls -v /etc/rc.d/rc${runlevel}.d/S* 2> /dev/null) do diff --git a/bootscripts/lfs/init.d/template b/bootscripts/lfs/init.d/template index 0a7872d98..4b3c4642a 100644 --- a/bootscripts/lfs/init.d/template +++ b/bootscripts/lfs/init.d/template @@ -45,7 +45,7 @@ case "${1}" in # if it is possible to use killproc killproc fully_qualified_path # if it is not possible to use killproc - # (the daemon shoudn't be stopped by killing it) + # (the daemon shouldn't be stopped by killing it) if pidofproc daemon_name_as_reported_by_ps >/dev/null; then command_to_stop_the_service fi diff --git a/bootscripts/lfs/lib/services/init-functions b/bootscripts/lfs/lib/services/init-functions index ece4d79aa..a86a23d86 100644 --- a/bootscripts/lfs/lib/services/init-functions +++ b/bootscripts/lfs/lib/services/init-functions @@ -155,7 +155,7 @@ start_daemon() fi # Return a value ONLY - # It is the init script's (or distribution's functions) responsibilty + # It is the init script's (or distribution's functions) responsibility # to log messages! case "${retval}" in @@ -271,7 +271,7 @@ killproc() fi # Return a value ONLY - # It is the init script's (or distribution's functions) responsibilty + # It is the init script's (or distribution's functions) responsibility # to log messages! case "${retval}" in diff --git a/bootscripts/lfs/sysconfig/createfiles b/bootscripts/lfs/sysconfig/createfiles index 378fa3ee7..bb744778f 100644 --- a/bootscripts/lfs/sysconfig/createfiles +++ b/bootscripts/lfs/sysconfig/createfiles @@ -21,7 +21,7 @@ # dev creates a new device # is either block, char or pipe # block creates a block device -# char creates a character deivce +# char creates a character device # pipe creates a pipe, this will ignore the and # fields # and are the major and minor numbers used for diff --git a/bootscripts/lfs/sysconfig/rc.site b/bootscripts/lfs/sysconfig/rc.site index 903aebff5..56b6f8d9b 100644 --- a/bootscripts/lfs/sysconfig/rc.site +++ b/bootscripts/lfs/sysconfig/rc.site @@ -32,7 +32,7 @@ #FAILURE_PREFIX="${FAILURE}*****${NORMAL} " #WARNING_PREFIX="${WARNING} *** ${NORMAL} " -# Manually seet the right edge of message output (characters) +# Manually set the right edge of message output (characters) # Useful when resetting console font during boot to override # automatic screen width detection #COLUMNS=120 diff --git a/part3intro/toolchaintechnotes.xml b/part3intro/toolchaintechnotes.xml index 16b6aafd2..c5b8dc577 100644 --- a/part3intro/toolchaintechnotes.xml +++ b/part3intro/toolchaintechnotes.xml @@ -151,7 +151,7 @@ referred to as the system triplet. Since the vendor field is mostly irrelevant, autoconf allows to omit it. An astute reader may wonder why a triplet refers to a four component name. The - reason is the kernel field and the os field originiated from one + reason is the kernel field and the os field originated from one system field. Such a three-field form is still valid today for some systems, for example x86_64-unknown-freebsd. But for other systems, From 8e0c191b9b6d35274b363b478a479c7dd4ed32e4 Mon Sep 17 00:00:00 2001 From: Pierre Labastie Date: Sun, 2 Oct 2022 09:52:59 +0200 Subject: [PATCH 3/6] umount /dev/shm before rebooting Now that /dev/shm is always a mountpoint, it needs to be umounted otherwise dev cannot be umounted. --- chapter11/reboot.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/chapter11/reboot.xml b/chapter11/reboot.xml index ebfb0a2b1..1d76fcc7a 100644 --- a/chapter11/reboot.xml +++ b/chapter11/reboot.xml @@ -107,6 +107,7 @@ Then unmount the virtual file systems: umount -v $LFS/dev/pts +umount -v $LFS/dev/shm umount -v $LFS/dev umount -v $LFS/run umount -v $LFS/proc From bde421e48d7a25e38fb4a6114bd2a1ca1506ea30 Mon Sep 17 00:00:00 2001 From: Xi Ruoyao Date: Sun, 2 Oct 2022 16:12:26 +0800 Subject: [PATCH 4/6] reboot: fix /dev/shm unmounting command /dev/shm may be a mount point, or a symlink. --- chapter11/reboot.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapter11/reboot.xml b/chapter11/reboot.xml index 1d76fcc7a..809d9bb70 100644 --- a/chapter11/reboot.xml +++ b/chapter11/reboot.xml @@ -107,7 +107,7 @@ Then unmount the virtual file systems: umount -v $LFS/dev/pts -umount -v $LFS/dev/shm +mountpoint -q $LFS/dev/shm && umount $LFS/dev/shm umount -v $LFS/dev umount -v $LFS/run umount -v $LFS/proc From 9b2dedc676a0377d5101986aa97576b8215676ea Mon Sep 17 00:00:00 2001 From: Xi Ruoyao Date: Sun, 2 Oct 2022 19:11:57 +0800 Subject: [PATCH 5/6] package: add optional instruction to change the owner of downloaded packages to root Many users will create a user with the same username and UID so the files will still be owned by his/her. So make it optional by "If you won't assign the same UID for your user in the LFS system". --- chapter03/introduction.xml | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/chapter03/introduction.xml b/chapter03/introduction.xml index 1a69187a2..0e90508ae 100644 --- a/chapter03/introduction.xml +++ b/chapter03/introduction.xml @@ -104,4 +104,14 @@ popd This check can be used after retrieving the needed files with any of the methods listed above. + If the packages and patches are downloaded as a non-&root; user, + these files will be owned by the user. The file system records the + owner by its UID, and the UID of a normal user in the host distro is + not assigned in LFS. So the files will be left owned by an unnamed UID + in the final LFS system. If you won't assign the same UID for your user + in the LFS system, change the owners of these files to &root; now to + avoid this issue: + +chown root:root $LFS/sources/* + From 6582ddc527ff5959daf6dce5cb16a2c42678f7c5 Mon Sep 17 00:00:00 2001 From: Xi Ruoyao Date: Sun, 2 Oct 2022 21:02:16 +0800 Subject: [PATCH 6/6] pkgmgt: fix two typos --- chapter08/pkgmgt.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/chapter08/pkgmgt.xml b/chapter08/pkgmgt.xml index 5d9477e80..60c472ad4 100644 --- a/chapter08/pkgmgt.xml +++ b/chapter08/pkgmgt.xml @@ -94,7 +94,7 @@ libfoo.so.1.24), you should remove the library file from the previously installed version (libfoo.so.1.25 in this case). - Otherwise, a ldconfig command (invokeed by yourself from the command + Otherwise, a ldconfig command (invoked by yourself from the command line, or by the installation of some package) will reset the symlink libfoo.so.1 to point to the old library file because it seems to be a newer @@ -107,7 +107,7 @@ (especially, a security vulnerability) is fixed, all running programs linked to the shared library should be restarted. The following command, run as root after - the update is cmplete, will list which processes are using the old versions of those libraries + the update is complete, will list which processes are using the old versions of those libraries (replace libfoo with the name of the library):