Freebsd handbook make kernel


















On the other hand, it might lead to unexpected kernel build breakage. Run config 8 to generate the kernel source code:. Change into the build directory. A dash means that the permission is turned off. In this example, the permissions are set so the owner can read and write to the file, the group can read the file, and the rest of the world can only read the file.

How does the system control permissions on devices? FreeBSD treats most hardware devices as a file that programs can open, read, and write data to. Directories are also treated as files. They have read, write, and execute permissions. The executable bit for a directory has a slightly different meaning than that of files. When a directory is marked executable, it means it is possible to change into that directory using cd 1.

This also means that it is possible to access the files within that directory, subject to the permissions on the files themselves. In order to perform a directory listing, the read permission must be set on the directory. In order to delete a file that one knows the name of, it is necessary to have write and execute permissions to the directory containing the file. There are more permission bits, but they are primarily used in special circumstances such as setuid binaries and sticky directories.

For more information on file permissions and how to set them, refer to chmod 1. Symbolic permissions use characters instead of octal values to assign permissions to files or directories. Symbolic permissions use the syntax of who action permissions , where the following values are available:. These values are used with chmod 1 , but with letters instead of numbers. For example, the following command would block other users from accessing FILE :.

A comma separated list can be provided when more than one set of changes to a file must be made. For example, the following command removes the group and "world" write permission on FILE , and adds the execute permissions for everyone:.

In addition to file permissions, FreeBSD supports the use of "file flags". These flags add an additional level of security and control over files, but not directories. With file flags, even root can be prevented from removing or altering files.

File flags are modified using chflags 1. For example, to enable the system undeletable flag on the file file1 , issue the following command:. To view the flags of a file, use -lo with ls 1 :.

Several file flags may only be added or removed by the root user. In other cases, the file owner may set its file flags. Refer to chflags 1 and chflags 2 for more information. Other than the permissions already discussed, there are three other specific settings that all administrators should know about. They are the setuid , setgid , and sticky permissions. To understand them, the difference between the real user ID and effective user ID must be noted. As an example, passwd 1 runs with the real user ID when a user changes their password.

However, in order to update the password database, the command runs as the effective ID of the root user. This allows users to change their passwords without seeing a Permission Denied error. The setuid permission may be set by prefixing a permission set with the number four 4 as shown in the following example:.

Note that a s is now part of the permission set designated for the file owner, replacing the executable bit. This allows utilities which need elevated permissions, such as passwd 1. The nosuid mount 8 option will cause such binaries to silently fail without alerting the user. That option is not completely reliable as a nosuid wrapper may be able to circumvent it.

To view this in real time, open two terminals. On one, type passwd as a normal user. While it waits for a new password, check the process table and look at the user information for passwd 1 :. Although passwd 1 is run as a normal user, it is using the effective UID of root. The setgid permission performs the same function as the setuid permission; except that it alters the group settings. When an application or utility executes with this setting, it will be granted the permissions based on the group that owns the file, not the user who started the process.

To set the setgid permission on a file, provide chmod 1 with a leading two 2 :. In the following listing, notice that the s is now in the field designated for the group permission settings:. In these examples, even though the shell script in question is an executable file, it will not run with a different EUID or effective user ID.

This is because shell scripts may not access the setuid 2 system calls. The setuid and setgid permission bits may lower system security, by allowing for elevated permissions. The third special permission, the sticky bit , can strengthen the security of a system.

When the sticky bit is set on a directory, it allows file deletion only by the file owner. To utilize this permission, prefix the permission set with a one 1 :. The sticky bit permission will display as a t at the very end of the permission set:. The FreeBSD directory hierarchy is fundamental to obtaining an overall understanding of the system. This directory is the first one mounted at boot time and it contains the base system necessary to prepare the operating system for multi-user operation.

The root directory also contains mount points for other file systems that are mounted during the transition to multi-user operation. A mount point is a directory where additional file systems can be grafted onto a parent file system usually the root file system.

This is further described in Disk Organization. This file is a table of various file systems and mount points and is read by the system. Details can be found in The fstab File.

A complete description of the file system hierarchy is available in hier 7. The following table provides a brief overview of the most common directories. Default boot configuration files. Refer to loader. Device nodes. Refer to intro 4 for details. Default system configuration files. Refer to rc 8 for details. Configuration files for mail transport agents such as sendmail 8. Scripts that run daily, weekly, and monthly, via cron 8. Refer to periodic 8 for details. Empty directory commonly used by system administrators as a temporary mount point.

