DOCSLIB.ORG

The Linux Boot Process

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

The Linux Boot Process Dr. Billy Harris -- Linux booting -- init/services configuration Copyright © 2002 Billy Harris ([email protected]) You are welcome to use and distribute this document so long as you retain this copyright message. Basic Input/Output System Basic Input/Output System ¥ POST power-on self test ¥ÊVideo BIOS VGA = 320x200, 256 colors ¥ÊMemory test ¥ÊDevice initialization ¥ Basic disk drivers ¥ÊSetup ¥ÊExecutes code from the MBR Master Boot Record Very first block of disk holds a boot loader. The purpose of the boot loader is to load an operating system. It has 512 bytes for code to do this. Master Boot Record Very first block of disk holds a boot loader. The purpose of the boot loader is to load an operating system. It has 512 bytes for code to do this. Minus whatever it uses to maintain the partition table. Under Windoze systems, the MBR is very simple — it simply loads specified blocks from the disk and JMPs to begin executing. Grand Unified Boot Loader Grand Unified Boot Loader GRUB ¥ÊMounts the boot partition [normally referenced as /boot] ¥ÊConfiguration is stored as an ordinary text file on the disk. ¥ÊDespite its name, it is still x86 specific, and does not support any of the BSD distributions. Other Boot Loaders /boot/loader for BSD systems LILO [older Linux boot loader] aboot, elilo, milo All have one purpose: →→ ←← Load Linux Linux Kernel The kernel is the operating system ¥ Memory management ¥ÊInterprocess communication ¥ÊFile I/O ¥ Various device drivers. Linux Kernel Linux uses a modular kernel, which means that device drivers can be added and removed without rebooting the system. But what about device drivers that are needed to boot the system (SCSI ?) -- Initial ramdisk [initrd] holds copies of these modules and is also loaded by the boot loader. Linux Booting ¥ÊThe kernel loads init ¥Ê init launches a whole bunch of programs including a variant of getty. ¥Êgetty runs login ¥Ê login su's to the user, and executes the user’s shell. --slight variations if you use an Xwindows-based login. Files which Modify Boot Behavoir /nologin disables non-root logins. /fastboot disabled fsck /forcefsck requires fsck /.autofsck requires fsck Configuring Init Old Days Shell scripts init would execute rc, then rc.local Wanted a new web server? Edit rc.local. Wanted a new ftp server? Edit rc.local. Ranted to replace old web server with a new one? Edit rc.local System V Conceptually much more complicated… Each service provides a shell script which lives in the init.d directory, and can start, stop, or restart the service. The system uses different run levels to determine which services to start and stop. Run Levels Run Level 0: System halt Run Level 1 [S]: Single User Run Level 3: Multi-user; text login Run Level 5: Multi-user; graphical login Run Level 6: System reboot Also have two customized run levels, A and B, which start or stop services, but do not change the actual run level. Init Scripts # cd /etc/init.d # ls anacron gpm kdcrotate atd halt keytable autofs httpd killall netfs random sshd crond identd kudzu functions iptables lpd # ./atd status atd (pid 883) is running... # ./lpd stop Stopping lpd: [ OK ] Service # service httpd restart Stopping httpd: [ OK ] Starting httpd: [ OK ] Can also use service --status-all service httpd --full-restart Services & Run Levels How does init know which services to start/stop? ¥ÊWe still have rc.sysinit, rc, and rc.local. ¥ Better method: each run level has a directory. Each directory has symbolic links to the init.d scripts The name of the link determines whether the service should be started/stopped. Services & Run Levels # cd /etc/rc.d/rc3.d # ls K05saslauthd S13portmap S55sshd K65identd S17keytable S56rawdevices S05kudzu S20random S56xinetd S08iptables S25netfs S58ntpd S10network S26ups S60lpd S12syslog S28autofs S78mysqld # ls -al S60lpd lrwxrwxrwx …S60lpd->../init.d/lpd Telinit Use telinit to change run levels ¥ ÊExamine each K script. If the system is running, execute the script with “stop” ¥ Examine each S script. If the system is not running, execute the script with “start” How does init know whether or not the system is running?Ê Configuring Services The RPMS should install the scripts you need. After installing, a simple # service <name> start should work. Similarly, you can stop a service and use rpm -e to remove it from your system. Chkconfing Chkconfig will add/remove the symbolic links for you. # chkconfig --level 345 ntpd on # chkconfig --list ntpd ntpd 0:off 1:off 2:off 3:on 4:on 5:on 6:off Can also use --del to remove the links entirely [but the script is still in init.d] or --add to add a new service. How does chkconfig know what number to use for the S and K links? Chkconfing Chkconfig will add/remove the symbolic links for you. # chkconfig --level 345 ntpd on # chkconfig --list ntpd ntpd 0:off 1:off 2:off 3:on 4:on 5:on 6:off Can also use --del to remove the links entirely [but the script is still in init.d] or --add to add a new service. How does chkconfig know what number to use for the S and K links? Chkconfing [init.d]# more sshd #!/bin/bash # # Init file for OpenSSH server daemon # # chkconfig: 2345 55 25 # description: OpenSSH server daemon Redhat Service Confifuration ntsysv menu-based text program redhat-configure-services GNOME based program. Both give a list of possible services; you can check/uncheck to enable/disable. Inittab # # inittab This file describes # the system in a id:5:initdefault: # Trap CTRL-ALT-DELETE ca::ctrlaltdel:/sbin/shutdown -t3 -r now l2:2:wait:/etc/rc.d/rc 2 1:2345:respawn:/sbin/mingetty tty1 x:5:respawn:/etc/X11/prefdm -nodaemon.
Recommended publications
  • Boot Mode Considerations: BIOS Vs UEFI

    Boot Mode Considerations: BIOS Vs UEFI

    Boot Mode Considerations: BIOS vs. UEFI An overview of differences between UEFI Boot Mode and traditional BIOS Boot Mode Dell Engineering June 2018 Revisions Date Description October 2017 Initial release June 2018 Added DHCP Server PXE configuration details. The information in this publication is provided “as is.” Dell Inc. makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any software described in this publication requires an applicable software license. Copyright © 2017 Dell Inc. or its subsidiaries. All Rights Reserved. Dell, EMC, and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be the property of their respective owners. Published in the USA [1/15/2020] [Deployment and Configuration Guide] [Document ID] Dell believes the information in this document is accurate as of its publication date. The information is subject to change without notice. 2 : BIOS vs. UEFI | Doc ID 20444677 | June 2018 Table of contents Revisions............................................................................................................................................................................. 2 Executive Summary ............................................................................................................................................................ 4 1 Introduction ..................................................................................................................................................................
  • Operating System Boot from Fully Encrypted Device

    Operating System Boot from Fully Encrypted Device

    Masaryk University Faculty of Informatics Operating system boot from fully encrypted device Bachelor’s Thesis Daniel Chromik Brno, Fall 2016 Replace this page with a copy of the official signed thesis assignment and the copy of the Statement of an Author. Declaration Hereby I declare that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Daniel Chromik Advisor: ing. Milan Brož i Acknowledgement I would like to thank my advisor, Ing. Milan Brož, for his guidance and his patience of a saint. Another round of thanks I would like to send towards my family and friends for their support. ii Abstract The goal of this work is description of existing solutions for boot- ing Linux and Windows from fully encrypted devices with Secure Boot. Before that, though, early boot process and bootloaders are de- scribed. A simple Linux distribution is then set up to boot from a fully encrypted device. And lastly, existing Windows encryption solutions are described. iii Keywords boot process, Linux, Windows, disk encryption, GRUB 2, LUKS iv Contents 1 Introduction ............................1 1.1 Thesis goals ..........................1 1.2 Thesis structure ........................2 2 Boot Process Description ....................3 2.1 Early Boot Process ......................3 2.2 Firmware interfaces ......................4 2.2.1 BIOS – Basic Input/Output System . .4 2.2.2 UEFI – Unified Extended Firmware Interface .5 2.3 Partitioning tables ......................5 2.3.1 MBR – Master Boot Record .
  • White Paper: Indestructible Firewall in a Box V1.0 Nick Mccubbins

    White Paper: Indestructible Firewall in a Box V1.0 Nick Mccubbins

    White Paper: Indestructible Firewall In A Box v1.0 Nick McCubbins 1.1 Credits • Nathan Yawn ([email protected]) 1.2 Acknowledgements • Firewall-HOWTO • Linux Router Project • LEM 1.3 Revision History • Version 1.0 First public release 1.4 Feedback • Send all information and/or criticisms to [email protected] 1.5 Distribution Policy 2 Abstract In this document, the procedure for creating an embedded firewall whose root filesystem is loaded from a flash disk and then executed from a RAMdisk will be illustrated. A machine such as this has uses in many environments, from corporate internet access to sharing of a cable modem or xDSL connection among many computers. It has the advantages of being very light and fast, being impervious to filesystem corruption due to power loss, and being largely impervious to malicious crackers. The type of firewall illustrated herein is a simple packet-filtering, masquerading setup. Facilities for this already exist in the Linux kernel, keeping the system's memory footprint small. As such the device lends itself to embedding very well. For a more detailed description of firewall particulars, see the Linux Firewall-HOWTO. 3 Equipment This project has minimal hardware requirements. An excellent configuration consists of: For a 100-baseT network: • SBC-554 Pentium SBC with PISA bus and on-board PCI NIC (http://www.emacinc.com/pc.htm#pentiumsbc), approx. $373 • PISA backplane, chassis, power supply (http://www.emacinc.com/sbcpc_addons/mbpc641.htm), approx. $305 • Second PCI NIC • 32 MB RAM • 4 MB M-Systems Flash Disk (minimum), approx. $45 For a 10-baseT network: • EMAC's Standard Server-in-a-Box product (http://www.emacinc.com/server_in_a_box.htm), approx.
  • Chapter 3. Booting Operating Systems

    Chapter 3. Booting Operating Systems

    Chapter 3. Booting Operating Systems Abstract: Chapter 3 provides a complete coverage on operating systems booting. It explains the booting principle and the booting sequence of various kinds of bootable devices. These include booting from floppy disk, hard disk, CDROM and USB drives. Instead of writing a customized booter to boot up only MTX, it shows how to develop booter programs to boot up real operating systems, such as Linux, from a variety of bootable devices. In particular, it shows how to boot up generic Linux bzImage kernels with initial ramdisk support. It is shown that the hard disk and CDROM booters developed in this book are comparable to GRUB and isolinux in performance. In addition, it demonstrates the booter programs by sample systems. 3.1. Booting Booting, which is short for bootstrap, refers to the process of loading an operating system image into computer memory and starting up the operating system. As such, it is the first step to run an operating system. Despite its importance and widespread interests among computer users, the subject of booting is rarely discussed in operating system books. Information on booting are usually scattered and, in most cases, incomplete. A systematic treatment of the booting process has been lacking. The purpose of this chapter is to try to fill this void. In this chapter, we shall discuss the booting principle and show how to write booter programs to boot up real operating systems. As one might expect, the booting process is highly machine dependent. To be more specific, we shall only consider the booting process of Intel x86 based PCs.
  • Network Boot and Exotic Root HOWTO

    Network Boot and Exotic Root HOWTO

    Network Boot and Exotic Root HOWTO Brieuc Jeunhomme frtest [email protected] Logilab S.A. Revision History Revision 0.3 2002−04−28 Revised by: bej Many feedback inclusions, added links to several projects Revision 0.2.2 2001−12−08 Revised by: dcm Licensed GFDL Revision 0.2.1 2001−05−21 Revised by: logilab Fixed bibliography and artheader Revision 0.2 2001−05−19 Revised by: bej Many improvements and included Ken Yap's feedback. Revision 0.1.1 2001−04−09 Revised by: logilab First public draft. Revision 0.1 2000−12−09 Revised by: bej Initial draft. This document explains how to quickly setup a linux server to provide what diskless linux clients require to get up and running, using an IP network. It includes data and partly rewritten text from the Diskless−HOWTO, the Diskless−root−NFS−HOWTO, the linux kernel documentation, the etherboot project's documentation, the linux terminal server project's homepage, and the author's personal experience, acquired when working for Logilab. Eventually this document may end up deprecating the Diskless−HOWTO and Diskless−root−NFS−HOWTO. Please note that you'll also find useful information in the From−PowerUp−to−bash−prompt−HOWTO and the Thin−Client−HOWTO, and the Claus−Justus Heine's page about NFS swapping. Network Boot and Exotic Root HOWTO Table of Contents 1. Introduction.....................................................................................................................................................1 1.1. What is this all about?.......................................................................................................................1 1.2. Thanks...............................................................................................................................................1 1.3. Diskless booting advocacy................................................................................................................1 1.3.1. Buying is cheaper than building.......................................................................................1 1.3.2.
  • DOS Technical Reference

    DOS Technical Reference

    -------- - ---- Personal Computer - ---- - --- ------ - . - Programming Family DOS Technical Reference 6138536 Preliminary First Edition (February 1985) The following paragraph does not apply to the United Kingdom or any country where such provisions are inconsistent ~ith local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES TIllS PUBLICATION "AS IS" wrrnom WARRANTY OF ANY KIND, EmlER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, 1HE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. lbis publication could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and!or changes in the product(s) and/or the program(s) described in this pUblication at any time. It is possible that this publication may contain reference to, or information about, IBM products (machines and programs), programming, or services that are not announced in your country. Such references or information must not be construed to mean that IBM intends to announce such IBM products, programming, or services in your country. Products are not stocked at the address below. Requests for copies of this publication and for technical information about IBM Personal Computer products should be made to your authorized IBM Personal Computer dealer, IBM Product Center, or your IBM Marketing Representative. The following paragraph applies only to the United States and Puerto Rico: A Reader's Comment Form is provided at the back of this publication. If the form has been removed.
  • Unit V Algorithm for Booting the UNIX System

    Unit V Algorithm for Booting the UNIX System

    Unit V Algorithm for booting the UNIX system : As we’ve noted, the boot process begins when the instructions stored in the computer’s permanent, nonvolatile memory (referred to colloquially as the BIOS, ROM,NVRAM, and so on) are executed. This storage location for the initial boot instructions is generically referred to as firmware (in contrast to “software,” but reflecting the fact that the instructions constitute a program[2]). These instructions are executed automatically when the power is turned on or the system is reset, although the exact sequence of events may vary according to the values of stored parameters.[3] The firmware instructions may also begin executing in response to a command entered on the system console (as we’ll see in a bit). However they are initiated, these instructions are used to locate and start up the system’s boot program , which in turn starts the Unix operating system. The boot program is stored in a standard location on a bootable device. For a normal boot from disk, for example, the boot program might be located in block 0 of the root disk or, less commonly, in a special partition on the root disk. In the same way, the boot program may be the second file on a bootable tape or in a designated location on a remote file server in the case of a network boot of a diskless workstation. There is usually more than one bootable device on a system. The firmware program may include logic for selecting the device to boot from, often in the form of a list of potential devices to examine.
  • Bootloader and Startup Feature Overview and Configuratoin Guide

    Bootloader and Startup Feature Overview and Configuratoin Guide

    TechnicalTTechnicalechnical GuideGuidGuidee Bootloader and Startup Feature Overview and Configuration Guide The AlliedWare Plus™ Bootloader Every switch has a startup process. The end result of the startup is that the unit is running a specific version of the operating system software, with the features configured according to a specific startup configuration file. The startup process goes through two main phases: First, the switch boots up off a dedicated bootloader software image, which initializes core functionality of the unit. Then, the bootloader launches the main operating software image, and passes control over to this operating system. The bootloader is the executable code responsible for setting up the system and loading the operating system software. The bootloader is the software that runs the unit when it first powers up, performing basic initialization and executing the product software release. As part of the startup process of the switch, the bootloader allows you various options before running the product operating system software. C613-22004-00 x REV A alliedtelesis.com Products and software version that apply to this guide This guide applies to all AlliedWare Plus products, running version 5.4.4 or later. However, not all features in this guide are supported on all products. To see whether a product supports a particular feature or command, see the following documents: The product’s Datasheet The AlliedWare Plus Datasheet The product’s Command Reference These documents are available from the above links on our website at alliedtelesis.com. Feature support may change in later versions. For the latest information, see the above documents. Content The AlliedWare Plus™ Bootloader ....................................................................................
  • Using the OMAP-L132/L138 Bootloader

    Using the OMAP-L132/L138 Bootloader

    Application Report SPRAB41F–January 2014–Revised January 2019 Using the OMAP-L132/L138 Bootloader Joseph Coombs ABSTRACT This application report describes various boot mechanisms supported by the OMAP-L132/L138 bootloader read-only memory (ROM) image. Topics covered include the Application Image Script (AIS) boot process, an AISgen tool used to generate boot scripts, protocol for booting the device from an external master device, a UART Boot Host GUI for booting the device from a host PC, and any limitations, default settings, and assumptions made by the bootloader. Project collateral discussed in this application report can be downloaded from the following URL: http://www.ti.com/lit/zip/sprab41. Contents 1 Introduction ................................................................................................................... 3 2 Boot Modes................................................................................................................... 3 3 Non-AIS Boot Modes........................................................................................................ 3 4 Application Image Script (AIS) Boot....................................................................................... 6 5 AISgen: Tool to Generate Boot Script (AIS Image).................................................................... 11 6 Master Boot – Booting From a Slave Memory Device ................................................................ 19 7 Slave Boot – Booting From an External Master Host ................................................................
  • Sbadmin for Linux System Recovery Guide Is a Supplement to the Sbadmin User Guide, Providing Details on Reinstalling a Linux System from a Sbadmin System Backup

    Sbadmin for Linux System Recovery Guide Is a Supplement to the Sbadmin User Guide, Providing Details on Reinstalling a Linux System from a Sbadmin System Backup

    Linux System Recovery Guide Version 8.2 Trademarks and Copyrights © Copyright Storix, Inc. 1999-2021 SBAdmin is a registered trademark of Storix, Inc. SBAdmin is a trademark of Storix, Inc in the USA and other countries Intel is a registered trademark of Intel, Inc. Linux is a registered trademark of Linus Torvalds. Intel, Pentium, IA32, Itanium, Celeron and IA64 are registered trademarks of Intel Corporation. AMD, Opteron, and Athlon are registered trademarks of Advanced Micro Devices. HP Integrity servers are registered trademarks of Hewlett-Packard Development Company. Publicly Available Software This product either includes or is developed using source code that is publicly available: AESCrypt* Rijndael and Cipher Block Feedback Copyright 1999, 2000 Enhanced Software Technologies Inc. mode (CFB-128) encryption/decryption http://aescrypt.sourceforge.net/ algorithms BusyBox Single executable containing tiny Copyright 1989, 1991 Free Software Foundation, Inc. versions of common UNIX utilities http://busybox.net/cgi-bin/cvsweb/busybox/ LILO LInux boot Loader Copyright 1999-2003 John Coffman. Copyright 1992-1998 Werner Almesberger. http://freshmeat.net/projects/lilo/ Tcl Open source scripting language Copyright Regents of the University of California, Sun Microsystems, Inc. http://tcl.sourceforge.net Tk Tk graphics toolkit Copyright Regents of the University of California, Sun Microsystems, Inc. http://tcl.sourceforge.net DropBear A Smallish SSH 2 Server and Client Copyright 2002, 2003 Matt Johnston http://www.matt.ucc.asn.au/dropbear/dropbear.html GRUB Grand Unified Bootloader (GNU GRUB) Copyright 1989, 1991 Free Software Foundation, Inc. http://www.gnu.org/software/grub/grub.html Lighttpd Secure, fast, compliant and flexible Copyright 2004 Jan Kneschkle, incremental web-server http://www.lighttpd.net OpenSSL Toolkit implementing Secure Socket Copyright 1998-2008 The OpenSSL Project Layer Copyright 1995-1998 Eric A.
  • Installation Guide

    Installation Guide

    ATA Hard Drive Installation Guide Copyright © 2002 Maxtor Corporation. All rights reserved. Changes are periodically made to the information herein which will be incorporated in revised editions of this publication. Maxtor may make changes or improvements to the product(s) described in this publication at any time and without notice. MaxBlast is a trademark and Maxtor is a registered trademark of Maxtor Corporation. All other brands or products are trademarks or registered trademarks of their respective holders. FCC Declaration of Conformance This device complies with part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received including interference that may cause undesired operation. Maxtor Corporation Part Number 500 McCarthy Blvd., Milpitas, California 95035 USA 20186800/A P/N: 20186800/A Contents 1 Getting Started . 1 Handling the Hard Drive. 1 Operating System Requirements . 1 Back Up Your Data . 2 Important Capacity Notice . 2 2 Installing the Hard Drive. 3 Removing the System Cover. 3 Setting the Jumpers . 4 Mounting the Hard Drive . 7 Attaching the Cables . 9 Configuring the System BIOS . 12 3 Formatting the Hard Drive . 15 Installing Hard Drive as a Boot Drive. 16 Installing Hard Drive to Replace Existing Hard Drive. 20 Installing Hard Drive as an Additional Hard Drive . 21 4 Getting Help . 23 Installation Troubleshooting . 23 Frequently Asked Questions . 25 5 Glossary . 27 Maxtor Product Warranty. 30 Getting Started 1 Thank you for selecting a Maxtor hard drive storage product. This installation guide will lead you through the installation of your hard drive.
  • Using the OMAP-L1x7 Bootloader Urmil Parikh and Joseph Coombs

    Using the OMAP-L1x7 Bootloader Urmil Parikh and Joseph Coombs

    Application Report SPRAB04G– June 2012 Using the OMAP-L1x7 Bootloader Urmil Parikh and Joseph Coombs ABSTRACT This application report describes various boot mechanisms supported by the OMAP-L1x7 bootloader read- only memory (ROM) image. Topics covered include the Application Image Script (AIS) boot process, an AISgen tool used to generate boot scripts, protocol for booting the device from an external master device, a UART Boot Host GUI for booting the device from a host PC, and any limitations, default settings, and assumptions made by the bootloader. Project collateral discussed in this application report can be downloaded from the following URL: http://www.ti.com/lit/zip/SPRAB04. Contents 1 Introduction .......................................................................................................................................................... 2 2 Boot Modes .......................................................................................................................................................... 3 3 Non-AIS Boot Modes ........................................................................................................................................... 3 4 Application Image Script (AIS) Boot ..................................................................................................................... 5 5 AISgen: Tool to Generate Boot Script (AIS image) ........................................................................................... 11 6 Master Boot – Booting From a Slave Memory Device