≪
≫

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: on motherboard numeric coprocessor, on chip

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: at pcibus 0 on motherboa pciO: on pcibO

agpO: mem 0xe0000000-0xe3ff eO.O on pciO

pcibl: at device 1.0 on pciO

pcil: on pcibl

This motherboard has an Intel 82443 BX chipset with two PCI buses. Next we see some of the devices on the motherboard:

pcil:

isabO: at device 7.0 on pciO

isaO: on isabO ISA bus

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: at device 7.3 (no driver attached)

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: port OxeOOO-OxeOff mem 0xe7800000-0xe78000ff irq 11 at device 11.0

on pciO dcO: Ethernet address: 00:80:c6:f9:a6:c8

miibusO: on dcO

dcphyO: on miibusO

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: -0xdc07 irq 11 at device 19.1 on pciO Fourth IDE controller

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: flags 0x1 irq 1 on atkbdcO keyboard

kbdO at atkbdO

vgaO: at port 0x3c0-0x3df iomem OxaOOOO-Oxbffff on isaC scO: at flags 0x100 on isaO system console scO: VGA <16 virtual consoles, flags=0x300>

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: at port 0x378-0x37f irq 7 on isaO parallel port controller ppcO: Generic chipset (NIBBLE-only) in COMPATIBLE mode

plipO: on ppbusO

IptO: on ppbusO line printer on parallel port

IptO: Interrupt-driven port

ppiO: on ppbusO alternate I/O on the same port

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 [39770/16/63] at ataO-master UDMA33 ad4:19574MB [39770/16/63] at ataO-master UDMA66 Waiting 15 seconds for SCSI devices to settle

(noperiph: sym0:0:-l:-l): SCSI BUS reset delivered.

G. Lehey FreeBSD Operating System

daO at syml bus 0 target 3 lun 0 daO: Fixed Direct Access SCSI-2 d daO: 20.000MB/S transfers (10.000MHz, offset 15, 16bit), Tagged Queueing En

daO: 4095MB (8386733 512 byte sectors: 255H 63S/T 522C)

dal at syml bus 0 target 0 lun 0

dal: Fixed Direct Access SCSI-2 d dal: 20.000MB/S transfers (10.000MHz, offset 15, 16bit), Tagged Queueing En dal: 4095MB (8386733 512 byte sectors: 255H 63S/T 522C

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 ) status: active

supported media: autoselect lOObaseTX lOObaseTX lObaseT/1

G. Lehey FreeBSD Operating System

lObaseT/UTP lOObaseTX none

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

  • ** /dev/adOsla
  • ** Last Mounted on/
  • ** Root file system
  • ** Phase 1 - Check Blocks and Sizes
  • ** Phase 2 - Check Pathnames
  • ** Phase 3 - Check Connectivity
  • ** Phase 4 - Check Reference Counts
  • ** Phase 5 - Check Cyl groups
  • 1064 files, 8190 used, 6913 free (61 frags, 1713 blocks, 0.4% fragmentation) mount -u / remount root file system read/write

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:

  • • Use the - r option to reboot the computer. You sometimes need to do this, for example after installing a new kernel
  • • Use the -h option to stop the machine. This isn't the default.
  • • Without an option, shutdown attempts to put the machine in single-user mode. This doesn't always work as well as booting in single-user mode.
  • • shutdown requires a time parameter to tell it when to actually perform the shutdown. This is useful in a multi-user environment, but normally you'll want to shut down immediately, so shutdown understands the keyword now.

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:

  • • Disks are unreliable. For a machine that you want to keep running for a long time, the most likely hardware failure is a disk failure.
  • • Disks are noisy. There are places where you might not want the noise.
  • • Disks are sensitive. You may not want to place them in some environments.
  • • You may find systems administration easier if all the configuration files are in one place.
  • • The "sweet spot" for hard disk prices, the place where you get the most storage for your dollar, is currently around 80 GB, about 10 times what it was five years before. You may not want that much disk space for anyone machine, but for a group, it might make more sense to have a disk for the whole group on one machine.

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:

  • • You can boot a minimal system from floppy disk or CD-ROM and use this to mount the file systems remotely. This is different from running the system from floppy or CD-ROM: in this case, the disk device serves effectively as a bootstrap, and the operating system is located elsewhere.
  • • You can create a boot PROM for your network card and use that to boot.
  • • You can use PXE if your card supports it.

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:

  • • You might copy the files in the root and /usr file systems of the server machine.
  • • You could install FreeBSD on a separate disk and NFS mount it where the remote system can access it. By itself, this doesn't have much of an advantage over having a local disk on the machine, but it's possible to install a number of systems on a single disk and have different machines access the different installations.
  • • You could combine those two methods and copy a freshly installed system to a file system where you need it.

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:

  • • The next-server line tells where the TFTP server is located. If it's the same as the machine running the DHCP server, you don't need this specification.
  • • As we've seen, hardware restrictions may make it impossible to load the kernel directly. In this case you need to load a loader. The only one that FreeBSD currently supplies is pxeboot^. Choose one of the two filename lines.
  • • You have to specify the root path as an IP address, because no name services are available when the root file system is mounted.

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:

  • • Obviously, any changeable data specific to a system can't be shared.
  • • To ensure that things don't change, you should mount shared resources read-only.
  • • Refer to Table 32-lfor an overview of FreeBSD installed directories. O1 these directories, only /etc and /usr/local/etc must be specific for a particular system, though there are some other issues:

о 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:

  • • For really small systems, you can use PicoBSD, a special small version oi FreeBSD that fits on a single floppy disk. It requires a fair amount of memory as RAM disk, and obviously it's very limited.
  • • PicoBSD is good for some special applications. As the FreeBSD kerne] grows, it's becoming more and more difficult to get even the kernel onto a single floppy, let alone any application software. Still, you can find a number of different configurations in the source tree in /usr/src/release/picobsd. Be prepared for some serious configuration work.
  • • Alternatively, you can boot from CD-R or CD-ROM. In this case, you can have up to 700 MB of data, enough for a number of applications. It's possible to run programs direcdy from the CD, but there's little advantage to having files on CD instead of on disk. The most likely application for this alternative is for systems where the reliability of rotating media is insufficient, where the CD is used only for booting, and after that the system runs from RAM disk.
  • • Yet another alternative is Flash memory, often abbreviated simply as Flash, which we looked at in Chapter 8, on page 159. Flash is available in sizes up to several hundred megabytes, and Compact Flash cards look like disks to their interface. They don't fit IDE connectors, but adapters are available.

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

 
Посмотреть оригинал