Process file system. Statically linked programs for emergency recovery as described in rescue 8. System programs and administration utilities fundamental to both single-user and multi-user environments. Temporary files which are usually not preserved across a system reboot. This can be automated using the tmpmfs-related variables of rc. Local executables and libraries. Also used as the default destination for the FreeBSD ports framework. Multi-purpose log, temporary, transient, and spool files.

This can be automated using the varmfs-related variables in rc. The smallest unit of organization that FreeBSD uses to find files is the filename. Filenames are case-sensitive, which means that readme. TXT are two separate files. FreeBSD does not use the extension of a file to determine whether the file is a program, document, or some other form of data. Files are stored in directories.

A directory may contain no files, or it may contain many hundreds of files. A directory can also contain other directories, allowing a hierarchy of directories within one another in order to organize data.

For example, if the directory foo contains a directory bar which contains the file readme. FreeBSD does not use drive letters, or other drive names in the path. Directories and files are stored in a file system. Each file system contains exactly one directory at the very top level, called the root directory for that file system.

This root directory can contain other directories. Every other file system is mounted under the root file system. No matter how many disks are on the FreeBSD system, every directory appears to be part of the same disk.

Consider three file systems, called A , B , and C. Each file system has one root directory, which contains two other directories, called A1 , A2 and likewise B1 , B2 and C1 , C2. Call A the root file system. If ls 1 is used to view the contents of this directory, it will show two subdirectories, A1 and A2. The directory tree looks like this:. A file system must be mounted on to a directory in another file system.

When mounting file system B on to the directory A1 , the root directory of B replaces A1 , and the directories in B appear accordingly:. They will reappear if B is unmounted from A. File systems can be mounted on top of one another. Continuing the last example, the C file system could be mounted on top of the B1 directory in the B file system, leading to this arrangement:. Or C could be mounted directly on to the A file system, under the A1 directory:. It is entirely possible to have one large root file system, and not need to create any others.

There are some drawbacks to this approach, and one advantage. Different file systems can have different mount options. For example, the root file system can be mounted read-only, making it impossible for users to inadvertently delete or edit a critical file. FreeBSD automatically optimizes the layout of files on a file system, depending on how the file system is being used.

So a file system that contains many small files that are written frequently will have a different optimization to one that contains fewer, larger files. By having one big file system this optimization breaks down.

However, a power loss at a critical point could still damage the structure of the file system. By splitting data over multiple file systems it is more likely that the system will still come up, making it easier to restore from backup as necessary. File systems are a fixed size.

If you create a file system when you install FreeBSD and give it a specific size, you may later discover that you need to make the partition bigger. This is not easily accomplished without backing up, recreating the file system with the new size, and then restoring the backed up data. FreeBSD features the growfs 8 command, which makes it possible to increase the size of file system on the fly, removing this limitation.

File systems are contained in partitions. Each partition is identified by a letter from a through to h. Each partition can contain only one file system, which means that file systems are often described by either their typical mount point in the file system hierarchy, or the letter of the partition they are contained in. FreeBSD also uses disk space for swap space to provide virtual memory.

This allows your computer to behave as though it has much more memory than it actually does. When FreeBSD runs out of memory, it moves some of the data that is not currently being used to the swap space, and moves it back in moving something else out when it needs it. Normally the same size as the enclosing slice. This allows utilities that need to work on the entire slice, such as a bad block scanner, to work on the c partition. A file system would not normally be created on this partition.

Partition d used to have a special meaning associated with it, although that is now gone and d may work as any normal partition. These are then divided into partitions, which contain file systems, and are labeled using letters. Slice numbers follow the device name, prefixed with an s , starting at 1. So "da0 s1 " is the first slice on the first SCSI drive. There can only be four physical slices on a disk, but there can be logical slices inside physical slices of the appropriate type.

These extended slices are numbered starting at 5, so "ada0 s5 " is the first extended slice on the first SATA disk.

These devices are used by file systems that expect to occupy a slice. Slices, "dangerously dedicated" physical drives, and other drives contain partitions , which are represented as letters from a to h. This letter is appended to the device name, so "da0 a " is the a partition on the first da drive, which is "dangerously dedicated". Finally, each disk on the system is identified. A disk name starts with a code that indicates the type of disk, and then a number, indicating which disk it is.

Unlike slices, disk numbering starts at 0. Common codes are listed in Disk Device Names. When referring to a partition, include the disk name, s , the slice number, and then the partition letter.

Conceptual Model of a Disk shows a conceptual model of a disk layout. When installing FreeBSD, configure the disk slices, create partitions within the slice to be used for FreeBSD, create a file system or swap space in each partition, and decide where each file system will be mounted. The first partition a on the first slice s1 on the first SATA disk ada0. The fifth partition e on the second slice s2 on the second SCSI disk da1. This example FreeBSD installation has four data partitions and a swap partition.

