306 lines
8.1 KiB
HTML
306 lines
8.1 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>What happens when you switch on a computer?</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="The Unix and Internet Fundamentals HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Basic anatomy of your computer"
|
|
HREF="anatomy.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="What happens when you log in?"
|
|
HREF="login.html"></HEAD
|
|
><BODY
|
|
CLASS="sect1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>The Unix and Internet Fundamentals HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="anatomy.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="login.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="sect1"
|
|
><H1
|
|
CLASS="sect1"
|
|
><A
|
|
NAME="bootup"
|
|
></A
|
|
>3. What happens when you switch on a computer?</H1
|
|
><P
|
|
>A computer without a program running is just an inert hunk of
|
|
electronics. The first thing a computer has to do when it is turned on is
|
|
start up a special program called an <A
|
|
NAME="os"
|
|
></A
|
|
><I
|
|
CLASS="firstterm"
|
|
>operating
|
|
system</I
|
|
>. The operating system's job is to help other computer
|
|
programs to work by handling the messy details of controlling the
|
|
computer's hardware.</P
|
|
><P
|
|
>The process of bringing up the operating system is called <A
|
|
NAME="boot"
|
|
></A
|
|
> <I
|
|
CLASS="firstterm"
|
|
>booting</I
|
|
> (originally this was
|
|
<I
|
|
CLASS="firstterm"
|
|
>bootstrapping</I
|
|
> and alluded to the process of pulling
|
|
yourself up <SPAN
|
|
CLASS="QUOTE"
|
|
>"by your bootstraps"</SPAN
|
|
>). Your computer knows how to
|
|
boot because instructions for booting are built into one of its chips, the
|
|
BIOS (or Basic Input/Output System) chip.</P
|
|
><P
|
|
>The BIOS chip tells it to look in a fixed place, usually on the
|
|
lowest-numbered hard disk (the <I
|
|
CLASS="firstterm"
|
|
>boot disk</I
|
|
>) for a
|
|
special program called a <I
|
|
CLASS="firstterm"
|
|
>boot loader</I
|
|
> (under Linux the
|
|
boot loader is called Grub or LILO). The boot loader is pulled into memory and
|
|
started. The boot loader's job is to start the real operating
|
|
system.</P
|
|
><P
|
|
>The loader does this by looking for a
|
|
<I
|
|
CLASS="firstterm"
|
|
>kernel</I
|
|
>,
|
|
loading it into memory, and starting it. If you Linux and see
|
|
"LILO" on the screen followed by a bunch of dots, it is loading the kernel.
|
|
(Each dot means it has loaded another <A
|
|
NAME="diskblock"
|
|
></A
|
|
><I
|
|
CLASS="firstterm"
|
|
>disk
|
|
block</I
|
|
> of kernel code.)</P
|
|
><P
|
|
>(You may wonder why the BIOS doesn't load the kernel directly —
|
|
why the two-step process with the boot loader? Well, the BIOS isn't very
|
|
smart. In fact it's very stupid, and Linux doesn't use it at all after
|
|
boot time. It was originally written for primitive 8-bit PCs with tiny
|
|
disks, and literally can't access enough of the disk to load the kernel
|
|
directly. The boot loader step also lets you start one of several
|
|
operating systems off different places on your disk, in the unlikely event
|
|
that Unix isn't good enough for you.)</P
|
|
><P
|
|
>Once the kernel starts, it has to look around, find the rest of the
|
|
hardware, and get ready to run programs. It does this by poking not at
|
|
ordinary memory locations but rather at <I
|
|
CLASS="firstterm"
|
|
>I/O ports</I
|
|
>
|
|
— special bus addresses that are likely to have device controller
|
|
cards listening at them for commands. The kernel doesn't poke at random;
|
|
it has a lot of built-in knowledge about what it's likely to find where,
|
|
and how controllers will respond if they're present. This process is
|
|
called
|
|
<I
|
|
CLASS="firstterm"
|
|
>autoprobing</I
|
|
>.</P
|
|
><P
|
|
>You may or may not be able to see any of this going on. Back when
|
|
Unix systems used text consoles, you'd see boot messages scroll by on your
|
|
screen as the system started up. Nowawadays, Unixes often hide the boot
|
|
messages behind a graphical splash screen. You may be able to see them by
|
|
switching to a text console view with the key combination Ctrl-Shift-F1. If
|
|
this works, you should be able to switch back to the graphical boot screen
|
|
with a different Ctrl-Shift sequence; try F7, F8, and F9.</P
|
|
><P
|
|
>Most of the messages emitted boot time are the kernel autoprobing
|
|
your hardware through the I/O ports, figuring out what it has available to
|
|
it and adapting itself to your machine. The Linux kernel is extremely good
|
|
at this, better than most other Unixes and <I
|
|
CLASS="firstterm"
|
|
>much</I
|
|
> better
|
|
than DOS or Windows. In fact, many Linux old-timers think the cleverness
|
|
of Linux's boot-time probes (which made it relatively easy to install) was
|
|
a major reason it broke out of the pack of free-Unix experiments to attract
|
|
a critical mass of users.</P
|
|
><P
|
|
>But getting the kernel fully loaded and running isn't the end of the
|
|
boot process; it's just the first stage (sometimes called <I
|
|
CLASS="firstterm"
|
|
>run
|
|
level 1</I
|
|
>). After this first stage, the kernel hands control to a
|
|
special process called ‘init’ which spawns several housekeeping
|
|
processes. (Some recent Linuxes use a different program called
|
|
‘upstart’ that does similar things)</P
|
|
><P
|
|
>The init process's first job is usually to check to make sure your disks
|
|
are OK. Disk file systems are fragile things; if they've been damaged by a
|
|
hardware failure or a sudden power outage, there are good reasons to take
|
|
recovery steps before your Unix is all the way up. We'll go into some of
|
|
this later on when we talk about <A
|
|
HREF="disk-layout.html#fsck"
|
|
>how file systems can
|
|
go wrong</A
|
|
>.</P
|
|
><P
|
|
>Init's next step is to start several <I
|
|
CLASS="firstterm"
|
|
>daemons</I
|
|
>. A
|
|
daemon is a program like a print spooler, a mail listener or a WWW server
|
|
that lurks in the background, waiting for things to do. These special
|
|
programs often have to coordinate several requests that could conflict.
|
|
They are daemons because it's often easier to write one program that runs
|
|
constantly and knows about all requests than it would be to try to make
|
|
sure that a flock of copies (each processing one request and all running at
|
|
the same time) don't step on each other. The particular collection of
|
|
daemons your system starts may vary, but will almost always include a print
|
|
spooler (a gatekeeper daemon for your printer).</P
|
|
><P
|
|
>The next step is to prepare for users. Init starts a copy of a
|
|
program called <B
|
|
CLASS="command"
|
|
>getty</B
|
|
> to watch your screen and keyboard
|
|
(and maybe more copies to watch dial-in serial ports). Actually, nowadays
|
|
it usually starts multiple copies of <B
|
|
CLASS="command"
|
|
>getty</B
|
|
> so you have
|
|
several (usually 7 or 8) virtual consoles, with your screen and keyboards
|
|
connected to one of them at a time. But you likely won't see any of these,
|
|
because one of your consoles will be taken over by the X server (about
|
|
which more in a bit).</P
|
|
><P
|
|
>We're not done yet. The next step is to start up various daemons
|
|
that support networking and other services. The most important of these is
|
|
your X server. X is a daemon that manages your display, keyboard, and
|
|
mouse. Its main job is to produce the color pixel graphics you normally
|
|
see on your screen.</P
|
|
><P
|
|
>When the X server comes up, during the last part of your machine's
|
|
boot process, it effectively takes over the hardware from whatever virtual
|
|
console was previously in control. That's when you'll see a graphical
|
|
login screen, produced for you by a program called a <I
|
|
CLASS="firstterm"
|
|
>display
|
|
manager</I
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="anatomy.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="login.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Basic anatomy of your computer</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>What happens when you log in?</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |