CS 480 M01 Lecture Notes 10 - Sep 26, 2022

Ch 2. Booting and System Management Daemons

• Find, load, and run bootstrapping code
• Find, load, and run OS kernel
• Run startup scripts and system daemons
• Maintain process hygiene and map system state transitions
      (continues as long as the system remains up for this one - part of normal operation, not just bootstrapping ...)

1. Boot process overview

Changed a lot recently... BIOS => UEFI , init => systemd (adds dependency mgmt, concurrency, logging ) , cloud, ....
General Overview:
Kernel is loaded into memory and begins to execute.

Admins have little direct control during the process - need to modify bootstrap configurations through config files plus can change arguments passed to kernel.
startup / init scripts mount file systems and start system daemons
- managed by
    a series of shell scripts ("init scripts") or
    unit files run in sequence by init or parsed by systemd.
- layout and manner of execution varies among systems.

2. System Firmware

other systems may have proprietary code in ROM that knows network, FS, devices ,...
X
PC had BIOS (several levels of BIOS: PC itself, video, SCSI, other components )
from around 2010 the BIOS firmware of PCs started to be replaced by a Unified Extensible Firmware Interface (UEFI)

When the PC is powered on its CPU is hardwired to execute boot code stored in ROM.
The firmware

• knows about the devices on the motherboard, allows configuration and enabling their exposure to OS through its user interface through special keys on console pressed shortly after the power on: DEL, F2, F8, F10, F11, F12, ...
• probes for hardware and disks
• runs simple health checks
• looks for the next stage bootstrapping code (firmware/bios config allows to designate the boot device)
Legacy BIOS (Basic Input/Output System)
• inits the screen and keyboard, tests the main memory
• loads info about date, time, main peripherals from CMOS
• It allows to choose a device to try to boot from
  BIOS may support networking => boot loader may be loaded from network (PXE or BOOTP)
• reads / loads 1st 512 bytes from disk (MBR - Master Boot Record) - assumes that the boot device starts with MBR
• MBR includes the first-stage (very simple) boot loader and (primitive) disk partitioning table
• MBR too small => code not sophisticated enough to read filesystem => need 2nd-stage boot loader
• Two scenarios:
  • Code from MBR reads partitioning table, identifies the active partition, and loads from its beginning the second-stage boot loader - "volume boot record"
  • Alternatively, 2nd-stage boot loader lives in between MBR and and the beginning of the first partition (64th block) => 32KB of storage: enough for a file system driver - commonly used by GRUB
• The second-stage boot loader loads the kernel
UEFI (Unified Extensible Firmware Interface)
Specification includes modern partitioning scheme : GPT GUID Partition Table (GUID : Globally Unique Identifier)
Also understands FAT (File Allocation Table) filesytems (original MS-DOS layout)
Together define the concept of an EFI System Partition (ESP) - generic FAT filesystem - can be read by any OS
At boot time the firmware checks GPT to identify ESP , reads the configured target application directly from a file in ESP, executes it.
UEFI target could be directly UNIX or Linux kernel (no boot loader needed) - not used in practice much.

UEFI saves the pathname to load from the ESP as a configuration parameter.
standard path /efi/boot/bootx64.efi
OpenSUSE - lab ...
UEFI defines standard APIs to acceess hw - "miniature operating system in its own right"

efibootmgr - examine and modify UEFI variables on running system

# efibootmgr -v
BootCurrent: 0004
BootOrder: 0004,0000,0001,0002,0003
Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0)	PciRoot(0x0)/Pci(0x10,0x0)/SCSI(0,0)
Boot0001* EFI VMware Virtual IDE CDROM Drive (IDE 1:0)	PciRoot(0x0)/Pci(0x7,0x1)/Ata(1,0,0)
Boot0002* EFI Network	PciRoot(0x0)/Pci(0x11,0x0)/Pci(0x1,0x0)/MAC(000c29d7cf75,0)
Boot0003* EFI Internal Shell (Unsupported option)	MemoryMapped(11,0xef9d018,0xf3f7017)/FvFile(c57ad6b7-0515-40a8-9d21-551652854e37)
Boot0004* opensuse-secureboot	HD(1,GPT,c3d4f4e1-657c-479e-9a12-1c3d4af8a5d6,0x800,0xfa000)/File(\EFI\opensuse\shim.efi)

-o to change boot order ...

3. Boot Loaders

Job: Identify and load appropriate OS kernel.
Usually include boot-time user interface to select a kernel and set kernel's configuration arguments/ options
single or -s for single-user mode , ...


LILO + /etc/lilo.conf (not used anymore - was Slackware default )
GRUB (/boot/grub/menu.lst ) past default till 12.1
GRUB2 (/boot/grub2/grub.cfg was grub.conf in 42.3 / before 15.0)
...

4. GRUB: the GRand Unified Boot loader

complete manual at http://www.gnu.org/software/grub/manual

/boot/grub2/grub.cfg:

#
# 
# DO NOT EDIT THIS FILE
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub 

about 130 lines ...

### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/00_tuned ###
set tuned_params=""
set tuned_initrd=""
### END /etc/grub.d/00_tuned ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'openSUSE Leap 15.4'  --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-d0a2b221-0159-4616-834a-4fb743c980a6' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod btrfs
	set root='hd0,gpt2'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint='hd0,gpt2'  d0a2b221-0159-4616-834a-4fb743c980a6
	else
	  search --no-floppy --fs-uuid --set=root d0a2b221-0159-4616-834a-4fb743c980a6
	fi
	echo	'Loading Linux 5.14.21-150400.24.21-default ...'
	linux	/boot/vmlinuz-5.14.21-150400.24.21-default root=UUID=d0a2b221-0159-4616-834a-4fb743c980a6  ${extra_cmdline} resume=/dev/disk/by-id/nvme-KXG50ZNV512G_TOSHIBA_X8MS10B7TYST-part3 splash=silent preempt=full mitigations=auto quiet
	echo	'Loading initial ramdisk ...'
	initrd	/boot/initrd-5.14.21-150400.24.21-default
}
submenu 'Advanced options for openSUSE Leap 15.4' --hotkey=1 $menuentry_id_option 'gnulinux-advanced-d0a2b221-0159-4616-834a-4fb743c980a6' {
	menuentry 'openSUSE Leap 15.4, with Linux 5.14.21-150400.24.21-default' --hotkey=2 --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.14.21-150400.24.21-default-advanced-d0a2b221-0159-4616-834a-4fb743c980a6' {
		load_video
		set gfxpayload=keep
		insmod gzio
		insmod part_gpt
		insmod btrfs
		set root='hd0,gpt2'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint='hd0,gpt2'  d0a2b221-0159-4616-834a-4fb743c980a6
		else
		  search --no-floppy --fs-uuid --set=root d0a2b221-0159-4616-834a-4fb743c980a6
		fi
		echo	'Loading Linux 5.14.21-150400.24.21-default ...'
		linux	/boot/vmlinuz-5.14.21-150400.24.21-default root=UUID=d0a2b221-0159-4616-834a-4fb743c980a6  ${extra_cmdline} resume=/dev/disk/by-id/nvme-KXG50ZNV512G_TOSHIBA_X8MS10B7TYST-part3 splash=silent preempt=full mitigations=auto quiet
		echo	'Loading initial ramdisk ...'
		initrd	/boot/initrd-5.14.21-150400.24.21-default
	}
	menuentry 'openSUSE Leap 15.4, with Linux 5.14.21-150400.24.21-default (recovery mode)' --hotkey=3 --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.14.21-150400.24.21-default-recovery-d0a2b221-0159-4616-834a-4fb743c980a6' {

	...
        }
}


...
}
	




Grub Command Line Options:



Kernel Boot-Time Options Examples:

• acpi=off
• debug - Turns on kernel debugging
• init=/bin/bash - Starts the shell only (emergency recovery)
• single - Booting into Single-User Mode
• root=/dev/sdb - use /dev/sdb as the root device

  These do not persist, nor do changes to /boot/grub2/grub.cfg (after updates) => modify GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub

6. System Management Daemons

• Once loaded the kernel itself takes over ( usually /boot/vmlinuz which is a link to vmlinuz-version-number)
  Kernel ...
  • does hardware / device detection and configuration / checks
    based on how the kernel was built it probes bus and disables the missing and non-responding drivers
  • creates system (spontaneous) processes in user space - not through fork - kernel maintenance related processes / part of kernel really (kswapd, flush, kjournald, ksoftirqd, khubd,..)

    USER        PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    root          1  0.1  0.6  90552 13272 ?        Ss   Sep24   4:52 /usr/lib/systemd/systemd --switched-root --system --deserialize 29
    root          2  0.0  0.0      0     0 ?        S    Sep24   0:00 [kthreadd]
    root          3  0.0  0.0      0     0 ?        I<   Sep24   0:00 [rcu_gp]
    root          4  0.0  0.0      0     0 ?        I<   Sep24   0:00 [rcu_par_gp]
    root          6  0.0  0.0      0     0 ?        I<   Sep24   0:00 [kworker/0:0H-kblockd]
    root          9  0.0  0.0      0     0 ?        I<   Sep24   0:00 [mm_percpu_wq]
    root         10  0.0  0.0      0     0 ?        S    Sep24   0:02 [ksoftirqd/0]
    root         11  0.0  0.0      0     0 ?        I    Sep24   1:10 [rcu_sched]
    

  • and starts system management daemon init / systemd
