Merging upstream version 6.8.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 0 insertions, 230 deletions

diff --git a/man7/boot.7 b/man7/boot.7
deleted file mode 100644
index 3aa0341..0000000
--- a/man7/boot.7
+++ /dev/null
@@ -1,230 +0,0 @@
-.\" Written by Oron Peled <oron@actcom.co.il>.
-.\"
-.\" SPDX-License-Identifier: GPL-1.0-or-later
-.\"
-.\" I tried to be as much generic in the description as possible:
-.\" - General boot sequence is applicable to almost any
-.\" OS/Machine (DOS/PC, Linux/PC, Solaris/SPARC, CMS/S390)
-.\" - kernel and init(1) is applicable to almost any UNIX/Linux
-.\" - boot scripts are applicable to SYSV-R4 based UNIX/Linux
-.\"
-.\" Modified 2004-11-03 patch from Martin Schulze <joey@infodrom.org>
-.\"
-.TH boot 7 2023-10-31 "Linux man-pages 6.7"
-.SH NAME
-boot \- System bootup process based on UNIX System V Release 4
-.SH DESCRIPTION
-The \fBbootup process\fR (or "\fBboot sequence\fR") varies in details
-among systems, but can be roughly divided into phases controlled by
-the following components:
-.IP (1) 5
-hardware
-.IP (2)
-operating system (OS) loader
-.IP (3)
-kernel
-.IP (4)
-root user-space process (\fIinit\fR and \fIinittab\fR)
-.IP (5)
-boot scripts
-.P
-Each of these is described below in more detail.
-.SS Hardware
-After power-on or hard reset, control is given
-to a program stored in read-only memory (normally
-PROM); for historical reasons involving the personal
-computer, this program is often called "the \fBBIOS\fR".
-.P
-This program normally performs a basic self-test of the
-machine and accesses nonvolatile memory to read
-further parameters.
-This memory in the PC is
-battery-backed CMOS memory, so most people
-refer to it as "the \fBCMOS\fR"; outside
-of the PC world, it is usually called "the \fBNVRAM\fR"
-(nonvolatile RAM).
-.P
-The parameters stored in the NVRAM vary among
-systems, but as a minimum, they should specify
-which device can supply an OS loader, or at least which
-devices may be probed for one; such a device is known as "the
-\fBboot device\fR".
-The hardware boot stage loads the OS loader from a fixed position on
-the boot device, and then transfers control to it.
-.TP
-Note:
-The device from which the OS loader is read may be attached via a network,
-in which case the details of booting are further specified by protocols such as
-DHCP, TFTP, PXE, Etherboot, etc.
-.SS OS loader
-The main job of the OS loader is to locate the kernel
-on some device, load it, and run it.
-Most OS loaders allow
-interactive use, in order to enable specification of an alternative
-kernel (maybe a backup in case the one last compiled
-isn't functioning) and to pass optional parameters
-to the kernel.
-.P
-In a traditional PC, the OS loader is located in the initial 512-byte block
-of the boot device; this block is known as "the \fBMBR\fR"
-(Master Boot Record).
-.P
-In most systems, the OS loader is very
-limited due to various constraints.
-Even on non-PC systems,
-there are some limitations on the size and complexity
-of this loader, but the size limitation of the PC MBR
-(512 bytes, including the partition table) makes it
-almost impossible to squeeze much functionality into it.
-.P
-Therefore, most systems split the role of loading the OS between
-a primary OS loader and a secondary OS loader; this secondary
-OS loader may be located within a larger portion of persistent
-storage, such as a disk partition.
-.P
-In Linux, the OS loader is often
-.BR grub (8)
-(an alternative is
-.BR lilo (8)).
-.SS Kernel
-When the kernel is loaded, it initializes various components of
-the computer and operating system; each portion of software
-responsible for such a task is usually consider "a \fBdriver\fR" for
-the applicable component.
-The kernel starts the virtual memory
-swapper (it is a kernel process, called "kswapd" in a modern Linux
-kernel), and mounts some filesystem at the root path,
-.IR / .
-.P
-Some of the parameters that may be passed to the kernel
-relate to these activities (for example, the default root filesystem
-can be overridden); for further information
-on Linux kernel parameters, read
-.BR bootparam (7).
-.P
-Only then does the kernel create the initial userland
-process, which is given the number 1 as its
-.B PID
-(process ID).
-Traditionally, this process executes the
-program
-.IR /sbin/init ,
-to which are passed the parameters that haven't already been
-handled by the kernel.
-.SS Root user-space process
-.TP
-Note:
-The following description applies to an OS based on UNIX System V Release 4.
-However, a number of widely used systems have adopted a related but
-fundamentally different approach known as
-.BR systemd (1),
-for which the bootup process is detailed in its associated
-.BR bootup (7).
-.P
-When
-.I /sbin/init
-starts, it reads
-.I /etc/inittab
-for further instructions.
-This file defines what should be run when the
-.I /sbin/init
-program is instructed to enter a particular run level, giving
-the administrator an easy way to establish an environment
-for some usage; each run level is associated with a set of services
-(for example, run level
-.B S
-is single-user mode,
-and run level
-.B 2
-entails running most network services).
-.P
-The administrator may change the current run level via
-.BR init (1),
-and query the current run level via
-.BR runlevel (8).
-.P
-However, since it is not convenient to manage individual services
-by editing this file,
-.I /etc/inittab
-only bootstraps a set of scripts
-that actually start/stop the individual services.
-.SS Boot scripts
-.TP
-Note:
-The following description applies to an OS based on UNIX System V Release 4.
-However, a number of widely used systems (Slackware Linux, FreeBSD, OpenBSD)
-have a somewhat different scheme for boot scripts.
-.P
-For each managed service (mail, nfs server, cron, etc.), there is
-a single startup script located in a specific directory
-.RI ( /etc/init.d
-in most versions of Linux).
-Each of these scripts accepts as a single argument
-the word "start" (causing it to start the service) or the word
-\&"stop" (causing it to stop the service).
-The script may optionally
-accept other "convenience" parameters (e.g., "restart" to stop and then
-start, "status" to display the service status, etc.).
-Running the script
-without parameters displays the possible arguments.
-.SS Sequencing directories
-To make specific scripts start/stop at specific run levels and in a
-specific order, there are \fIsequencing directories\fR, normally
-of the form  \fI/etc/rc[0\-6S].d\fR.
-In each of these directories,
-there are links (usually symbolic) to the scripts in the \fI/etc/init.d\fR
-directory.
-.P
-A primary script (usually \fI/etc/rc\fR) is called from
-.BR inittab (5);
-this primary script calls each service's script via a link in the
-relevant sequencing directory.
-Each link whose name begins with \[aq]S\[aq] is called with
-the argument "start" (thereby starting the service).
-Each link whose name begins with \[aq]K\[aq] is called with
-the argument "stop" (thereby stopping the service).
-.P
-To define the starting or stopping order within the same run level,
-the name of a link contains an \fBorder-number\fR.
-Also, for clarity, the name of a link usually
-ends with the name of the service to which it refers.
-For example,
-the link \fI/etc/rc2.d/S80sendmail\fR starts the
-.BR sendmail (8)
-service on
-run level 2.
-This happens after \fI/etc/rc2.d/S12syslog\fR is run
-but before \fI/etc/rc2.d/S90xfs\fR is run.
-.P
-To manage these links is to manage the boot order and run levels;
-under many systems, there are tools to help with this task
-(e.g.,
-.BR chkconfig (8)).
-.SS Boot configuration
-A program that provides a service is often called a "\fBdaemon\fR".
-Usually, a daemon may receive various command-line options
-and parameters.
-To allow a system administrator to change these
-inputs without editing an entire boot script,
-some separate configuration file is used, and is located in a specific
-directory where an associated boot script may find it
-(\fI/etc/sysconfig\fR on older Red Hat systems).
-.P
-In older UNIX systems, such a file contained the actual command line
-options for a daemon, but in modern Linux systems (and also
-in HP-UX), it just contains shell variables.
-A boot script in \fI/etc/init.d\fR reads and includes its configuration
-file (that is, it "\fBsources\fR" its configuration file) and then uses
-the variable values.
-.SH FILES
-.IR /etc/init.d/ ,
-.IR /etc/rc[S0\-6].d/ ,
-.I /etc/sysconfig/
-.SH SEE ALSO
-.BR init (1),
-.BR systemd (1),
-.BR inittab (5),
-.BR bootparam (7),
-.BR bootup (7),
-.BR runlevel (8),
-.BR shutdown (8)