Starting and stopping the system
Running the kernel
The next step in the boot process is to run the kernel. This is what happens by 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-intensity 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 of 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 all configured drivers to examine the hardware configuration of the machine on which it is running. This is called 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 scroll 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
grog@nonorcMd.example.org:/usr/src/sys/i386/compile/BlMBLE
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0663000.
Here the kernel identifies itself with information about the release number, when and where it was built, and where it was loaded from.
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=0x183fbff <FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, CMOV,P AT,PSE36,MMX,FXSR> real memory =134217728 (128 MB) 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 kB 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 fixit, 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 /usr/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
cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000
cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000
io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000
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: <math processor> on motherboard numeric coprocessor, on chip npx0: INT 16 interfac
The GEOMetry 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.
pcib0: <Intel 82443BX (440 BX) host to PCI bridge> at pcibus 0 on motherboard pci0: <PCI bus> on pcib0 agp0: <Intel 82443BX (440 BX) host to PCI bridge> mem 0xe0000000-0xe3ffffff at devic e0.0 on pci0 pcib1: <PCIBIOS PCI-PCI bridge> at device 1.0 on pci0 pci1: <PCI bus> on pcib1
This motherboard has an Intel 82443 BX chipset with two PCI buses. Next we see some of the devices on the motherboard:
pci1: <Matrox MGA G200 AGP graphics accelerator> at 0.0 isab0: <Intel 82371AB PCI to ISA bridge> at device 7.0 on pci0 isa0: <ISA bus> on isab0 ISA bus atapci0: <Intel PIIX4 ATA33 controller> port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 primary IDE controller ata1: at 0x170 irq 15 on atapci0 secondary IDE controller uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xc000-0xc01f irq 10 at device 7.2 on pci0 USB controller usb0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0 USB bus usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered Timecounter "PIIX" frequency 3579545 Hz pci0: <bridge, PCI-unknown> 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:
sym0: <875> port 0xc400-0xc4ff mem 0xec002000-0xec002fff, 0xec003000-0xec0030ff irq 1 0atdevice 9.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-20, SE, NO parity sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: SCAN FOR LUNS disabled for targets 0. sym1: <875> port 0xc800-0xc8ff mem 0xec001000-0xec001fff, 0xec000000-0xec0000ff irq 9 at device 13.0 on pci0 sym1: 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.
dc0: <Macronix 98715AEC-C 10/100BaseTX> port 0xe000-0xe0ff mem 0xe7800000-0xe78000ff irq 11 at device 11.0 on pci0 dc0: Ethernet address: 00:80:c6:f9:a6:c8 miibus0: <MII bus> on dc0 dcphy0: <Intel 21143 NWAY media interface> on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-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:
atapci1: <HighPoint HPT366 ATA66 controller> port 0xd800-0xd8ff,0xd400-0xd403,0xd000 -0xd007 irq 11 at device 19.0 on pci0 ata2: at 0xd000 on atapci1 Third lDE controller atapci2: <HighPoint HPT366 ATA66 controller> port 0xe400-0xe4ff,0xe000-0xe003,0xdc00 -0xdc07 irq 11 at device 19.1 on pci0 Fourth IDE controller ata3: at 0xdc00 on atapci2 orm0: <Option RCMs> at iomem 0xc0000-0xc7fff,0xc8000-0xc87ff on isa0 fdc0: ready for input in output Floppy controller fdc0: cmd 3 failed at out byte 1 of 3
The floppy driver command failure here is caused by the lack of any floppy drive on this machine.
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0 atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0 keyboard kbd0 at atkbd0 vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: <System console> at flags 0x100 on isa0 system console sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 first serial port sio0: type 16550A it's a buffered UART sio1 at port 0x2f8-0x2ff irq 3 on isa0 second serial port sio1: 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/sio0 through /dev/sio3 are known as COM1: through COM4: in the Microsoft world.
ppc0: <Parallel port>at port 0x378-0x37f irq 7 on isa0 parallel port controller ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: <PLIP network interface> on ppbus0 lpt0: <Printer> on ppbus0 line printer on parallel port lpt0: Interrupt-driven port ppi0: <Parallel I/C> on ppbus0 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:
ad0: 19574MB <WDC WD205BA> [39770/16/63] at ata0-master UDMA33 ad4: 19574MB <WDC WD205BA> [39770/16/63] at ata0-master UDMA66 Waiting 15 seconds for SCSI devices to settle (noperiph: sym0:0:-1:-1): SCSI BUS reset delivered. da0 at sym1 bus 0 target 3 lun 0 da0: <SEAGATE ST15230W SUN4.2G 0738> Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4095MB (8386733 512 byte sectors: 255H 63S/T 522C) da1 at sym1 bus 0 target 0 lun 0 da1: <SEAGATE ST15230W SUN4.2G 0738> Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (10.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 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/ad0s1a vinum: loaded vinum: reading configuration from /dev/ad0s1h vinum: updating configuration from /dev/ad4s2h swapon: adding /dev/ad0s1b 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 ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib setting a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout starting standard daemons: inetd cron Initial rc.i386 initialization:. rc.i386 configuring syscons: blank_time. 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/da0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1a: clean, 6311 free (367 frags, 743 blocks, 0.9% fragmentation) /dev/da0s1e: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1e: clean, 1577 files, 31178 used, 7813 free (629 frags, 898 blocks, 1.6% fr 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/da0s1a: 6311 free (367 frags, 743 blocks, 0.9% fragmentation
On a large file system, fsck 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 necessary:
Doing initial network setup: hostname.
dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 223.147.37.81 netmask 0xffffff00 broadcast 223.147.37.255
inet6 fe80::280:c6ff:fef9:a6c8%dc0 prefixlen 64 scopeid 0x1
ether 00:80:c6:f9:a6:c8
media: autoselect (100baseTX <full-duplex>) status: active
supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP
<full-duplex> 10baseT/UTP 100baseTX <hw-loopback> none
lo0: flags=8049<UP, LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
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 frequently.
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 grog@freebie.example.org:/usr /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 (ep0) listening on [127.0.0.1].53 (lo0) 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 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 nfsd 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 ldconfig:
setting ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib setting a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout /usr/local/lib/aout
Next, it starts your choice of inetd, cron, printer, sendmail 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) (ttyv0) Login:
At this point, we're at the beginning of "Chapter 7" (page 111).