• init / systemd - PID 1
  - first fully fledged process that makes sure that system runs the right complement of services and daemons at any given time - modes in which to operate
  Modes:
  • Single-user: minimal set of FSs loaded, no services running, root shell on the console
  • Multiuser: all FSs needed get mounted, services running, window system and graphical login manager
  • Server: no GUI (formerly multiuser w/o graphical)
  Each mode has defined complement of system services (and milepost tasks to run when the mode begins or ends).
  Tasks example when transitioning from bootstrapping into multiuser mode:
  • Setting the computer name and timezone
  • FS checking and mounting
  • Cleaning /tmp
  • Network and firewall configuration
  • Starting other daemons and network services
  3 types of init (in UNIX / Linux) :
  1. System V (traditional) with runlevels and 2nd, 3rd level start up scripts in level specific directories (/etc/init.d/; /etc/init.d/rcN.d/, ...)
  2. BSD based (also traditional)
  3. systemd: unified field theory of how services should be configured, accessed, and managed
     dependency modes and services and targets
  ...plus ...
  
  4. launchd (macOS), Upstart (was in Ubuntu), ...

Traditional init

• Modes were called "run levels":
  • 1,S : single-user
  • 2 : multi-user
  • 3 : multi-user with networking
  • 5 : multi-user with networking and GUI
  • 6 : reboot
  • 0 : shutdown
init executes the system startup scripts (sh or bash).
"The exact location, content, and organization of the scripts vary enormously among vendors"...
/etc/inittab tells init what to do in each run-level
  - often just calling the same /etc script with a different paramater which in turn calls other scripts from the particular run-level directory
Scripts in /etc/init.d , /etc/(init.d)/rcN.d, ...
Ex.: /etc/init.d/[S80cups|K80cups] + plus soft links into the relevant run-level directories ...
SuSE scripts were well commented and organized, dependencies, ...
Simple but Problems - " hackish and unsightly" and mainly does not support concurrent execution => longer time to start, change mode/run-level

systemd vs. the world

Complaints...
• ever-increasing scope
• "unified field theory of how services should be configured, accessed, and managed"
• monolithic control over so many of the OS’s other subsystems vs.
    UNIX philosophy to keep system components small, simple, and modular
• imposing new standards and responsibilities on the Linux kernel
• code quality, functional design, bug fixes, ....
• ...
• Adopted by major Linux distros nevertheless forcing most others to follow ...

systemd in detail

systemd aims to standardize configuration and control of system services ... and more ...
Not a single daemon but collection of programs, daemons, libraries, technologies, and kernel components (~70 different binaries).
unit - entity managed by systemd:
• service
• socket
• device
• mount point
• automount point
• swap file or partition
• startup target
• watched filesystem path
• timer
• resource management slice
• group of externally created processes
Behavior of each unit is defined and configured by a unit file in
  /usr/lib/systemd/system/ (not to be modified) and
  /etc/systemd/system (local customization)
rsyncd.service example:

[Unit]
Description=Start the rsync server daemon
After=network.target
ConditionPathExists=/etc/rsyncd.conf

[Service]
ExecStart=/usr/sbin/rsyncd --daemon --no-detach
IOSchedulingClass=idle
CPUSchedulingPolicy=batch
PrivateTmp=true

[Install]
WantedBy=multi-user.target
	

Next: Managed by systemctl


systemctl list-units| less
systemctl list-units| wc
systemctl list-unit-files| wc
systemctl list-units --type=service
systemctl status -l ntp		# older
systemctl status -l chronyd	# new
systemctl status -l cups
systemctl status -l postfix
systemctl stop postfix
systemctl disable postfix
systemctl status -l postfix
systemctl enable postfix
systemctl start postfix
systemctl status -l postfix