Changeset 81a73ed8


Ignore:
Timestamp:
03/25/2020 03:07:11 PM (4 years ago)
Author:
Pierre Labastie <pieere@…>
Branches:
10.0, 10.1, 11.0, 11.1, 11.2, 11.3, 12.0, 12.1, kea, ken/TL2024, ken/inkscape-core-mods, ken/tuningfonts, lazarus, lxqt, plabs/newcss, plabs/python-mods, python3.11, qt5new, rahul/power-profiles-daemon, renodr/vulkan-addition, trunk, upgradedb, xry111/intltool, xry111/llvm18, xry111/soup3, xry111/test-20220226, xry111/xf86-video-removal
Children:
986f53b9
Parents:
fa3edfef
Message:

Format postlfs config

git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@22886 af4574ff-66df-0310-9fd7-8a98e5e911e0

Location:
postlfs/config
Files:
10 edited

Legend:

Unmodified
Added
Removed
  • postlfs/config/bootdisk.xml

    rfa3edfef r81a73ed8  
    1919    <title>Decent Rescue Boot Device Needs</title>
    2020
    21     <para>This section is really about creating a <emphasis>rescue</emphasis>
    22     device.  As the name <emphasis>rescue</emphasis> implies, the host
    23     system has a problem, often lost partition information or corrupted file
    24     systems, that prevents it from booting and/or operating normally.  For
    25     this reason, you <emphasis>must not</emphasis> depend on resources from
    26     the host being "rescued".  To presume that any given partition or hard
    27     drive <emphasis>will</emphasis> be available is a risky presumption.</para>
     21    <para>
     22      This section is really about creating a <emphasis>rescue</emphasis>
     23      device.  As the name <emphasis>rescue</emphasis> implies, the host
     24      system has a problem, often lost partition information or corrupted file
     25      systems, that prevents it from booting and/or operating normally.  For
     26      this reason, you <emphasis>must not</emphasis> depend on resources from
     27      the host being "rescued".  To presume that any given partition or hard
     28      drive <emphasis>will</emphasis> be available is a risky presumption.
     29    </para>
    2830
    29     <para>In a modern system, there are many devices that can be
    30     used as a rescue device: floppy, cdrom, usb drive, or even a network card.
    31     Which one you use depends on your hardware and your BIOS.  In the past,
    32     a rescue device was thought to be a floppy disk.  Today, many
    33     systems do not even have a floppy drive.</para>
     31    <para>
     32      In a modern system, there are many devices that can be used as a
     33      rescue device: floppy, cdrom, usb drive, or even a network card.
     34      Which one you use depends on your hardware and your BIOS.  In the past,
     35      a rescue device was thought to be a floppy disk.  Today, many
     36      systems do not even have a floppy drive.
     37    </para>
    3438
    35     <para>Building a complete rescue device is a challenging task.  In many
    36     ways, it is equivalent to building an entire LFS system.
    37     In addition, it would be a repetition of information already available.
    38     For these reasons, the procedures for a rescue device image are not
    39     presented here.</para>
     39    <para>
     40      Building a complete rescue device is a challenging task.  In many
     41      ways, it is equivalent to building an entire LFS system.
     42      In addition, it would be a repetition of information already available.
     43      For these reasons, the procedures for a rescue device image are not
     44      presented here.
     45    </para>
    4046
    4147  </sect2>
     
    4450    <title>Creating a Rescue Floppy</title>
    4551
    46     <para>The software of today's systems has grown large.  Linux 2.6 no longer
    47     supports booting directly from a floppy.  In spite of this, there are solutions
    48     available using older versions of Linux.  One of the best is Tom's Root/Boot
    49     Disk available at <ulink url='http://www.toms.net/rb/'/>.  This will provide a
    50     minimal Linux system on a single floppy disk and provides the ability to
    51     customize the contents of your disk if necessary.</para>
     52    <para>
     53      The software of today's systems has grown large.  Linux 2.6 no longer
     54      supports booting directly from a floppy.  In spite of this, there are
     55      solutions available using older versions of Linux.  One of the best is
     56      Tom's Root/Boot Disk available at <ulink
     57      url='http://www.toms.net/rb/'/>.  This will provide a minimal Linux
     58      system on a single floppy disk and provides the ability to customize
     59      the contents of your disk if necessary.
     60    </para>
    5261
    5362  </sect2>
     
    5665    <title>Creating a Bootable CD-ROM</title>
    5766
    58     <para>There are several sources that can be used for a rescue CD-ROM.
    59     Just about any commercial distribution's installation CD-ROMs or
    60     DVDs will work.  These include RedHat, Ubuntu, and SuSE.  One
    61     very popular option is Knoppix.</para>
     67    <para>
     68      There are several sources that can be used for a rescue CD-ROM.
     69      Just about any commercial distribution's installation CD-ROMs or
     70      DVDs will work.  These include RedHat, Ubuntu, and SuSE.  One
     71      very popular option is Knoppix.
     72    </para>
    6273
    63     <para>Also, the LFS Community has developed its own LiveCD available at
    64     <ulink url='http://www.&lfs-domainname;/livecd/'/>.  This LiveCD, is no
    65     longer capable of building an entire LFS/BLFS system, but is still a
    66     good rescue CD-ROM.  If you download the
    67     ISO image, use <xref linkend="xorriso"/> to copy the image to a
    68     CD-ROM.</para>
     74    <para>
     75      Also, the LFS Community has developed its own LiveCD available at
     76      <ulink url='http://www.&lfs-domainname;/livecd/'/>.  This LiveCD, is no
     77      longer capable of building an entire LFS/BLFS system, but is still a
     78      good rescue CD-ROM.  If you download the
     79      ISO image, use <xref linkend="xorriso"/> to copy the image to a
     80      CD-ROM.
     81    </para>
    6982
    70     <para>The instructions for using GRUB2 to make a custom rescue CD-ROM are
    71     also available in <ulink
    72     url='http://www.&lfs-domainname;/lfs/view/stable/chapter08/grub.html'>LFS
    73     Chapter 8</ulink>.</para>
     83    <para>
     84      The instructions for using GRUB2 to make a custom rescue CD-ROM are
     85      also available in <ulink
     86      url='http://www.&lfs-domainname;/lfs/view/stable/chapter08/grub.html'>LFS
     87      Chapter 8</ulink>.
     88    </para>
    7489
    7590  </sect2>
     
    7893    <title>Creating a Bootable USB Drive</title>
    7994
    80     <para>A USB Pen drive, sometimes called a Thumb drive, is recognized by Linux as
    81     a SCSI device.  Using one of these devices as a rescue device has the advantage
    82     that it is usually large enough to hold more than a minimal boot image.  You
    83     can save critical data to the drive as well as use it to diagnose and recover
    84     a damaged system.  Booting such a drive requires BIOS support, but building the
    85     system consists of formatting the drive, adding <application>GRUB</application>
    86     as well as the Linux kernel and supporting files.</para>
     95    <para>
     96      A USB Pen drive, sometimes called a Thumb drive, is recognized by Linux
     97      as a SCSI device.  Using one of these devices as a rescue device has
     98      the advantage that it is usually large enough to hold more than a
     99      minimal boot image.  You can save critical data to the drive as well
     100      as use it to diagnose and recover a damaged system.  Booting such a
     101      drive requires BIOS support, but building the system consists of
     102      formatting the drive, adding <application>GRUB</application> as well
     103      as the Linux kernel and supporting files.
     104    </para>
    87105
    88106    <para condition="html" role="usernotes">User Notes:
    89     <ulink url='&blfs-wiki;/CreatingaCustomBootDevice'/></para>
     107    <ulink url='&blfs-wiki;/CreatingaCustomBootDevice'/>
     108    </para>
    90109
    91110  </sect2>
  • postlfs/config/config.xml

    rfa3edfef r81a73ed8  
    1616  <title>After LFS Configuration Issues</title>
    1717
    18   <para>The intention of LFS is to provide a basic system which you can
    19   build upon.  There are several things about tidying up the system which
    20   many people wonder about once they have done the base install.
    21   We hope to cover these issues in this chapter.</para>
     18  <para>
     19    The intention of LFS is to provide a basic system which you can
     20    build upon.  There are several things about tidying up the system which
     21    many people wonder about once they have done the base install.
     22    We hope to cover these issues in this chapter.
     23  </para>
    2224
    23   <para>Most people coming from non-Unix like backgrounds to Linux find the
    24   concept of text-only configuration files slightly strange.  In Linux, just
    25   about all configuration is done via the manipulation of text files. The
    26   majority of these files can be found in the
    27   <filename class='directory'>/etc</filename> hierarchy. There are often
    28   graphical configuration programs available for different subsystems but most
    29   are simply pretty front ends to the process of editing a text file. The
    30   advantage of text-only configuration is that you can edit parameters using
    31   your favorite text editor, whether that be <command>vim</command>,
    32   <command>emacs</command>, or any other editor.</para>
     25  <para>
     26    Most people coming from non-Unix like backgrounds to Linux find the
     27    concept of text-only configuration files slightly strange.  In Linux, just
     28    about all configuration is done via the manipulation of text files. The
     29    majority of these files can be found in the <filename
     30    class='directory'>/etc</filename> hierarchy. There are often graphical
     31    configuration programs available for different subsystems but most
     32    are simply pretty front ends to the process of editing a text file. The
     33    advantage of text-only configuration is that you can edit parameters using
     34    your favorite text editor, whether that be <command>vim</command>,
     35    <command>emacs</command>, or any other editor.
     36  </para>
    3337
    34   <para>The first task is making a recovery boot device in
    35   <xref linkend="postlfs-config-bootdisk"/> because it's the most critical need.
    36   Hardware issues relevant to firmware and other devices is addressed next.
    37   The system is then configured to ease addition of new users, because this
    38   can affect the choices you make in the two subsequent
    39   topics&mdash;<xref linkend="postlfs-config-profile"/> and
    40   <xref linkend="postlfs-config-vimrc"/>.</para>
     38  <para>
     39    The first task is making a recovery boot device in <xref
     40    linkend="postlfs-config-bootdisk"/> because it's the most critical need.
     41    Hardware issues relevant to firmware and other devices is addressed next.
     42    The system is then configured to ease addition of new users, because this
     43    can affect the choices you make in the two subsequent
     44    topics&mdash;<xref linkend="postlfs-config-profile"/> and
     45    <xref linkend="postlfs-config-vimrc"/>.
     46  </para>
    4147
    42   <para> The remaining topics, <xref linkend="postlfs-config-logon"/>,
    43   <phrase revision="sysv"><xref linkend="postlfs-config-random"/>,</phrase>
    44   and <xref linkend="autofs"/> are then addressed, in that order. They
    45   don't have much interaction with the other topics in this chapter.</para>
     48  <para revision="sysv">
     49    The remaining topics, <xref linkend="postlfs-config-logon"/> and
     50    <xref linkend="postlfs-config-random"/> are then addressed, in that order.
     51    They don't have much interaction with the other topics in this chapter.
     52  </para>
     53
     54  <para revision="systemd">
     55    There is one remaining topic: <xref linkend="postlfs-config-logon"/>.
     56    It doesn't have much interaction with the other topics in this chapter.
     57  </para>
     58<!-- autofs has been moved to sysutils -->
    4659
    4760  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="bootdisk.xml"/>
  • postlfs/config/devices.xml

    rfa3edfef r81a73ed8  
    2020  </indexterm>
    2121
    22   <para>Although most devices needed by packages in BLFS and beyond are set up
    23   properly by <application>udev</application> using the default rules installed
    24   by LFS in <filename class="directory">/etc/udev/rules.d</filename>, there are
    25   cases where the rules must be modified or augmented.</para>
     22  <para>
     23    Although most devices needed by packages in BLFS and beyond are set up
     24    properly by <application>udev</application> using the default rules
     25    installed by LFS in <filename
     26    class="directory">/etc/udev/rules.d</filename>, there are cases where
     27    the rules must be modified or augmented.
     28  </para>
    2629
    2730  <para condition="html" role="usernotes">User Notes:
     
    3134    <title>Multiple Sound Cards</title>
    3235
    33     <para>If there are multiple sound cards in a system, the "default"
    34     sound card becomes random.  The method to establish sound card order
    35     depends on whether the drivers are modules or not.  If the sound card
    36     drivers are compiled into the kernel, control is via kernel command line
    37     parameters in <filename>/boot/grub/grub.cfg</filename>.  For example,
    38     if a system has both an FM801 card and a SoundBlaster PCI card, the
    39     following can be appended to the command line:</para>
     36    <para>
     37      If there are multiple sound cards in a system, the "default"
     38      sound card becomes random.  The method to establish sound card order
     39      depends on whether the drivers are modules or not.  If the sound card
     40      drivers are compiled into the kernel, control is via kernel command line
     41      parameters in <filename>/boot/grub/grub.cfg</filename>.  For example,
     42      if a system has both an FM801 card and a SoundBlaster PCI card, the
     43      following can be appended to the command line:
     44    </para>
    4045
    4146<screen><literal>snd-fm801.index=0 snd-ens1371.index=1</literal></screen>
    4247
    43     <para>If the sound card drivers are built as modules, the order can be
    44     established in the <filename>/etc/modprobe.conf</filename> file
    45     with:</para>
     48    <para>
     49      If the sound card drivers are built as modules, the order can be
     50      established in the <filename>/etc/modprobe.conf</filename> file with:
     51    </para>
    4652
    4753<screen><literal>options snd-fm801 index=0
     
    5359    <title>USB Device Issues</title>
    5460
    55     <para>USB devices usually have two kinds of device nodes associated with
    56     them.</para>
    57 
    58     <para>The first kind is created by device-specific drivers (e.g.,
    59     usb_storage/sd_mod or usblp) in the kernel. For example, a USB mass storage
    60     device would be /dev/sdb, and a USB printer would be /dev/usb/lp0. These
    61     device nodes exist only when the device-specific driver is loaded.</para>
    62 
    63     <para>The second kind of device nodes (/dev/bus/usb/BBB/DDD, where BBB is
    64     the bus number and DDD is the device number) are created even if the device
    65     doesn't have a kernel driver. By using these "raw" USB device nodes, an
    66     application can exchange arbitrary USB packets with the device, i.e.,
    67     bypass the possibly-existing kernel driver.</para>
    68 
    69     <para>Access to raw USB device nodes is needed when a userspace program is
    70     acting as a device driver. However, for the program to open the device
    71     successfully, the permissions have to be set correctly. By default, due to
    72     security concerns, all raw USB devices are owned by user root and group
    73     usb, and have 0664 permissions (the read access is needed, e.g., for lsusb
    74     to work and for programs to access USB hubs). Packages (such as SANE and
    75     libgphoto2) containing userspace USB device drivers also ship udev rules
    76     that change the permissions of the controlled raw USB devices. That is, rules
    77     installed by SANE change permissions for known scanners, but not printers.
    78     If a package maintainer forgot to write a rule for your device,
    79     report a bug to both BLFS (if the package is there) and upstream, and
    80     you will need to write your own rule.</para>
    81 
    82     <para>There is one situation when such fine-grained access control with
    83     pre-generated udev rules doesn't work. Namely, PC emulators such as KVM,
    84     QEMU and VirtualBox use raw USB device nodes to present arbitrary USB
    85     devices to the guest operating system (note: patches are needed in order to
    86     get this to work without the obsolete /proc/bus/usb mount point described
    87     below). Obviously, maintainers of these packages cannot know which USB
    88     devices are going to be connected to the guest operating system. You can
    89     either write separate udev rules for all needed USB devices yourself, or
    90     use the default catch-all "usb" group, members of which can send
    91     arbitrary commands to all USB devices. </para>
    92 
    93     <para>Before Linux-2.6.15, raw USB device access was performed not with
    94     /dev/bus/usb/BBB/DDD device nodes, but with /proc/bus/usb/BBB/DDD
    95     pseudofiles. Some applications (e.g., VMware Workstation) still use only
    96     this deprecated technique and can't use the new device nodes. For them to
    97     work, use the "usb" group, but remember that members will have unrestricted
    98     access to all USB devices.  To create the fstab entry for the obsolete
    99     usbfs filesystem:</para>
     61    <para>
     62      USB devices usually have two kinds of device nodes associated with them.
     63    </para>
     64
     65    <para>
     66      The first kind is created by device-specific drivers (e.g.,
     67      usb_storage/sd_mod or usblp) in the kernel. For example, a USB mass
     68      storage device would be /dev/sdb, and a USB printer would be
     69      /dev/usb/lp0. These device nodes exist only when the device-specific
     70      driver is loaded.
     71    </para>
     72
     73    <para>
     74      The second kind of device nodes (/dev/bus/usb/BBB/DDD, where BBB is
     75      the bus number and DDD is the device number) are created even if the
     76      device doesn't have a kernel driver. By using these "raw" USB device
     77      nodes, an application can exchange arbitrary USB packets with the
     78      device, i.e., bypass the possibly-existing kernel driver.
     79    </para>
     80
     81    <para>
     82      Access to raw USB device nodes is needed when a userspace program is
     83      acting as a device driver. However, for the program to open the device
     84      successfully, the permissions have to be set correctly. By default, due
     85      to security concerns, all raw USB devices are owned by user root and
     86      group usb, and have 0664 permissions (the read access is needed, e.g.,
     87      for lsusb to work and for programs to access USB hubs). Packages (such
     88      as SANE and libgphoto2) containing userspace USB device drivers also
     89      ship udev rules that change the permissions of the controlled raw USB
     90      devices. That is, rules installed by SANE change permissions for known
     91      scanners, but not printers.  If a package maintainer forgot to write
     92      a rule for your device, report a bug to both BLFS (if the package is
     93      there) and upstream, and you will need to write your own rule.
     94    </para>
     95
     96    <para>
     97      There is one situation when such fine-grained access control with
     98      pre-generated udev rules doesn't work. Namely, PC emulators such as KVM,
     99      QEMU and VirtualBox use raw USB device nodes to present arbitrary USB
     100      devices to the guest operating system (note: patches are needed in order
     101      to get this to work without the obsolete /proc/bus/usb mount point
     102      described below). Obviously, maintainers of these packages cannot know
     103      which USB devices are going to be connected to the guest operating
     104      system. You can either write separate udev rules for all needed USB
     105      devices yourself, or use the default catch-all "usb" group, members
     106      of which can send arbitrary commands to all USB devices.
     107    </para>
     108
     109    <para>
     110      Before Linux-2.6.15, raw USB device access was performed not with
     111      /dev/bus/usb/BBB/DDD device nodes, but with /proc/bus/usb/BBB/DDD
     112      pseudofiles. Some applications (e.g., VMware Workstation) still use only
     113      this deprecated technique and can't use the new device nodes. For them to
     114      work, use the "usb" group, but remember that members will have
     115      unrestricted access to all USB devices.  To create the fstab entry for
     116      the obsolete usbfs filesystem:
     117    </para>
    100118
    101119<screen><literal>usbfs  /proc/bus/usb  usbfs  devgid=14,devmode=0660  0  0</literal></screen>
    102120
    103     <note><para>Adding users to the "usb" group is inherently insecure, as they
    104     can bypass access restrictions imposed through the driver-specific USB
    105     device nodes. For instance, they can read sensitive data from USB hard drives
    106     without being in the "disk" group. Avoid adding users to this group, if
    107     you can.</para></note>
     121    <note>
     122      <para>
     123        Adding users to the "usb" group is inherently insecure, as they can
     124        bypass access restrictions imposed through the driver-specific USB
     125        device nodes. For instance, they can read sensitive data from USB
     126        hard drives without being in the "disk" group. Avoid adding users
     127        to this group, if you can.
     128    </para>
     129    </note>
    108130
    109131  </sect2>
     
    112134    <title>Udev Device Attributes</title>
    113135
    114     <para>Fine-tuning of device attributes such as group name and permissions
    115     is possible by creating extra <application>udev</application> rules,
    116     matching on something like this. The vendor and product can be found by
    117     searching the <filename class='directory'>/sys/devices</filename> directory
    118     entries or using <command>udevadm info</command> after the device has been
    119     attached. See the documentation in the current
    120     <application>udev</application> directory of
    121     <filename class='directory'>/usr/share/doc</filename> for details.</para>
     136    <para>
     137      Fine-tuning of device attributes such as group name and permissions
     138      is possible by creating extra <application>udev</application> rules,
     139      matching on something like this. The vendor and product can be found by
     140      searching the <filename class='directory'>/sys/devices</filename>
     141      directory entries or using <command>udevadm info</command> after the
     142      device has been attached. See the documentation in the current
     143      <application>udev</application> directory of <filename
     144      class='directory'>/usr/share/doc</filename> for details.
     145    </para>
    122146
    123147<screen><literal>SUBSYSTEM=="usb_device", SYSFS{idVendor}=="05d8", SYSFS{idProduct}=="4002", \
    124148  GROUP:="scanner", MODE:="0660"</literal></screen>
    125149
    126     <note><para>The above line is used for descriptive purposes only. The
    127     scanner <application>udev</application> rules are put into place when
    128     installing <xref linkend='sane'/>.</para></note>
     150    <note>
     151      <para>
     152        The above line is used for descriptive purposes only. The
     153        scanner <application>udev</application> rules are put into place when
     154        installing <xref linkend='sane'/>.
     155      </para>
     156    </note>
    129157
    130158  </sect2>
     
    141169    <title>Devices for Servers</title>
    142170
    143     <para>In some cases, it makes sense to disable
    144     <application>udev</application> completely and create static devices.
    145     Servers are one example of this situation.  Does a server need the
    146     capability of handling dynamic devices?  Only the system administrator can
    147     answer that question, but in many cases the answer will be no.</para>
    148 
    149     <para>If dynamic devices are not desired, then static devices must be
    150     created on the system.  In the default configuration, the
    151     <filename>/etc/rc.d/rcS.d/S10udev</filename> boot script mounts a
    152     <systemitem class="filesystem">tmpfs</systemitem> partition over the
    153     <filename class="directory">/dev</filename> directory.  This problem can be
    154     overcome by mounting the root partition temporarily:</para>
    155 
    156     <warning><para>If the instructions below are not followed carefully, your
    157     system could become unbootable.</para></warning>
     171    <para>
     172      In some cases, it makes sense to disable
     173      <application>udev</application> completely and create static devices.
     174      Servers are one example of this situation.  Does a server need the
     175      capability of handling dynamic devices?  Only the system administrator
     176      can answer that question, but in many cases the answer will be no.
     177    </para>
     178
     179    <para>
     180      If dynamic devices are not desired, then static devices must be
     181      created on the system.  In the default configuration, the
     182      <filename>/etc/rc.d/rcS.d/S10udev</filename> boot script mounts a
     183      <systemitem class="filesystem">tmpfs</systemitem> partition over the
     184      <filename class="directory">/dev</filename> directory. This problem can
     185      be overcome by mounting the root partition temporarily:
     186    </para>
     187
     188    <warning>
     189      <para>
     190        If the instructions below are not followed carefully, your
     191        system could become unbootable.
     192      </para>
     193    </warning>
    158194
    159195
     
    163199umount /mnt</userinput></screen>
    164200
    165     <para>At this point, the system will use static devices upon the next
    166     reboot.  Create any desired additional devices using
    167     <command>mknod</command>.</para>
    168 
    169     <para>If you want to restore the dynamic devices, recreate the
    170     <filename>/etc/rc.d/rcS.d/{S10udev,S50udev_retry}</filename> symbolic
    171     links and reboot again.  Static devices do not need to be removed (console
    172     and null are always needed) because they are covered by the <systemitem
    173     class="filesystem">tmpfs</systemitem> partition.  Disk usage for devices is
    174     negligible (about 20&ndash;30 bytes per entry.)</para>
     201    <para>
     202      At this point, the system will use static devices upon the next
     203      reboot.  Create any desired additional devices using
     204      <command>mknod</command>.
     205    </para>
     206
     207    <para>
     208      If you want to restore the dynamic devices, recreate the
     209      <filename>/etc/rc.d/rcS.d/{S10udev,S50udev_retry}</filename> symbolic
     210      links and reboot again.  Static devices do not need to be removed
     211      (console and null are always needed) because they are covered by the
     212      <systemitem class="filesystem">tmpfs</systemitem> partition.  Disk
     213      usage for devices is negligible (about 20&ndash;30 bytes per entry.)
     214    </para>
    175215
    176216  </sect2>
     
    179219    <title>Devices for DVD Drives</title>
    180220
    181     <para>If the initial boot process does not set up the
    182     <systemitem>/dev/dvd</systemitem> device properly, it can
    183     be installed using the following modification to the default udev rules.
    184     As the <systemitem class="username">root</systemitem> user, run:</para>
     221    <para>
     222      If the initial boot process does not set up the
     223      <systemitem>/dev/dvd</systemitem> device properly, it can
     224      be installed using the following modification to the default udev rules.
     225      As the <systemitem class="username">root</systemitem> user, run:
     226    </para>
    185227
    186228<screen><userinput>sed '1d;/SYMLINK.*cdrom/ a\
  • postlfs/config/firmware.xml

    rfa3edfef r81a73ed8  
    2020  </indexterm>
    2121
    22   <para> On some recent PCs it can be necessary, or desirable, to load firmware
    23   to make them work at their best. There is a directory, <filename
    24   class="directory">/lib/firmware</filename>, where the kernel or kernel
    25   drivers look for firmware images.</para>
    26 
    27   <para>Preparing firmware for multiple different machines, as a distro would
    28   do, is outside the scope of this book.</para>
    29 
    30   <para>Currently, most firmware can be found at a <userinput>git</userinput>
    31   repository: <ulink
    32   url="http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/"/>.
    33   For convenience, the LFS Project has created a mirror, updated daily, where
    34   these firmware files can be accessed via <userinput>wget</userinput> or a web
    35   browser at <ulink
    36   url="&sources-anduin-http;/linux-firmware/"/>.</para>
    37 
    38   <para>To get the firmware, either point a browser to one of the above
    39   repositories and then download the item(s) which you need, or install
    40   <userinput>git</userinput> and clone that repository.</para>
    41 
    42   <para>For some other firmware, particularly for Intel microcode and certain
    43   wifi devices, the needed firmware is not available in the above repository.
    44   Some of this will be addressed below, but a search of the Internet for needed
    45   firmware is sometimes necessary.</para>
    46 
    47   <para>Firmware files are conventionally referred to as blobs because you cannot
    48   determine what they will do. Note that firmware is distributed under various
    49   different licenses which do not permit disassembly or reverse-engineering.</para>
    50 
    51   <para>Firmware for PCs falls into four categories:</para>
     22  <para>
     23    On some recent PCs it can be necessary, or desirable, to load firmware
     24    to make them work at their best. There is a directory, <filename
     25    class="directory">/lib/firmware</filename>, where the kernel or kernel
     26    drivers look for firmware images.
     27  </para>
     28
     29  <para>
     30    Preparing firmware for multiple different machines, as a distro would
     31    do, is outside the scope of this book.
     32  </para>
     33
     34  <para>
     35    Currently, most firmware can be found at a <userinput>git</userinput>
     36    repository: <ulink url=
     37      "http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/"/>.
     38    For convenience, the LFS Project has created a mirror, updated daily, where
     39    these firmware files can be accessed via <userinput>wget</userinput> or a
     40    web browser at <ulink url="&sources-anduin-http;/linux-firmware/"/>.
     41  </para>
     42
     43  <para>
     44    To get the firmware, either point a browser to one of the above
     45    repositories and then download the item(s) which you need, or install
     46    <xref linkend="git"/> and clone that repository.
     47  </para>
     48
     49  <para>
     50    For some other firmware, particularly for Intel microcode and certain
     51    wifi devices, the needed firmware is not available in the above repository.
     52    Some of this will be addressed below, but a search of the Internet for
     53    needed firmware is sometimes necessary.
     54  </para>
     55
     56  <para>
     57    Firmware files are conventionally referred to as blobs because you cannot
     58    determine what they will do. Note that firmware is distributed under
     59    various different licenses which do not permit disassembly or
     60    reverse-engineering.
     61  </para>
     62
     63  <para>
     64    Firmware for PCs falls into four categories:
     65  </para>
    5266
    5367  <itemizedlist spacing="compact">
    5468    <listitem>
    55       <para>Updates to the CPU to work around errata, usually referred to as
    56        microcode.</para>
     69      <para>
     70        Updates to the CPU to work around errata, usually referred to as
     71        microcode.
     72      </para>
    5773    </listitem>
    5874    <listitem>
    59       <para>Firmware for video controllers. On x86 machines this seems to mostly
    60       apply to ATI devices (Radeon and AMDGPU chips) and Nvidia
    61       Maxwell and Pascal cards which all require firmware to be able to use KMS
    62       (kernel modesetting - the preferred option) as well as for Xorg. For
    63       earlier radeon chips (before the R600), the firmware is still in the
    64       kernel.</para>
     75      <para>
     76        Firmware for video controllers. On x86 machines this seems to mostly
     77        apply to ATI devices (Radeon and AMDGPU chips) and Nvidia Maxwell
     78        and Pascal cards which all require firmware to be able to use KMS
     79        (kernel modesetting - the preferred option) as well as for Xorg. For
     80        earlier radeon chips (before the R600), the firmware is still in the
     81        kernel.
     82      </para>
    6583    </listitem>
    6684    <listitem>
    67       <para>Firmware updates for wired network ports. Mostly they work even
    68       without the updates, but probably they will work better with
    69       the updated firmware. For some modern laptops, firmware for both
    70       wired ethernet (e.g. rtl_nic) and also for bluetooth devices (e.g. qca)
    71       is <emphasis>required</emphasis> before the wired network can be used.
     85      <para>
     86        Firmware updates for wired network ports. Mostly they work even
     87        without the updates, but probably they will work better with
     88        the updated firmware. For some modern laptops, firmware for both
     89        wired ethernet (e.g. rtl_nic) and also for bluetooth devices (e.g. qca)
     90        is <emphasis>required</emphasis> before the wired network can be used.
    7291      </para>
    7392    </listitem>
    7493    <listitem>
    75       <para>Firmware for other devices, such as wifi. These devices are not
    76       required for the PC to boot, but need the firmware before these devices
    77       can be used.</para>
     94      <para>
     95        Firmware for other devices, such as wifi. These devices are not
     96        required for the PC to boot, but need the firmware before these devices
     97        can be used.
     98      </para>
    7899    </listitem>
    79100  </itemizedlist>
    80101
    81   <note><para>Although not needed to load a firmware blob, the following
    82   tools may be useful for determining, obtaining, or preparing the needed
    83   firmware in order to load it into the system:
    84     <xref linkend="cpio"/>,
    85     <xref linkend="git"/>,
    86     <xref linkend="pciutils"/>, and
    87     <xref linkend="wget"/></para></note>
     102  <note>
     103    <para>
     104      Although not needed to load a firmware blob, the following
     105      tools may be useful for determining, obtaining, or preparing the needed
     106      firmware in order to load it into the system:
     107      <xref linkend="cpio"/>,
     108      <xref linkend="git"/>,
     109      <xref linkend="pciutils"/>, and
     110      <xref linkend="wget"/>
     111    </para>
     112  </note>
    88113
    89114  <para condition="html" role="usernotes">User Notes:
     
    93118    <title>Microcode updates for CPUs</title>
    94119
    95     <para>In general, microcode can be loaded by the BIOS or UEFI, and it might
    96     be updated by upgrading to a newer version of those. On linux, you can also
    97     load the microcode from the kernel if you are using an AMD family 10h or
    98     later processor (first introduced late 2007), or an Intel processor from
    99     1998 and later (Pentium4, Core, etc), if updated microcode has been
    100     released. These updates only last until the machine is powered off, so they
    101     need to be applied on every boot.</para>
    102 
    103     <para>Intel provide updates of their microcode for SandyBridge and later
    104     processors as new vulnerabilities come to light. New versions of AMD
    105     firmware are rare and usually only apply to a few models, although
    106     motherboard manufacturers get extra updates which maybe update microcode
    107     along with the changes to support newer CPUs and faster memory.</para>
    108 
    109     <para>There are two ways of loading the microcode, described as 'early'
    110     and 'late'. Early loading happens before userspace has been started, late
    111     loading happens after userspace has started. Not surprisingly, early loading
    112     is preferred, (see e.g. an explanatory comment in a kernel commit noted at
    113     <ulink url="https://lwn.net/Articles/530346/">x86/microcode: Early load
    114     microcode </ulink> on LWN.)  Indeed, it is needed to work around one
    115     particular erratum in early Intel Haswell processors which had TSX enabled.
    116     (See <ulink
    117     url="http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwellyi/">
    118     Intel Disables TSX Instructions: Erratum Found in Haswell, Haswell-E/EP,
    119     Broadwell-Y</ulink>.) Without this update glibc can do the wrong thing in
    120     uncommon situations. </para>
    121 
    122     <para>It is still possible to manually force late loading of microcode,
    123     either for testing or to prevent having to reboot. You will need to
    124     reconfigure your kernel for either method. The instructions here will
    125     create a kernel <filename>.config</filename> to suite early loading, before
    126     forcing late loading to see if there is any microcode. If there is, the
    127     instructions then show you how to create an initrd for early loading.</para>
    128 
    129     <para>To confirm what processor(s) you have (if more than one, they will be
    130     identical) look in /proc/cpuinfo.</para>
     120    <para>
     121      In general, microcode can be loaded by the BIOS or UEFI, and it might be
     122      updated by upgrading to a newer version of those. On linux, you can also
     123      load the microcode from the kernel if you are using an AMD family 10h or
     124      later processor (first introduced late 2007), or an Intel processor from
     125      1998 and later (Pentium4, Core, etc), if updated microcode has been
     126      released. These updates only last until the machine is powered off, so
     127      they need to be applied on every boot.
     128    </para>
     129
     130    <para>
     131      Intel provide updates of their microcode for SandyBridge and later
     132      processors as new vulnerabilities come to light. New versions of AMD
     133      firmware are rare and usually only apply to a few models, although
     134      motherboard manufacturers get extra updates which maybe update microcode
     135      along with the changes to support newer CPUs and faster memory.
     136    </para>
     137
     138    <para>
     139      There are two ways of loading the microcode, described as 'early' and
     140      'late'. Early loading happens before userspace has been started, late
     141      loading happens after userspace has started. Not surprisingly, early
     142      loading is preferred, (see e.g. an explanatory comment in a kernel
     143      commit noted at <ulink url="https://lwn.net/Articles/530346/">
     144        x86/microcode: Early load microcode</ulink> on LWN.)  Indeed, it
     145      is needed to work around one particular erratum in early Intel Haswell
     146      processors which had TSX enabled.  (See <ulink url=
     147      "http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwellyi/">
     148        Intel Disables TSX Instructions: Erratum Found in Haswell,
     149        Haswell-E/EP, Broadwell-Y
     150      </ulink>.) Without this update glibc can do the wrong thing in uncommon
     151      situations.
     152    </para>
     153
     154    <para>
     155      It is still possible to manually force late loading of microcode, either
     156      for testing or to prevent having to reboot. You will need to reconfigure
     157      your kernel for either method. The instructions here will create a
     158      kernel <filename>.config</filename> to suite early loading, before
     159      forcing late loading to see if there is any microcode. If there is,
     160      the instructions then show you how to create an initrd for early loading.
     161    </para>
     162
     163    <para>
     164      To confirm what processor(s) you have (if more than one, they will be
     165      identical) look in /proc/cpuinfo.
     166    </para>
    131167
    132168    <sect3 id="intel-microcode">
    133169      <title>Intel Microcode for the CPU</title>
    134170
    135      <para>The first step is to get the most recent version of the Intel
    136      microcode.  This must be done by navigating to <ulink
    137      url='https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/'/>
    138      and downloading the latest file there.  As of this writing the most recent
    139      version of the microcode is microcode-20191115.
    140      Extract this file in the normal way, the microcode is in the <filename>intel-ucode</filename>
    141      directory, containing various blobs with names in the form XX-YY-ZZ.
    142      There are also various other files, and a releasenote.</para>
    143 
    144      <para>In the past, intel did not provide any details of which blobs had
    145      changed versions, but now the release note details this.</para>
    146 
    147      <para>The recent firmware for older processors is provided to deal with
    148      vulnerabilities which have now been made public, and for some of these such
    149      as Microarchitectural Data Sampling (MDS) you might wish to increase the
    150      protection by disabling hyperthreading, or alternatively to disable the
    151      kernel's default mitigation because of its impact on compile times. Please
    152      read the online documentation at <ulink
    153      url='https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html'/>.
    154      </para>
    155 
    156      <para>To be able to use this latest microcode to provide mitigation on all
    157      the affected processors, the kernel version needs to be at least 5.3.11 (or
    158      4.19.84 if you are using the 4.19 long term support series).</para>
    159 
    160      <para>Now you need to determine your processor's identity to see if there
    161      is any microcode for it. Determine the decimal values of the cpu family,
    162      model and stepping by running the following command (it will also report
    163      the current microcode version):</para>
     171      <para>
     172        The first step is to get the most recent version of the Intel
     173        microcode.  This must be done by navigating to <ulink url=
     174         'https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/'/>
     175        and downloading the latest file there.  As of this writing the most
     176        recent version of the microcode is microcode-20191115.  Extract this
     177        file in the normal way, the microcode is in the <filename>intel-ucode
     178        </filename> directory, containing various blobs with names in the form
     179        XX-YY-ZZ. There are also various other files, and a releasenote.
     180      </para>
     181
     182      <para>
     183        In the past, intel did not provide any details of which blobs had
     184        changed versions, but now the release note details this.
     185      </para>
     186
     187      <para>
     188        The recent firmware for older processors is provided to deal with
     189        vulnerabilities which have now been made public, and for some of these
     190        such as Microarchitectural Data Sampling (MDS) you might wish to
     191        increase the protection by disabling hyperthreading, or alternatively
     192        to disable the kernel's default mitigation because of its impact on
     193        compile times. Please read the online documentation at <ulink url=
     194        'https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html'/>.
     195      </para>
     196
     197      <para>
     198        To be able to use this latest microcode to provide mitigation on all
     199        the affected processors, the kernel version needs to be at least 5.3.11
     200        (or 4.19.84 if you are using the 4.19 long term support series).
     201      </para>
     202
     203      <para>
     204        Now you need to determine your processor's identity to see if there
     205        is any microcode for it. Determine the decimal values of the cpu family,
     206        model and stepping by running the following command (it will also report
     207        the current microcode version):
     208      </para>
    164209
    165210<screen><userinput>head -n7 /proc/cpuinfo</userinput></screen>
    166211
    167       <para>Convert the cpu family, model and stepping to pairs of hexadecimal
    168       digits. For a Skylake i3 6100 (described as Intel(R) Core(TM) i3-6100
    169       CPU) the relevant values are cpu family 6, model 94, stepping 3 so in
    170       this case the required identification is 06-5e-03. A look at the blobs
    171       will show that there is one for this CPU (although for older issues it
    172       might have already been applied by the BIOS). If there is a blob for your
    173       system then test if it will be applied by copying it (replace &lt;XX-YY-ZZ&gt;
    174       by the identifier for your machine) to where the kernel can find it:</para>
     212      <para>
     213        Convert the cpu family, model and stepping to pairs of hexadecimal
     214        digits. For a Skylake i3 6100 (described as Intel(R) Core(TM) i3-6100
     215        CPU) the relevant values are cpu family 6, model 94, stepping 3 so in
     216        this case the required identification is 06-5e-03. A look at the blobs
     217        will show that there is one for this CPU (although for older issues it
     218        might have already been applied by the BIOS). If there is a blob for
     219        your system then test if it will be applied by copying it (replace
     220        &lt;XX-YY-ZZ&gt; by the identifier for your CPU) to where the
     221        kernel can find it:
     222      </para>
    175223
    176224<screen><userinput>mkdir -pv /lib/firmware/intel-ucode
    177225cp -v intel-ucode/&lt;XX-YY-ZZ&gt; /lib/firmware/intel-ucode</userinput></screen>
    178226
    179       <para>Now that the Intel microcode has been prepared, use the following
    180       options when you configure the kernel to load Intel
    181       microcode:</para>
     227      <para>
     228        Now that the Intel microcode has been prepared, use the following
     229        options when you configure the kernel to load Intel microcode:
     230      </para>
    182231
    183232<screen><literal>General Setup ---&gt;
     
    187236  [y]      Intel microcode loading support [CONFIG_MICROCODE_INTEL]</literal></screen>
    188237
    189       <para>After you have successfully booted the new system, force late loading by
    190       using the command:</para>
     238      <para>
     239        After you have successfully booted the new system, force late loading
     240        by using the command:
     241      </para>
    191242
    192243<screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>
    193244
    194       <para>Then use the following command to see if anything was loaded:</para>
     245      <para>
     246        Then use the following command to see if anything was loaded:
     247      </para>
    195248
    196249<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
    197250
    198       <para>This reformatted example was created by temporarily booting without
    199       microcode, to show the current Firmware Bug message, then the late load
    200       shows it being updated to revision 0xd6.</para>
     251      <para>
     252        This reformatted example was created by temporarily booting without
     253        microcode, to show the current Firmware Bug message, then the late load
     254        shows it being updated to revision 0xd6.
     255      </para>
    201256
    202257<screen><literal>[    0.000000] Linux version 5.4.2 (lfs@leshp) (gcc version 9.2.0 (GCC))
     
    211266[  277.674231] x86/CPU: CPU features have changed after loading microcode, but might not take effect</literal></screen>
    212267
    213     <para>If the microcode was not updated, there is no new microcode for
    214     this system's processor. If it did get updated, you can now proceed to <xref
    215     linkend='early-microcode'/>.</para>
     268      <para>
     269        If the microcode was not updated, there is no new microcode for this
     270        system's processor. If it did get updated, you can now proceed to
     271        <xref linkend='early-microcode'/>.
     272      </para>
    216273
    217274    </sect3>
     
    220277      <title>AMD Microcode for the CPU</title>
    221278
    222       <para>Begin by downloading a container of firmware for your CPU family
    223       from <ulink
    224       url='&sources-anduin-http;/linux-firmware/amd-ucode/'/>.
    225       The family is always specified in hex. Families 10h to 14h (16 to 20)
    226       are in microcode_amd.bin.  Families 15h, 16h and 17h have their own containers.
    227       Create the required directory and put the firmware you downloaded into
    228       it as the <systemitem class="username">root</systemitem> user:</para>
     279      <para>
     280        Begin by downloading a container of firmware for your CPU family
     281        from <ulink url=
     282          '&sources-anduin-http;/linux-firmware/amd-ucode/'/>.
     283        The family is always specified in hex. Families 10h to 14h (16 to 20)
     284        are in microcode_amd.bin.  Families 15h, 16h and 17h have their own
     285        containers.  Create the required directory and put the firmware you
     286        downloaded into it as the <systemitem
     287        class="username">root</systemitem> user:
     288      </para>
    229289
    230290<screen><userinput>mkdir -pv /lib/firmware/amd-ucode
    231291cp -v microcode_amd* /lib/firmware/amd-ucode</userinput></screen>
    232292
    233       <para>When you configure the kernel, use the following options
    234       to load AMD microcode:</para>
     293      <para>
     294        When you configure the kernel, use the following options
     295        to load AMD microcode:
     296      </para>
    235297
    236298<screen><literal>General Setup ---&gt;
     
    240302  [y]      AMD microcode loading support [CONFIG_MICROCODE_AMD]</literal></screen>
    241303
    242       <para>After you have successfully booted the new system, force late loading by
    243       using the command:</para>
     304      <para>
     305        After you have successfully booted the new system, force late loading
     306        by using the command:
     307      </para>
    244308
    245309<screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>
    246310
    247       <para>Then use the following command to see if anything was loaded:</para>
     311      <para>
     312        Then use the following command to see if anything was loaded:
     313      </para>
    248314
    249315<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
    250       <para>This historic example from an old Athlon(tm) II X2 shows it has been
    251       updated. At that time, all CPUs were still reported in the microcode details on
    252       AMD machines (the current position for AMD machines where newer microcode is
    253       available is unknown) :</para>
     316      <para>
     317        This historic example from an old Athlon(tm) II X2 shows it has been
     318        updated. At that time, all CPUs were still reported in the microcode
     319        details on AMD machines (the current position for AMD machines where
     320        newer microcode is available is unknown) :
     321      </para>
    254322
    255323<screen><literal>[    0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))
     
    262330[  187.928899] microcode: CPU1: new patch_level=0x010000c8</literal></screen>
    263331
    264     <para>If the microcode was not updated, there is no new microcode for
    265     this system's processor. If it did get updated, you can now proceed to <xref
    266     linkend='early-microcode'/>.</para>
     332      <para>
     333        If the microcode was not updated, there is no new microcode for
     334        this system's processor. If it did get updated, you can now proceed to
     335        <xref linkend='early-microcode'/>.
     336      </para>
    267337
    268338    </sect3>
     
    271341      <title>Early loading of microcode</title>
    272342
    273       <para>If you have established that updated microcode is available for
    274       your system, it is time to prepare it for early loading. This requires
    275       an additional package, <xref linkend='cpio'/> and the creation of an
    276       initrd which will need to be added to grub.cfg.</para>
    277 
    278       <para>It does not matter where you prepare the initrd, and once it is
    279       working you can apply the same initrd to later LFS systems or newer
    280       kernels on this same machine, at least until any newer microcode is
    281       released. Use the following commands:</para>
     343      <para>
     344        If you have established that updated microcode is available for
     345        your system, it is time to prepare it for early loading. This requires
     346        an additional package, <xref linkend='cpio'/> and the creation of an
     347        initrd which will need to be added to grub.cfg.
     348      </para>
     349
     350      <para>
     351        It does not matter where you prepare the initrd, and once it is
     352        working you can apply the same initrd to later LFS systems or newer
     353        kernels on this same machine, at least until any newer microcode is
     354        released. Use the following commands:
     355      </para>
    282356
    283357<screen><userinput>mkdir -p initrd/kernel/x86/microcode
    284358cd initrd</userinput></screen>
    285359
    286       <para>For an AMD machine, use the following command (replace
    287       &lt;MYCONTAINER&gt; with the name of the container for your CPU's
    288       family):</para>
     360      <para>
     361        For an AMD machine, use the following command (replace
     362        &lt;MYCONTAINER&gt; with the name of the container for your CPU's
     363        family):
     364      </para>
    289365
    290366<screen><userinput>cp -v /lib/firmware/amd-ucode/&lt;MYCONTAINER&gt; kernel/x86/microcode/AuthenticAMD.bin</userinput></screen>
    291367
    292       <para>Or for an Intel machine copy the appropriate blob using this command:</para>
     368      <para>
     369        Or for an Intel machine copy the appropriate blob using this command:
     370      </para>
    293371
    294372<screen><userinput>cp -v /lib/firmware/intel-ucode/&lt;XX-YY-ZZ&gt; kernel/x86/microcode/GenuineIntel.bin</userinput></screen>
    295373
    296       <para>Now prepare the initrd:</para>
     374      <para>
     375        Now prepare the initrd:
     376      </para>
    297377
    298378<screen><userinput>find . | cpio -o -H newc &gt; /boot/microcode.img</userinput></screen>
    299379
    300       <para>You now need to add a new entry to /boot/grub/grub.cfg and
    301       here you should add a new line after the linux line within the stanza.
    302       If /boot is a separate mountpoint: </para>
     380      <para>
     381        You now need to add a new entry to /boot/grub/grub.cfg and
     382        here you should add a new line after the linux line within the stanza.
     383        If /boot is a separate mountpoint:
     384       </para>
    303385
    304386<screen><userinput>initrd /microcode.img</userinput></screen>
    305387
    306       <para>or this if it is not:</para>
     388      <para>
     389        or this if it is not:
     390      </para>
    307391
    308392<screen><userinput>initrd /boot/microcode.img</userinput></screen>
    309393
    310       <para>If you are already booting with an initrd (see <xref
    311       linkend="initramfs"/>), you should run <command>mkinitramfs</command>
    312       again after putting the appropriate blob or container into <filename
    313       class="directory">/lib/firmware</filename> as explained above.
    314       Alternatively, you can have both initrd on the same line, such as
    315       <userinput>initrd /microcode.img /other-initrd.img</userinput> (adapt
    316       that as above if /boot is not a separate mountpoint).</para>
    317 
    318       <para>You can now reboot with the added initrd, and then use the same
    319       command to check that the early load worked.</para>
     394      <para>
     395        If you are already booting with an initrd (see <xref
     396        linkend="initramfs"/>), you should run <command>mkinitramfs</command>
     397        again after putting the appropriate blob or container into <filename
     398        class="directory">/lib/firmware</filename> as explained above.
     399        Alternatively, you can have both initrd on the same line, such as
     400        <userinput>initrd /microcode.img /other-initrd.img</userinput> (adapt
     401        that as above if /boot is not a separate mountpoint).
     402      </para>
     403
     404      <para>
     405        You can now reboot with the added initrd, and then use the same
     406        command to check that the early load worked:
     407      </para>
    320408
    321409<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
    322410
    323       <para>If you updated to address vulnerabilities, you can look at <filename
    324       class="directory">/sys/devices/system/cpu/vulnerabilities/</filename> to
    325       see what is now reported.</para>
    326 
    327       <para>The places and times where early loading happens are very different
    328       in AMD and Intel machines. First, an Intel example with early loading:</para>
     411      <para>
     412        If you updated to address vulnerabilities, you can look at <filename
     413        class="directory">/sys/devices/system/cpu/vulnerabilities/</filename>
     414        to see what is now reported.
     415      </para>
     416
     417      <para>
     418        The places and times where early loading happens are very different
     419        in AMD and Intel machines. First, an Intel example with early loading:
     420      </para>
    329421
    330422<screen><literal>[    0.000000] microcode: microcode updated early to revision 0xd6, date = 2019-10-03
     
    335427[    0.579961] microcode: Microcode Update Driver: v2.2.</literal></screen>
    336428
    337       <para>A historic AMD example:</para>
     429      <para>
     430        A historic AMD example:
     431      </para>
    338432
    339433<screen><literal>[    0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))
     
    352446    <title>Firmware for Video Cards</title>
    353447
    354   <sect3 id="ati-video-firmware">
    355     <title>Firmware for ATI video chips (R600 and later)</title>
    356 
    357     <para>These instructions do NOT apply to old radeons before the R600
    358     family. For those, the firmware is in the kernel's <filename
    359     class='directory'>/lib/firmware/</filename> directory. Nor do they apply if
    360     you intend to avoid a graphical setup such as Xorg and are content to use
    361     the default 80x25 display rather than a framebuffer. </para>
    362 
    363     <para> Early radeon devices only needed a single 2K blob of firmware.
    364     Recent devices need several different blobs, and some of them are much
    365     bigger. The total size of the radeon firmware directory is over 500K &mdash; on a
    366     large modern system you can probably spare the space, but it is still
    367     redundant to install all the unused files each time you build a system.</para>
    368 
    369     <para>A better approach is to install <xref linkend='pciutils'/> and then
    370     use <userinput>lspci</userinput> to identify which VGA controller is
    371     installed.</para>
    372 
    373     <para>With that information, check the RadeonFeature page of the Xorg wiki
    374     for <ulink url="http://wiki.x.org/wiki/RadeonFeature/#index5h2">Decoder
    375     ring for engineering vs marketing names</ulink> to identify the family (you
    376     may need to know this for the Xorg driver in BLFS &mdash; Southern Islands and
    377     Sea Islands use the radeonsi driver) and the specific model.</para>
    378 
    379     <para>Now that you know which controller you are using, consult the
    380     <ulink url="https://wiki.gentoo.org/wiki/Radeon#Firmware">Radeon</ulink> page
    381     of the Gentoo wiki which has a table listing the required firmware blobs
    382     for the various chipsets. Note that Southern Islands and Sea Islands chips
    383     use different firmware for kernel 3.17 and later compared to earlier
    384     kernels. Identify and download the required blobs then install them:</para>
     448    <sect3 id="ati-video-firmware">
     449      <title>Firmware for ATI video chips (R600 and later)</title>
     450
     451      <para>
     452        These instructions do NOT apply to old radeons before the R600
     453        family. For those, the firmware is in the kernel's <filename
     454        class='directory'>/lib/firmware/</filename> directory. Nor do they
     455        apply if you intend to avoid a graphical setup such as Xorg and are
     456        content to use the default 80x25 display rather than a framebuffer.
     457      </para>
     458
     459      <para>
     460        Early radeon devices only needed a single 2K blob of firmware. Recent
     461        devices need several different blobs, and some of them are much bigger.
     462        The total size of the radeon firmware directory is over 500K &mdash;
     463        on a large modern system you can probably spare the space, but it is
     464        still redundant to install all the unused files each time you build
     465        a system.
     466      </para>
     467
     468      <para>
     469        A better approach is to install <xref linkend='pciutils'/> and then
     470        use <userinput>lspci</userinput> to identify which VGA controller is
     471        installed.
     472      </para>
     473
     474      <para>
     475        With that information, check the RadeonFeature page of the Xorg wiki
     476        for <ulink url="http://wiki.x.org/wiki/RadeonFeature/#index5h2">Decoder
     477        ring for engineering vs marketing names</ulink> to identify the family
     478        (you may need to know this for the Xorg driver in BLFS &mdash;
     479        Southern Islands and Sea Islands use the radeonsi driver) and the
     480        specific model.
     481      </para>
     482
     483      <para>
     484        Now that you know which controller you are using, consult the
     485        <ulink url="https://wiki.gentoo.org/wiki/Radeon#Firmware">
     486           Radeon</ulink> page of the Gentoo wiki which has a table listing
     487        the required firmware blobs for the various chipsets. Note that
     488        Southern Islands and Sea Islands chips use different firmware for
     489        kernel 3.17 and later compared to earlier kernels. Identify and
     490        download the required blobs then install them:
     491      </para>
    385492
    386493<screen><userinput>mkdir -pv /lib/firmware/radeon
    387494cp -v &lt;YOUR_BLOBS&gt; /lib/firmware/radeon</userinput></screen>
    388495
    389     <para>There are actually two ways of installing this firmware. BLFS, in the
    390     'Kernel Configuration for additional firmware' section part of the <xref
    391     linkend="xorg-ati-driver"/> section  gives an example of compiling the
    392     firmware into the kernel - that is slightly faster to load, but uses more
    393     kernel memory. Here we will use the alternative method of making the radeon
    394     driver a module. In your kernel config set the following: </para>
     496      <para>
     497        There are actually two ways of installing this firmware. BLFS, in the
     498        'Kernel Configuration for additional firmware' section part of the
     499        <xref linkend="xorg-ati-driver"/> section gives an example of
     500        compiling the firmware into the kernel - that is slightly faster to
     501        load, but uses more kernel memory. Here we will use the alternative
     502        method of making the radeon driver a module. In your kernel config
     503        set the following:
     504      </para>
    395505
    396506<screen><literal>Device Drivers ---&gt;
     
    400510      &lt;m&gt; ATI Radeon                                        [CONFIG_DRM_RADEON]</literal></screen>
    401511
    402     <para>Loading several large blobs from /lib/firmware takes a noticeable
    403     time, during which the screen will be blank. If you do not enable the
    404     penguin framebuffer logo, or change the console size by using a bigger
    405     font, that probably does not matter. If desired, you can slightly
    406     reduce the time if you follow the alternate method of specifying 'y' for
    407     CONFIG_DRM_RADEON covered in BLFS at the link above &mdash; you must specify each
    408     needed radeon blob if you do that.</para>
    409 
    410   </sect3>
    411 
    412   <sect3 id="nvidia-video-firmware">
    413     <title>Firmware for Nvidia video chips</title>
    414 
    415     <para>Some Nvidia graphics chips need firmware updates to take advantage
    416     of all the card's capability.  These are generally the GeForce 8, 9, 9300,
    417     and 200-900 series chips.  For more exact information, see <ulink
    418     url="https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware">
    419     https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware</ulink>.</para>
     512      <para>
     513        Loading several large blobs from /lib/firmware takes a noticeable
     514        time, during which the screen will be blank. If you do not enable the
     515        penguin framebuffer logo, or change the console size by using a bigger
     516        font, that probably does not matter. If desired, you can slightly
     517        reduce the time if you follow the alternate method of specifying 'y'
     518        for CONFIG_DRM_RADEON covered in BLFS at the link above &mdash; you
     519        must specify each needed radeon blob if you do that.
     520      </para>
     521
     522    </sect3>
     523
     524    <sect3 id="nvidia-video-firmware">
     525      <title>Firmware for Nvidia video chips</title>
     526
     527      <para>
     528        Some Nvidia graphics chips need firmware updates to take advantage
     529        of all the card's capability.  These are generally the GeForce 8, 9,
     530        9300, and 200-900 series chips.  For more exact information, see
     531        <ulink url=
     532          "https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware"/>.
     533      </para>
    420534   
    421     <para>First, the kernel Nvidia driver must be activated:</para>
     535      <para>
     536        First, the kernel Nvidia driver must be activated:
     537      </para>
    422538
    423539<screen><literal>Device Drivers ---&gt;
     
    427543      &lt;*/m&gt; Nouveau (NVIDIA) cards                          [CONFIG_DRM_NOUVEAU]</literal></screen>
    428544
    429     <para>The steps to install the Nvidia firmware are:</para>
     545      <para>
     546        The steps to install the Nvidia firmware are:
     547      </para>
    430548
    431549<screen><userinput>wget https://raw.github.com/imirkin/re-vp2/master/extract_firmware.py
     
    436554cp -d nv* vuc-* /lib/firmware/nouveau/</userinput></screen>
    437555
    438   </sect3>
     556    </sect3>
    439557  </sect2>
    440558
     
    442560    <title>Firmware for Network Interfaces</title>
    443561
    444     <para>The kernel likes to load firmware for some network drivers,
    445     particularly those from Realtek (the /lib/linux-firmware/rtl_nic/) directory,
    446     but they generally appear to work without it. Therefore, you can boot the
    447     kernel, check dmesg for messages about this missing firmware, and if
    448     necessary download the firmware and put it in the specified directory in
    449     /lib/firmware so that it will be found on subsequent boots. Note that with
    450     current kernels this works whether or not the driver is compiled in or
    451     built as a module, there is no need to build this firmware into the kernel.
    452     Here is an example where the R8169 driver has been compiled in but the
    453     firmware was not made available. Once the firmware had been provided, there
    454     was no mention of it on later boots. </para>
     562    <para>
     563      The kernel likes to load firmware for some network drivers, particularly
     564      those from Realtek (the /lib/linux-firmware/rtl_nic/) directory, but
     565      they generally appear to work without it. Therefore, you can boot the
     566      kernel, check dmesg for messages about this missing firmware, and if
     567      necessary download the firmware and put it in the specified directory in
     568      <filename class="directory">/lib/firmware</filename> so that it will
     569      be found on subsequent boots. Note that with current kernels this
     570      works whether or not the driver is compiled in or built as a module,
     571      there is no need to build this firmware into the kernel.
     572      Here is an example where the R8169 driver has been compiled in but the
     573      firmware was not made available. Once the firmware had been provided,
     574      there was no mention of it on later boots.
     575    </para>
    455576
    456577<screen><literal>dmesg | grep firmware | grep r8169
     
    463584    <title>Firmware for Other Devices</title>
    464585
    465     <para> Identifying the correct firmware will typically require you to
    466     install <xref linkend='pciutils'/>, and then use
    467     <userinput>lspci</userinput> to identify the device. You should then search
    468     online to check which module it uses, which firmware, and where to obtain
    469     the firmware &mdash; not all of it is in linux-firmware.</para>
    470 
    471     <para>If possible, you should begin by using a wired connection when you
    472     first boot your LFS system. To use a wireless connection you will need to
    473     use a network tools such as <xref linkend='wireless_tools'/> and <xref
    474     linkend='wpa_supplicant'/>.</para>
    475 
    476     <para>Firmware may also be needed for other devices such as some SCSI
    477     controllers, bluetooth adaptors, or TV recorders. The same principles
    478     apply.</para>
     586    <para>
     587      Identifying the correct firmware will typically require you to install
     588      <xref linkend='pciutils'/>, and then use <userinput>lspci</userinput>
     589      to identify the device. You should then search online to check which
     590      module it uses, which firmware, and where to obtain the firmware &mdash;
     591      not all of it is in linux-firmware.
     592    </para>
     593
     594    <para>
     595      If possible, you should begin by using a wired connection when you first
     596      boot your LFS system. To use a wireless connection you will need to
     597      use a network tools such as <xref linkend='wireless_tools'/> and <xref
     598      linkend='wpa_supplicant'/>.
     599    </para>
     600
     601    <para>
     602      Firmware may also be needed for other devices such as some SCSI
     603      controllers, bluetooth adaptors, or TV recorders. The same principles
     604      apply.
     605    </para>
    479606
    480607  </sect2>
  • postlfs/config/logon.xml

    rfa3edfef r81a73ed8  
    2020  </indexterm>
    2121
    22   <para>When you first boot up your new LFS system, the logon screen will
    23   be nice and plain (as it should be in a bare-bones system).  Many people
    24   however, will want their system to display some information in the logon
    25   message.  This can be accomplished using the
    26   file <filename>/etc/issue</filename>.</para>
     22  <para>
     23    When you first boot up your new LFS system, the logon screen will be
     24    nice and plain (as it should be in a bare-bones system).  Many people
     25    however, will want their system to display some information in the logon
     26    message.  This can be accomplished using the
     27    file <filename>/etc/issue</filename>.
     28  </para>
    2729
    28   <para>The <filename>/etc/issue</filename> file is a plain text file
    29   which will also accept certain escape sequences (see below) in order to
    30   insert information about the system.  There is also the file
    31   <filename>issue.net</filename> which can be used when logging on remotely.
    32   <command>ssh</command> however, will only use it if you set the option in the
    33   configuration file and will <emphasis>not</emphasis> interpret the
    34   escape sequences shown below.</para>
     30  <para>
     31    The <filename>/etc/issue</filename> file is a plain text file
     32    which will also accept certain escape sequences (see below) in order to
     33    insert information about the system.  There is also the file
     34    <filename>issue.net</filename> which can be used when logging on remotely.
     35    <command>ssh</command> however, will only use it if you set the option in
     36    the configuration file and will <emphasis>not</emphasis> interpret the
     37    escape sequences shown below.
     38  </para>
    3539
    36   <para>One of the most common things which people want to do is clear the
    37   screen at each logon.  The easiest way of doing that is to put a "clear"
    38   escape sequence into <filename>/etc/issue</filename>.  A simple way of doing
    39   this is to issue the command <command>clear &gt; /etc/issue</command>.  This
    40   will insert the relevant escape code into the start of the
    41   <filename>/etc/issue</filename> file.  Note that if you do this, when you
    42   edit the file, you should leave the characters (normally '^[[H^[[2J') on the
    43   first line alone.</para>
     40  <para>
     41    One of the most common things which people want to do is clear the
     42    screen at each logon.  The easiest way of doing that is to put a "clear"
     43    escape sequence into <filename>/etc/issue</filename>.  A simple way of
     44    doing this is to issue the command <command>clear &gt;
     45    /etc/issue</command>.  This will insert the relevant escape code into
     46    the start of the <filename>/etc/issue</filename> file.  Note that if
     47    you do this, when you edit the file, you should leave the characters
     48    (normally '^[[H^[[2J') on the first line alone.
     49  </para>
    4450
    45   <note><para>Terminal escape sequences are special codes recognized by the
    46   terminal.  The ^[ represents an ASCII ESC character.  The sequence ESC [ H
    47   puts the cursor in the upper left hand corner of the screen and ESC 2 J
    48   erases the screen.  For more information on terminal escape sequences see
    49   <ulink url='http://rtfm.etla.org/xterm/ctlseq.html'/></para></note>
     51  <note>
     52    <para>
     53      Terminal escape sequences are special codes recognized by the terminal.
     54      The ^[ represents an ASCII ESC character.  The sequence ESC [ H
     55      puts the cursor in the upper left hand corner of the screen and ESC 2 J
     56      erases the screen.  For more information on terminal escape sequences see
     57      <ulink url='http://rtfm.etla.org/xterm/ctlseq.html'/>
     58    </para>
     59  </note>
    5060
    51   <para>The following sequences are recognized by <command>agetty</command>
    52   (the program which usually parses <filename>/etc/issue</filename>).  This
    53   information is from <command>man agetty</command> where you can find
    54   extra information about the logon process.</para>
     61  <para>
     62    The following sequences are recognized by <command>agetty</command>
     63    (the program which usually parses <filename>/etc/issue</filename>).  This
     64    information is from <command>man agetty</command> where you can find
     65    extra information about the logon process.
     66  </para>
    5567
    56   <para>The <filename>issue</filename> file can contain certain character
    57   sequences to display various information.  All <filename>issue</filename>
    58   sequences consist of a backslash (\) immediately followed by one of the
    59   letters explained below (so <option>\d</option> in
    60   <filename>/etc/issue</filename> would insert the current date).</para>
     68  <para>
     69    The <filename>issue</filename> file can contain certain character
     70    sequences to display various information.  All <filename>issue</filename>
     71    sequences consist of a backslash (\) immediately followed by one of the
     72    letters explained below (so <option>\d</option> in
     73    <filename>/etc/issue</filename> would insert the current date).
     74  </para>
    6175
    6276<screen><literal>b   Insert the baudrate of the current line.
  • postlfs/config/profile.xml

    rfa3edfef r81a73ed8  
    1616  <title>The Bash Shell Startup Files</title>
    1717
    18   <para>The shell program <filename>/bin/bash</filename> (hereafter
    19   referred to as just "the shell") uses a collection of startup files to
    20   help create an environment.  Each file has a specific use and
    21   may affect login and interactive environments differently.  The files in
    22   the <filename class="directory">/etc</filename> directory generally provide
    23   global settings. If an equivalent file exists in your home directory it may
    24   override the global settings.</para>
    25 
    26   <para>An interactive login shell is started after a successful login, using
    27   <filename>/bin/login</filename>, by reading the
    28   <filename>/etc/passwd</filename> file. This shell invocation normally reads
    29   <filename>/etc/profile</filename> and its private equivalent
    30   <filename>~/.bash_profile</filename> (or <filename>~/.profile</filename> if
    31   called as <command>/bin/sh</command>) upon startup.</para>
    32 
    33   <para>An interactive non-login shell is normally started at the command-line
    34   using a shell program (e.g.,
    35   <prompt>[prompt]$</prompt><command>/bin/bash</command>) or by the
    36   <command>/bin/su</command> command.  An interactive non-login shell is also
    37   started with a terminal program such as <command>xterm</command> or
    38   <command>konsole</command> from within a graphical environment. This type of
    39   shell invocation normally copies the parent environment and then reads the
    40   user's <filename>~/.bashrc</filename> file for additional startup
    41   configuration instructions.</para>
    42 
    43   <para>A non-interactive shell is usually present when a shell script is
    44   running.  It is non-interactive because it is processing a script and not
    45   waiting for user input between commands. For these shell invocations, only
    46   the environment inherited from the parent shell is used.</para>
    47 
    48   <para> The file <filename>~/.bash_logout</filename> is not used for an
    49   invocation of the shell.  It is read and executed when a user exits from an
    50   interactive login shell.</para>
    51 
    52   <para>Many distributions use <filename>/etc/bashrc</filename> for system wide
    53   initialization of non-login shells. This file is usually called from the
    54   user's <filename>~/.bashrc</filename> file and is not built directly into
    55   <command>bash</command> itself.  This convention is followed in this
    56   section.</para>
    57 
    58   <para>For more information see <command>info bash</command> --
    59   <emphasis role="strong">Nodes: Bash Startup Files and Interactive
    60   Shells</emphasis>.</para>
     18  <para>
     19    The shell program <filename>/bin/bash</filename> (hereafter referred to
     20    as just "the shell") uses a collection of startup files to help create
     21    an environment.  Each file has a specific use and may affect login and
     22    interactive environments differently.  The files in the <filename
     23    class="directory">/etc</filename> directory generally provide global
     24    settings. If an equivalent file exists in your home directory it may
     25    override the global settings.
     26  </para>
     27
     28  <para>
     29    An interactive login shell is started after a successful login, using
     30    <filename>/bin/login</filename>, by reading the
     31    <filename>/etc/passwd</filename> file. This shell invocation normally reads
     32    <filename>/etc/profile</filename> and its private equivalent
     33    <filename>~/.bash_profile</filename> (or <filename>~/.profile</filename>
     34    if called as <command>/bin/sh</command>) upon startup.
     35  </para>
     36
     37  <para>
     38    An interactive non-login shell is normally started at the command-line
     39    using a shell program (e.g.,
     40    <prompt>[prompt]$</prompt><command>/bin/bash</command>) or by the
     41    <command>/bin/su</command> command.  An interactive non-login shell is also
     42    started with a terminal program such as <command>xterm</command> or
     43    <command>konsole</command> from within a graphical environment. This type
     44    of shell invocation normally copies the parent environment and then reads
     45    the user's <filename>~/.bashrc</filename> file for additional startup
     46    configuration instructions.
     47  </para>
     48
     49  <para>
     50    A non-interactive shell is usually present when a shell script is
     51    running.  It is non-interactive because it is processing a script and not
     52    waiting for user input between commands. For these shell invocations, only
     53    the environment inherited from the parent shell is used.
     54  </para>
     55
     56  <para>
     57    The file <filename>~/.bash_logout</filename> is not used for an
     58    invocation of the shell.  It is read and executed when a user exits from an
     59    interactive login shell.
     60  </para>
     61
     62  <para>
     63    Many distributions use <filename>/etc/bashrc</filename> for system wide
     64    initialization of non-login shells. This file is usually called from the
     65    user's <filename>~/.bashrc</filename> file and is not built directly into
     66    <command>bash</command> itself.  This convention is followed in this
     67    section.
     68  </para>
     69
     70  <para>
     71    For more information see <command>info bash</command> --
     72    <emphasis role="strong">Nodes: Bash Startup Files and Interactive
     73    Shells</emphasis>.
     74  </para>
    6175
    6276  <note>
    63     <para>Most of the instructions below are used to create files located in
    64     the <filename class='directory'>/etc</filename> directory structure which
    65     requires you to execute the commands as the
    66     <systemitem class='username'>root</systemitem> user. If you elect to create
    67     the files in user's home directories instead, you should run the commands
    68     as an unprivileged user.</para>
     77    <para>
     78      Most of the instructions below are used to create files located in the
     79      <filename class='directory'>/etc</filename> directory structure which
     80      requires you to execute the commands as the <systemitem
     81      class='username'>root</systemitem> user. If you elect to create the
     82      files in user's home directories instead, you should run the commands
     83      as an unprivileged user.
     84    </para>
    6985  </note>
    7086
    71     <para condition="html" role="usernotes">User Notes:
    72     <ulink url="&blfs-wiki;/bash-shell-startup-files"/></para>
     87  <para condition="html" role="usernotes">User Notes:
     88  <ulink url="&blfs-wiki;/bash-shell-startup-files"/></para>
    7389
    7490  <sect2 id="etc-profile-profile">
     
    7995    </indexterm>
    8096
    81     <para>Here is a base <filename>/etc/profile</filename>. This file starts by
    82     setting up some helper functions and some basic parameters.  It specifies some
    83     <command>bash</command> history parameters and, for security purposes,
    84     disables keeping a permanent history file for the <systemitem
    85     class="username">root</systemitem> user.  It also sets a
    86     default user prompt.  It then calls small, single purpose scripts in the
    87     <filename class='directory'>/etc/profile.d</filename> directory to provide most
    88     of the initialization.</para>
    89 
    90     <para>For more information on the escape sequences you can use for your prompt
    91     (i.e., the <envar>PS1</envar> environment variable) see <command>info
    92     bash</command> -- <emphasis role="strong">Node: Printing a
    93     Prompt</emphasis>.</para>
     97    <para>
     98      Here is a base <filename>/etc/profile</filename>. This file starts by
     99      setting up some helper functions and some basic parameters. It specifies
     100      some <command>bash</command> history parameters and, for security
     101      purposes, disables keeping a permanent history file for the <systemitem
     102      class="username">root</systemitem> user.  It also sets a default user
     103      prompt.  It then calls small, single purpose scripts in the <filename
     104      class='directory'>/etc/profile.d</filename> directory to provide most
     105      of the initialization.
     106    </para>
     107
     108    <para>
     109      For more information on the escape sequences you can use for your prompt
     110      (i.e., the <envar>PS1</envar> environment variable) see <command>info
     111      bash</command> -- <emphasis role="strong">Node: Printing a
     112      Prompt</emphasis>.
     113    </para>
    94114
    95115<screen role="root"><?dbfo keep-together="auto"?><userinput>cat &gt; /etc/profile &lt;&lt; "EOF"
     
    180200      </indexterm>
    181201
    182       <para>Now create the <filename class='directory'>/etc/profile.d</filename>
    183       directory, where the individual initialization scripts are placed:</para>
     202      <para>
     203        Now create the <filename class='directory'>/etc/profile.d</filename>
     204        directory, where the individual initialization scripts are placed:
     205      </para>
    184206
    185207<screen role="root"><userinput>install --directory --mode=0755 --owner=root --group=root /etc/profile.d</userinput></screen>
     
    194216      </indexterm>
    195217
    196       <note><para>Using the bash completion script below is controversial.
    197       Not all users like it.  It adds many (usually over 1000) lines to the
    198       bash environment and makes it difficult to use the 'set' command to
    199       examine simple environment variables.  Omitting this script does not
    200       interfere with the ability of bash to use the tab key for file name
    201       completion.</para></note>
    202 
    203       <para>This script imports bash completion scripts, installed by many
    204       other BLFS packages, to allow TAB command line completion.</para>
     218      <note>
     219        <para>
     220          Using the bash completion script below is controversial. Not all
     221          users like it.  It adds many (usually over 1000) lines to the bash
     222          environment and makes it difficult to use the 'set' command to
     223          examine simple environment variables.  Omitting this script does
     224          not interfere with the ability of bash to use the tab key for file
     225          name completion.
     226        </para>
     227      </note>
     228
     229      <para>
     230        This script imports bash completion scripts, installed by many
     231        other BLFS packages, to allow TAB command line completion.
     232      </para>
    205233
    206234<screen role="root"><userinput>cat &gt; /etc/profile.d/bash_completion.sh &lt;&lt; "EOF"
     
    240268# End /etc/profile.d/bash_completion.sh</literal>
    241269EOF</userinput></screen>
    242       <para>Make sure that the directory exists:</para>
     270      <para>
     271        Make sure that the directory exists:
     272      </para>
    243273
    244274<screen role="root"><userinput>install --directory --mode=0755 --owner=root --group=root /etc/bash_completion.d</userinput></screen>
    245275
    246       <para>For a more complete installation, see
    247       <ulink url="&blfs-wiki;/bash-shell-startup-files#bash-completions"/>.</para>
     276      <para>
     277        For a more complete installation, see
     278        <ulink url="&blfs-wiki;/bash-shell-startup-files#bash-completions"/>.
     279      </para>
    248280
    249281    </sect3>
     
    256288      </indexterm>
    257289
    258       <para>This script uses the <filename>~/.dircolors</filename> and
    259       <filename>/etc/dircolors</filename> files to control the colors of file names in a
    260       directory listing. They control colorized output of things like <command>ls
    261       --color</command>.  The explanation of how to initialize these files is at the
    262       end of this section.</para>
     290      <para>
     291        This script uses the <filename>~/.dircolors</filename> and
     292        <filename>/etc/dircolors</filename> files to control the colors of
     293        file names in a directory listing. They control colorized output of
     294        things like <command>ls --color</command>.  The explanation of how to
     295        initialize these files is at the end of this section.
     296      </para>
    263297
    264298<screen role="root"><userinput>cat &gt; /etc/profile.d/dircolors.sh &lt;&lt; "EOF"
     
    285319      </indexterm>
    286320
    287       <para>This script adds some useful paths to the <envar>PATH</envar> and
    288       can be used to customize other PATH related environment variables
    289       (e.g. LD_LIBRARY_PATH, etc) that may be needed for all users.</para>
     321      <para>
     322        This script adds some useful paths to the <envar>PATH</envar> and
     323        can be used to customize other PATH related environment variables
     324        (e.g. LD_LIBRARY_PATH, etc) that may be needed for all users.
     325      </para>
    290326
    291327<screen role="root"><userinput>cat &gt; /etc/profile.d/extrapaths.sh &lt;&lt; "EOF"
     
    314350      </indexterm>
    315351
    316       <para>This script sets up the default <filename>inputrc</filename>
    317       configuration file. If the user does not have individual settings, it uses the
    318       global file.</para>
     352      <para>
     353        This script sets up the default <filename>inputrc</filename>
     354        configuration file. If the user does not have individual settings, it
     355        uses the global file.
     356      </para>
    319357
    320358<screen role="root"><userinput>cat &gt; /etc/profile.d/readline.sh &lt;&lt; "EOF"
     
    335373      </indexterm>
    336374
    337       <para>Setting the <command>umask</command> value is important for security.
    338       Here the default group write permissions are turned off for system users and when
    339       the user name and group name are not the same.</para>
     375      <para>
     376        Setting the <command>umask</command> value is important for security.
     377        Here the default group write permissions are turned off for system
     378        users and when the user name and group name are not the same.
     379      </para>
    340380
    341381<screen role="root"><userinput>cat &gt; /etc/profile.d/umask.sh &lt;&lt; "EOF"
     
    358398      </indexterm>
    359399
    360       <para>If <application>X</application> is installed, the <envar>PATH</envar>
    361       and <envar>PKG_CONFIG_PATH</envar> variables are also updated.</para>
     400      <para>
     401        If <application>X</application> is installed, the <envar>PATH</envar>
     402        and <envar>PKG_CONFIG_PATH</envar> variables are also updated.
     403      </para>
    362404
    363405<screen role="root"><userinput>cat &gt; /etc/profile.d/X.sh &lt;&lt; "EOF"
     
    382424    </indexterm>
    383425
    384       <para>This script sets an environment variable necessary for
    385       native language support. A full discussion on determining this
    386       variable can be found on the <ulink
    387       url="&lfs-root;/chapter07/profile.html">LFS Bash Shell
    388       Startup Files</ulink> page.</para>
     426      <para>
     427        This script sets an environment variable necessary for
     428        native language support. A full discussion on determining this
     429        variable can be found on the <ulink
     430        url="&lfs-root;/chapter07/profile.html">LFS Bash Shell
     431        Startup Files</ulink> page.
     432      </para>
    389433
    390434<screen role="root" revision="sysv"><userinput>cat &gt; /etc/profile.d/i18n.sh &lt;&lt; "EOF"
     
    404448      <title>Other Initialization Values</title>
    405449
    406       <para>Other initialization can easily be added to the
    407       <filename>profile</filename> by adding additional scripts to the
    408       <filename class='directory'>/etc/profile.d</filename> directory.</para>
     450      <para>
     451        Other initialization can easily be added to the
     452        <filename>profile</filename> by adding additional scripts to the
     453        <filename class='directory'>/etc/profile.d</filename> directory.
     454      </para>
    409455
    410456    </sect3>
     
    419465    </indexterm>
    420466
    421     <para>Here is a base <filename>/etc/bashrc</filename>.  Comments in the
    422     file should explain everything you need.</para>
     467    <para>
     468      Here is a base <filename>/etc/bashrc</filename>.  Comments in the
     469      file should explain everything you need.
     470    </para>
    423471
    424472<screen role="root"><userinput>cat &gt; /etc/bashrc &lt;&lt; "EOF"
     
    469517    </indexterm>
    470518
    471     <para>Here is a base <filename>~/.bash_profile</filename>.  If you want each
    472     new user to have this file automatically, just change the output of
    473     the command to <filename>/etc/skel/.bash_profile</filename> and check the
    474     permissions after the command is run. You can then copy
    475     <filename>/etc/skel/.bash_profile</filename> to the home directories of already
    476     existing users, including <systemitem class="username">root</systemitem>,
    477     and set the owner and group appropriately.</para>
     519    <para>
     520      Here is a base <filename>~/.bash_profile</filename>.  If you want each
     521        new user to have this file automatically, just change the output of
     522      the command to <filename>/etc/skel/.bash_profile</filename> and check the
     523      permissions after the command is run. You can then copy <filename>
     524      /etc/skel/.bash_profile</filename> to the home directories of already
     525      existing users, including <systemitem class="username">root</systemitem>,
     526      and set the owner and group appropriately.
     527    </para>
    478528
    479529<screen><userinput>cat &gt; ~/.bash_profile &lt;&lt; "EOF"
     
    514564    </indexterm>
    515565
    516     <para>Here is a base <filename>~/.profile</filename>. The comments and
    517     instructions for using <filename class="directory">/etc/skel</filename> for
    518     <filename>.bash_profile</filename> above also apply here. Only the target
    519     file names are different.</para>
     566    <para>
     567      Here is a base <filename>~/.profile</filename>. The comments and
     568      instructions for using <filename class="directory">/etc/skel</filename>
     569      for <filename>.bash_profile</filename> above also apply here. Only the
     570      target file names are different.
     571    </para>
    520572
    521573<screen><userinput>cat &gt; ~/.profile &lt;&lt; "EOF"
     
    542594    </indexterm>
    543595
    544     <para>Here is a base <filename>~/.bashrc</filename>.</para>
     596    <para>
     597      Here is a base <filename>~/.bashrc</filename>.
     598    </para>
    545599
    546600<screen><userinput>cat &gt; ~/.bashrc &lt;&lt; "EOF"
     
    576630    </indexterm>
    577631
    578     <para>This is an empty <filename>~/.bash_logout</filename> that can be used as
    579     a template.  You will notice that the base <filename>~/.bash_logout</filename>
    580     does not include a <userinput>clear</userinput> command.  This is because the
    581     clear is handled in the <filename>/etc/issue</filename> file.</para>
     632    <para>
     633      This is an empty <filename>~/.bash_logout</filename> that can be used as
     634      a template.  You will notice that the base <filename>~/.bash_logout
     635      </filename> does not include a <userinput>clear</userinput> command.
     636      This is because the clear is handled in the
     637      <filename>/etc/issue</filename> file.
     638    </para>
    582639
    583640<screen><userinput>cat &gt; ~/.bash_logout &lt;&lt; "EOF"
     
    605662    </indexterm>
    606663
    607     <para> If you want to use the <filename>dircolors</filename> capability,
    608     then run the following command. The
    609     <filename class="directory">/etc/skel</filename> setup steps shown above
    610     also can be used here to provide a <filename>~/.dircolors</filename> file
    611     when a new user is set up. As before, just change the output file name on
    612     the following command and assure the permissions, owner, and group are
    613     correct on the files created and/or copied.</para>
     664    <para>
     665       If you want to use the <filename>dircolors</filename> capability, then
     666       run the following command. The <filename class="directory">/etc/skel
     667       </filename> setup steps shown above also can be used here to provide
     668       a <filename>~/.dircolors</filename> file when a new user is set up.
     669       As before, just change the output file name on the following command
     670       and assure the permissions, owner, and group are correct on the files
     671       created and/or copied.
     672    </para>
    614673
    615674<screen role="root"><userinput>dircolors -p > /etc/dircolors</userinput></screen>
    616675
    617     <para>If you wish to customize the colors used for different file types,
    618     you can edit the <filename>/etc/dircolors</filename> file. The instructions
    619     for setting the colors are embedded in the file.</para>
    620 
    621 
    622     <para>Finally, Ian Macdonald has written an excellent collection of tips and
    623     tricks to enhance your shell environment.  You can read it online at
    624     <ulink url="http://www.caliban.org/bash/index.shtml"/>.</para>
     676    <para>
     677      If you wish to customize the colors used for different file types, you
     678      can edit the <filename>/etc/dircolors</filename> file. The instructions
     679      for setting the colors are embedded in the file.
     680    </para>
     681
     682
     683    <para>
     684      Finally, Ian Macdonald has written an excellent collection of tips and
     685      tricks to enhance your shell environment.  You can read it online at
     686      <ulink url="http://www.caliban.org/bash/index.shtml"/>.
     687    </para>
    625688
    626689  </sect2>
  • postlfs/config/random.xml

    rfa3edfef r81a73ed8  
    2020  </indexterm>
    2121
    22   <para>The Linux kernel supplies a random number generator which is accessed
    23   through <filename class="devicefile">/dev/random</filename> and
    24   <filename class="devicefile">/dev/urandom</filename>.  Programs that utilize
    25   the random and urandom devices, such as <application>OpenSSH</application>,
    26   will benefit from these instructions.</para>
     22  <para>
     23    The Linux kernel supplies a random number generator which is accessed
     24    through <filename class="devicefile">/dev/random</filename> and
     25    <filename class="devicefile">/dev/urandom</filename>. Programs that utilize
     26    the random and urandom devices, such as <application>OpenSSH</application>,
     27    will benefit from these instructions.
     28  </para>
    2729
    28   <para>When a Linux system starts up without much operator interaction, the
    29   entropy pool (data used to compute a random number) may be in a fairly
    30   predictable state.  This creates the real possibility that the number generated
    31   at startup may always be the same.  In order to counteract this effect,
    32   you should carry the entropy pool information across your shut-downs and
    33   start-ups.</para>
     30  <para>
     31    When a Linux system starts up without much operator interaction, the
     32    entropy pool (data used to compute a random number) may be in a fairly
     33    predictable state.  This creates the real possibility that the number
     34    generated at startup may always be the same.  In order to counteract
     35    this effect, you should carry the entropy pool information across your
     36    shut-downs and start-ups.
     37  </para>
    3438
    35   <para>Install the <filename>/etc/rc.d/init.d/random</filename> init script
    36   included with the <xref linkend="bootscripts"/> package.</para>
     39  <para>
     40    Install the <filename>/etc/rc.d/init.d/random</filename> init script
     41    included with the <xref linkend="bootscripts"/> package.
     42  </para>
    3743
    3844<screen role="root"><userinput>make install-random</userinput></screen>
  • postlfs/config/skel.xml

    rfa3edfef r81a73ed8  
    2424  </indexterm>
    2525
    26   <para>Together, the <command>/usr/sbin/useradd</command> command and
    27   <filename class="directory">/etc/skel</filename> directory (both are easy to
    28   set up and use) provide a way to assure new users are added to your LFS
    29   system with the same beginning settings for things such as the
    30   <envar>PATH</envar>, keyboard processing and other environmental variables.
    31   Using these two facilities makes it easier to assure this initial state for
    32   each new user added to the system.</para>
     26  <para>
     27    Together, the <command>/usr/sbin/useradd</command> command and <filename
     28    class="directory">/etc/skel</filename> directory (both are easy to
     29    set up and use) provide a way to assure new users are added to your LFS
     30    system with the same beginning settings for things such as the
     31    <envar>PATH</envar>, keyboard processing and other environmental variables.
     32    Using these two facilities makes it easier to assure this initial state for
     33    each new user added to the system.
     34  </para>
    3335
    34   <para>The <filename class="directory">/etc/skel</filename> directory holds
    35   copies of various initialization and other files that may be copied to the
    36   new user's home directory when the <command>/usr/sbin/useradd</command>
    37   program adds the new user.</para>
     36  <para>
     37    The <filename class="directory">/etc/skel</filename> directory holds
     38    copies of various initialization and other files that may be copied to the
     39    new user's home directory when the <command>/usr/sbin/useradd</command>
     40    program adds the new user.
     41  </para>
    3842
    3943  <bridgehead renderas="sect5">Useradd</bridgehead>
    4044
    41   <para>The <command>useradd</command> program uses a collection of
    42   default values kept in <filename>/etc/default/useradd</filename>. This file
    43   is created in a base LFS installation by the
    44   <application>Shadow</application> package. If it has been removed or renamed,
    45   the <command>useradd</command> program uses some internal defaults.  You can
    46   see the default values by running
    47   <command>/usr/sbin/useradd -D</command>.</para>
     45  <para>
     46    The <command>useradd</command> program uses a collection of default
     47    values kept in <filename>/etc/default/useradd</filename>. This file
     48    is created in a base LFS installation by the
     49    <application>Shadow</application> package. If it has been removed or
     50    renamed, the <command>useradd</command> program uses some internal
     51    defaults.  You can see the default values by running
     52    <command>/usr/sbin/useradd -D</command>.
     53  </para>
    4854
    49   <para>To change these values, simply modify the
    50   <filename>/etc/default/useradd</filename> file as the
    51   <systemitem class='username'>root</systemitem> user. An alternative to
    52   directly modifying the file is to run <command>useradd</command> as the
    53   <systemitem class='username'>root</systemitem> user while supplying the
    54   desired modifications on the command line. Information on how to do this
    55   can be found in the <command>useradd</command> man page.</para>
     55  <para>
     56    To change these values, simply modify the
     57    <filename>/etc/default/useradd</filename> file as the
     58    <systemitem class='username'>root</systemitem> user. An alternative to
     59    directly modifying the file is to run <command>useradd</command> as the
     60    <systemitem class='username'>root</systemitem> user while supplying the
     61    desired modifications on the command line. Information on how to do this
     62    can be found in the <command>useradd</command> man page.
     63  </para>
    5664
    5765  <bridgehead renderas="sect5">/etc/skel</bridgehead>
    5866
    59   <para>To get started, create an
    60   <filename class="directory">/etc/skel</filename> directory and make sure it
    61   is writable only by the system administrator, usually
    62   <systemitem class="username">root</systemitem>. Creating the directory as
    63   <systemitem class="username">root</systemitem> is the best way to go.</para>
     67  <para>
     68    To get started, create an
     69    <filename class="directory">/etc/skel</filename> directory and make sure it
     70    is writable only by the system administrator, usually
     71    <systemitem class="username">root</systemitem>. Creating the directory as
     72    <systemitem class="username">root</systemitem> is the best way to go.
     73  </para>
    6474
    65   <para>The mode of any files from this part of the book that you put in
    66   <filename class="directory">/etc/skel</filename> should be writable only by
    67   the owner. Also, since there is no telling what kind of sensitive information
    68   a user may eventually place in their copy of these files, you should
    69   make them unreadable by "group" and "other".</para>
     75  <para>
     76    The mode of any files from this part of the book that you put in <filename
     77    class="directory">/etc/skel</filename> should be writable only by the
     78    owner. Also, since there is no telling what kind of sensitive information
     79    a user may eventually place in their copy of these files, you should
     80    make them unreadable by "group" and "other".
     81  </para>
    7082
    71   <para>You can also put other files in
    72   <filename class="directory">/etc/skel</filename> and
    73   different permissions may be needed for them.</para>
     83  <para>
     84    You can also put other files in
     85    <filename class="directory">/etc/skel</filename> and
     86    different permissions may be needed for them.
     87  </para>
    7488
    75   <para>Decide which initialization files should be provided in every (or most)
    76   new user's home directory. The decisions you make will affect what you
    77   do in the next two sections, <xref linkend="postlfs-config-profile"/> and
    78   <xref linkend="postlfs-config-vimrc"/>. Some or all of those files will be
    79   useful for <systemitem class="username">root</systemitem>, any
    80   already-existing users, and new users.</para>
     89  <para>
     90    Decide which initialization files should be provided in every (or most)
     91    new user's home directory. The decisions you make will affect what you
     92    do in the next two sections, <xref linkend="postlfs-config-profile"/> and
     93    <xref linkend="postlfs-config-vimrc"/>. Some or all of those files will be
     94    useful for <systemitem class="username">root</systemitem>, any
     95    already-existing users, and new users.
     96  </para>
    8197
    82   <para>The files from those sections that you might want to place in
    83   <filename class="directory">/etc/skel</filename> include
    84   <filename>.inputrc</filename>, <filename>.bash_profile</filename>,
    85   <filename>.bashrc</filename>, <filename>.bash_logout</filename>,
    86   <filename>.dircolors</filename>, and <filename>.vimrc</filename>. If
    87   you are unsure which of these should be placed there, just continue to
    88   the following sections, read each section and any references provided,
    89   and then make your decision.</para>
     98  <para>
     99    The files from those sections that you might want to place in
     100    <filename class="directory">/etc/skel</filename> include
     101    <filename>.inputrc</filename>, <filename>.bash_profile</filename>,
     102    <filename>.bashrc</filename>, <filename>.bash_logout</filename>,
     103    <filename>.dircolors</filename>, and <filename>.vimrc</filename>. If
     104    you are unsure which of these should be placed there, just continue to
     105    the following sections, read each section and any references provided,
     106    and then make your decision.
     107  </para>
    90108
    91   <para>You will run a slightly modified set of commands for files which
    92   are placed in <filename class="directory">/etc/skel</filename>. Each section
    93   will remind you of this. In brief, the book's commands have been written for
    94   files <emphasis>not</emphasis> added to
    95   <filename class="directory">/etc/skel</filename> and instead just sends the
    96   results to the user's home directory. If the file is going to be in
    97   <filename class="directory">/etc/skel</filename>, change the book's command(s)
    98   to send output there instead and then just copy the file from
    99   <filename class="directory">/etc/skel</filename> to the appropriate
    100   directories, like <filename class="directory">/etc</filename>,
    101   <filename class="directory">~</filename> or the home directory
    102   of any other user already in the system.</para>
     109  <para>
     110    You will run a slightly modified set of commands for files which are
     111    placed in <filename class="directory">/etc/skel</filename>. Each section
     112    will remind you of this. In brief, the book's commands have been written
     113    for files <emphasis>not</emphasis> added to <filename class="directory">
     114    /etc/skel</filename> and instead just sends the results to the user's
     115    home directory. If the file is going to be in <filename class="directory">
     116    /etc/skel</filename>, change the book's command(s) to send output there
     117    instead and then just copy the file from <filename class="directory">
     118    /etc/skel</filename> to the appropriate directories, like <filename
     119    class="directory">/etc</filename>, <filename class="directory">~
     120    </filename> or the home directory of any other user already in the system.
     121  </para>
    103122
    104123  <bridgehead renderas="sect5">When Adding a User</bridgehead>
    105124
    106   <para>When adding a new user with <command>useradd</command>, use
    107   the <option>-m</option> parameter, which tells
    108   <command>useradd</command> to create the user's home directory and
    109   copy files from <filename class="directory">/etc/skel</filename> (can be
    110   overridden) to the new user's home directory.  For example (perform as the
    111   <systemitem class="username">root</systemitem> user):</para>
     125  <para>
     126    When adding a new user with <command>useradd</command>, use
     127    the <option>-m</option> parameter, which tells
     128    <command>useradd</command> to create the user's home directory and
     129    copy files from <filename class="directory">/etc/skel</filename> (can be
     130    overridden) to the new user's home directory.  For example (perform as the
     131    <systemitem class="username">root</systemitem> user):
     132  </para>
    112133
    113134<screen role="root"><userinput>useradd -m <replaceable>&lt;newuser&gt;</replaceable></userinput></screen>
  • postlfs/config/users.xml

    rfa3edfef r81a73ed8  
    2828  </indexterm>
    2929
    30   <para>Throughout BLFS, many packages install programs that
    31   run as daemons or in some way should have a user or group name
    32   assigned.  Generally these names are used to map a user ID (uid) or group
    33   ID (gid) for system use.  Generally the specific uid or gid numbers used
    34   by these applications are not significant.  The exception of course, is
    35   that <systemitem class='username'>root</systemitem> has a uid and gid of 0
    36   (zero) that is indeed special.  The uid values are stored in
    37   <filename>/etc/passwd</filename> and the gid values
    38   are found in <filename>/etc/group</filename>.</para>
     30  <para>
     31    Throughout BLFS, many packages install programs that run as daemons or in
     32    some way should have a user or group name assigned.  Generally these
     33    names are used to map a user ID (uid) or group ID (gid) for system use.
     34    Generally the specific uid or gid numbers used by these applications are
     35    not significant.  The exception of course, is that <systemitem
     36    class='username'>root</systemitem> has a uid and gid of 0 (zero) that
     37    is indeed special.  The uid values are stored in
     38    <filename>/etc/passwd</filename> and the gid values are found in
     39    <filename>/etc/group</filename>.
     40  </para>
    3941
    40   <para>Customarily, Unix systems classify users and groups into two
    41   categories: system users and regular users.  The system users and groups are
    42   given low numbers and regular users and groups have numeric values greater
    43   than all the system values.  The cutoff for these numbers is found in two
    44   parameters in the <filename>/etc/login.defs</filename> configuration file.
    45   The default UID_MIN value is 1000 and the default GID_MIN value is 1000.  If a
    46   specific uid or gid value is not specified when creating a user with
    47   <command>useradd</command> or a group with <command>groupadd</command> the values
    48   assigned will always be above these cutoff values.</para>
     42  <para>
     43    Customarily, Unix systems classify users and groups into two categories:
     44    system users and regular users.  The system users and groups are given
     45    low numbers and regular users and groups have numeric values greater
     46    than all the system values.  The cutoff for these numbers is found in
     47    two parameters in the <filename>/etc/login.defs</filename> configuration
     48    file.  The default UID_MIN value is 1000 and the default GID_MIN value
     49    is 1000.  If a specific uid or gid value is not specified when creating
     50    a user with <command>useradd</command> or a group with
     51    <command>groupadd</command> the values assigned will always be above
     52    these cutoff values.
     53  </para>
    4954
    50   <para>Additionally, the <ulink
    51   url='http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/usernames.html'>
    52   Linux Standard Base</ulink> recommends that system uid and gid values should be
    53   below 100.</para>
     55  <para>
     56    Additionally, the <ulink url=
     57      "http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/usernames.html">
     58    Linux Standard Base</ulink> recommends that system uid and gid values
     59    should be below 100.
     60  </para>
    5461
    55   <para>Below is a table of suggested uid/gid values used in BLFS beyond those
    56   defined in a base LFS installation.  These can be changed as desired, but
    57   provide a suggested set of consistent values.</para>
     62  <para>
     63    Below is a table of suggested uid/gid values used in BLFS beyond those
     64    defined in a base LFS installation.  These can be changed as desired, but
     65    provide a suggested set of consistent values.
     66  </para>
    5867
    5968  <table id="uidgid" class="uidvalues">
     
    143152  </table>
    144153
    145   <para>One value that is missing is 65534.  This value is customarily assigned
    146   to the user <systemitem class="username">nobody</systemitem> and group
    147   <systemitem class="groupname">nogroup</systemitem> and is unnecessary.
     154  <para>
     155    One value that is missing is 65534.  This value is customarily assigned
     156    to the user <systemitem class="username">nobody</systemitem> and group
     157    <systemitem class="groupname">nogroup</systemitem> and is unnecessary.
    148158  </para>
    149159
  • postlfs/config/vimrc.xml

    rfa3edfef r81a73ed8  
    2424  </indexterm>
    2525
    26   <para>The LFS book installs <application>Vim</application>
    27   as its text editor.  At this point it should be noted that there are a
    28   <emphasis>lot</emphasis> of different editing applications out there including
    29   <application>Emacs</application>, <application>nano</application>,
    30   <application>Joe</application> and many more.  Anyone who has been around the
    31   Internet (especially usenet) for a short time will certainly have observed at
    32   least one flame war, usually involving <application>Vim</application> and
    33   <application>Emacs</application> users!</para>
     26  <para>
     27    The LFS book installs <application>Vim</application> as its text editor.
     28    At this point it should be noted that there are a <emphasis>lot</emphasis>
     29    of different editing applications out there including
     30    <application>Emacs</application>, <application>nano</application>,
     31    <application>Joe</application> and many more.  Anyone who has been
     32    around the Internet (especially usenet) for a short time will certainly
     33    have observed at least one flame war, usually involving
     34    <application>Vim</application> and <application>Emacs</application> users!
     35  </para>
    3436
    35   <para>The LFS book creates a basic <filename>vimrc</filename> file. In this
    36   section you'll find an attempt to enhance this file. At startup,
    37   <command>vim</command> reads the global configuration file
    38   (<filename>/etc/vimrc</filename>) as well as a user-specific file
    39   (<filename>~/.vimrc</filename>). Either or both can be tailored to suit
    40   the needs of your particular system.</para>
     37  <para>
     38    The LFS book creates a basic <filename>vimrc</filename> file. In this
     39    section you'll find an attempt to enhance this file. At startup,
     40    <command>vim</command> reads the global configuration file
     41    (<filename>/etc/vimrc</filename>) as well as a user-specific file
     42    (<filename>~/.vimrc</filename>). Either or both can be tailored to suit
     43    the needs of your particular system.
     44  </para>
    4145
    42   <para>Here is a slightly expanded <filename>.vimrc</filename> that you can
    43   put in <filename>~/.vimrc</filename> to provide user specific effects. Of
    44   course, if you put it into <filename>/etc/skel/.vimrc</filename> instead, it
    45   will be made available to users you add to the system later. You can also copy
    46   the file from <filename>/etc/skel/.vimrc</filename> to the home directory of
    47   users already on the system, such as
    48   <systemitem class='username'>root</systemitem>. Be sure to set permissions,
    49   owner, and group if you do copy anything directly from
    50   <filename class="directory">/etc/skel</filename>.</para>
     46  <para>
     47    Here is a slightly expanded <filename>.vimrc</filename> that you can put
     48    in <filename>~/.vimrc</filename> to provide user specific effects. Of
     49    course, if you put it into <filename>/etc/skel/.vimrc</filename> instead,
     50    it will be made available to users you add to the system later. You
     51    can also copy the file from <filename>/etc/skel/.vimrc</filename> to
     52    the home directory of users already on the system, such as <systemitem
     53    class='username'>root</systemitem>. Be sure to set permissions, owner,
     54    and group if you do copy anything directly from <filename
     55    class="directory">/etc/skel</filename>.
     56  </para>
    5157
    5258<screen><literal>" Begin .vimrc
     
    5864" End .vimrc</literal></screen>
    5965
    60   <para>Note that the comment tags are " instead of the more
    61   usual # or //.  This is correct, the syntax for
    62   <filename>vimrc</filename> is slightly unusual.</para>
     66  <para>
     67    Note that the comment tags are " instead of the more
     68    usual # or //.  This is correct, the syntax for
     69    <filename>vimrc</filename> is slightly unusual.
     70  </para>
    6371
    64   <para>Below you'll find a quick explanation of what each of the
    65   options in this example file means here:</para>
     72  <para>
     73    Below you'll find a quick explanation of what each of the
     74    options in this example file means here:
     75  </para>
    6676
    6777  <itemizedlist>
    6878    <!--
    6979    <listitem>
    70       <para><option>set nocompatible</option> : This option
    71       stops <command>vim</command> from behaving in a strongly <command>vi
    72       </command>-compatible way. It should be at the start of any <filename>vimrc
    73       </filename> file as it can affect lots of other options which you may want to
    74       override.</para>
     80      <para>
     81        <option>set nocompatible</option> : This option
     82        stops <command>vim</command> from behaving in a strongly <command>vi
     83        </command>-compatible way. It should be at the start of any
     84        <filename>vimrc </filename> file as it can affect lots of other
     85        options which you may want to override.
     86      </para>
    7587    </listitem>
    7688    <listitem>
    77       <para><option>set bs=2</option>: This influences the behavior
    78       of the backspace option.  It is fairly complex so see <command>:help 'bs'
    79       </command> for more details.</para>
     89      <para>
     90        <option>set bs=2</option>: This influences the behavior of the
     91        backspace option.  It is fairly complex so see <command>:help 'bs'
     92        </command> for more details.
     93      </para>
    8094    </listitem>
    8195    -->
    8296    <listitem>
    83       <para><option>set columns=80</option>: This simply sets the
    84       number of columns used on the screen.</para>
     97      <para>
     98        <option>set columns=80</option>: This simply sets the
     99        number of columns used on the screen.
     100      </para>
    85101    </listitem>
    86102    <!--
    87103    <listitem>
    88       <para><option>set background=dark</option>: This tells
    89       <command>vim</command> to use colors which look good on a dark
    90       background.</para>
     104      <para>
     105        <option>set background=dark</option>: This tells
     106        <command>vim</command> to use colors which look good on a dark
     107        background.
     108      </para>
    91109    </listitem>
    92110    -->
    93111    <listitem>
    94       <para><option>set wrapmargin=8</option>: This is the number of
    95       characters from the right window border where wrapping starts.</para>
     112      <para>
     113        <option>set wrapmargin=8</option>: This is the number of
     114        characters from the right window border where wrapping starts.
     115      </para>
    96116    </listitem>
    97117    <!--
    98118    <listitem>
    99       <para><option>syntax on</option>: Enables
    100       <command>vim</command>'s syntax highlighting.</para>
     119      <para>
     120        <option>syntax on</option>: Enables
     121        <command>vim</command>'s syntax highlighting.
     122      </para>
    101123    </listitem>
    102124    -->
    103125    <listitem>
    104       <para><option>set ruler</option>: This makes <command>vim</command>
    105       show the current row and column at the bottom right of the screen.</para>
     126      <para>
     127        <option>set ruler</option>: This makes <command>vim</command>
     128        show the current row and column at the bottom right of the screen.
     129      </para>
    106130    </listitem>
    107131  </itemizedlist>
    108132
    109   <para>More information on the <emphasis>many</emphasis>
    110   <command>vim</command> options can be found by reading the help
    111   inside <command>vim</command> itself.  Do this by typing
    112   <command>:</command><option>help</option> in
    113   <command>vim</command> to get the general help, or by typing
    114   <command>:</command><option>help usr_toc.txt</option> to view
    115   the User Manual Table of Contents.</para>
     133  <para>
     134    More information on the <emphasis>many</emphasis>
     135    <command>vim</command> options can be found by reading the help
     136    inside <command>vim</command> itself.  Do this by typing
     137    <command>:</command><option>help</option> in
     138    <command>vim</command> to get the general help, or by typing
     139    <command>:</command><option>help usr_toc.txt</option> to view
     140    the User Manual Table of Contents.
     141  </para>
    116142
    117143</sect1>
Note: See TracChangeset for help on using the changeset viewer.