FreeBSD configuration File
/etc/ttys
/etc/ttys is a file that describes terminals and pseudo-terminals to init. We've looked at it in a number of places: check the index.
Here's an excerpt from the default /etc/ttys:
#This entry needed for asking password when init goes to single-user mode #If you want to be asked for password, change "secure" to "insecure" here console none unknown off secure
The system console. This is not a real terminal: it can be moved from one device to another. By default, it corresponds to /dev/ttyv0 (the next entry).
ttyv0 "/usr/libexec/getty Pc" cons25 on secure
This is the first virtual terminal, the one that you get automatically at boot time. To change to the others, press Alt-Fx, where x is between 1 and 16. This will give you one of the others:
#Virtual terminals ttyv1 "/usr/libexec/getty Pc" cons25 on secure ttyv2 "/usr/libexec/getty Pc" cons25 on secure ttyv3 "/usr/libexec/getty Pc" cons25 on secure (etc) ttyv8 "usr /X11R6/bin/xdm -nodaemon" xterm off secure
Each virtual terminal can support either a login or an X server. The default /etc/ttys enables getty on the first eight virtual terminals and reserves /dev/ttyv8 for X. If you don't enable xdm on this terminal, you start X with startx.
The default kernel supports sixteen virtual terminals, the maximum possible value. The kernel configuration parameter MAXCONS (defined in /usr/src/sys/conf/NOTES) allows you to reduce this number.
#Serial terminals ttyd0 "/usr/libexec/getty std.9600" unknown off secure ttyd1 "/usr/libexec/getty std.9600" unknown off secure ttyd2 "/usr/libexec/getty std.9600" unknown off secure ttyd3 "/usr/libexec/getty std.9600" unknown off secure
These are the serial ports on your machine. It doesn't matter if it contains names that correspond to non-existent hardware, such as /dev/ttyd3, as long as you don't try to enable them.
#Pseudo terminals ttyp0 none network ttyp1 none network
There's a whole list of these. The purpose here is to tell network programs the properties of the terminal: in particular, they're not secure, which means that you're not allowed to log in on them as root.
/boot/device.hints
The file /boot/device.hints contains configuration information that was previously stored in the kernel configuration file, and which could not be changed except by building and running a new kernel. Now it can be set at boot time. For these changes to apply, you may still need to reboot, but you no longer need a new kernel.
The information in /boot/device.hints consists of structured variables. For example, consider a third ISA serial I/O port, called /dev/sio2 in FreeBSD. By default, this port gets IRQ 4, the same as /dev/sio0. This just plain doesn't work, so you will have to find a different IRQ. The hints for this device start with the text hint.sio.2. The default /boot/device.hints contains the following parameters for this device:
hint.sio.2.at="isa" hint.sio.2.disabled="1" hint.sio.2.port="0x3E8" hint.sio.2.irq="5"
In sequence, these "hints" state that the device is connected to the ISA bus, that it is disabled (in other words, the kernel does not probe for it), that its device registers are at address 0x3e8, and that it interrupts at IRQ 5. Modern motherboards configure this device via the BIOS. You may find that on your system it's more appropriate to run at IRQ 11. In this case, in /boot/device.hints, you would remove the "disabled" line and change the irq line:
hint.sio.2.at="isa" hint.sio.2.port="0x3E8" hint.sio.2.irq="11"
In some cases, you can change these flags at run time with the kenv command. For example, to change the flags of the first serial port to 0x90 to run a serial debugger, you might enter:
kenv hint.sio.O.flags 0x0 kenv hint.sio.0.flags=0x90 hint.sio.0.flags="0x90"
Wiring down SCSI devices
Another example is so-called wiring down SCSI and ATA devices. We looked at this issue on page 202. By default, FreeBSD assigns SCSI unit numbers in the order in which it finds the devices on the SCSI bus. If you remove or add a disk drive, the numbers change, and you may have to modify your /etc/fstab file. To avoid this problem, you can wire down your SCSI devices so that a given bus, target, and unit (LUN) always come on line as the same device unit.
The unit assignment begins with the first non-wired down unit for a device type. Units that are not specified are treated as if specified as LUN 0. For example, if you wire a disk as sd3, the first non-wired disk is assigned sd4.
The following example shows configuration file entries for a system with three Adaptec 2940 class host adapters, one of them with two buses. The first has a disk on ID 0 that we want to call /dev/da0, the second has a tape on ID 6 that we want to call /dev/sa0, the first bus of the third adapter has a disk on ID 3 that we want to call /dev/da2, and the second bus of the third adapter has a disk on ID 1 that we want to call /dev/dal.
hint.scbus.0.at="ahc0" scbusO is ahc0 hint.scbus.1.at="ahc1" scbusl is ahcl bus 0 (only one) hint.scbus.1.bus="0" hint.scbus.3.at="ahc2" scbus3 is ahc2 bus 0 hint.scbus.3.bus="0" hint.scbus.2.at="ahc2" scbus2 is ahc2 bus 1 hint.scbus.2.bus="1" hint.da.0.at="scbus0" da0 is on scsbus0, target0,unit 0 hint.da.0.target="0" hint.da.0.unit=" 0" hint.da.1.at=="scbus3=" dal is on scsbus3, target1 hint.da.1.target="1" hint.da.2.at="scbus2" da2 is on scsbus2, target3 hint.da.2.target="3" hint.sa.1.at="scbus1" a1 is on scsbus1, target6 hint.sa.1.target="6"
If there are any other devices connected to the host adapters, they are assigned other names in sequence, starting at /dev/da3 and /dev/sa2.
This arrangement corresponds to the earlier syntax in the kernel configuration file:
controller scbus0 at ahc0 #Single bus device controller scbus1 at ahc1 bus 0 #Single bus device controller scbus3 at ahc2 bus 0 #Twin bus device controller scbus2 at ahc2 bus 1 #Twin bus device disk da0 at scbus0 target 0 unit 0 disk da1 at scbus3 target 1 disk da2 at scbus2 target 3 tape sa1 at scbus1 target 6 device cd0 at scbus?