The four partitions each hold a file system. Partition letter c refers to the entire slice, and so is not used for ordinary partitions. There are various reasons to house some of these directories on separate file systems. This file contains entries in the following format:. The file system type to pass to mount 8. The default FreeBSD file system is ufs. Either rw for read-write file systems, or ro for read-only file systems, followed by any other options that may be needed.

A common option is noauto for file systems not normally mounted during the boot sequence. Other options are listed in mount 8. Used by dump 8 to determine which file systems require dumping. If the field is missing, a value of zero is assumed. Determines the order in which file systems should be checked.

File systems that should be skipped should have their passno set to zero. The root file system needs to be checked before everything else and should have its passno set to one. The other file systems should be set to values greater than one. If more than one file system has the same passno , fsck 8 will attempt to check file systems in parallel if possible. File systems are mounted using mount 8.

The most basic syntax is as follows:. This command provides many options which are described in mount 8 , The most commonly used options include:. Do everything except for the actual mount system call. This option is useful in conjunction with the -v flag to determine what mount 8 is actually trying to do.

Mount the specified file system type or mount only file systems of the given type, if -a is included. Do not interpret setuid or setgid flags on the file system. This is also a useful security option. To unmount a file system use umount 8. This command takes one parameter which can be a mountpoint, device name, -a or -A. All forms take -f to force unmounting, and -v for verbosity. Be warned that -f is not generally a good idea as it might crash the computer or damage data on the file system.

To unmount all mounted file systems, or just the file system types listed after -t , use -a or -A. Note that -A does not attempt to unmount the root file system. FreeBSD is a multi-tasking operating system.

Each program running at any one time is called a process. Every running command starts at least one new process and there are a number of system processes that are run by FreeBSD.

Similar to files, each process has one owner and group, and the owner and group permissions are used to determine which files and devices the process can open. Most processes also have a parent process that started them. For example, the shell is a process, and any command started in the shell is a process which has the shell as its parent process. The exception is a special process called init 8 which is always the first process to start at boot time and which always has a PID of 1.

Some programs are not designed to be run with continuous user input and disconnect from the terminal at the first opportunity. For example, a web server responds to web requests, rather than user input. Mail servers are another example of this type of application. These types of programs are known as daemons. The term daemon comes from Greek mythology and represents an entity that is neither good nor evil, and which invisibly performs useful tasks.

This is why the BSD mascot is the cheerful-looking daemon with sneakers and a pitchfork. There is a convention to name programs that normally run as daemons with a trailing "d". The Apache web server program is httpd and the line printer spooling daemon is lpd. This is only a naming convention. For example, the main mail daemon for the Sendmail application is sendmail , and not maild. To see the processes running on the system, use ps 1 or top 1. To display a static list of the currently running processes, their PIDs, how much memory they are using, and the command they were started with, use ps 1.

To display all the running processes and update the display every few seconds in order to interactively see what the computer is doing, use top 1. By default, ps 1 only shows the commands that are running and owned by the user. For example:. The output from ps 1 is organized into a number of columns. PIDs are assigned starting at 1, go up to , then wrap around back to the beginning. However, a PID is not reassigned if it is already in use. This is usually not the elapsed time since the program was started, as most programs spend a lot of time waiting for things to happen before they need to spend time on the CPU.

A number of different options are available to change the information that is displayed. One of the most useful sets is auxww , where a displays information about all the running processes of all users, u displays the username and memory usage of the process' owner, x displays information about daemon processes, and ww causes ps 1 to display the full command line for each process, rather than truncating it once it gets too long to fit on the screen.

The output from top 1 is similar:. The output is split into two sections. The header the first five or six lines shows the PID of the last process to run, the system load averages which are a measure of how busy the system is , the system uptime time since the last reboot and the current time. The other figures in the header relate to how many processes are running, how much memory and swap space has been used, and how much time the system is spending in different CPU states.

If the ZFS file system module has been loaded, an ARC line indicates how much data was read from the memory cache instead of from disk. Below the header is a series of columns containing similar information to the output from ps 1 , such as the PID, username, amount of CPU time, and the command that started the process.

By default, top 1 also displays the amount of memory space taken by the process. This is split into two columns: one for total size and one for resident size.

Total size is how much memory the application has needed and the resident size is how much it is actually using now. A different interval can be specified with -s. One way to communicate with any running process or daemon is to send a signal using kill 1.

The operating system can also send a signal to a process. If an application has been written to use the alarm 3 system call to be alerted after a period of time has elapsed, it will be sent the "Alarm" signal SIGALRM.

SIGTERM is the polite way to kill a process as the process can read the signal, close any log files it may have open, and attempt to finish what it is doing before shutting down. Since these are general purpose signals, different applications will respond differently.

