mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-03-05 22:04:48 +00:00
Text updated for cross2 chapter 9
git-svn-id: http://svn.linuxfromscratch.org/LFS/branches/cross2@11928 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Bruce Dubbs
parent
96f04d7906
commit
a3d0817020
@ -23,7 +23,7 @@
|
||||
<para>The <filename>shells</filename> file contains a list of
|
||||
login shells on the system. Applications use this file to determine
|
||||
whether a shell is valid. For each shell a single line should be
|
||||
present, consisting of the shell's path, relative to the root of the
|
||||
present, consisting of the shell's path relative to the root of the
|
||||
directory structure (/).</para>
|
||||
|
||||
<para>For example, this file is consulted by <command>chsh</command>
|
||||
|
||||
@ -15,14 +15,14 @@
|
||||
</indexterm>
|
||||
|
||||
<para>The <filename>inputrc</filename> file is the configuration file for
|
||||
the Readline library, which provides editing capabilities while the user is
|
||||
the readline library, which provides editing capabilities while the user is
|
||||
entering a line from the terminal. It works by translating keyboard inputs
|
||||
into specific actions. Readline is used by Bash and most other shells as
|
||||
into specific actions. Readline is used by bash and most other shells as
|
||||
well as many other applications.</para>
|
||||
|
||||
<para>Most people do not need user-specific functionality so the command
|
||||
below creates a global <filename>/etc/inputrc</filename> used by everyone who
|
||||
logs in. If you later decide you need to override the defaults on a per-user
|
||||
logs in. If you later decide you need to override the defaults on a per user
|
||||
basis, you can create a <filename>.inputrc</filename> file in the user's home
|
||||
directory with the modified mappings.</para>
|
||||
|
||||
|
||||
@ -18,12 +18,6 @@
|
||||
process must be organized to ensure the tasks are performed in the correct
|
||||
order but, at the same time, be executed as fast as possible.</para>
|
||||
|
||||
<!-- <para>In the packages that were installed in Chapter 6, there were two
|
||||
different boot systems installed. LFS provides the ability to easily
|
||||
select which system the user wants to use and to compare and contrast the
|
||||
two systems by actually running each system on the local computer. The
|
||||
advantages and disadvantages of these systems is presented below.</para>-->
|
||||
|
||||
<sect2 id='sysv-desc'>
|
||||
<title>System V</title>
|
||||
|
||||
@ -39,15 +33,13 @@
|
||||
<filename>/etc/inittab</filename> file and is organized into run levels that
|
||||
can be run by the user:</para>
|
||||
|
||||
<literallayout>
|
||||
0 — halt
|
||||
<literallayout>0 — halt
|
||||
1 — Single user mode
|
||||
2 — Multiuser, without networking
|
||||
3 — Full multiuser mode
|
||||
4 — User definable
|
||||
5 — Full multiuser mode with display manager
|
||||
6 — reboot
|
||||
</literallayout>
|
||||
6 — reboot</literallayout>
|
||||
|
||||
<para>The usual default run level is 3 or 5.</para>
|
||||
|
||||
@ -69,7 +61,7 @@
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Slower to boot. A medium speed base LFS system
|
||||
<para>May be slower to boot. A medium speed base LFS system
|
||||
takes 8-12 seconds where the boot time is measured from the
|
||||
first kernel message to the login prompt. Network
|
||||
connectivity is typically established about 2 seconds
|
||||
@ -94,132 +86,6 @@
|
||||
</itemizedlist>
|
||||
|
||||
</sect2>
|
||||
<!--
|
||||
<sect2 id='sysd-desc'>
|
||||
<title>Systemd</title>
|
||||
|
||||
<para>Systemd is a group of interconnected programs that handles system and
|
||||
individual process requests. It provides a dependency system between
|
||||
various entities called "units". It automatically addresses dependencies
|
||||
between units and can execute several startup tasks in parallel. It
|
||||
provides login, inetd, logging, time, and networking services. </para>
|
||||
|
||||
<bridgehead renderas="sect3">Advantages</bridgehead>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Used on many established distributions by default.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>There is extensive documentation.
|
||||
See <ulink url="http://www.freedesktop.org/wiki/Software/systemd/"/>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Parallel execution of boot processes. A medium speed
|
||||
base LFS system takes 6-10 seconds from kernel start to a
|
||||
login prompt. Network connectivity is typically established
|
||||
about 2 seconds after the login prompt. More complex startup
|
||||
procedures may show a greater speedup when compared to System V.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Implements advanced features such as control groups to
|
||||
manage related processes.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Maintains backward compatibility with System V programs
|
||||
and scripts.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<bridgehead renderas="sect3">Disadvantages</bridgehead>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>There is a substantial learning curve.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Some advanced features such as dbus or cgroups cannot be
|
||||
disabled if they are not otherwise needed.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Although implemented as several executable programs
|
||||
the user cannot choose to implement only the portions desired.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Due to the nature of using compiled programs, systemd is
|
||||
more difficult to debug.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Logging is done in a binary format. Extra tools must
|
||||
be used to process logs or additional processes must be implemented
|
||||
to duplicate traditional logging programs.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</sect2>
|
||||
-->
|
||||
<!--
|
||||
<sect2 id='sysv'>
|
||||
<title>Selecting a Boot Method</title>
|
||||
|
||||
<para>Selecting a boot method in LFS is relatively easy.
|
||||
Both systems are installed side-by-side. The only task needed is to
|
||||
ensure the files that are needed by the system have the correct names.
|
||||
The following scripts do that.</para>
|
||||
|
||||
<screen><userinput remap="install">cat > /usr/sbin/set-systemd << "EOF"
|
||||
#! /bin/bash
|
||||
|
||||
ln -svfn init-systemd /sbin/init
|
||||
ln -svfn init.d-systemd /etc/init.d
|
||||
|
||||
for tool in halt poweroff reboot runlevel shutdown telinit; do
|
||||
ln -sfvn ${tool}-systemd /sbin/${tool}
|
||||
ln -svfn ${tool}-systemd.8 /usr/share/man/man8/${tool}.8
|
||||
done
|
||||
|
||||
echo "Now reboot with /sbin/reboot-sysv"
|
||||
EOF
|
||||
|
||||
chmod 0744 /usr/sbin/set-systemd
|
||||
|
||||
cat > /usr/sbin/set-sysv << "EOF"
|
||||
#! /bin/bash
|
||||
|
||||
ln -sfvn init-sysv /sbin/init
|
||||
ln -svfn init.d-sysv /etc/init.d
|
||||
|
||||
for tool in halt poweroff reboot runlevel shutdown telinit; do
|
||||
ln -sfvn ${tool}-sysv /sbin/${tool}
|
||||
ln -svfn ${tool}-sysv.8 /usr/share/man/man8/${tool}.8
|
||||
done
|
||||
|
||||
echo "Now reboot with /sbin/reboot-systemd"
|
||||
EOF
|
||||
|
||||
chmod 0744 /usr/sbin/set-sysv</userinput></screen>
|
||||
|
||||
<note><para>The comment about the correct command to reboot in the
|
||||
above scripts is correct. The reboot command for the current boot
|
||||
system must be used after the script changes the default reboot command.
|
||||
</para></note>
|
||||
|
||||
<para>Now set the desired boot system. The default is System V:</para>
|
||||
|
||||
<screen><userinput remap="install">/usr/sbin/set-sysv</userinput></screen>
|
||||
|
||||
<para>Changing the boot system can be done at any time by running the
|
||||
appropriate script above and rebooting.</para>
|
||||
|
||||
</sect2>
|
||||
-->
|
||||
</sect1>
|
||||
|
||||
|
||||
@ -13,17 +13,7 @@
|
||||
<indexterm zone="ch-config-network">
|
||||
<primary sortas="d-network">network</primary>
|
||||
<secondary>configuring</secondary></indexterm>
|
||||
<!--
|
||||
<para>This section only applies if a network card is to be
|
||||
configured.</para>
|
||||
|
||||
<para>If a network card will not be used, there is likely no need to create
|
||||
any configuration files relating to network cards. If that is the case, you
|
||||
will need to remove the <filename class="symlink">network</filename> symlinks
|
||||
from all run-level directories (<filename
|
||||
class="directory">/etc/rc.d/rc*.d</filename>) after the bootscripts are
|
||||
installed in <xref linkend="ch-config-bootscripts"/>.</para>
|
||||
-->
|
||||
<sect2>
|
||||
<title>Creating Network Interface Configuration Files</title>
|
||||
|
||||
@ -37,7 +27,7 @@
|
||||
address(es), subnet masks, and so forth. It is necessary that the stem of
|
||||
the filename be <emphasis>ifconfig</emphasis>.</para>
|
||||
|
||||
<note><para>If the procedure in the previous section was not used, Udev
|
||||
<note><para>If the procedure in the previous section was not used, udev
|
||||
will assign network card interface names based on system physical
|
||||
characteristics such as enp2s1. If you are not sure what your interface
|
||||
name is, you can always run <command>ip link</command> or <command>ls
|
||||
@ -64,7 +54,7 @@ EOF</userinput></screen>
|
||||
|
||||
<para>If the <envar>ONBOOT</envar> variable is set to <quote>yes</quote> the
|
||||
System V network script will bring up the Network Interface Card (NIC) during
|
||||
booting of the system. If set to anything but <quote>yes</quote> the NIC
|
||||
the system boot process. If set to anything but <quote>yes</quote> the NIC
|
||||
will be ignored by the network script and not be automatically brought up.
|
||||
The interface can be manually started or stopped with the
|
||||
<command>ifup</command> and <command>ifdown</command> commands.</para>
|
||||
|
||||
@ -103,8 +103,8 @@ LC_ALL=<locale name> locale int_prefix</userinput></screen>
|
||||
encoding used by the locale, the local currency, and the prefix to dial
|
||||
before the telephone number in order to get into the country. If any of the
|
||||
commands above fail with a message similar to the one shown below, this means
|
||||
that your locale was either not installed in Chapter 6 or is not supported by
|
||||
the default installation of Glibc.</para>
|
||||
that your locale was either not installed in <xref linkend="ch-system-glibc"/>
|
||||
or is not supported by the default installation of Glibc.</para>
|
||||
|
||||
<screen><computeroutput>locale: Cannot set LC_* to default locale: No such file or directory</computeroutput></screen>
|
||||
|
||||
@ -114,7 +114,7 @@ LC_ALL=<locale name> locale int_prefix</userinput></screen>
|
||||
Glibc.</para>
|
||||
|
||||
<!-- FIXME: the xlib example will became obsolete real soon -->
|
||||
<para>Some packages beyond LFS may also lack support for your chosen locale. One
|
||||
<!--<para>Some packages beyond LFS may also lack support for your chosen locale. One
|
||||
example is the X library (part of the X Window System), which outputs the
|
||||
following error message if the locale does not exactly match one of the character
|
||||
map names in its internal files:</para>
|
||||
@ -128,7 +128,7 @@ LC_ALL=<locale name> locale int_prefix</userinput></screen>
|
||||
by running the <command>locale charmap</command> command in both locales.
|
||||
For example, one would have to change "de_DE.ISO-8859-15@euro" to
|
||||
"de_DE@euro" in order to get this locale recognized by Xlib.</para>
|
||||
|
||||
-->
|
||||
<para>Other packages can also function incorrectly (but may not necessarily
|
||||
display any error messages) if the locale name does not meet their expectations.
|
||||
In those cases, investigating how other Linux distributions support your locale
|
||||
@ -145,7 +145,7 @@ export LANG=<replaceable><ll>_<CC>.<charmap><@modifiers>
|
||||
# End /etc/profile</literal>
|
||||
EOF</userinput></screen>
|
||||
|
||||
<para>The <quote>C</quote> (default) and <quote>en_US</quote> (the recommended
|
||||
<para>The <quote>C</quote> (default) and <quote>en_US.utf8</quote> (the recommended
|
||||
one for United States English users) locales are different. <quote>C</quote>
|
||||
uses the US-ASCII 7-bit character set, and treats bytes with the high bit set
|
||||
as invalid characters. That's why, e.g., the <command>ls</command> command
|
||||
|
||||
@ -21,7 +21,7 @@
|
||||
discovered. 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.</para>
|
||||
could get renumbered the other way around.</para>
|
||||
|
||||
<para>In the new naming scheme, typical network device names would then
|
||||
be something like enp5s0 or wlp3s0. If this naming convention is not
|
||||
@ -44,7 +44,7 @@
|
||||
<sect3>
|
||||
<title>Creating Custom Udev Rules</title>
|
||||
|
||||
<para>The naming scheme can be customized by creating custom Udev
|
||||
<para>The naming scheme can be customized by creating custom udev
|
||||
rules. A script has been included that generates the initial rules.
|
||||
Generate these rules by running:</para>
|
||||
|
||||
@ -68,24 +68,24 @@
|
||||
along with its driver in parentheses, if the driver can be found. Neither
|
||||
the hardware ID nor the driver is used to determine which name to give an
|
||||
interface; this information is only for reference. The second line is the
|
||||
Udev rule that matches this NIC and actually assigns it a name.</para>
|
||||
udev rule that matches this NIC and actually assigns it a name.</para>
|
||||
|
||||
<para>All Udev rules are made up of several keys, separated by commas and
|
||||
<para>All udev rules are made up of several keys, separated by commas and
|
||||
optional whitespace. This rule's keys and an explanation of each of them
|
||||
are as follows:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><literal>SUBSYSTEM=="net"</literal> - This tells Udev to ignore
|
||||
<para><literal>SUBSYSTEM=="net"</literal> - This tells udev to ignore
|
||||
devices that are not network cards.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><literal>ACTION=="add"</literal> - This tells Udev to ignore this
|
||||
<para><literal>ACTION=="add"</literal> - This tells udev to ignore this
|
||||
rule for a uevent that isn't an add ("remove" and "change" uevents also
|
||||
happen, but don't need to rename network interfaces).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><literal>DRIVERS=="?*"</literal> - This exists so that Udev will
|
||||
<para><literal>DRIVERS=="?*"</literal> - This exists so that udev will
|
||||
ignore VLAN or bridge sub-interfaces (because these sub-interfaces do
|
||||
not have drivers). These sub-interfaces are skipped because the name
|
||||
that would be assigned would collide with their parent devices.</para>
|
||||
@ -96,14 +96,14 @@
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><literal>ATTR{type}=="1"</literal> - This ensures the rule only
|
||||
matches the primary interface in the case of certain wireless drivers,
|
||||
matches the primary interface in the case of certain wireless drivers
|
||||
which create multiple virtual interfaces. The secondary interfaces are
|
||||
skipped for the same reason that VLAN and bridge sub-interfaces are
|
||||
skipped: there would be a name collision otherwise.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><literal>NAME</literal> - The value of this key is the name that
|
||||
Udev will assign to this interface.</para>
|
||||
udev will assign to this interface.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
@ -133,8 +133,8 @@
|
||||
default for USB and FireWire devices), where the rules it creates depend on
|
||||
the physical path to the CD or DVD device. Second, it can operate in
|
||||
<quote>by-id</quote> mode (default for IDE and SCSI devices), where the
|
||||
rules it creates depend on identification strings stored in the CD or DVD
|
||||
device itself. The path is determined by Udev's <command>path_id</command>
|
||||
rules it creates depend on identification strings stored on the CD or DVD
|
||||
device itself. The path is determined by udev's <command>path_id</command>
|
||||
script, and the identification strings are read from the hardware by its
|
||||
<command>ata_id</command> or <command>scsi_id</command> programs, depending
|
||||
on which type of device you have.</para>
|
||||
@ -159,11 +159,11 @@
|
||||
<important><para>External devices (for example, a USB-connected CD drive)
|
||||
should not use by-path persistence, because each time the device is plugged
|
||||
into a new external port, its physical path will change. All
|
||||
externally-connected devices will have this problem if you write Udev rules
|
||||
externally-connected devices will have this problem if you write udev rules
|
||||
to recognize them by their physical path; the problem is not limited to CD
|
||||
and DVD drives.</para></important>
|
||||
|
||||
<para>If you wish to see the values that the Udev scripts will use, then
|
||||
<para>If you wish to see the values that the udev scripts will use, then
|
||||
for the appropriate CD-ROM device, find the corresponding directory under
|
||||
<filename class="directory">/sys</filename> (e.g., this can be
|
||||
<filename class="directory">/sys/block/hdd</filename>) and
|
||||
@ -182,18 +182,18 @@
|
||||
as follows (where <replaceable>mode</replaceable> is one of
|
||||
<quote>by-id</quote> or <quote>by-path</quote>):</para>
|
||||
|
||||
<screen role="nodump"><userinput>sed -i -e 's/"write_cd_rules"/"write_cd_rules <replaceable>mode</replaceable>"/' \
|
||||
/etc/udev/rules.d/83-cdrom-symlinks.rules</userinput></screen>
|
||||
<screen role="nodump"><userinput>sed -e 's/"write_cd_rules"/"write_cd_rules <replaceable>mode</replaceable>"/' \
|
||||
-i /etc/udev/rules.d/83-cdrom-symlinks.rules</userinput></screen>
|
||||
|
||||
<para>Note that it is not necessary to create the rules files or symlinks
|
||||
at this time, because you have bind-mounted the host's
|
||||
<filename class="directory">/dev</filename> directory into the LFS system,
|
||||
at this time because you have bind-mounted the host's
|
||||
<filename class="directory">/dev</filename> directory into the LFS system
|
||||
and we assume the symlinks exist on the host. The rules and symlinks will
|
||||
be created the first time you boot your LFS system.</para>
|
||||
|
||||
<para>However, if you have multiple CD-ROM devices, then the symlinks
|
||||
generated at that time may point to different devices than they point to on
|
||||
your host, because devices are not discovered in a predictable order. The
|
||||
your host because devices are not discovered in a predictable order. The
|
||||
assignments created when you first boot the LFS system will be stable, so
|
||||
this is only an issue if you need the symlinks on both systems to point to
|
||||
the same device. If you need that, then inspect (and possibly edit) the
|
||||
@ -212,9 +212,9 @@
|
||||
E.g., if you have a USB web camera and a TV tuner, sometimes
|
||||
<filename>/dev/video0</filename> refers to the camera and
|
||||
<filename>/dev/video1</filename> refers to the tuner, and sometimes
|
||||
after a reboot the order changes to the opposite one.
|
||||
after a reboot the order changes.
|
||||
For all classes of hardware except sound cards and network cards, this is
|
||||
fixable by creating Udev rules for custom persistent symlinks.
|
||||
fixable by creating udev rules for custom persistent symlinks.
|
||||
The case of network cards is covered separately in
|
||||
<xref linkend="ch-config-network"/>, and sound card configuration can
|
||||
be found in <ulink url="&blfs-book;postlfs/devices.html">BLFS</ulink>.</para>
|
||||
@ -237,10 +237,8 @@
|
||||
<screen role="nodump"><userinput>cat > /etc/udev/rules.d/83-duplicate_devs.rules << "EOF"
|
||||
<literal>
|
||||
# Persistent symlinks for webcam and tuner
|
||||
KERNEL=="video*", ATTRS{idProduct}=="1910", ATTRS{idVendor}=="0d81", \
|
||||
SYMLINK+="webcam"
|
||||
KERNEL=="video*", ATTRS{device}=="0x036f", ATTRS{vendor}=="0x109e", \
|
||||
SYMLINK+="tvtuner"
|
||||
KERNEL=="video*", ATTRS{idProduct}=="1910", ATTRS{idVendor}=="0d81", SYMLINK+="webcam"
|
||||
KERNEL=="video*", ATTRS{device}=="0x036f", ATTRS{vendor}=="0x109e", SYMLINK+="tvtuner"
|
||||
</literal>
|
||||
EOF</userinput></screen>
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
<secondary>usage</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>In <xref linkend="chapter-building-system"/>, we installed the Udev
|
||||
<para>In <xref linkend="chapter-building-system"/>, we installed the udev
|
||||
package when <phrase revision="sysv">eudev</phrase>
|
||||
<phrase revision="systemd">systemd</phrase> was built. Before we go into the
|
||||
details regarding how this works, a brief history of previous methods of
|
||||
@ -30,7 +30,7 @@
|
||||
major and minor device numbers for every possible device that might exist in
|
||||
the world.</para>
|
||||
|
||||
<para>Using the Udev method, only those devices which are detected by the
|
||||
<para>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 <systemitem
|
||||
class="filesystem">devtmpfs</systemitem> file system (a virtual file system
|
||||
@ -135,7 +135,7 @@
|
||||
<filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file
|
||||
might contain the string
|
||||
<quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
|
||||
The default rules provided with Udev will cause <command>udevd</command>
|
||||
The default rules provided with udev will cause <command>udevd</command>
|
||||
to call out to <command>/sbin/modprobe</command> with the contents of the
|
||||
<envar>MODALIAS</envar> uevent environment variable (which should be the
|
||||
same as the contents of the <filename>modalias</filename> file in sysfs),
|
||||
@ -149,7 +149,7 @@
|
||||
be prevented.</para>
|
||||
|
||||
<para>The kernel itself is also able to load modules for network
|
||||
protocols, filesystems and NLS support on demand.</para>
|
||||
protocols, filesystems, and NLS support on demand.</para>
|
||||
|
||||
</sect3>
|
||||
|
||||
@ -177,12 +177,12 @@
|
||||
<para>Udev will only load a module if it has a bus-specific alias and the
|
||||
bus driver properly exports the necessary aliases to <systemitem
|
||||
class="filesystem">sysfs</systemitem>. In other cases, one should
|
||||
arrange module loading by other means. With Linux-&linux-version;, Udev is
|
||||
arrange module loading by other means. With Linux-&linux-version;, udev is
|
||||
known to load properly-written drivers for INPUT, IDE, PCI, USB, SCSI,
|
||||
SERIO, and FireWire devices.</para>
|
||||
|
||||
<para>To determine if the device driver you require has the necessary
|
||||
support for Udev, run <command>modinfo</command> with the module name as
|
||||
support for udev, run <command>modinfo</command> with the module name as
|
||||
the argument. Now try locating the device directory under
|
||||
<filename class="directory">/sys/bus</filename> and check whether there is
|
||||
a <filename>modalias</filename> file there.</para>
|
||||
@ -190,7 +190,7 @@
|
||||
<para>If the <filename>modalias</filename> file exists in <systemitem
|
||||
class="filesystem">sysfs</systemitem>, 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
|
||||
driver. Load the driver without the help from udev and expect the issue
|
||||
to be fixed later.</para>
|
||||
|
||||
<para>If there is no <filename>modalias</filename> file in the relevant
|
||||
@ -206,7 +206,7 @@
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>A kernel module is not loaded automatically, and Udev is not
|
||||
<title>A kernel module is not loaded automatically, and udev is not
|
||||
intended to load it</title>
|
||||
|
||||
<para>If the <quote>wrapper</quote> module only enhances the
|
||||
@ -214,7 +214,7 @@
|
||||
<emphasis>snd-pcm-oss</emphasis> enhances the functionality of
|
||||
<emphasis>snd-pcm</emphasis> by making the sound cards available to OSS
|
||||
applications), configure <command>modprobe</command> to load the wrapper
|
||||
after Udev loads the wrapped module. To do this, add a
|
||||
after udev loads the wrapped module. To do this, add a
|
||||
<quote>softdep</quote> line to the corresponding
|
||||
<filename>/etc/modprobe.d/<replaceable><filename></replaceable>.conf</filename>
|
||||
file. For example:</para>
|
||||
@ -279,7 +279,7 @@
|
||||
|
||||
<para>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.</para>
|
||||
that udev doesn't create a misnamed device.</para>
|
||||
|
||||
<para>Udev has no information needed to create a device node if a kernel
|
||||
driver does not export its data to
|
||||
@ -297,12 +297,12 @@
|
||||
<sect3>
|
||||
<title>Device naming order changes randomly after rebooting</title>
|
||||
|
||||
<para>This is due to the fact that Udev, by design, handles uevents and
|
||||
<para>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 <quote>fixed</quote>. 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.
|
||||
serial number or the output of various *_id utilities installed by udev.
|
||||
See <xref linkend="ch-config-symlinks"/> and
|
||||
<xref linkend="ch-config-network"/> for examples.</para>
|
||||
|
||||
|
||||
@ -235,50 +235,6 @@ EOF</userinput></screen>
|
||||
|
||||
<para>For information on kernel module loading and udev, see
|
||||
<xref linkend="module-loading"/>.</para>
|
||||
<!--
|
||||
<sect3>
|
||||
<title>Module Loading</title>
|
||||
|
||||
<para>Device drivers compiled as modules may have aliases built into them.
|
||||
Aliases are visible in the output of the <command>modinfo</command>
|
||||
program and are usually related to the bus-specific identifiers of devices
|
||||
supported by a module. For example, the <emphasis>snd-fm801</emphasis>
|
||||
driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801,
|
||||
and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>.
|
||||
For most devices, the bus driver exports the alias of the driver that
|
||||
would handle the device via <systemitem
|
||||
class="filesystem">sysfs</systemitem>. E.g., the
|
||||
<filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file
|
||||
might contain the string
|
||||
<quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
|
||||
The default rules provided with Udev will cause <command>udevd</command>
|
||||
to call out to <command>/sbin/modprobe</command> with the contents of the
|
||||
<envar>MODALIAS</envar> uevent environment variable (which should be the
|
||||
same as the contents of the <filename>modalias</filename> file in sysfs),
|
||||
thus loading all modules whose aliases match this string after wildcard
|
||||
expansion.</para>
|
||||
|
||||
<para>In this example, this means that, in addition to
|
||||
<emphasis>snd-fm801</emphasis>, the obsolete (and unwanted)
|
||||
<emphasis>forte</emphasis> driver will be loaded if it is
|
||||
available. See below for ways in which the loading of unwanted drivers can
|
||||
be prevented.</para>
|
||||
|
||||
<para>The kernel itself is also able to load modules for network
|
||||
protocols, filesystems and NLS support on demand.</para>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Handling Hotpluggable/Dynamic Devices</title>
|
||||
|
||||
<para>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 uevent. This uevent is then handled by
|
||||
<command>udevd</command> as described above.</para>
|
||||
|
||||
</sect3>
|
||||
-->
|
||||
</sect2>
|
||||
|
||||
<sect2 id="ch-config-clock">
|
||||
@ -293,11 +249,11 @@ EOF</userinput></screen>
|
||||
(CMOS) clock. If the hardware clock is set to UTC, this script will convert the
|
||||
hardware clock's time to the local time using the
|
||||
<filename>/etc/localtime</filename> file (which tells the
|
||||
<command>hwclock</command> program which timezone the user is in). There is no
|
||||
<command>hwclock</command> program which timezone to use). There is no
|
||||
way to detect whether or not the hardware clock is set to UTC, so this
|
||||
needs to be configured manually.</para>
|
||||
|
||||
<para>The <command>setclock</command> is run via
|
||||
<para>The <command>setclock</command> program is run via
|
||||
<application>udev</application> when the kernel detects the hardware
|
||||
capability upon boot. It can also be run manually with the stop parameter to
|
||||
store the system time to the CMOS clock.</para>
|
||||
@ -315,7 +271,7 @@ EOF</userinput></screen>
|
||||
|
||||
<para>Change the value of the <envar>UTC</envar> variable below
|
||||
to a value of <parameter>0</parameter> (zero) if the hardware clock
|
||||
is <emphasis>not</emphasis> set to UTC time.</para>
|
||||
is <emphasis>NOT</emphasis> set to UTC time.</para>
|
||||
|
||||
<para>Create a new file <filename>/etc/sysconfig/clock</filename> by running
|
||||
the following:</para>
|
||||
@ -336,7 +292,7 @@ EOF</userinput></screen>
|
||||
at <ulink url="&hints-root;time.txt"/>. It explains issues such as
|
||||
time zones, UTC, and the <envar>TZ</envar> environment variable.</para>
|
||||
|
||||
<note><para>The CLOCKPARAMS and UTC paramaters may be alternatively set
|
||||
<note><para>The CLOCKPARAMS and UTC paramaters may also be set
|
||||
in the <filename>/etc/sysconfig/rc.site</filename> file.</para></note>
|
||||
|
||||
</sect2>
|
||||
@ -352,7 +308,7 @@ EOF</userinput></screen>
|
||||
</indexterm>
|
||||
|
||||
<para>This section discusses how to configure the <command>console</command>
|
||||
bootscript that sets up the keyboard map, console font and console kernel log
|
||||
bootscript that sets up the keyboard map, console font, and console kernel log
|
||||
level. If non-ASCII characters (e.g., the copyright sign, the British pound
|
||||
sign and Euro symbol) will not be used and the keyboard is a U.S. one, much
|
||||
of this section can be skipped. Without the configuration file, (or
|
||||
@ -505,7 +461,7 @@ EOF</userinput></screen>
|
||||
<listitem>
|
||||
<para>Due to the use of a 512-glyph LatArCyrHeb-16 font in the previous
|
||||
example, bright colors are no longer available on the Linux console unless
|
||||
a framebuffer is used. If one wants to have bright colors without
|
||||
a framebuffer is used. If one wants to have bright colors without a
|
||||
framebuffer and can live without characters not belonging to his language,
|
||||
it is still possible to use a language-specific 256-glyph font, as
|
||||
illustrated below:</para>
|
||||
@ -548,7 +504,7 @@ EOF</userinput></screen>
|
||||
are not multibyte. This deficiency doesn't affect keymaps for European
|
||||
languages, because there accents are added to unaccented ASCII
|
||||
characters, or two ASCII characters are composed together. However, in
|
||||
UTF-8 mode it is a problem, e.g., for the Greek language, where one
|
||||
UTF-8 mode it is a problem; e.g., for the Greek language, where one
|
||||
sometimes needs to put an accent on the letter <quote>alpha</quote>.
|
||||
The solution is either to avoid the use of UTF-8, or to install the
|
||||
X window system that doesn't have this limitation in its input
|
||||
@ -556,11 +512,11 @@ EOF</userinput></screen>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>For Chinese, Japanese, Korean and some other languages, the Linux
|
||||
<para>For Chinese, Japanese, Korean, and some other languages, the Linux
|
||||
console cannot be configured to display the needed characters. Users
|
||||
who need such languages should install the X Window System, fonts that
|
||||
cover the necessary character ranges, and the proper input method (e.g.,
|
||||
SCIM, it supports a wide variety of languages).</para>
|
||||
SCIM, supports a wide variety of languages).</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
@ -571,7 +527,7 @@ EOF</userinput></screen>
|
||||
<para>The <filename>/etc/sysconfig/console</filename> file only controls
|
||||
the Linux text console localization. It has nothing to do with setting
|
||||
the proper keyboard layout and terminal fonts in the X Window System, with
|
||||
ssh sessions or with a serial console. In such situations, limitations
|
||||
ssh sessions, or with a serial console. In such situations, limitations
|
||||
mentioned in the last two list items above do not apply.</para>
|
||||
</note>
|
||||
|
||||
@ -585,9 +541,9 @@ EOF</userinput></screen>
|
||||
<secondary>configuring</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>At times, it is desired to create files at boot time. For instance,
|
||||
<para>At times, it is desirable to create files at boot time. For instance,
|
||||
the <filename class="directory">/tmp/.ICE-unix</filename> directory
|
||||
may be desired. This can be done by creating an entry in the
|
||||
is often needed. This can be done by creating an entry in the
|
||||
<filename>/etc/sysconfig/createfiles</filename> configuration script.
|
||||
The format of this file is embedded in the comments of the default
|
||||
configuration file.</para>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user