Created with The GIMP
   


Features

2007 CHLUGger of the Year!
Mailing List
Archive
Help Open Source
Question of the Day

About Us

Mission
Directions to Meetings
Contact Us
Video
Guest Speaker Info
Acceptable Use
Link To Us!

CHLUG Exclusives

Open Office 3.0- New and Enhanced Features New!
Linux Hacking and the Law New!
VOIP with Asterisk
Assessing OSS
Knoppix Ubiquitous Computing
Filesystem Hierarchy
Virtual Hosting
Wesnoth
Xbox/Linux
udev
Emacs Talk Notes
Home Sweet ~
Top 100 CLIs
Device Drivers
Real Time Linux
Network Considerations Part II
Network Considerations Part I
Amanda Presentation
GNU/Linux Calculators Configuring Rio
ReiserFS
Linux Sound
Samba notes
Network time protocol
C programming in Linux
Boot, startup and shutdown
hdparm HOWTO

Friends of CHLUG

Ubuntu NJ LoCo
New!
Cherry Hill Library
RUSLUG
LUG in Princeton
Useful Links

Loads of Linux Links
LinuxToday.com
Art of UNIX Programming
More Links

Agenda

Contact Congress
Why We Use Linux
Companies Using Linux
Linux in Business



Get Linux!


Get Firefox!

Get OpenOffice.org!




Created with The GIMP



Website Designer- jesran.net



Linux Boot, Startup and Shutdown.

Gerald Neale

October 29, 2001

The following applies to RH linux and its derivatives ie Mandrake. Other systems such as Debian GNU/Linux might have different run level schemes and system config file locatiions.
-----------------------------------------------------------
Boot and Startup.

----------------------------------------
Sitting in front of a powered down Linux box is like sitting in a car with its ignition off in the driveway. It is very easy to imagine this thing zooming down the highway with radio playing and climate control going. But how does this machine, currently doing nothing, get to a state of doing so much? One step at a time.

--------------------------------------------
I. BIOS
II. Lilo
III. Kernel
IV. /sbin/init-The father of all processes
V. /etc/rc.d/rcx.d scripts
VI. /etc/rc.d/rc.local script

-----------------------------------------
I. BIOS (Basic Input/Output System)-

Accessible to the microprocessor when you first turn on your computer.
A small program located on an erasable, read-only memory (EPROM) chip.
Determines if peripheral hardware is in place.
Sets harware system clock.
Tries to find the bootable device; ie cdrom, floppy, hda1.
You can easily add a password here to greatly enhance system security.
------------------------------------------
II. Lilo (Linux Loader)-

A boot program that usually writes to the MBR (Master Boot Record) of your first harddrive.
Takes system control from the BIOS program and eventually gives it to the kernel.
Shows the system where the "root" partition is.
Lilo is highly configurable.
 -Multiple OSs.
 -Multiple kernels.
 -Special hardware parameter arguments..
The configuration file for Lilo is called /etc/lilo.conf.
First make changes to this file.
Then you must run the /sbin/lilo program to write those changes to MBR.
A very common mistake is to make changes to lilo.conf and to forget to run /sbin/lilo. This makes for a confusing reboot.
GRUB is also a kernel/OS loader that is very similar to Lilo.
-----------------------------------------------------
III. Kernel-

Lilo or GRUB boot loader passes control to the kernel.
The Linux kernel is, technically speaking, "Linux".
Sets up swap memory.
Initializes devices via drivers.
Mounts devices.
Highy configurable.
 One can build drivers and/or filesystems right into the kernel, set them to be loadable modules, or eliminate them from ever being used by the kernel.
 This makes for a very flexible system kernel. Kernel customization is one reason Linux works equally well on a tiny PDA or a large mainframe.
Everything in Linux is said to be a "process", with the exception of the kernel.
The last thing the kernel does is pass control to the /sbin/init process.
-----------------------------------------------------------
IV. /sbin/init (The father of all processes)-

