Booting Unix
- Steps in the typical Unix/Linux boot process
- The initial bootstrap program resides in firmware somewhere; indeed, UEFI might even provide enough bootstrap to get the kernel loaded without an MBR
UNIX/Linux Kernel initialization
- Try to find output during a boot (likely to be mostly dealing with the recognition of hardware.) (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, or even /var/log/syslog ) 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 might be able to scan a series of boot messages to 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 were syslinux/extutils and lilo, which are 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
(continued) 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
- 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 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, Slackware, Sabotage, and Devuan for example). 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 still 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.
- This file controls which bootup scripts will be executed
- The scripts are traditionally divided into ``run-levels'', which determine the boot target (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/UEFI can't find bootblock, bootloader, or even the kernel (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 ext4)
Upshot
- You should know Bourne shell-family syntax (especially BASH).
- Occasionally you may wish to customize the boot to either modify the ``out of the box'' behavior of the boot process or to add your own daemon startups.
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.