diff --git a/chapter01/changelog.xml b/chapter01/changelog.xml index 4cddeb7cd..cf55f3297 100644 --- a/chapter01/changelog.xml +++ b/chapter01/changelog.xml @@ -36,6 +36,15 @@ --> + + April 13, 2006 + + + [archaic] - Merged the udev_update branch to trunk. + + + + April 12, 2006 @@ -43,9 +52,6 @@ [jhuntwork] - Rewrote section explaining IP Addresses. Thanks Bryan Kadzban and Bruce Dubbs. Resolves Ticket 1663. - - [jhuntwork] - Adjust some redundant text in Berkeley DB page. - [jhuntwork] - Added a pointer to GDBM in Berkeley DB page. Also added explanatory text concerning why LFS chose Debian's @@ -69,6 +75,19 @@ + + April 8, 2006 + + + [jhuntwork] - Added a command to create an empty /etc/mtab file early + in chapter 6. This avoids testsuite failures in e2fsprogs and possibly other + programs that expect /etc/mtab to be present. Explanation from Dan Nicholson, + slightly modified. Also merged the 'Creating Essential Symlinks' section with + 'Creating passwd, group and log Files'. + + + + April 6, 2006 @@ -82,12 +101,31 @@ + + April 2, 2006 + + + [archaic] - Moved the chowning of /tools to the end of chapter 5 + and rewrote note about backing up or re-using /tools. Moved the + mounting of kernel filesystems before pkgmgt page and rewrote the page + to mount --bind /dev and mount all other kernel filesystems while + outside chroot. Rewrote note about re-entering chroot and remounting + kernel filesystems. Removed /dev from the list of dirs created in + chroot and added it before chroot. + + + + March 30, 2006 [ken] - Correct my erroneous comment about UTF-8 locales in - Man-DB. Thanks to Alexander for explaining it. + Man-DB. Thanks to Alexander for explaining it. + + + [ken] - upgraded to Linux-2.6.16.1, Iproute2-2.6.16-060323, + and Udev-088. @@ -97,20 +135,33 @@ [ken] - Upgrade to shadow-4.0.15 and add convert-mans script - to convert its UTF-8 man pages. Thanks to Alexander and Archaic for - the script and commands. Fixes tickets #1748 and #1750. + to convert its UTF-8 man pages. Thanks to Alexander and Archaic for + the script and commands. Fixes tickets #1748 and #1750. - March 22, 2006 - - - [archaic] - Updated to lfs-bootscripts-20060321. - - - + March 22, 2006 + + + [archaic] - Updated to + lfs-bootscripts-udev_update-20060321. + + + + + + March 21, 2006 + + + [archaic] - Updated the bootscripts. Removed references to + hotplug and the bootscripts udev patch. Removed reference to + udevstart. Added text and commands for generating Udev bug reports. + + + + March 18, 2006 @@ -163,12 +214,32 @@ [matthew] - Upgrade to Man-pages 2.25. + + [matthew] - Remove an example of poor Udev support as it + does not apply to the kernel used in the book. Thanks to Alexander + Patrakov. + + + [matthew] - Upgrade to Linux 2.6.15.6. + + + [matthew] - Upgrade to udev-087. + + + [matthew] - Udev's run_program rules require a null device to be + present at an early stage, so create one in /lib/udev/devices. + March 7, 2006 + + [matthew] - Update Udev rules file to load SCSI modules and + upload firmware to devices that need it. Improve explanations of + device and module handling. Thanks to Alexander Patrakov. + [archaic] - Replaced the debian-specific groff patch with an LFS-style patch. @@ -189,6 +260,10 @@ March 1, 2006 + + [archaic] - Create the Udev directories before creating the + symlinks. + [jhuntwork] - Added a description of perl configure flags that help perl deal with a lack of groff. Thanks Dan Nicholson. @@ -209,6 +284,11 @@ February 20, 2006 + + [matthew] - Use non-deprecated format for accessing MODALIAS + keys in the Udev rules file, and prevent the "$" from being + expanded by the shell. + [matthew] - Add patches 009 and 010 from Bash upstream. @@ -225,6 +305,16 @@ [matthew] - Upgrade Perl libc patch to prevent Perl from trying to find headers on the host system. Fixes bug 1695. + + [matthew] - Expand the Udev module handling rule to run for + every subsystem, not just USB. + + + [matthew] - Upgrade to Linux 2.6.15.4. + + + [matthew] - Upgrade to Udev 085. + [matthew] - Install Sed's HTML documentation by using --enable-html instead of editing the Makefile. Thanks to Greg Schafer @@ -256,6 +346,13 @@ [matthew] - Add the verbose parameter to a couple of commands in Linux-Libc-Headers and DB. + + [matthew] - Create udev specific directories in udev's + instructions instead of the more generic creatingdirs.xml. Add + "pts" and "shm" directories to + /lib/udev/devices so that they + can be mounted successfully at boot time. + @@ -269,6 +366,62 @@ + + February 8, 2006 + + + [matthew] - Rewrite the majority of chapter07/udev.xml to + reflect the new configuration for handling dynamic device naming and + module loading. + + + + + + February 3, 2006 + + + [matthew] - Create the + /lib/firmware directory that + can be used by Udev's firmware_helper utility. + + + + [matthew] - Add descriptions of Udev's helper binaries. + + + [manuel] - Add udev bootscript patch to whatsnew. Removed + hotplug from list of packages to download. + + + [ken] - Add udev bootscript patch to list of patches to + download. + + + [ken] - Correct the size of the udev tarball. + + + + + + February 2, 2006 + + + [matthew] - Upgrade to Udev-084 and build all its extras to + enable custom rules to be written more easily. Also, change the + rules file to handle kernel module loading and patch the udev + bootscript to work with this version of udev. + + + [matthew] - Remove the hotplug package and related bootscript + Udev will now handle device creation and module loading. + + + [matthew] - Upgrade to Linux-2.6.15.2. + + + + January 30, 2006 diff --git a/chapter01/whatsnew.xml b/chapter01/whatsnew.xml index 9f4e0d79e..f3054097f 100644 --- a/chapter01/whatsnew.xml +++ b/chapter01/whatsnew.xml @@ -91,18 +91,15 @@ - IANA-Etc &iana-etc-version; - + @@ -269,6 +266,9 @@ glibc-2.3.4-fix_test-1.patch + + hotplug-2004-09-23 + inetutils-1.4.2-kernel_headers-1.patch diff --git a/chapter03/packages.xml b/chapter03/packages.xml index da1489765..8fe04e4fb 100644 --- a/chapter03/packages.xml +++ b/chapter03/packages.xml @@ -242,14 +242,6 @@ - - Hotplug (&hotplug-version;) - 40 KB: - - Download: - - - Iana-Etc (&iana-etc-version;) - 174 KB: @@ -270,7 +262,7 @@ - IPRoute2 (&iproute2-version;) - 291 KB: + IPRoute2 (&iproute2-version;) - 377 KB: Home page: @@ -315,7 +307,7 @@ - Linux (&linux-version;) - 36,522 KB: + Linux (&linux-version;) - 39,884 KB: Home page: Download: - Udev (&udev-version;) - 427 KB: + Udev (&udev-version;) - 185 KB: Home page: diff --git a/chapter03/patches.xml b/chapter03/patches.xml index 9a6132cbc..3bb1068b4 100644 --- a/chapter03/patches.xml +++ b/chapter03/patches.xml @@ -138,7 +138,7 @@ - Linux kernel UTF-8 Composing Patch - 3 KB: + Linux kernel UTF-8 Composing Patch - 11 KB: diff --git a/chapter05/changingowner.xml b/chapter05/changingowner.xml new file mode 100644 index 000000000..b80ebb1b4 --- /dev/null +++ b/chapter05/changingowner.xml @@ -0,0 +1,46 @@ + + + %general-entities; +]> + + + + + Changing Ownership + + + The commands in the remainder of this book must be performed while + logged in as user root and no + longer as user lfs. Also, double + check that $LFS is set in root's environment. + + + Currently, the /tools directory + is owned by the user lfs, a user + that exists only on the host system. If the /tools directory is kept as is, the files are + owned by a user ID without a corresponding account. This is dangerous because + a user account created later could get this same user ID and would own the + /tools directory and all the files + therein, thus exposing these files to possible malicious manipulation. + + To avoid this issue, you could add the lfs user to the new LFS system later when + creating the /etc/passwd file, taking care to assign it + the same user and group IDs as on the host system. Better yet, change the + ownership of the /tools directory to + user root by running the following + command: + +chown -R root:root /tools + + Although the /tools directory can + be deleted once the LFS system has been finished, it can be retained to build + additional LFS systems of the same book version. How best + to backup /tools is a matter of + personal preference and is left as an exercise for the reader. + + diff --git a/chapter05/chapter05.xml b/chapter05/chapter05.xml index 02739479f..df3d854bb 100644 --- a/chapter05/chapter05.xml +++ b/chapter05/chapter05.xml @@ -42,5 +42,6 @@ + diff --git a/chapter06/changingowner.xml b/chapter06/changingowner.xml deleted file mode 100644 index 83deca414..000000000 --- a/chapter06/changingowner.xml +++ /dev/null @@ -1,40 +0,0 @@ - - - %general-entities; -]> - - - - - Changing Ownership - - Currently, the /tools directory - is owned by the user lfs, a user - that exists only on the host system. Although the /tools directory can be deleted once the LFS - system has been finished, it can be retained to build additional LFS systems. - If the /tools directory is kept as is, - the files are owned by a user ID without a corresponding account. This is - dangerous because a user account created later could get this same user ID - and would own the /tools directory - and all the files therein, thus exposing these files to possible malicious - manipulation. - - To avoid this issue, add the lfs - user to the new LFS system later when creating the - /etc/passwd file, taking care to assign it the same user - and group IDs as on the host system. Alternatively, assign the contents of - the /tools directory to user - root by running the following - command: - -chown -R 0:0 /tools - - The command uses 0:0 instead of - root:root, because chown - is unable to resolve the name root until the - passwd file has been created. - - diff --git a/chapter06/chapter06.xml b/chapter06/chapter06.xml index 4186fd7bb..5715d6be9 100644 --- a/chapter06/chapter06.xml +++ b/chapter06/chapter06.xml @@ -12,14 +12,11 @@ Installing Basic System Software - + - - - @@ -53,7 +50,6 @@ - diff --git a/chapter06/chroot.xml b/chapter06/chroot.xml index ca3e86a92..ea213033e 100644 --- a/chapter06/chroot.xml +++ b/chapter06/chroot.xml @@ -44,16 +44,18 @@ reason, hashing is switched off by passing the +h option to bash. - It is important that all the commands throughout the remainder of this - chapter and the following chapters are run from within the chroot environment. - If you leave this environment for any reason (rebooting for example), remember - to first mount the proc and - devpts file systems (discussed - in the previous section) and enter chroot again before continuing with the - installations. - Note that the bash prompt will say I have no name! This is normal because the /etc/passwd file has not been created yet. + + It is important that all the commands throughout the remainder of this + chapter and the following chapters are run from within the chroot + environment. If you leave this environment for any reason (rebooting for + example), ensure that the virtual kernel filesystems are mounted as + explained in and and enter chroot again before continuing + with the installation. + + diff --git a/chapter06/createfiles.xml b/chapter06/createfiles.xml index ae22a241d..0cfc7596f 100644 --- a/chapter06/createfiles.xml +++ b/chapter06/createfiles.xml @@ -8,7 +8,31 @@ - Creating Essential Symlinks + Creating Essential Files and Symlinks + + + /etc/passwd + + + + /etc/group + + + + /var/run/utmp + + + + /var/log/btmp + + + + /var/log/lastlog + + + + /var/log/wtmp + Some programs use hard-wired paths to programs which do not exist yet. In order to satisfy these programs, create a number of symbolic links which will be @@ -20,4 +44,94 @@ ln -sv /tools/bin/perl /usr/bin ln -sv /tools/lib/libgcc_s.so{,.1} /usr/lib ln -sv bash /bin/sh + A proper Linux system maintains a list of the mounted file systems in + the file /etc/mtab. Normally, this file would be + created when we mount a new file system. Since we will not be mounting any + file systems inside our chroot environment, create an empty file for + utilities that expect the presence of /etc/mtab: + +touch /etc/mtab + + In order for user root to be + able to login and for the name root to be recognized, there + must be relevant entries in the /etc/passwd and + /etc/group files. + + Create the /etc/passwd file by running the following + command: + +cat > /etc/passwd << "EOF" +root:x:0:0:root:/root:/bin/bash +EOF + + The actual password for root + (the x used here is just a placeholder) will be set later. + + Create the /etc/group file by running the following + command: + +cat > /etc/group << "EOF" +root:x:0: +bin:x:1: +sys:x:2: +kmem:x:3: +tty:x:4: +tape:x:5: +daemon:x:6: +floppy:x:7: +disk:x:8: +lp:x:9: +dialout:x:10: +audio:x:11: +video:x:12: +utmp:x:13: +usb:x:14: +cdrom:x:15: +EOF + + The created groups are not part of any standard—they are groups + decided on in part by the requirements of the Udev configuration in this + chapter, and in part by common convention employed by a number of existing + Linux distributions. The Linux Standard Base (LSB, available at ) recommends only that, besides the group + root with a Group ID (GID) of 0, + a group bin with a GID of 1 be + present. All other group names and GIDs can be chosen freely by the system + administrator since well-written programs do not depend on GID numbers, but + rather use the group's name. + + To remove the I have no name! prompt, start a new + shell. Since a full Glibc was installed in and the + /etc/passwd and /etc/group + files have been created, user name and group name resolution will now + work. + +exec /tools/bin/bash --login +h + + Note the use of the +h directive. This tells + bash not to use its internal path hashing. Without this + directive, bash would remember the paths to binaries it has + executed. To ensure the use of the newly compiled binaries as soon as they are + installed, the +h directive will be used for the duration + of this chapter. + + The login, agetty, and + init programs (and others) use a number of log + files to record information such as who was logged into the system and + when. However, these programs will not write to the log files if they + do not already exist. Initialize the log files and give them + proper permissions: + +touch /var/run/utmp /var/log/{btmp,lastlog,wtmp} +chgrp -v utmp /var/run/utmp /var/log/lastlog +chmod -v 664 /var/run/utmp /var/log/lastlog + + The /var/run/utmp file records the users + that are currently logged in. The /var/log/wtmp + file records all logins and logouts. The + /var/log/lastlog file records when + each user last logged in. The /var/log/btmp file + records the bad login attempts. + diff --git a/chapter06/creatingdirs.xml b/chapter06/creatingdirs.xml index b9a269ebc..4e602b356 100644 --- a/chapter06/creatingdirs.xml +++ b/chapter06/creatingdirs.xml @@ -13,7 +13,7 @@ It is time to create some structure in the LFS file system. Create a standard directory tree by issuing the following commands: -install -dv /{bin,boot,dev,etc/opt,home,lib,mnt} +install -dv /{bin,boot,etc/opt,home,lib,mnt} install -dv /{sbin,srv,usr/local,var,opt} install -dv /root -m 0750 install -dv /tmp /var/tmp -m 1777 diff --git a/chapter06/devices.xml b/chapter06/devices.xml deleted file mode 100644 index 51821fe84..000000000 --- a/chapter06/devices.xml +++ /dev/null @@ -1,93 +0,0 @@ - - - %general-entities; -]> - - - - - Populating /dev - - - /dev/* - - - - Creating Initial Device Nodes - - When the kernel boots the system, it requires the presence of a few - device nodes, in particular the console - and null devices. The device nodes - will be created on the hard disk so that they are available before - udev has been started, and additionally when Linux is - started in single user mode (hence the restrictive permissions on - console). Create the devices by - running the following commands: - -mknod -m 600 /dev/console c 5 1 -mknod -m 666 /dev/null c 1 3 - - - - - Mounting tmpfs and Populating /dev - - The recommended method of populating the /dev directory with devices is to mount a - virtual filesystem (such as tmpfs) - on the /dev directory, and allow the - devices to be created dynamically on that virtual filesystem as they are - detected or accessed. This is generally done during the boot process. Since - this new system has not been booted, it is necessary to do what the - LFS-Bootscripts package would otherwise do by mounting /dev: - -mount -nvt tmpfs none /dev - - The Udev package is what actually creates the devices in the /dev directory. Since it will not be installed - until later on in the process, manually create the minimal set of device nodes - needed to complete the building of this system: - -mknod -m 622 /dev/console c 5 1 -mknod -m 666 /dev/null c 1 3 -mknod -m 666 /dev/zero c 1 5 -mknod -m 666 /dev/ptmx c 5 2 -mknod -m 666 /dev/tty c 5 0 -mknod -m 444 /dev/random c 1 8 -mknod -m 444 /dev/urandom c 1 9 -chown -v root:tty /dev/{console,ptmx,tty} - - There are some symlinks and directories required by LFS that are - created during system startup by the LFS-Bootscripts package. Since this - is a chroot environment and not a booted environment, those symlinks and - directories need to be created here: - -ln -sv /proc/self/fd /dev/fd -ln -sv /proc/self/fd/0 /dev/stdin -ln -sv /proc/self/fd/1 /dev/stdout -ln -sv /proc/self/fd/2 /dev/stderr -ln -sv /proc/kcore /dev/core -mkdir -v /dev/pts -mkdir -v /dev/shm - - Finally, mount the proper virtual (kernel) file systems on the - newly-created directories: - -mount -vt devpts -o gid=4,mode=620 none /dev/pts -mount -vt tmpfs none /dev/shm - - The mount commands executed above may result - in the following warning message: - -can't open /etc/fstab: No such file or directory. - - This file—/etc/fstab—has not - been created yet but is also not required for the file systems to be - properly mounted. As such, the warning can be safely ignored. - - - - diff --git a/chapter06/hotplug.xml b/chapter06/hotplug.xml deleted file mode 100644 index d66e0c7e7..000000000 --- a/chapter06/hotplug.xml +++ /dev/null @@ -1,223 +0,0 @@ - - - %general-entities; -]> - - - - - Hotplug-&hotplug-version; - - - Hotplug - - - - - - <para>The Hotplug package contains scripts that react upon hotplug events - generated by the kernel. Such events correspond to every change in the kernel - state visible in the <systemitem class="filesystem">sysfs</systemitem> - filesystem, e.g., the addition and removal of hardware. This package also - detects existing hardware during boot and inserts the relevant modules into the - running kernel.</para> - - <segmentedlist> - <segtitle>&buildtime;</segtitle> - <segtitle>&diskspace;</segtitle> - - <seglistitem> - <seg>0.01 SBU</seg> - <seg>460 KB</seg> - </seglistitem> - </segmentedlist> - - <segmentedlist> - <segtitle>&dependencies;</segtitle> - - <seglistitem> - <seg>Bash, Coreutils, Findutils, Gawk, and Make</seg> - </seglistitem> - </segmentedlist> - - </sect2> - - <sect2 role="installation"> - <title>Installation of Hotplug - - This package does not come with a test suite. - - Install the Hotplug package: - -make install - - Copy a file that the install target omits. - -cp -v etc/hotplug/pnp.distmap /etc/hotplug - - Remove the init script that Hotplug installs since we are going to be - using the script included in the LFS-Bootscripts package: - -rm -rfv /etc/init.d - - Network device hotplugging is not yet supported by the LFS-Bootscripts - package. For that reason, remove the network hotplug agent: - -rm -fv /etc/hotplug/net.agent - - Create a directory for storing firmware that can be loaded by - hotplug: - -mkdir -v /lib/firmware - - - - - - Contents of Hotplug - - - Installed program - Installed scripts - Installed files - - - hotplug - /etc/hotplug/*.rc, /etc/hotplug/*.agent - /etc/hotplug/hotplug.functions, /etc/hotplug/blacklist, - /etc/hotplug/{pci,usb}, /etc/hotplug/usb.usermap, /etc/hotplug.d, - and /var/log/hotplug/events - - - - - Short Descriptions - - - - - hotplug - - This script is called by default by the Linux kernel when - something changes in its internal state (e.g., a new device is - added or an existing device is removed) - - hotplug - - - - - - /etc/hotplug/*.rc - - These scripts are used for cold plugging, i.e., detecting and - acting upon hardware already present during system startup. They are - called by the hotplug initscript included in - the LFS-Bootscripts package. The *.rc scripts try - to recover hotplug events that were lost during system boot because, - for example, the root filesystem was not mounted by the kernel - - /etc/hotplug/*.rc - - - - - - /etc/hotplug/*.agent - - These scripts are called by hotplug in response - to different types of hotplug events generated by the kernel. Their - action is to insert corresponding kernel modules and call any - user-provided scripts - - /etc/hotplug/*.agent - - - - - - /etc/hotplug/blacklist - - This file contains the list of modules that should never be - inserted into the kernel by the Hotplug scripts - - /etc/hotplug/blacklist - - - - - - /etc/hotplug/hotplug.functions - - This file contains common functions used by other scripts in the - Hotplug package - - /etc/hotplug/hotplug.functions - - - - - - /etc/hotplug/{pci,usb} - - These directories contain user-written handlers for hotplug - events - - /etc/hotplug/{pci,usb} - - - - - - /etc/hotplug/usb.usermap - - This file contains rules that determine which user-defined handlers to - call for each USB device, based on its vendor ID and other - attributes - - /etc/hotplug/usb.usermap - - - - - - /etc/hotplug.d - - This directory contains programs (or symlinks to them) that are - interested in receiving hotplug events. For example, Udev puts its - symlink here during installation - - /etc/hotplug.d - - - - - - /lib/firmware - - This directory contains the firmware for devices that need to - have their firmware loaded before use - - /lib/firmware - - - - - - /var/log/hotplug/events - - This file contains all the events that hotplug - has called since bootup - - /var/log/hotplug/events - - - - - - - - - diff --git a/chapter06/introduction.xml b/chapter06/introduction.xml index 5e9cfd5c3..588d84780 100644 --- a/chapter06/introduction.xml +++ b/chapter06/introduction.xml @@ -55,11 +55,4 @@ there is a list of programs and libraries (along with brief descriptions of these) that the package installs. - - At this point, you may wish to keep your finished temporary - tools for use in future LFS builds by creating a tarball of the - /tools directory and - storing it in a safe location. - - diff --git a/chapter06/iproute2.xml b/chapter06/iproute2.xml index 84e4244e0..fdf93aa08 100644 --- a/chapter06/iproute2.xml +++ b/chapter06/iproute2.xml @@ -25,8 +25,8 @@ &diskspace; - 0.1 SBU - 4.3 MB + 0.2 SBU + 4.8 MB diff --git a/chapter06/kernfs.xml b/chapter06/kernfs.xml index 2bdf9f9c3..3c9e68c0b 100644 --- a/chapter06/kernfs.xml +++ b/chapter06/kernfs.xml @@ -8,33 +8,72 @@ - Mounting Virtual Kernel File Systems + Preparing Virtual Kernel File Systems - Various file systems exported by the kernel are used to communicate to and - from the kernel itself. These file systems are virtual in that no disk space is - used for them. The content of the file systems resides in memory. + + /dev/* + - Begin by creating directories onto which the file systems will be - mounted: + Various file systems exported by the kernel are used to communicate to + and from the kernel itself. These file systems are virtual in that no disk + space is used for them. The content of the file systems resides in + memory. -mkdir -pv $LFS/{proc,sys} + Begin by creating directories onto which the file systems will be + mounted: - Now mount the file systems: +mkdir -pv $LFS/{dev,proc,sys} -mount -vt proc proc $LFS/proc + + Creating Initial Device Nodes + + When the kernel boots the system, it requires the presence of a few + device nodes, in particular the console and null devices. The device nodes will be created + on the hard disk so that they are available before udev + has been started, and additionally when Linux is started in single user mode + (hence the restrictive permissions on console). Create the devices by running the + following commands: + +mknod -m 600 $LFS/dev/console c 5 1 +mknod -m 666 $LFS/dev/null c 1 3 + + + + + Mounting and Populating /dev + + The recommended method of populating the /dev directory with devices is to mount a + virtual filesystem (such as tmpfs) on the /dev directory, and allow the devices to be + created dynamically on that virtual filesystem as they are detected or + accessed. This is generally done during the boot process by Udev. Since + this new system does not yet have Udev and has not yet been booted, it is + necessary to mount and populate /dev manually. This is accomplished by bind + mounting the host system's /dev + directory. A bind mount is a special type of mount that allows you to + create a mirror of a directory or mount point to some other location. Use + the following command to achieve this: + +mount --bind /dev $LFS/dev + + + + + Mounting Virtual Kernel File Systems + + Now mount the remaining virtual kernel filesystems: + +mount -vt devpts devpts $LFS/dev/pts +mount -vt tmpfs shm $LFS/dev/shm +mount -vt proc proc $LFS/proc mount -vt sysfs sysfs $LFS/sys - Remember that if for any reason you stop working on the LFS - system and start again later, it is important to check that these file - systems are mounted again before entering the chroot - environment. - - Additional file systems will soon be mounted from within the - chroot environment. To keep the host up to date, perform a fake - mount for each of these now: - -mount -vft tmpfs tmpfs $LFS/dev -mount -vft tmpfs tmpfs $LFS/dev/shm -mount -vft devpts -o gid=4,mode=620 devpts $LFS/dev/pts + diff --git a/chapter06/pkgmgt.xml b/chapter06/pkgmgt.xml index 76ea123e2..4ce94106d 100644 --- a/chapter06/pkgmgt.xml +++ b/chapter06/pkgmgt.xml @@ -39,14 +39,6 @@ the Hints subproject and see if one of them fits your need. - - As no particular package management technique is mentioned in LFS, - the commands in the remainder of this book must be performed while logged in - as user root and no longer as user - lfs. Also, double check that - $LFS is set. - - Upgrade Issues diff --git a/chapter06/udev.xml b/chapter06/udev.xml index 96d2ec579..f78ab1cec 100644 --- a/chapter06/udev.xml +++ b/chapter06/udev.xml @@ -26,7 +26,7 @@ 0.1 SBU - 3.8 MB + 4.8 MB @@ -43,19 +43,31 @@ Installation of Udev + Create some devices and directories that Udev cannot handle due to + them being required very early in the boot process: + +install -dv /lib/{firmware,udev/devices/{pts,shm}} +mknod -m0666 /lib/udev/devices/null c 1 3 +ln -sv /proc/self/fd /lib/udev/devices/fd +ln -sv /proc/self/fd/0 /lib/udev/devices/stdin +ln -sv /proc/self/fd/1 /lib/udev/devices/stdout +ln -sv /proc/self/fd/2 /lib/udev/devices/stderr +ln -sv /proc/kcore /lib/udev/devices/core + Compile the package: -make EXTRAS=extras/run_directory +make EXTRAS="extras/ata_id extras/cdrom_id extras/edd_id \ + extras/firmware extras/floppy extras/scsi_id \ + extras/usb_id extras/volume_id" The meaning of the make option: - EXTRAS=extras/run_directory + EXTRAS=... - This builds the udev_run_devd and - udev_run_hotplugd binaries, which are required - for correct handling of hotpluggable devices. + This builds several helper binaries that can aid in writing custom + Udev rules. @@ -66,7 +78,10 @@ Install the package: -make DESTDIR=/ EXTRAS=extras/run_directory install +make DESTDIR=/ \ + EXTRAS="extras/ata_id extras/cdrom_id extras/edd_id \ + extras/firmware extras/floppy extras/scsi_id \ + extras/usb_id extras/volume_id" install The meaning of the make parameter: @@ -87,16 +102,78 @@ cp -v ../&udev-config-file; /etc/udev/rules.d/25-lfs.rules + Create some rules that work around broken sysfs attribute creation + timing in linux-2.6.15: + +cat >> /etc/udev/rules.d/10-wait_for_sysfs.rules << "EOF" +ACTION=="add", DEVPATH=="/devices/*", ENV{PHYSDEVBUS}=="?*", WAIT_FOR_SYSFS="bus" +ACTION=="add", SUBSYSTEM=="net", WAIT_FOR_SYSFS="address" +EOF + Install the documentation that explains how to create Udev rules: install -m644 -D -v docs/writing_udev_rules/index.html /usr/share/doc/udev-&udev-version;/index.html - - - Run the udevstart program to create our full - complement of device nodes. + -/sbin/udevstart + When Udev is started by the LFS-Bootscripts, a replay of all kernel + device events happens. These events tell Udev what devices exist. + Sometimes the Udev bootscript doesn't wait long enough for + udevd to process all of the replayed events and + consequently the devices for those missed events are not created before the + script exits. Since udevd is still running in the + background, the devices will be created a few milliseconds later, but the + next bootscript to run may require a device to exist before it has been + created. To avoid such missed events, and to avoid hardcoding an overly + long wait time, It is recommended that you run the following commands to + aid the LFS development team in debugging these missed events and finding + an acceptable solution more quickly. + + First, create a simple C file: + +cat > bug.c << EOF +/* Simple event recorder */ +#define _GNU_SOURCE +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#include <unistd.h> +#include <stdlib.h> +#include <argz.h> +int main(int argc, char * argv[]) +{ + char * envz; + size_t len; + int bug; + bug = open("/dev/bug", O_WRONLY | O_APPEND); + if (bug == -1) + return 0; + setenv("_SEPARATOR", "--------------------------------------", 1); + argz_create(environ, &envz, &len); + argz_stringify(envz, len, '\n'); + envz[len-1]='\n'; + write(bug, envz, len); + close(bug); + free(envz); + return 0; +} +EOF + + Now compile it: + +gcc -o /lib/udev/bug bug.c + + The next step adds a simple logging rule to run this program. + +cat > /etc/udev/rules.d/90-bug.rules << "EOF" +ACTION=="add", RUN+="bug" +EOF + + When booting the new LFS system, if any events are missed, a warning + message will appear and a /dev/bugreport file will be + created. The warning message will tell you where to send feedback. + + @@ -108,8 +185,9 @@ Installed directory - udev, udev_run_devd, udev_run_hotplugd, udevcontrol, udevd, - udevinfo, udevmonitor, udevsend, udevstart, and udevtest + ata_id, cdrom_id, create_floppy_devices, edd_id, firmware_helper, + scsi_id, udevcontrol, udevd, udevinfo, udevmonitor, udevtest, usb_id + and vol_id /etc/udev @@ -119,38 +197,66 @@ - - udev + + ata_id - Creates device nodes in /dev - or renames network interfaces (not in LFS) in response to hotplug - events - - udev + Provides Udev with a unique string and + additional information (uuid, label) for an ATA drive + + ata_id - - udev_run_devd + + cdrom_id - Executes programs and scripts in the /etc/dev.d/ directory in response to - hotplug events - - udev_run_devd + Provides Udev with the capabilities of a + CD-ROM or DVD-ROM drive + + cdrom_id - - udev_run_hotplugd + + create_floppy_devices - Executes programs and scripts in the /etc/hotplug.d/ directory in response - to hotplug events - - udev_run_hotplugd + Creates all possible floppy devices based on the CMOS type + + create_floppy_devices + + + + + + edd_id + + Provides Udev with the EDD ID for a BIOS disk drive + + edd_id + + + + + + firmware_helper + + Uploads firmware to devices + + firmware_helper + + + + + + scsi_id + + Provides Udev with a unique SCSI identifier + based on the data returned from sending a SCSI INQUIRY command to + the specified device + + scsi_id @@ -169,8 +275,9 @@ udevd - A daemon that reorders hotplug events before submitting them to - udev, thus avoiding various race conditions + A daemon that listens for uevents on the netlink socket, + creates devices and runs the configured external programs in + response to these uevents udevd @@ -180,7 +287,7 @@ udevinfo - Allows users to query the udev database for + Allows users to query the Udev database for information on any device currently present on the system; it also provides a way to query any device in the sysfs tree to help create udev @@ -194,56 +301,52 @@ udevmonitor - Prints the event received from the kernel and the event which - udev sends out after rule processing + Prints the event received from the kernel and the environment + which Udev sends out after rule processing udevmonitor - - udevsend - - Delivers hotplug events to udevd - - udevsend - - - - - - udevstart - - Creates device nodes in /dev - that correspond to drivers compiled directly into the kernel; it - performs that task by simulating hotplug events presumably dropped by - the kernel before invocation of this program (e.g., because the root - filesystem has not been mounted) and submitting such synthetic hotplug - events to udev - - udevstart - - - - udevtest - Simulates a udev run for the given device, - and prints out the name of the node the real udev - would have created or (not in LFS) the name of the renamed network - interface + Simulates a uevent for the given device, and prints out the + name of the node the real udevd would have created, + or the name of the renamed network interface udevtest + + usb_id + + Provides Udev with information about USB + devices + + usb_id + + + + + + vol_id + + Provides Udev with the label and uuid of a + filesystem + + vol_id + + + + /etc/udev - Contains udev configuation files, + Contains Udev configuation files, device permissions, and rules for device naming /etc/udev diff --git a/chapter07/bootscripts.xml b/chapter07/bootscripts.xml index 775215e7e..a5c589c76 100644 --- a/chapter07/bootscripts.xml +++ b/chapter07/bootscripts.xml @@ -56,7 +56,7 @@ Installed scripts - checkfs, cleanfs, console, functions, halt, hotplug, ifdown, ifup, + checkfs, cleanfs, console, functions, halt, ifdown, ifup, localnet, mountfs, mountkernfs, network, rc, reboot, sendsignals, setclock, static, swap, sysklogd, template, and udev @@ -125,16 +125,6 @@ - - hotplug - - Loads modules for system devices - - hotplug - - - - ifdown diff --git a/chapter07/network.xml b/chapter07/network.xml index c09f92431..ac6082271 100644 --- a/chapter07/network.xml +++ b/chapter07/network.xml @@ -23,6 +23,48 @@ symlinks from all run-level directories (/etc/rc.d/rc*.d). + + Creating stable names for network interfaces + + Instructions in this section are optional if you have only one + network card. + + With Udev and modular network drivers, the network interface numbering + is not persistent across reboots by default, because the drivers are loaded + in parallel and, thus, in random order. For example, on a computer having + two network cards made by Intel and Realtek, the network card manufactured + by Intel may become eth0 and the + Realtek card becomes eth1. In some + cases, after a reboot the cards get renumbered the other way around. To + avoid this, create Udev rules that assign stable names to network cards + based on their MAC addresses. + + First, find out the MAC addresses of your network cards: + +grep -H . /sys/class/net/*/address + + For each network card (but not for the loopback interface), + invent a descriptive name, such as realtek, and create + Udev rules similar to the following: + +cat > /etc/udev/rules.d/26-network.rules << "EOF" +ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="52:54:00:12:34:56", NAME="realtek" +ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="00:a0:c9:78:9a:bc", NAME="intel" +EOF + + These rules will always rename the network cards to + realtek and intel, independently of the + original numbering provided by the kernel. Use these names instead of + eth0 in the network interface configuration files created + below. + + + Persistent names must be different from the default network + interface names assigned by the kernel. + + + + Creating Network Interface Configuration Files diff --git a/chapter07/udev.xml b/chapter07/udev.xml index 5f98e6139..7d4bcc495 100644 --- a/chapter07/udev.xml +++ b/chapter07/udev.xml @@ -23,13 +23,15 @@ Linux systems in general traditionally use a static device creation method, whereby a great many device nodes are created under /dev (sometimes literally thousands of nodes), - regardless of whether the corresponding hardware devices actually exist. This is - typically done via a MAKEDEV script, which contains a number - of calls to the mknod program with the relevant major and - minor device numbers for every possible device that might exist in the world. - Using the Udev method, only those devices which are detected by the kernel get - device nodes created for them. Because these device nodes will be created each - time the system boots, they will be stored on a MAKEDEV script, which contains a + number of calls to the mknod program with the relevant + major and minor device numbers for every possible device that might exist in + the world. + + Using the Udev method, only those devices which are detected by the + kernel get device nodes created for them. Because these device nodes will be + created each time the system boots, they will be stored on a tmpfs file system (a virtual file system that resides entirely in system memory). Device nodes do not require much space, so the memory that is used is negligible. @@ -50,160 +52,278 @@ naming, was perhaps the most critical. It is generally accepted that if device names are allowed to be configurable, then the device naming policy should be up to a system administrator, not imposed on them by any - particular developer(s). The devfs - file system also suffers from race conditions that are inherent in its design - and cannot be fixed without a substantial revision to the kernel. It has also - been marked as deprecated due to a lack of recent maintenance. + particular developer(s). The devfs file system also suffers from race + conditions that are inherent in its design and cannot be fixed without a + substantial revision to the kernel. It has also been marked as deprecated + due to a lack of recent maintenance. - With the development of the unstable 2.5 kernel tree, later released as - the 2.6 series of stable kernels, a new virtual filesystem called sysfs came to be. The job of sysfs is to export a view of the system's - hardrware configuration to userspace processes. With this userspace-visible - representation, the possibility of seeing a userspace replacement for - devfs became much more - realistic. + With the development of the unstable 2.5 kernel tree, later released + as the 2.6 series of stable kernels, a new virtual filesystem called + sysfs came to be. The job of + sysfs is to export a view of + the system's hardware configuration to userspace processes. With this + userspace-visible representation, the possibility of seeing a userspace + replacement for devfs became + much more realistic. Udev Implementation - The sysfs filesystem was - mentioned briefly above. One may wonder how sysfs knows about the devices present on - a system and what device numbers should be used for them. Drivers that have - been compiled into the kernel directly register their objects with - sysfs as they are detected by - the kernel. For drivers compiled as modules, this registration will happen - when the module is loaded. Once the sysfs filesystem is mounted (on /sys), data which the built-in drivers - registered with sysfs are - available to userspace processes and to udev for device - node creation. + + Sysfs - The S10udev initscript takes care of creating - these device nodes when Linux is booted. This script starts by registering - /sbin/udevsend as a hotplug event handler. Hotplug events - (discussed below) are not usually generated during this stage, but - udev is registered just in case they do occur. The - udevstart program then walks through the /sys filesystem and creates devices under - /dev that match the descriptions. - For example, /sys/class/tty/vcs/dev contains the - string 7:0 This string is used by udevstart - to create /dev/vcs with major number - 7 and minor 0. The names and - permissions of the nodes created under the /dev directory are configured according to the - rules specified in the files within the /etc/udev/rules.d/ directory. These are - numbered in a similar fashion to the LFS-Bootscripts package. If - udev can't find a rule for the device it is creating, - it will default permissions to 660 and ownership to - root:root. + The sysfs filesystem was + mentioned briefly above. One may wonder how sysfs knows about the devices present on + a system and what device numbers should be used for them. Drivers that + have been compiled into the kernel directly register their objects with + sysfs as they are detected by + the kernel. For drivers compiled as modules, this registration will happen + when the module is loaded. Once the sysfs filesystem is mounted (on /sys), data which the built-in drivers + registered with sysfs are + available to userspace processes and to udevd for device + node creation. - Once the above stage is complete, all devices that were already present - and have compiled-in drivers will be available for use. This leads us to the - devices that have modular drivers. + - Earlier, we mentioned the concept of a hotplug event - handler. When a new device connection is detected by the kernel, - the kernel will generate a hotplug event and look at the file - /proc/sys/kernel/hotplug to determine the userspace - program that handles the device's connection. The udev - bootscript registered udevsend as this handler. When - these hotplug events are generated, the kernel will tell - udev to check the /sys filesystem for the information pertaining - to this new device and create the /dev - entry for it. + + Udev Bootscript - This brings us to one problem that exists with udev, - and likewise with devfs before it. - It is commonly referred to as the chicken and egg problem. Most - Linux distributions handle loading modules via entries in - /etc/modules.conf. Access to a device node causes the - appropriate kernel module to load. With udev, this method - will not work because the device node does not exist until the module is loaded. - To solve this, the S05modules bootscript was added to the - LFS-Bootscripts package, along with the - /etc/sysconfig/modules file. By adding module names to the - modules file, these modules will be loaded when the - computer starts up. This allows udev to detect the devices - and create the appropriate device nodes. + The S10udev initscript takes care of creating + device nodes when Linux is booted. The script starts by unsetting the + hotplug event handler from the default of /sbin/hotplug + This is done because, instead of the kernel calling out to an external + binary, udevd will listen on a netlink socket for + hotplug events that the kernel raises. The bootscript copies any static + device nodes that exist in /lib/udev/devices to /dev. This is necessary because some devices, + directories and symlinks are needed before the dynamic device handling + processes are available during the early stages of booting a system. + Creating static device nodes in + /lib/udev/devices also provides + an easy workaround for devices that are not supported by the dynamic + device handling infrastructure. The bootscript then starts the Udev + daemon, udevd, which will act on any hotplug events it + receives. Finally, the bootscript "coldplugs" any devices that + have already been registered with the kernel by forcing them to raise + hotplug events which udevd will then handle. - Note that on slower machines or for drivers that create a lot of device - nodes, the process of creating devices may take a few seconds to complete. - This means that some device nodes may not be immediately accessible. + + + + Device Node Creation + + To obtain the right major and minor number for a device, Udev relies + on the information provided by sysfs in /sys. For example, + /sys/class/tty/vcs/dev contains the string + 7:0. This string is used by udevd + to create a device node with major number 7 and minor + 0. The names and permissions of the nodes created + under the /dev directory are + determined by rules specified in the files within the /etc/udev/rules.d/ directory. These are + numbered in a similar fashion to the LFS-Bootscripts package. If + udevd can't find a rule for the device it is creating, + it will default permissions to 660 and ownership to + root:root. Documentation on the syntax of the Udev + rules configuration files are available in + /usr/share/doc/udev-&udev-version;/index.html + + + + + Module Loading + + Device drivers compiled as modules may have aliases built into them. + Aliases are visible in the output of the modinfo + program and are usually related to the bus-specific identifiers of devices + supported by a module. For example, the snd-fm801 + driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801, + and has an alias of pci:v00001319d00000801sv*sd*bc04sc01i*. + For most devices, the bus driver exports the alias of the driver that + would handle the device via sysfs. E.g., the + /sys/bus/pci/devices/0000:00:0d.0/modalias file + might contain the string + pci:v00001319d00000801sv00001319sd00001319bc04sc01i00. + The rules that LFS installs will cause udevd to call + out to /sbin/modprobe with the contents of the + MODALIAS uevent environment variable (that should be the + same as the contents of the modalias file in sysfs), + thus loading all modules whose aliases match this string after wildcard + expansion. + + In this example, this means that, in addition to + snd-fm801, the obsolete (and unwanted) + forte driver will be loaded if it is + available. See below for ways in which the loading of unwanted drivers can + be prevented. + + The kernel itself is also able to load modules for network + protocols, filesystems and NLS support on demand. + + + + + Handling Hotpluggable/Dynamic Devices + + When you plug in a device, such as a Universal Serial Bus (USB) MP3 + player, the kernel recognizes that the device is now connected and + generates a hotplug event. This hotplug event is then handled by + udevd as described above. + + - Handling Hotpluggable/Dynamic Devices + Problems with Loading Modules and Creating Devices - When you plug in a device, such as a Universal Serial Bus (USB) MP3 - player, the kernel recognizes that the device is now connected and generates - a hotplug event. If the driver is already loaded (either because it was - compiled into the kernel or because it was loaded via the - S05modules bootscript), udev will be - called upon to create the relevant device node(s) according to the - sysfs data available in - /sys. + There are a few possible problems when it comes to automatically + creating device nodes. - If the driver for the just plugged in device is available as a module but - currently unloaded, the Hotplug package will load the appropriate module - and make this device available by creating the device node(s) for it. + + A kernel module is not loaded automatically - + Udev will only load a module if it has a bus-specific alias and the + bus driver properly exports the necessary aliases to sysfs. In other cases, one should + arrange module loading by other means. With Linux-&linux-version;, Udev is + known to load properly-written drivers for PCI, USB, SCSI, SERIO and + FireWire devices. - - Problems with Creating Devices + - There are a few known problems when it comes to automatically creating - device nodes: + To determine if the device driver you require has the necessary + support for Udev, run modinfo with the module name as + the argument. Now try locating the device directory under + /sys/bus and check whether there is + a modalias file there. - 1) A kernel driver may not export its data to sysfs. + If the modalias file exists in sysfs, the driver supports the device and + can talk to it directly, but doesn't have the alias, it is a bug in the + driver. Load the driver without the help from Udev and expect the issue + to be fixed later. - This is most common with third party drivers from outside the kernel - tree. Udev will be unable to automatically create device nodes for such - drivers. Use the /etc/sysconfig/createfiles - configuration file to manually create the devices. Consult the - devices.txt file inside the kernel documentation or - the documentation for that driver to find the proper major/minor - numbers. + If there is no modalias file in the relevant + directory under /sys/bus, this + means that the kernel developers have not yet added modalias support to + this bus type. With Linux-&linux-version;, this is the case with ISA and + IDE busses. Expect this issue to be fixed in later kernel versions. - 2) A non-hardware device is required. This is most common with - the Advanced Linux Sound Architecture (ALSA) project's Open Sound - System (OSS) compatibility module. These types of devices can be - handled in one of two ways: + - + Udev is not intended to load wrapper drivers such as + snd-pcm-oss and non-hardware drivers such as + loop at all. - - Adding the module names to - /etc/sysconfig/modules - + - - Using an install line in - /etc/modprobe.conf. This tells the - modprobe command when loading this module, - also load this other module, at the same time. - For example: + + A kernel module is not loaded automatically, and Udev is not + intended to load it -install snd-pcm modprobe -i snd-pcm ; modprobe \ - snd-pcm-oss ; true + If the wrapper module only enhances the functionality + provided by some other module (e.g., snd-pcm-oss + enhances the functionality of snd-pcm by making the + sound cards available to OSS applications), configure + modprobe to load the wrapper after Udev loads the + wrapped module. To do this, add an install line in + /etc/modprobe.conf. For example: - This will cause the system to load both the - snd-pcm and snd-pcm-oss - modules when any request is made to load the driver - snd-pcm. - +install snd-pcm modprobe -i snd-pcm ; modprobe \ + snd-pcm-oss ; true - + If the module in question is not a wrapper and is useful by itself, + configure the S05modules bootscript to load this + module on system boot. To do this, add the module name to the + /etc/sysconfig/modules file on a separate line. + This works for wrapper modules too, but is suboptimal in that case. + + + + + Udev loads some unwanted module + + Either don't build the module, or blacklist it in + /etc/modprobe.conf file as done with the + forte module in the example below: + +blacklist forte + + Blacklisted modules can still be loaded manually with the + explicit modprobe command. + + + + + Udev creates a device incorrectly, or makes a wrong symlink + + This usually happens if a rule unexpectedly matches a device. For + example, a poorly-writen rule can match by both a SCSI disk (as desired) + and the corresponding SCSI generic device (incorrectly) by vendor. + Increase the logging verbosity of Udev, find the offending rule by + examining the logs and make it more specific. + + + + + Udev rule works unreliably + + This may be another manifestation of the previous problem. If not, + and your rule uses sysfs + attributes, it may be a kernel timing issue, to be fixed in later kernels. + For now, you can work around it by creating a rule that waits for the used + sysfs attribute and appending + it to the /etc/udev/rules.d/10-wait_for_sysfs.rules + file. Please notify the LFS Development list if you do so and it + helps. + + + + + Udev does not create a device + + Further text assumes that the driver is built statically into the + kernel or already loaded as a module, and that you have already checked + that Udev doesn't create a misnamed device. + + Udev has no information needed to create a device node if a kernel + driver does not export its data to sysfs. + This is most common with third party drivers from outside the kernel + tree. Create a static device node in + /lib/udev/devices with the appropriate major/minor + numbers (see the file devices.txt inside the kernel + documentation or the documentation provided by the third party driver + vendor). The static device node will be copied to + /dev by the + S10udev bootscript. + + + + + Device naming order changes randomly after rebooting + + This is due to the fact that Udev, by design, handles uevents and + loads modules in parallel, and thus in an unpredictable order. This will + never be fixed. You should not rely upon the kernel device + names being stable. Instead, create your own rules that make symlinks with + stable names based on some stable attributes of the device, such as a + serial number or the output of various *_id utilities installed by Udev. + See also the network interface renaming example in + . + + diff --git a/chapter08/kernel.xml b/chapter08/kernel.xml index 9a9de871b..ad2573624 100644 --- a/chapter08/kernel.xml +++ b/chapter08/kernel.xml @@ -24,8 +24,8 @@ &diskspace; - 4.20 SBU - 181 MB + 2.4 SBU + 344 MB @@ -98,27 +98,13 @@ make - If using kernel modules, an /etc/modprobe.conf file - may be needed. Information pertaining to modules and kernel configuration is - located in the kernel documentation in the If using kernel modules, an /etc/modprobe.conf + file may be needed. Information pertaining to modules and kernel + configuration is located in and in the + kernel documentation in the linux-&linux-version;/Documentation directory. Also, modprobe.conf(5) may be of interest. - Be very careful when reading other documentation relating to kernel - modules because it usually applies to 2.4.x kernels only. As far as we know, - kernel configuration issues specific to Hotplug and Udev are not documented. - The problem is that Udev will create a device node only if Hotplug or a - user-written script inserts the corresponding module into the kernel, and not - all modules are detectable by Hotplug. Note that statements like the one below - in the /etc/modprobe.conf file do not work with - Udev: - -alias char-major-XXX some-module - - Because of the complications with Hotplug, Udev, and modules, we - strongly recommend starting with a completely non-modular kernel - configuration, especially if this is the first time using Udev. - Install the modules, if the kernel configuration uses them: make modules_install diff --git a/general.ent b/general.ent index bcf9a8b85..3123456b7 100644 --- a/general.ent +++ b/general.ent @@ -1,6 +1,6 @@ - - + + @@ -52,15 +52,14 @@ - - + - + - + @@ -83,8 +82,8 @@ - - + + diff --git a/patches.ent b/patches.ent index 07ff10904..fa33436cb 100644 --- a/patches.ent +++ b/patches.ent @@ -30,7 +30,7 @@ - +