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)
- See ``man eeprom'', ``man monitor'' on Suns
- ``man grub'' on Linux (grub is covered in more detail below)
UNIX/Linux Kernel initialization
- You can see running monologue from various kernel routines, mostly dealing with the kernel and device drivers recognizing the hardware of the system. (You may have to use 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.)
- 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
- Tend to be very system-specific but with experience you should 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's behavior is controlled by /boot/grub/grub.conf.
Previously, there was lilo, which is still seen occasionally, and even older, the loadlin program which used DOS to boot Linux.
Grub2 is pretty much the standard.
Linux booting
Here's a grub configuration file on a Linux Mint 17.1 machine:
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
Linux booting
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
Linux booting
Here's a grub configuration file on a Linux Mint 17.1 machine:
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
UNIX/Linux init and bootup scripts
- Some UNIX/Linux operating systems still use some series of
programs and/or scripting that are started at boot
time (LFS; Sabotage; DEVUAN?). These scripts are plain shell script
text files.
- Many BSD-based systems still use a simple naming convention
of /etc/rc*.
UNIX/Linux init and bootup scripts
- The few systems using SystemV bootup scripts allow 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.
init: UNIX/Linux bootup scripts
- In SYSV, /etc/inittab is the master config file for init — but it doesn't have much in it these days.
- This file controls which bootup scripts will be executed
- The scripts are traditionally 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.
init: UNIX/Linux bootup scripts
The idea 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 includes a nifty utility named runlevel that you can run to determine the current machine's run level.
init: UNIX bootup scripts
Notice the location of the actual startup 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
init: 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
The systemd approach
- Using dependency resolution, socket, and even D-Bus activation to speed booting up.
- Best reference for systemd administration is (as is so often the case) the Arch Wiki.
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)
- Can't find swap partition(s) (very 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 ext4)
Upshot
- You should know BASH syntax, so you can figure out what went wrong during boot.
- Occasionally you may wish to customize the shell scripts to either modify the ``out of the box'' behavior of the boot process or to add your own daemon startups.
- 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). However, with systems governed by chkconfig, it's best to use its scheme.
Upshot
Many versions of UNIX/Linux SYSV implementations choose to use 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 boot modifications that might have been made recently.
