Booting Unix
- Steps in the typical Unix boot process
- The initial bootstrap program resides in firmware somewhere (e.g., the Sun "monitor", PC BIOS mode, [U]EFI (also see this article)
- ``man grub?'' on Linux
UNIX/Linux Kernel initialization
- Try to find output from the kernel and device drivers recognizing the hardware of the system. You might try CTRL-ALT-F1 / CTRL-ALT-F2} / etc. to find the
virtual terminal output. Also, if you are coming up with X enabled, you may have to click on a button labeled something like ``details'' to see more, or perhaps the "Esc" key. It all varies these days.
- Often logged in /var/adm/messages (or /var/log/messages, or perhaps /var/log/boot.log) and typically the system console and usually accessible via dmesg --- but, dmesg is not available on all UNIXes.
- Very system-specific, but you might be able to scan a series of boot messages and spot problems.
Linux booting
Linux provides a flexible multi-operating system boot loader named grub (GRand Unified Bootloader) that can be used to boot different operating systems. Like Windows bootloaders, it can also sit on the Master Boot Record (MBR) of the boot device and transfer control to specific operating system kernels depending on either a user type-in or a default. Grub comes in two flavors, 1.0 and 2.0.
Previously, there was lilo, which is still seen occasionally (especially when booting from cd/dvd).
Here's a grub configuration file on a Linux Mint 17.1 machine:
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
UNIX/Linux init and bootup scripts
- UNIX/Linux operating systems are rapidly moving toward a single
unified "systemd" world. The bootup sequence for systemd is
here.
- The first place to look is /lib/systemd/;
however, the systemd "infrastructure" is in such a state of flux
that's a little hard to predict where anything useful might be.
The official documentation suggests the default state is
in /lib/systemd/system/default.target, but I don't see that on any
non-Redhat machines.
- Old-style BSD-based systems used a simple naming convention
of /etc/rc*. This simplistic version of startup scripts
is rare these days. More common are the System V startup scripts
(with many variations).
- SystemV bootup scripts allowed for more complex script
configurations (the scripts are ``buried'' in directories
of /etc/ rather than just being all in one
directory). The init process starts the rc { }
file processing.
- But maybe what we want instead is more like the daemontools approach. Instead of "dependencies", maybe we should make
daemons that are smart enough to fail gracefully until a needed service is available.
UNIX/Linux bootup scripts
- /etc/inittab is the master config file for init — but it doesn't have much when you are using systemd.
# inittab is no longer used when using systemd.
#
# ADDING CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM.
#
# Ctrl-Alt-Delete is handled by /etc/systemd/system/ctrl-alt-del.target
#
# systemd uses 'targets' instead of runlevels. By default, there are two main targets:
#
# multi-user.target: analogous to runlevel 3
# graphical.target: analogous to runlevel 5
#
# To set a default target, run:
#
# ln -s /lib/systemd/system/.target /etc/systemd/system/default.target
#
This file controls which bootup scripts will be executed by init, but not by systemd!
The traditional scripts are divided into ``run-levels'', which determine what sort of booting you are doing (multi-user, single-user, shutdown, specialty boot, etc.). The ``man'' page for ``init'' (``man init'') explains the run level numbering.
Old style UNIX/Linux bootup scripts
The idea for init is that soft-links that start with a capital ``S'' are executed at startup; soft-links with a leading capital ``K'' are executed at shutdown (you can see this behavior in /sbin/rc2 on Solaris and /etc/rc.d/rc on RedHat).
The Linux init package usually includes a utility named runlevel that you can run to determine the current machine's run level.
Old style UNIX bootup scripts
Notice the location of the actual init shell scripts can vary (/etc, /etc/rc.d, etc.), even between different versions of UNIX. For instance, Solaris: /etc/rc?.d (/etc/rc2.d is typical), CentOS Linux: /etc/rc.d
UNIX/Linux Controlling init link sprawl
On some systems, you can use chkconfig to control the maze of links.
# chkconfig --list # show what is on and what is off for runlevels
anacron 0:off 1:off 2:on 3:on 4:on 5:on 6:off
atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
atieventsd 0:off 1:off 2:off 3:off 4:off 5:on 6:off
auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
autofs 0:off 1:off 2:off 3:on 4:on 5:on 6:off
# chkconfig --level 2345 sendmail on # have sendmail start 2345
# chkconfig --del sendmail # remove sendmail from chkconfig management
# chkconfig --add sendmail # add sendmail to chkconfig management
Typical problems with UNIX booting
- Error in startup scripts (much more common problem on established servers than rather newly installed servers, and generally happens when a sysadmin has made some sort of change)
- The monitor/BIOS can't find bootblock or bootloader (much more likely during install)
- Kernel won't load or recognize your hardware (much more likely during install)
- Damaged root (and/or /usr or maybe even /var) file system (not seen as often these
days due to good journaling file systems such as ext3)
Upshot
- You should know BASH syntax, so you can figure out what went wrong during boot.
- Occasionally you may wish to customize a shell script.
- Traditionally, best practice has been widely considered to keep all of your local customizations in separate shell scripts (e.g., /etc/rc.local is a good place on Linux machines, /etc/rc.d/S99local Solaris).
Upshot
Beware that older versions of UNIX/Linux used symbolic links between a common script directory and the particular runlevel directory. Treat any modifications to the startup shell scripts as you would any other program -- edit, test (reboot), document, debug until it works.
Upshot
In a major site, you may find that weekly reboots at an off time (such as early on Sunday morning) are automatically done to discover any bad interactions among system modifications that might have been made recently.
