Getting grubby: Demystifying the Linux start-up processes
The boot loader hands over responsibility to the selected kernel. Unless quiet was directed as a configuration item like above, arcane messages will fly past on the screen. This is what will be the first introduction to Linux that many people see.
These messages contain a load of useful information and can be reviewed after logging in by viewing /var/log/dmesg or running the dmesg command. They explain precisely what the Linux kernel is up to and give significant clues to troubleshooting any hardware or service problems.
Important messages include the kernel version, the amount of RAM and the number of CPUs detected, hard drives and partitions which have been found, network cards that have been found, and the active and swap filesystems loaded.
If you are having hardware compatibility problems, one very important first step is to consult these boot-time messages to check if any errors were displayed and if your hardware item was actually detected and a driver loaded.
While it is possible to compile drivers into the kernel, most all contemporary kernels are modular so that only required drivers are loaded into memory. Not all drivers are hardware-related; the ext3 filesystem is a software-based module. You can inspect the modules loaded via the command lsmod.
Processing begins; runlevels run
Finally, with all this loading complete, Linux is now able to kick off process number one. This is always a process known as init (or upstart in Ubuntu and experimental versions of Debian), which varies its behaviour based on parameters specified in /etc/inittab. init does two major things. Firstly, it fires off /etc/rc.d/rc.sysinit which configures the network, sets the system clock, mounts partitions and performs many other things. Secondly, though, init determines which runlevel it should be in.
A runlevel is merely a group of activities, bound together by a numbered runlevel. For each runlevel, there are a series of scripts to start specific processes which may be more or less than other runlevels. This allows the system to have a set of very distinct operating environments – in contrast to Microsoft Windows’ mere pair of safe and normal modes. A directive initdefault in /etc/inittab indicates the default runlevel, which is either runlevel 3 or 5, and which are the two most functional. Runlevel 3 provides multiuser services with full networking. Runlevel 5 is similar but with GUI services instead of a purely text console mode.
(Runlevel 0 halts the system; runlevel 1 provides a single-user environment that is mostly used for maintenance tasks; runlevel 2 offers a multi-user environment with some basic networking functionality; and runlevel 4 is unused. Runlevel 6 also exists, which reboots the system.)
The scripts which make runlevels work are stored under /etc/rc.d, in their own numbered subdirectory. Each script whose name begins with a K is executed, to stop (or kill) existing processes, and each script whose name begins with S is executed, to start new processes.
ITWIRE SERIES - CIO SUMMIT GOLD COAST
For CIOs & Senior IT Management Summit on the Gold Coast!This event has been personally vetted by the iTWire CEO who has attended four of these conferences in the past and is an event you cannot afford to miss!
We can guarantee that this conference is of great value. Network with fellow CIOs and IT Mgrs and hear Glenn Archer CIO, Australian Government Information Management Office (AGIMO), Matt Barrie, Award-winning Entrepreneur to provide insights on Navigating Your Entrepreneurial Initiatives in a Hyper-connected New World, Stephen Tame, CIO & Head of Group Information Technology, Jetstar, Tim Thurman, CIO, Australian Securities Exchange (ASX).
David M Williams
David has been computing since 1984 where he instantly gravitated to the family Commodore 64. He completed a Bachelor of Computer Science degree from 1990 to 1992, commencing full-time employment as a systems analyst at the end of that year. Within two years, he returned to his alma mater, the University of Newcastle, as a UNIX systems manager. This was a crucial time for UNIX at the University with the advent of the World-Wide-Web and the decline of VMS. David moved on to a brief stint in consulting, before returning to the University as IT Manager in 1998. In 2001, he joined an international software company as Asia-Pacific troubleshooter, specialising in AIX, HP/UX, Solaris and database systems. Settling down in Newcastle, David then found niche roles delivering hard-core tech to the recruitment industry and presently is the Chief Information Officer for a national resources company where he particularly specialises in mergers and acquisitions and enterprise applications.



















