Starting and stopping the system
Starting the system; Things you can do before booting; What are you going to boot?; Running the kernel; Single-user mode; Shutting down and rebooting the system; FreeBSD without disks.
Before you can run FreeBSD, you need to start it up. That's normally pretty straightforward: you turn the machine on, a lot of things scroll off the screen, and about a minute later you have a login: prompt or an X login window on the screen. Sometimes, though, the process is of more interest. You have a number of options when booting, and it's also a source of a number of problems, so it pays to understand it. In this chapter we'll look at the following topics:
- • In the next section, we'H look at the startup process in more detail
- • On page 529 we'll look at how to control the boot process.
- • If something goes wrong, and the system doesn't come up, those messages that scrolled off the screen are very important. We'll look at what they mean on page 529.
- • It's not so obvious that you need to adhere to a procedure when shutting down the system. We'll look at the hows and whys on page 541.
- • There are a number of ways of starting the system for particular applications. On page 542 we'll look at how to run FreeBSD without a disk.
Starting the system
When you power up the system, or when you reboot, a number of actions occur before the system is up and running. Starting the system is usually called 'bootstrapping, " after the story of Baron von Munchhausen pulling himself up by his own bootstraps. The following sequence describes the sequence on the PC architecture, but there are only relatively minor differences on other platforms.
- • First, the BIOS^ performs tests that check that the machine is working correctly and determines the hardware configuration. This Power On Self Test or POST has nothing to do with FreeBSD.
- • Next, the BIOS bootstrap loads the Master Boot Record from the first sector of the first disk on the system (C : in BIOS parlance) into memory and executes it. This step is the same for all operating systems on PCs.
- • It's up to this bootstrap to decide which operating system to boot. The bootstrap in the MBR may or may not be part of the FreeBSD system. FreeBSD can install two different MBRs, as we saw on page 66. The standard MBR works without intervention, while the boot manager gives you the choice of booting from any partition on the disk.
- • The FreeBSD bootstrap first loads the second-level bootstrap, BTX, from the next 15 sectors on disk and executes it.
- • The second-level boot locates the third-level bootstrap, called loader, and loads it into memory, loader is an intelligent bootstrap component that allows preloading of multiple kernel components. See the man page loader (8) for more information. By default, loader locates the kernel, the file /boot/kemel/kernel on the root file system, and loads it into memory. You can interrupt the loader at this point, for example to load different or additional files.
- • The kernel performs its own tests to look for hardware it knows about. It's quite verbose about this, and prints messages about both the hardware it finds and the hardware it doesn't find. This operation is called probing. Most kernels are built to recognize a large selection of hardware, so it's normalto have more "not found" messages than "found" messages.
- • After the probe, the kernel starts two processes. The first, process 0, is the swapper and is responsible for emergency clearing of memory when the standard virtual memory algorithms aren't fast enough.
- • Process 1 is called init. As the name suggests, it is responsible for starting up the system and daemons. When coming up in the default multi-user mode, it spawns a shell to execute the shell script /etc/rc.
- • /etc/rc first reads in the description files /etc/defaults/rc.conf, which contains defaults for a number of configuration variables, and /etc/rc.co/, which contains your modifications to the defaults. It then proceeds to perform the steps necessary to bring up the system, first starting virtual disk drivers, mounting swap space and checking the file system integrity if necessary.
- • When /etc/rc exits, init reads the file /etc/ttys and starts processes as determined there. It spends the rest of its life looking after these processes.
Things you can do before booting
You can do a number of things before you boot the system
• The most obvious thing to do is to decide what you're going to boot. The
G. Lehey FreeBSD Operating System
boot loader gives you the chance to load different operating systems or different FreeBSD kernels and modules. We'll look at that below.
• You can also set a number of options for the kernel loader, including specification of hardware and software characteristics. We'll look at that on page 532.
What are you going to boot?
If you have multiple operating systems on your system, you can use the boot manager described on page 64, to choose which one to boot. For example, il you have two disks, the first of which contains four partitions, the first stage of the boot looks something like this:
Fl: FreeBSD
F2: Windows
F3: Linux
F4: FreeBSD
F5: Drive 1
Default: F
After 10 seconds, the boot manager attempts to load the bootstrap from the default partition; you can choose any of the selections by pressing the corresponding function key. If you press F5, you get a menu showing the partitions on the second disk, with F5 to return to the first disk.
If you choose to boot FreeBSD, the bootstrap loaders load, and you see something like:
/ this is a "twirling baton"
BTX loader 1.00 BTX version is 1.01
BIOS drive A: is diskO
BIOS drive C: is diskl
BIOS drive D: is diskl
BIOS 639kB/130048kB available memory
These messages are printed by BTX. If you're loading from disk, the / character at the end of the previous line keeps changing through ,and | before going back to / again, giving the impression that the character is rotating. This display, called a twirling baton, is your indication that the system hasn't crashed and
G. Lehey FreeBSD Operating System
burned. It's normal for it to take a few seconds before the baton starts to twirl
Next, loader prints its prompt:
FreeBSD/i386 bootstrap loader, Revision 0.8
( Этот адрес e-mail защищен от спам-ботов. Чтобы увидеть его, у Вас должен быть включен Java-Script , Thu Jun 13 13:06:03 CST 2002)
Loading /boot/defaults/loader.conf
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [kernel] in 6 seconds... this counts down from 10 second
At this point, you would normally continue with the boot, either by pressing the Enter key or just waiting the 10 seconds. We'll see what happens then on page 533.
Sometimes you may want to change software or hardware characteristics. In this case, you press the "any other key" (by tradition the space bar) and enter commands to the loader.
Loader commands
There are two ways to communicate with the loader:
- • A number of files in the directory /boot on the root file system tell the loader what to do. Most are not intended to be changed, but you can create a file called /boot/loader.conf, into which you can enter commands to override the commands in/boot/defaults/loader.conf. We'll look at this below.
- • In addition, the file /boot/device.hints takes the place of many configuration file entries and allows you to set hardware characteristics such as information about IRQ, DMA, I/O address and other settings for the hardware. You can change these values during booting.
The CD-ROM installation installs /boot/device.hints, but a kernel install does not. You'll find it in the conf directory for your architecture. For example, /usr/src/sys/i386/conf includes the configuration file GENERIC and the corresponding hints file GENERIC.hints. Install it like this:
# cp /usr/src/sys/i386/conf/GENERIC.hints /boot/device.hints
G. Lehey FreeBSD Operating System
The hints file contains entries of the following nature: hint.sio.0.at="isa" hint.sio.0.port="0x3F8" hint, sio. 0. flags="0x10" hint.sio.0.irq="4" hint.sio. l.at= "isa" hint.sio. l.port="0x2F8" hint.sio. 1. irq="3" hint.sio.2.at="isa" hint.sio. 2.d±sabled-T" hint.sio.2.port="0x3E8" hint.sio.2.irq="5" hint.sio.3.at="isa" hint, sio. 3. disabled="1" hint.sio.3.port="0x2E8" hint.sio.3.irq="9"
These entries describe the serial port configuration. They replace the older method of hard coding the information in the kernel For example, the hints above contain the configuration information contained in these lines of the Release 4 configuration file:
|
Device |
sioO |
at isa? |
|
Device |
siol |
at isa? |
|
Device |
sio2 |
at isa? |
|
Device |
sio3 |
at isa? |
port IO_CCM1 flags 0x10 irq 4
port IO_CCM2 irq 3
disable port IC_CCM3 irq 5
disable port IC_CCM4 irq 9
The corresponding line in the Release 5 configuration file is:
Device sio #8250, 16[45]50 based serial ports
More importantly, though, this means that you don't need to recompile the kerne] if you change the hardware addresses.
• You can enter commands directly to the command prompt.
When you hit the space bar, you get the following prompt:
Type ’?’ for a list of commands, 'help' for more detailed help,
G. Lehey FreeBSD Operating System
ok ?
Available commands:
Reboot reboot the system
Heap show heap usage
Bcachestat get disk block cache stats
Boot boot a file or loaded kernel
Autoboot boot automatically after a delay
Help detailed help
? list commands
Show show variable(s)
Set set avariable
Unset unset avariable
More show contents of a file
Lsdev list all devices
Include read commands from a file
Ls list files
Load load akemel or module
Unload unload all modules
Lsmod list loaded modules
Pnpscan scan for PnP devices
The most important of these commands are set, show, load, unload and boot. We'll see some examples of their use in the following sections. Note, however, that if you have accidentally hit the "any" key during boot and just want to continue with the boot, you just have to enter boot.
loader.conf
Much of the behaviour of the loader is controlled by entries in /boot/defaults/loader.conf. You shouldn't change this file, though: put changes in a file /boot/loader.conf, which may not exist. There are a large number of possible entries; in /boot/defaults/loader.conf you'll see the default values, frequently commented out because the loader already knows the defaults. Here are some of the more interesting ones:
kernel= "kernel"
verbose_loading="NO" # Set to YES for verbose loader output
#autoboot delay="10" # Delay in seconds before autobooting
G. Lehey FreeBSD Operating System
#console-ddconsole" # Set the current console
#currdev="disklsla" # Set the current device
module_path="/boot/kernel;/boot/modules;/modules" #Set the module search pa #prompt='${interpret}" # Set the command prompt
#root_disk_unit="0" # Force the root disk unit number
#rootdev="disklsla" # Set the root filesystem
- • The kernel entry gives the name of the kernel, relative to the kerne] directory /boot/kerneL Sometimes it might be of interest to change this value, for example when testing.
- • console=vidconsole tells the loader where to output its messages, vidconsole is short for video console; you can also select comconsole if you have a serial terminal connected to a specified serial port.
- • currdev specifies where to look for the root file system. If you have multiple BIOS partitions on a disk, you can select the correct one with this value.
There are many more options to the loader; read the man page for more details.
Loading other modules at boot time
By default, loader loads only the kernel That may not be what you want. You might want to load a different kernel, or you may want to load a kid as well
There are two ways to do this. If you only want to do this once, you can interrupt the boot sequence by pressing the space bar, and tell loader what to do:
Booting [kernel] in 6 seconds... this counts down from 10 seconds
(space bar hit)
Type '?' for a list of commands, 'help' for more detailed help.
ok unload not the kernel we wanted
OK load /boot/kerneLold/kemel load the old kernel
/boot/kernelold/kernel text=0x3e474c data=0x52ffl0+0x81904 syms=[0x4+0x< b458]
OK load /boot/kerneLold/vinum.ко and the old vinum module
/boot/kemeLold/vinumko text=0xl49a4 data=0xaf75c+0xl64 syms=[0x4+0xF
G. Lehey FreeBSD Operating System
ok boot then start the kernel
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved.
FreeBSD 5.0-RELEASE #0: Sat 15 Feb 16:30:26 CST 2003
Этот адрес e-mail защищен от спам-ботов. Чтобы увидеть его, у Вас должен быть включен Java-Script /src/sys/i386/compile/BUMBLE
Preloaded elf kernel "/boot/kemelold/kemel" at 0xc072a000.
Preloaded elf module "/boot/kemelold/vinumko" at 0xc072a0bc.
Timecounter "i8254" frequency 1193182 Hz
(etc)
This example shows two separate activities: one is changing the kernel from /boot/kemel/kemel to /boot/kernelold/kernel, and the other is loading the vinum kid. You don't need to reload the kernel to load the vinum module.
Automatic kid load
The method described above is cumbersome if you want to load the kid every time you boot. In this case, it's easier to add the following line to /boot/loader. conf:
vinum_load='YES"
To see what commands you can use, look in /boot/defauks/loader.conf, where you would find all normal configuration entries commented out.
ccd_load="NO" # Concatenated disk driver vinum_load="NO" # Concatenated/mirror/raid driver md_load="NO" # Memory disk driver (vnode/swap/malloc)
Don't change this file; it's designed to be replaced on upgrade, and any changes would get lost when you upgrade.
Running the kernel
The next step in the boot process is to run the kernel This is what happens by
G. Lehey FreeBSD Operating System
default if you do nothing at the Booting [kernel] prompt, or if you press Enter. If you have interrupted the boot process, you continue with the command:
ok boot
The following example shows the output of booting an Abit BP6 dual processor motherboard. This board also has four IDE controllers on board, and the system had two SCSI host adapters connected to it.
The loader transfers control to the kernel it has preloaded. Messages from the kernel are in high-in tensity text (brighter than normal). This is the most common time to see them, though they sometimes appear during normal machine operation. These messages also get copied to the kernel message buffer, and you can retrieve the most recent messages with the dmesg program. In the course oi time, other messages may fill the buffer, and you will no longer be able to find the boot messages with dmesg, so one of the final steps in the startup saves the content of the boot messages in the file /var/run/dmesg.boot, which should always contain the complete startup messages. In the case of laptops, the message buffer normally does not get cleared on shutdown, not even if the power goes down, so you may find logs for multiple boots.
Once it has finished loading, the kernel prints some summary information and then calls aH configured drivers to examine the hardware configuration of the machine on which it is running. This is caUed probing for the devices. If you have time, it's a good idea to confirm that it's correct. Much of it appears so quickly that you can't read it, but once the boot is complete, you can examine it with the dmesg command. If something goes wrong, it won't scroH off the screen. The place where it stops is then of interest.
Under normal circumstances, we see something like:
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved.
FreeBSD 5.0-RELEASE #0: Sat 15 Feb 16:30:26 CST 2003
Этот адрес e-mail защищен от спам-ботов. Чтобы увидеть его, у Вас должен быть включен Java-Script /src/sys/i386/compne/BlMBLE
Preloaded elf kernel "/boot/kemel/kemel" at 0xc0663000.
Here the kernel identifies itself with information about the release number, when and where it was buflt, and where it was loaded from.
G. Lehey FreeBSD Operating System
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (467.73-MHz 686-class CPU)
Origin = "Genuinelntel" Id = 0x665 Stepping = 5
Features=0xl83fbff avail memory = 123465728 (117 MB) The lines above identify the basic hardware. There is one time counter (some motherboards have two), the CPU is a Celeron, Pentium II or Xeon, and it runs at 466 MHz. This information is relatively reliable. The real memory value is the size of RAM. Some older systems reserve 1 кВ of RAM in real mode, but this should not have any effect on the value of real memory. Available memory is the memory available to users after the kernel has been loaded and initialized. On some older machines, the kernel reports only 16 MB although the system has more memory. This is due to BIOS incompatibilities, and occurs surprisingly often on big-name machines. To fodt, build a custom kernel that specifies the memory size explicitly—see the description of the MAXMEM parameter, which is described in the verbose configuration file Zusr/src/sys/i386/conf/NOTES. This machine is in fact a multiprocessor with two CPUs, so we see: Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -< irq 0 IOAPIC #0 intpin 16 -< irq 10 IOAPIC #0 intpin 17 -< irq 9 IOAPIC #0 intpin 18 -< irq 11 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpuO (BSP): apic id: 0, version: 0x00040011, at OxfeeOOOOO cpul (AP): apic id: 1, version: 0x00040011, at OxfeeOOOOO ioO (APIC): apic id: 2, version: 0x00170011, at OxfeeOOOOO The IOAPIC is the I/O Advanced Programmable Interrupt Controller used by SMP machines only. It reassigns some interrupt requests. This information is provided in case you need to debug the kernel. None of this appears for a normal machine. Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npxO: G. Lehey FreeBSD Operating System npxO: INT 16 interfac The GEOMetiy subsystem is a disk I/O system that was introduced in FreeBSD Release 5. This processor is a P6 class processor, so it has Memory Type Range Registers or MTRRs, which are used to optimize memory usage. Next we look at the other chips on the motherboard, starting with the so-called "chipset," the processor support chips. pcibO: agpO: pcibl: pcil: This motherboard has an Intel 82443 BX chipset with two PCI buses. Next we see some of the devices on the motherboard: pcil: isabO: isaO: atapciO: atal: at 0x170 irq 15 on atapciO secondary IDE controller uhciO: 7.2 on pciO USB controller usbO: usbO: USB revision 1.0 uhubO: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhubO: 2 ports with 2 removable, self powered Trmecounter 'PIIX" frequency 3579545 Hz pciO: The system doesn't know which devices are implemented internally in the chipset, which are separate chips on the mother board, and which are on plug-in boards. So far it has found the IDE controllers, but not the disks; it'll look for them later. Next we find two Symbios SCSI host adapters: G. Lehey FreeBSD Operating System symO: <875> port 0xc400-0xc4ff mem 0xec002000-0xec002fff, 0xec003000-( Oatdevice 9.0 on pciO symO: Symbios NVRAM, ID 7, Fast-20, SE, NO parity symO: open drain IRQ line driver, using on-chip SRAM symO: using LOAD/STORE-based firmware. symO: SCAN FOR LUNS disabled for targets 0. syml: <875> port 0xc800-0xc8ffmem0xec001000-0xec001fff, 0xec000000-C at device 13.0 on pciO syml: No NVRAM, ID 7, Fast-20, SE, parity checking The first Symbios adapter is on IRQ 10. It is on ID 7, like most SCSI host adapters, and it doesn't support parity. The second board is on IRQ 9 and does support parity, but it doesn't have a BIOS. This is not a problem for FreeBSD, which doesn't use the BIOS, but if it were in the system by itself, the POST would not find it. In this case, the BIOS on the other Symbios board does in fact find the second host adapter. dcO: on pciO dcO: Ethernet address: 00:80:c6:f9:a6:c8 miibusO: dcphyO: dcphyO: lObaseT, lObaseT-FDX, lOObaseTX, lOObaseTX-FDX, auto This is a Macronix Ethernet card with associated PHY interface at IRQ 11. After that, we return to on-board peripherals, in this case two additional IDE controllers and legacy ISA peripherals: atapcil: ata2: at OxdOOO on atapcil Third IDE controller atapci2: ata3: at OxdcOO on atapci2 ormO: fdcO: cmd 3 failed at out byte 1 of 3 The floppy driver command failure here is caused by the lack of any floppy drive G. Lehey FreeBSD Operating System on this machine. atkbdcO: ^Keyboard controller (i8042)> at port 0x60,0x64 on isaO atkbdO: kbdO at atkbdO vgaO: sioO at port 0x3fB-0x3ff irq 4 flags 0x10 on isaO first serial port sioO: type 16550A it's a buffered UART siol at port 0x2f8-0x2ff irq 3 on isaO second serial port siol: type 16550A sio2 not found at 0x3e8 no moreserial I/O ports sio3 not found at 0x2e8 UNIX starts counting device numbers from 0, whereas Microsoft starts counting from 1. Devices /dev/sioO through /dev/sio3 are known as COMI: through COM4: in the Microsoft world. ppcO: plipO: IptO: IptO: Interrupt-driven port ppiO: Next, on this multiprocessor board, we get some SMP-specific messages. The system tests the IO-APIC, which can sometimes cause problems, and then starts the second processor: APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 SMP: AP CPU #1 Launched! Finally, the system detects the disks connected to this machine: adO: 19574MB (noperiph: sym0:0:-l:-l): SCSI BUS reset delivered. G. Lehey FreeBSD Operating System daO at syml bus 0 target 3 lun 0 daO: daO: 4095MB (8386733 512 byte sectors: 255H 63S/T 522C) dal at syml bus 0 target 0 lun 0 dal: Here, we have four disks, one each on the first and third IDE controllers, both as master, and two on the second SCSI host adapter. There is nothing on the first host adapter. Finally, the system starts Vinum and mounts the root file system and the swap partition: Mounting root from ufs: /dev/adOsla vinum: loaded vinum: reading configuration from /dev/adOslh vinum: updating configuration from /dev/ad4s2h swapon: adding/dev/adOslb as swap device swapon: /dev/vinum/swap: No such file or directory Automatic reboot in progress... At this point, the system is up and running, but it still needs to start some services. The remaining messages come from processes, not from the kernel, so they are in normal intensity. add net default: gateway 223.147.37.5 Additional routing options: tcp extensions=NO TCP keepalive=YES. routing daemons:. Mounting NFS file systems. additional daemons: syslogd Doing additional network setup: portmap. Starting final network daemons: rwhod. setting ELF Idconfig path: /usr/lib /usr/Kb/compat /usr/XllR6/lib /usr/local/lib setting a.out Idconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/XllR6/lib/aout starting standard daemons: inetd cron Initial rc.i386 initialization:. rc.i386 configuring syscons: blank time. G. Lehey FreeBSD Operating System Local package initialization:. Additional TCP options:. Tue Apr 23 13:59:05 CST 2000 At this point, the kernel has finished probing, and it transfers control to the shell script /etc/rc. From this point on the display is in normal intensity, /etc/rc first reads the configuration information in /etc/defaults/rc.conf and /etc/rc.conf (see page 552). Next, it checks the consistency of the file systems. Normally you'll see messages like this for each file system in /etc/fstab: /dev/daOsla: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/daOsla: clean, 6311 free (367 frags, 743 blocks, 0.9% fragmentation) /dev/daOsle: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/daOsle: clean, 1577 files, 31178 used, 7813 free (629 frags, 898 blocks, 1. Augmentation) If your system has crashed, however, either due to a software or hardware problem, or because it was not shut down correctly, it will perform a file system check (fsck), which can take quite a while, up to an hour on very big file systems. You'll see something like: WARNING: / was not properly dismounted /dev/daOsla: 6311 free (367 frags, 743 blocks, 0.9% fragmentation On a large file system, feck can take a long time to complete, up to several hours in extreme cases. By default, the system does not need to wait for it to terminate; the fsck continues in the background. This is a relatively new feature in FreeBSD, so you can turn it off in case you have problems with it. See page 554 for more details. Next, /etc/rc invokes the first of three network start invocations. This one initializes the interfaces, sets the routes and starts the firewall if necessaiy: Doing initial network setup: hostname. dcO: flags=8843 ether 00:80:c6:f9:a6:c8 media: autoselect (lOObaseTX supported media: autoselect lOObaseTX G. Lehey FreeBSD Operating System loO: flags=8049 inet 127.0.0.1 netmask OxflDOOOOO add net default: gateway 223.147.37.5 Additional routing options:. routing daemons:. In this example, there were no additional routing options and no routing daemons. The messages accordingly have nothing between the character: and the final period. You'll see this relatively frequendy. Next, /etc/rc mounts the network file systems, cleans up /var/run and then starts syslogd: Mounting NFS file systems. Additional daemons: syslog Then it checks if we have a core dump. If so, it tries to save it to /var/crash. checking for core dump...savecore: no core dum Saving the core dump may fail if there isn't enough space in /var/crash. If this happens, you can clean up and save the dump later, as long as you haven't used enough swap space to overwrite the dump. Next comes the second pass of the network startup, which starts our choice of named, ntpdate, ntpd, timed, portmap, ypserv, rpc.ypxfrd, rpc.yppasswdd, ypbind, ypset, keyserv and rpc.ypupdated: Doing additional network setup: named xntpd portmap. starting, named 8.1.2 Sun May 9 13:04:13 CST 1999
Этот адрес e-mail защищен от спам-ботов. Чтобы увидеть его, у Вас должен быть включен Java-Script
/obj/usr. sbin/named master zone "example.org" (IN) loaded (serial 1997010902) master zone "37.147.223.in-addr.arpa" (in) loaded (serial 1996110801) listening on [223.147.37.149].53 (epO) listening on [127.0.0.1].53 (loO) Forwarding source address is [0.0.0.0]. 1063 Ready to answer queries. With the exception of the first line, all the messages come from named. They may G. Lehey FreeBSD Operating System come in the middle of the first line, rather than waiting for the end of the line. Next, /etc/rc enables quotas if asked, and then runs the third network pass, which starts our choice of mountd, nfsd, rpc.lockd, rpc.statd, nfsiod, amd, rwhod and kerberos: Starting final network daemons: mountd nfcd rpc.statd nfsiod rwhod Now we're almost done, /etc/rc rebuilds a couple of internal databases (for use by the ps command and some others), then it sets the default paths for Idconfig: setting ELF Idconfig path: /usr/lib /usr/lib/compat /usr/XHR6/lib /usr/local/lib setting a.out Idconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/XHR6/]ib/aout /usr/local/lib/aout Next, it starts your choice of inetd, cron, printer, sendmatt and usbd: starting standard daemons: inetd cron sendmail The last thing that /etc/rc does is to check for other startup files. These could be in the files specified in the variable local_startup, or in the file /etc/rc.locaL In our case, there are none, so all we see is: Local package initialization:. Finally, we're done, /etc/rc stops, and init processes /etc/ttys, which starts getty processes on specified terminals. On the console, we see: Mon May 13 13:52:00 CST 2002 FreeBSD (freebie.example.org) (ttyvO) Login: At this point, we're at the beginning of Chapter 7 (page 111). Single-user mode Sometimes it's inconvenient that multiple users can access the system. For example, if you're repartitioning a disk, you don't want other people walking all over the disk while you're doing so. Even if you're the only user on the system, G. Lehey FreeBSD Operating System daemons may be doing things in the background. To avoid this problem, you can stop the boot process before most of the daemons have been started and enter single-user mode. To do this, set the boot_single variable, or specify the - s fag at boot time: ok boot -s As soon as the device probes have been completed, the system startup is interrupted, and you are prompted for a shell Only the root file system is accessible, and it is mounted read-only. The reason for this is that the file system may be damaged and require repair before you can write to it. If you do need to write to the root file system, you should first check the consistency of the file system with feck, after which you can mount it with the -u (update) option. For example, npxO on motherboard npxO: INT 16 interface end of the probes (high intensity display) Enter pathname of sheH or RETURN for sh: hit Enter erase ЛН, kill AU, intr ЛС # feck -y /dev/adOsla check the integrity of the root file system mount /usr mount any other file systems you need To leave single-user mode and enter multi-user mode, just enter Ctrl-D: #AD Skipping file system checks... (the rest of the boot sequenc) System V and Linux have the concept of run levels, which are controlled by init. Single-user mode corresponds to run level 1 or S, and multi-user mode G. Lehey FreeBSD Operating System corresponds roughly to System V run level 3 or Linux run level 4. Nothing corresponds with the other System V run levels, in particular run level 2, which starts a System V system without networking. Networking is such an integral part of FreeBSD that this is just not practicable. FreeBSD init now understands a syntax similar to the System V init. Table 29-1 shows the supported levels. For example, to read in the /etc/ttys file, you could enter: # init q Таблица 29.1. init levels Level Signal Action 0 SIGUSR2 Halt and turn the power off 1 SIGTERM Go to single-user mode 6 SIGINT Reboot the machine C SIGTSTP Block further logins q SIGHUP Rescan the ttys(5) file You can also enter single-user mode from a running FreeBSD system with the shutdown command, which we'll look at in the next section. Password protecting single-user mode If you run a secure environment, you could be concerned about the fact that you can start up in single-user mode without entering a password. That's the default— normally, if somebody can access your system console, a password is no longer much use, and it can be a nuisance—but you can change it. Find this entry in /etc/ttys, and change the word secure to insecure: #If you want to be asked for password, change "secure" to "insecure" here console none unknown off insecure If you do this, you will be in real trouble if you forget the root password. G. Lehey FreeBSD Operating System Shutting down and rebooting the system FreeBSD uses a number of sophisticated techniques to achieve its high performance. In particular, when you write data to a disk, the system doesn't put it on the disk immediately: it waits for more data to arrive, which reduces the number of disk accesses by up to several orders of magnitude and thus improves performance dramatically. The result of turning power off before the data is written is equally dramatic. You may just lose the data, but if the data is information on a change in file system structure, your file system will be damaged. To check for this, the system runs a program called feck (File System Check) at startup, feck can repair minor damage, but it's obviously a better idea to avoid damage by ensuring that the system is shut down in an orderly way. Never stop your machine by just turning off the power. The results could be devastating. The correct way to shut a system down is with the shutdown command. To quote the man page shutdown(8): Shutdown provides an automated shutdown procedure for super-users to nicely notify users when the system is shutting down, saving them from system administrators, hackers, and gurus, who would otherwise not bother with such niceties. This command has a number of useful options: In the normal case, where you want to stop the machine immediately so you can G. Lehey FreeBSD Operating System turn the power off, you type: # shutdown - h now Feb 4 12:38:36 freebie shutdown: halt by grog: Feb 4 12:38:39 freebie syslogd: exiting on signal 15 syncing disks...done The operating system has halted. Please press any key to reboot Be sure to wait for this message before you turn off the power. FreeBSD without disks Disks are getting much cheaper and their capacity is continually increasing, so it's easy to think that there would never be a reason to want to run FreeBSD without a disk at all Still, there are reasons: There are a number of ways to run a system without a disk. You can replace the disk with something else, such as a flash card, floppy disk or CD-ROM drive, or you can access a remote disk via a network. We'll consider network booting in the following section, and we']l look at the disk replacement strategy on page 549. Network booting Network booting is not a new idea. It was the original reason for Sun's Network File System, which we looked at in Chapters 24 and 25. Nowadays people G. Lehey FreeBSD Operating System normally use NFS for additional shared file systems; in the case of net booting, you mount your own private NFS file system as your root file system. Clearly, the first thing you need to do is to create this file system. Next, you need to find a way to boot the system. There are a few possibilities here: Whichever method you use, you need to set up a network interface very early. In Chapter 17 we saw that the network setup is part of the system initialization, and that the configuration is stored in /etc/rc.conf. For a network boot, the network must be running before the kernel can be loaded, so that method won't work here. Instead, we use DHCP, which we looked at on page 302. We could also use the bootpd daemon, but it's more limited, so it's better to use DHCP. If you use floppy or CD-ROM, you could theoretically load the bootstrap from that device. This isn't the same as the alternative we'll see on page 549, where we load the kernel from floppy or CD: here we only load the bootstrap and then load the kernel from the network. This minor difference has significant implications on the ease of system administration. The next step is to actually transfer the data. We do this with TFTP, the Trivial File Transfer Protocol As the name suggests, TFTP is a relatively simple replacement for FTP. In particular, it knows almost nothing about security. If you use TFTP, make sure that it can't be accessed from outside your network, for example by using a firewall The default firewall rules block TFTP. In the following sections we'll look at the example of setting up bumble.example.org as a diskless machine. Setting up the file system G. Lehey FreeBSD Operating System There are a number of ways to put the files on the NFS server: We'll look at refining this technique after the system is up and running. Building a diskless kernel You still need to build a special kernel for diskless workstations. The following entries in the configuration file are relevant: #Kemel BOOTP support Options BOOTP #Use BOOTP to obtain IP address/hostname Options BOOTP_NFSROOT #NFS mount root filesystem using BOOTP Options BOOTP_NFSV3 #Use NFS v3 to NFS mount root Options BOOTP_COMPAT #Workaround for broken bootp daemons. Options BOOTP_WIRED_TO=fepO #Use interface fxpO for BOOT Only the first two are required. If you use BOOTP_WIRED_TO, make sure that the interface name matches the network card you are using. Build the kernel, as described on page 617. To install, you need to set the DE S T DIR variable to specify the directory in which you want to install the kernel: # make install DESTDlR=/src/nodisk/bumbl Configuring lb IP Next we need to set up TFTP to deliver the kernel to the system The first G. Lehey FreeBSD Operating System question is whether the firmware on the Ethernet card can load the kernel directly or not. Some boot PROMs run in 16 bit 8086 mode, which limits their addressing capability to 640 кВ. That's too small for any FreeBSD kernel, and if you try to load the kernel directly you'll get a message like this: File transfer error: Image file too large for low memory. In this case, you'll need to load a loader, such aspxeboot. As a minor concession to security, the tftpd daemon refuses to access files outside its data directory hierarchy, which by convention is called /tftpboot. You can use symbolic links, however. It makes more sense to have the kernel in the same place as on machines with disks, namely in /boot/keme]/kemel on the root file system, so we create symbolic links: # mkdir /tftpboot # In -s /src/nodisk/bumble/boot/keme]/kernel/tftpboot/kerneLbumble # In -s /boot/pxeboot /tftpboot/pxeboo We also need to ensure that we can start the TFTP daemon, ftpd. Unless you're constantly booting, there's no need to have it running constantly: just enable it in /etc/inetd.conf, which has the following entries in the distribution file: #tftp dgram udp wait root /usr/libexec/tftpd tftpd -s /tftpboot #tftp dgram udp6 wait root /usr/libexec/tftpd tftpd -s /tftpboot These are entries for IPv4 and IPv6 respectively. We enable tftpd by uncommenting the first line (removing the # character) and sending a HUP signal to inetd: # kfflall -1 inetd send a SIGHUP Configuring DHCP We already looked at dhcpd's configuration file /usr/loca]/etc/dhcpd.conf on page 302, In addition to the information we looked at there, we need to know what file to load, which system to load it from, and where the root file system is located. For our diskless system bumble we might add the text in bold to the configuration we saw on page 303: G. Lehey FreeBSD Operating System subnet 223.147.37.0 netmask 255.255.255.0 range 223.147.37.90 223.147.37.110; option domain-name-servers freebie.example.com, presto.example.com; option domain-name "example.com"; option routers gw.example.com; option subnet-mask 255.255.255.0; option broadcast-address 223.147.37.255; default-lease-time 86400; max-lease-time 259200; host Sydney { hardware ethernet 0:50:da:cf:7:35; } host bumble { hardware ethernet 0:50:da:cf:17:d3; next-server presto.example.com; only if on a different machine filename "/tfipboot/bumble/kemelbumble"; for direct booting filename "/tftpboot/pxeboot"; for PXE option root-path 223.147.37. lysrc/nodisk/bumble; } } There are a few things to note here: Other Ethernet bootstraps If your Ethernet card doesn't have a boot ROM, you can make one with the net/etherboot port, or you can copy the necessary information to a floppy disk or CD-R and use that to start the bootstrap. In either case, you first build the port and then copy the data to your selected medium For example, to create a boot disk for a CompexRL2000 card, a 10 Mb/s PCI NE-2000 clone, you first look up the card in /usr/ports/net/ether-boot/work/etherboot-5.0.5/src/NIC,where you read: #Compex RL2000 compexrl2000 ns8390 0xllf6,0x1401 This information is mainly for the build process; you just need to know the compexr!2000, which is the name of the driver. # cd /usr/ports/net/etherboot # make all # cd work/ether*/src # cat bin/bootla.bin bin32/compexrl2000.1zrom > /dev/fdO bin/bootia.bin is a disk bootstrap intended to load and start compexrl2000.lzrom.You can also put compexr!2000.1zrom in an EPROM. This requires a little more care, and the information is subject to change. You can find detailed information about how to proceed at the web site http У/etherboot. sourceforge. net/doc/html/documentation.htmL etherboot uses NFS, not TFTP. As a result, things change: you can use absolute path names and you can't use symbolic links. An entry in dhcpd.conf for this method might look like this: host bumble { hardware ethemet 00:80:48:e6:a0:61; filename "/src/nodisk/bumble/boot/keme]/kernel"; fixed-address bumble.example.org; option root-path "192.109.197.82ysrc/nodisk/bumble"; } When booting in this manner, you don't see any boot messages. The boot loader outputs several screens full of periods, each indicating a downloaded block. It finishes like this: .........................done G. Lehey FreeBSD Operating System After that, nothing appears on the screen for quite some time. In fact, the boot is proceeding normally, and the next thing you see is a login prompt. Configuring the machine Setting up a diskless machine is not too difficult, but there are some gotchas: • Currently, locking across NFS does not work properly. As a result, you may see messages like this Dec 11 14:18:50 bumble sm-mta[141]: NOQUEUE: SYSERR(root): cannot flock(/var/run/ sendmailpid, fd=6, type=2, omode=40001, euid=0 Operation not supported One solution to this problem is to mount /var as an MD (memoiy) file system This is what currently happens by default, though it's subject to change: at startup, when the system detects that it is running diskless (via the sysctl vfc.nfc.disk-less_valid), it invokes the configuration file Zetc/rc.disklessl.This file in turn causes the file /etc/rc.diskless2 to be invoked later in the startup procedure. Each of these files adds an MD file system In the course of time, this will be phased out and replaced by the traditional configuration via /etc/fctab, but at the moment this file has no provision for creating MD file systems. You should probably look at these files carefully: they may need some tailoring to your requirements.: • It is currently not possible to add swap on an NFS file system swapon (usually invoked from the startup scripts) reports, incorrecdy: Dec 11 14:18:46 bumble savecore: 192.109.197.82:/src/nodisk/swap/bui] This, too, will change; in the meantime, it is possible to mount swap on files, even if they are NFS mounted, but not on the NFS file system itself. This means that the first of the following entries in /etc/fstab will not work, but the second will: 192.109.197.82ysrc/nodisk/swap/bumble none swap sw 0 0 /src/nodisk/swap/bumble none swap sw 0 0 echunga^src /src nfc rw 0 The reason here is the third line: /src/nodisk/swap/bumble is NFS mounted, so this is a swap-to-file situation. For this to work, you may have to add the following line at the end of your /etc/rc.diskless2: swapon -a This is because the standard system startup mounts swap before mounting additional NFS file systems. If you place the swap file on the root file system, it will still work, but frequently you will want the root file system to be read-only to be able to share it between several machines. • If the machine panics, it's not possible to take a dump, because you have no disk. The only alternative would be a kernel debugger. Sharing system files between multiple machines In many cases, you may have a number of machines that you want to run diskless. If you have enough disk (one image for each machine), you don't have anything to worry about, but often it may be attractive to share the system files between them. There are a lot of things to consider here: о Installing ports, for example, will install ports for all systems. That's not necessarily a bad thing, but if you have two systems both installing software in the same directory, you can expect conflicts. It's better to designate one system, possibly the host with the disk, to perform these functions. о If you share /boot and make some configuration changes, the options will apply to all systems. о When building system software, you can use the same /usr/src and /usr/obj directories as long as all systems maintain the same release G. Lehey FreeBSD Operating System of FreeBSD. You can even have different kernels: each kernel build directory carries the name of the configuration file, which by convention matches the name of the system The big problem is /etc. In particular, /etc/rc.conf contains information like the system name. One way to handle this is to have a separate /etc directory for each system This may seem reasonable, because /etc is only about 1.5 MB in size. In fact, this inplies mounting the entire root file system with the other top-leve] directories, and that means more like 60MB. Disk substitute The other alternative to network booting is to find a local substitute for the disk. This is obviously the only alternative for a stand-alone machine. There are a number of alternatives: Flash memory is intended mainly for reading. It is much slower to write than to read, and it can only take a certain number of write cycles before it fails. Clearly G. Lehey it's a candidate for read-only file systems. More accurately the system firmware. The firmware is called BIOS (Basic Input/Output System ) on the i386 architecture, SRM on the Alpha architecture, and Open Firmware on a number of other architectures 21 See httpy/www.freebsd.org/doc/en_US.ISO8859- 1/articles/pxe/index.html for documentation for setting up pxeboot on FreeBSD G. Lehey FreeBSD Operating System