Process number one.
First process to run and is always running.
Directly or indirectly spawns all other processes at startup.
Processes:
 -They are the basis of all Linux systems.
 -Run perpetually in the background most times, waiting for input.
 -AKA "services", "daemons", and sometimes "servers".
 -Examples: login prompt, X-Window server, keyboard input functionality, firewall, and all classic server programs; web, email, DNS, FTP, telnet, ssh, etc.
 The stability that Linux is known for comes from its ability to handle many of these processes concurrently without difficulty.
 Flexibility that Linux is known for comes from being able to specialize a machine by running only a few of these processes, reliably, on low-cost machines.
 Processes are different than applications. Applications are temporarily run. Ex. word processing, web browsing, playing MP3s. Crashing is usually not catastrophic for an application.
 A server process is by definition always available and cannot crash to be useful.
So, the first process, /sbin/init, on startup will run the /etc/rc.d/rc.sysinit script which sets path, starts swapping, checks the filesystems, etc.
Then it runs /etc/inittab script which reads your default runlevel and puts the machine into that particular state by running the scripts in the /etc/rcx.d directory.
Runlevels:
 0:halt
 1:single user (admin use).
 2:console based without networking (rarely used).
 3:console based with networking (used for full-time servers).
 4:not used (open for experimentation).
 5:full X-Windows, networking, etc.(used on most desktops).
 6:reboot

---------------------------------------------------
V. /etc/rcx.d (The system startup scripts)-

Where "x" is the default runlevel in /etc/inittab.
This is a directory with "soft" links to startup scripts located elsewhere in /etc/rc.d/init.d directory.
Soft links allow you to have the same few scripts run on different runlevels.
Scripts allow the system to start: stop: or restart services.
Examples: networking, web server, DNS, sendmail, ipchains, sshd.
If the symbolic link starts with a "K" the service is stopped.
If the symbolic link starts with an "S" the service is started.
The K's run first and then the S's. Proceeding numerically.
A green "ok" at startup is the system running through these scripts successfully.
Highly configurable.
The last script to run on /etc/rcx.d is called /etc/rc.d/rc.local.
Like it's name implies, used to start services that are thought to be local to your machine. Ex. database server.
----------------------------------------------
------------------------------------------
Shutdown

-----------------------
So now everything's running, smooth and fast. The system virtually never crashes. There is nothing to worry about. Right? Accidents happen.

------------------------------------------
I. The "shutdown" command
II. Flushing dirty buffers

-------------------------------
I. The "shutdown" command

To properly power a Linux system down or to reboot it, issue this command from the terminal---------->shutdown.
Variations:
 shutdown -h now---->shutdown completely now without waiting.
 shutdown -r -t3---->shutdown and reboot after 3ms delay.
 reboot------------->same as above
Also you can find the same options from the desktop in graphical representation.

------------------------------
II. Flushing dirty buffers

One of the reasons that Linux runs so reliably and fast on so little hardware is the way that it writes to disk. Disk writing is incredibly slow compared to memory writing. So what Linux does is it temporarily put all writes into a "buffer" located in real or swap memory. So while the system is very active it stays there, until a lull is detected and then it does the slow business of writing to disk; flushing its dirty buffers. Linux waits until the last possible moment to do this. Very efficient, huh? And it works great too because Linux is stable. This would not be possible on a crash prone system.

But there is one potential hazard with this scheme. When power is interupted to the system unexpectedly , "dirty" buffers that have not been written to disk are lost. This happens with a black out, pulling the plug, or by a frustrated newbie forgetting the shutdown command and pushing the "off" button. Most times even these extreme cases are not disasterous. If you are writing a paper on an otherwise idle system, for example, you will lose only changes since the last write to disk. Probably not too much. But if you are moving files around, erasing directories or something similar in the filesystem while the system is improperly shutdown; you can severely damage your system.  I've never heard of it happening, but the literature often warns of this type of thing.
A solution is the /bin/sync command. Type this in after any important modifications are made to your system. This command forces a disk write from the buffer. Thereby, flushing your dirty buffers. Have fun with Linux and share your experiences.