See this page as a slide show

Booting And Shutting Down

Colorado State University
Computer Science Department

Original slides from Dr. James Walden at Northern Kentucky University.

Topics

1. Booting
2. Bootstrap loaders
3. Run levels
4. Startup system
5. Shutdown and reboot

Booting

1. ROM boot code (BIOS in PCs)
2. Master Boot Record (MBR)
3. Bootloader
4. Kernel
5. Hardware detection and configuration
6. Creation of system processes
7. Multiuser operation

BIOS

• BIOS actions:
  • Load CMOS settings.
  • Initialize registers and power management.
  • POST (Power On Self Test.)
  • Display system settings (if key pressed.)
  • Activate other BIOSes
    • Disk interfaces
    • Graphics cards
    • Network interfaces
  • Find bootable device.
  • Load MBR.
  • Run MBR program.

MBR

• Up to four primary partitions in MBR:
  • Has CHS (Cyl/Head/Sector) addresses or partition
  • LBA (Logical Block Addressing) for newer disk drives
• One can be used as an extended partition
  • Links to an Extended Boot Record (EBR) on first sector
  • Each logical partition is described by its own EBR
  • Includes link to the next EBR, to allow any # of partitions

Bootloader: GRUB

• Stage 1 (stored in MBR or boot sector)
  • Initialize the system briefly.
  • Detect the geometry and access mode of the loading drive.
  • Load the first sector of Stage 2.
  • Jump to the starting address of the Stage 2.
• Stage 1.5 (stored in sectors of MBR track)
  • One version for each filesystem.
  • Loads stage 2 from filesystem.
• Stage 2 (stored in filesystem)
  • Displays menu of OS choices.
  • Often displays boot splash screen.
  • Loads selected OS kernel.

GRUB Boot

• Automatically boots default OS after timeout.
• Key sequences bring up
  • Menu of boot options (Linux, previous version of Linux, Windows, etc.)
  • Edit kernel options (runlevel, other features)
  • GRUB command shell
• A boot prompt password may be required before edit privileges or shell access granted.
  • Can bypass OS security by specifying kernel options or accessing files from GRUB shell.

Booting with GRUB

• Direct Boot
  • Specify OS kernel image to load.
• Chainloading
  • Specify another bootloader to load.
  • Chainload NTLDR to boot MS Windows.

GRUB Config

My /etc/default/grub:

    GRUB_DEFAULT=0
    GRUB_HIDDEN_TIMEOUT_QUIET=true
    GRUB_TIMEOUT=4
    GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
    GRUB_CMDLINE_LINUX=""

Edit, then update-grub.

How can GRUB_DISTRUBTOR possibly do shell stuff at boot-time?!

GRUB Naming Convention

• GRUB uses BIOS hard disk numbers
  • OS may not number disks identically to BIOS.
• Examples
  • (hd0,0) First partition of first hard disk
  • (hd1,2) Third partition of second hard disk.

Kernel

• GRUB loads kernel file into memory: /boot/vmlinuz-VERSION
• Kernel uncompresses self and begins running.
• Sets up interrupts and virtual memory.
• Initial RAMdisk /boot/initrd.img-VERSION to memory.
• Kernel uncompresses initrd and mounts as /sysroot.
• Kernel loads drivers and modules from /sysroot.
  • SCSI and RAID drivers, ext3 filesystem module, etc.
• Switches from real mode to protected mode.
• Creates kernel threads (ksoftirq, khelper, kblockd)
• Starts systemd, init, upstart, or whatever’s in fashion.

Kernel Arguments

Numeric arguments

• Specify runlevel.
• single also specifies single user mode

Root device options

• root= specifies which root device to use
• ro, rw specify access type

Kernel Arguments (continued)

Console options

• console=ttyS1,9600 will use serial console

Hardware options

• Enable, disable specific hardware devices/features.

See bootparam for many more.

Getting it all going

There has to be an initial process that gets things going. It must:

• mount disks
• start the ssh daemon
• start bluetooth processes
• start crond
• start the D-Bus daemon
• and many, many, more!

Historically, Linux systems have used the System V init to accomplish this.

What's wrong with init?

• Performance
  • Starts services sequentially.
  • Shell scripts spawn lots of processes.
• Manual configuration
  • Order to start services determined manually, a huge problem.
    • Network before authorization before NFS.
• Reliability
  • init does NOT monitor or restart services after boot. If a service dies, it dies. So sad!
• Hotplug hardware
  • Drives mounted at boot.
  • What about USB or network drives?

Competition

init has several competitors, including:

• initng
• runit
• upstart
• systemd

systemd is quite popular, and quite controversial. It is now the default startup mechanism for Debian, Fedora, Red Hat, SUSE, and Ubuntu. We will discuss only systemd.

Service Cheatsheet

Command	Purpose
systemctl start name	Start a service right now.
systemctl stop name	Stop a service right now.
systemctl restart name	Restart a service (stop+start).
systemctl reload name	Reload configuration (config file changed).
systemctl status name	How’s it going?
systemctl enable name	Start this service at each boot.
systemctl disable name	Do not start service at each boot.
systemctl is-active name	What services are active?
systemctl list-units --type service --all	What services exist?

Targets in systemd

Old init Runlevel	Systemd Target	Description
0	poweroff.target	Halt the system.
1, s, single	rescue.target	Single user mode
3	multi-user.target	Multi-user, non-graphical login via console or the network
5	graphical.target	Same as previous plus graphical login
6	reboot.target	Reboot
	emergency.target	Emergency shell

Switch to a different target: systemctl isolate name

What if single user mode doesn’t work?

• Nuke it from orbit, or:
• Bypass systemd by booting into shell
  • Pass init=/bin/bash argument to kernel.
  • Probably want to specify rw option as well.
  • No need for root password, usually.
  • No housekeeping performed.
• Boot from Live Install DVD

It’s all systemd

$ PATH=/sbin:/bin:/usr/bin
$ type -p shutdown halt poweroff reboot
/sbin/shutdown
/sbin/halt
/sbin/poweroff
/sbin/reboot
$ ls -l $(type -p shutdown halt poweroff reboot)
lrwxrwxrwx 1 root root 16 Sep 23 20:25 /sbin/halt -> ../bin/systemctl
lrwxrwxrwx 1 root root 16 Sep 23 20:25 /sbin/poweroff -> ../bin/systemctl
lrwxrwxrwx 1 root root 16 Sep 23 20:25 /sbin/reboot -> ../bin/systemctl
lrwxrwxrwx 1 root root 16 Sep 23 20:25 /sbin/shutdown -> ../bin/systemctl

Example systemd .service file

/usr/lib/systemd/system/crond.service:

    [Unit]
    Description=Command Scheduler
    After=auditd.service nss-user-lookup.target systemd-user-sessions.service time-s
    ync.target ypbind.service

    [Service]
    EnvironmentFile=/etc/sysconfig/crond
    ExecStart=/usr/sbin/crond -n $CRONDARGS
    ExecReload=/bin/kill -HUP $MAINPID
    KillMode=process

    [Install]
    WantedBy=multi-user.target

References

• M. Tim Jones, “Inside the Linux boot process,” https://www.ibm.com/developerworks/library/l-linuxboot/index.html, 2006.
• Starman, “Boot records revealed: MBR details,” http://mirror.href.com/thestarman/asm/mbr/index.html
• “Extended boot record,” https://en.wikipedia.org/wiki/Extended_Boot_Record.
• GRUB manual https://www.gnu.org/software/grub/manual/grub.html
• “How it works: Master Boot Record (MBR),” http://www.ata-atapi.com/hiwmbr.htm