Restarting httpd would result in a brief outage period on the web server. Be aware that different daemons will have different behavior, so refer to the documentation for the daemon to determine if SIGHUP will achieve the desired results. This example shows how to send a signal to inetd 8. Find the PID of the process to send the signal to using pgrep 1. In this example, the PID for inetd 8 is Use kill 1 to send the signal.

As inetd 8 is owned by root , use su 1 to become root first. If a signal is sent to a process not owned by that user, the message kill: PID : Operation not permitted will be displayed. Mistyping the PID will either send the signal to the wrong process, which could have negative results, or will send the signal to a PID that is not currently in use, resulting in the error kill: PID : No such process.

Be aware that different shells have a different syntax for specifying the name of the signal to send. Killing a random process on the system is a bad idea. In particular, init 8 , PID 1, is special. Always double check the arguments to kill 1 before pressing Return. A shell provides a command line interface for interacting with the operating system.

A shell receives commands from the input channel and executes them. Many shells provide built in functions to help with everyday tasks such as file management, file globbing, command line editing, command macros, and environment variables. The shell that is used is really a matter of taste. A C programmer might feel more comfortable with a C-like shell such as tcsh 1. One common shell feature is filename completion. After a user types the first few letters of a command or filename and presses Tab , the shell completes the rest of the command or filename.

Consider two files called foobar and football. To delete foobar , the user might type rm foo and press Tab to complete the filename.

But the shell only shows rm foo. It was unable to complete the filename because both foobar and football start with foo. Some shells sound a beep or show all the choices if more than one name matches. The user must then type more characters to identify the desired filename.

Typing a t and pressing Tab again is enough to let the shell determine which filename is desired and fill in the rest.

Another feature of the shell is the use of environment variables. This environment can be read by any program invoked by the shell, and thus contains a lot of program configuration. Before building a custom kernel, consider the reason for doing so. If there is a need for specific hardware support, it may already exist as a module. Most kernel drivers have a loadable module and manual page. For example, the ath 4 wireless Ethernet driver has the following information in its manual page:.

This is mostly true for certain subsystems. On a dual-boot system, the inventory can be created from the other operating system. If FreeBSD is the only installed operating system, use dmesg 8 to determine the hardware that was found and listed during the boot probe. Most device drivers on FreeBSD have a manual page which lists the hardware supported by that driver.

For example, the following lines indicate that the psm 4 driver found a mouse:. Since this hardware exists, this driver should not be removed from a custom kernel configuration file. Another tool for finding hardware is pciconf 8 , which provides more verbose output.

For example:. This output shows that the ath driver located a wireless Ethernet device. The -k flag of man 1 can be used to provide useful information. For example, it can be used to display a list of manual pages which contain a particular device brand or name:.

Once the hardware inventory list is created, refer to it to ensure that drivers for installed hardware are not removed as the custom kernel configuration is edited. In order to create a custom kernel configuration file and build a custom kernel, the full FreeBSD source tree must first be installed. This directory contains a number of subdirectories, including those which represent the following supported architectures: amd64 , i , powerpc , and sparc Instead, copy the file to a different name and make edits to the copy.

The convention is to use a name with all capital letters. The default editor is vi, though an easier editor for beginners, called ee, is also installed with FreeBSD. The format of the kernel configuration file is simple. Each line contains a keyword that represents a device or subsystem, an argument, and a brief description. Any text after a is considered a comment and ignored. To remove kernel support for a device or subsystem, put a at the beginning of the line representing that device or subsystem.

Additional variables are available. Refer to make. If config fails, it will print the line number that is incorrect. If make fails, it is usually due to an error in the kernel configuration file which is not severe enough for config to catch. Review the configuration, and if the problem is not apparent, send an email to the link:FreeBSD general questions mailing list which contains the kernel configuration file.

If the new kernel does not boot or fails to recognize devices, do not panic! Fortunately, FreeBSD has an excellent mechanism for recovering from incompatible kernels.

Simply choose the kernel to boot from at the FreeBSD boot loader. At the prompt, type boot [replaceable] kernel. After booting with a good kernel, check over the configuration file and try to build it again. Also, dmesg 8 will print the kernel messages from the current boot. To fix this, recompile and install a world built with the same version of the source tree as the kernel. It is never a good idea to use a different version of the kernel than the rest of the operating system.

Documentation for FreeBSD. Man Pages. FreeBSD Handbook. Working Groups. Improve this page. When to build a custom kernel. How to take a hardware inventory. How to customize a kernel configuration file. How to use the kernel configuration file to create and build a new kernel.

How to install the new kernel.



0コメント

  • 1000 / 1000