Партнёры:
Хостинг:
picobsd - building small FreeBSD disk images
The utility was originally created to build simple standalone systems such as firewalls or bridges, but because of the ability to cross-build images with different source trees than the one in the server, it can be extremely useful to developers to test their code without having to reinstall the system.
The boot media (historically a floppy disk, but also small CDROM or USB keys) contains a boot loader and a compressed kernel which includes a memory file system. Depending on the media, it might also contain a number of additional files, which can be updated at run time, and are used to override/update those in the memory file system.
The system loads the kernel in the normal way, uncompresses the memory file system and mounts it as root. It then updates the memory file system with files from the boot media (if present), and executes a specialized version of /etc/rc The boot media (floppy, etc.) is required for loading only, and typically used read-only. After the boot phase, the system runs entirely from RAM.
The following options are available (but also check the script for more details):
The supported build script is /usr/src/release/picobsd/build/picobsd which can be run from anywhere, and relies on the sysutils/makefs port to build a filesystem without requiring mdconfig or root privileges to mount a filesystem. When run in interactive mode (the default without the -n option), the script will let you configure the various parameters used to build the PicoBSD image. An image is configured using the files and directories described below. The base system contains a template, called bridge for historical reasons, that can be used as a base for building various kinds of network appliances.
You can define your own PicoBSD configuration, by creating a directory with a name of your choice (e.g. FOO which contains some of the following files and directories. For more information on how to construct these files, look at one of the standard configurations as a reference.
To be recognised as a kernel config file, the file must also contain the line beginning with ``#PicoBSD '' below, and a matching MD_ROOT_SIZE option:
#marker def_sz init MFS_inodes floppy_inodes #PicoBSD 4200 init 8192 32768 options MD_ROOT_SIZE=4200 # same as def_sz
This informs the script of the size of the memory file system and provides a few other details on how to build the image.
The following issues are particularly important when dealing with configurations:
"buildopts -DNO_PAM -DRELEASE_CRUNCH ..."
"srcdirs /usr/src/release/picobsd/tinyware"
so that -specific versions of the programs will be found there.
"srcdirs @__CWD__@/src"
If you plan to store the image on a CDROM (e.g. using the ``
'' floppy emulation), you can set fd_size equal to 2880. If you are planning to dump the image onto a hard disk (either in a partition or on the whole disk), you are not restricted to one of the standard floppy sizes. Using a large image size per se does not waste RAM at runtime, because only the files that are actually loaded from the image contribute to the memory usage.
Pa floppy.tree.exclude List of files from the standard floppy tree which we do not want to be copied (optional). Pa floppy.tree/ Local additions to the standard floppy tree (optional). The content of this subtree will be copied as-is into the floppy image. Pa floppy.tree. Ns Aq Ar site-name Same as above, but site-specific (optional).
More information on the build process can be found in the comments in the script.
cd <some_empty_directory> mkdir FOO (cd FOO; cvs -d<my_repository> co -rRELENG_4 src) picobsd --src FOO/src --init # this is needed only once picobsd --src FOO/src -n -v bridge
If the build is successful, the directory build_dir-bridge/ will contain a kernel that can be downloaded with etherboot, a floppy image called picobsd.bin plus the products of the compilation in other directories. If you want to modify the source tree in FOO/src a new image can be produced by simply running
"picobsd --src FOO/src -n -v bridge"
whereas if the change affects include files or libraries you first need to update them, e.g. by re-running
"picobsd --src FOO/src --init # this is needed only once"
as you would normally do for any change of this kind.
"dd if=picobsd.bin of=/dev/rfd0"
and the floppy is ready to boot.
dd if=picobsd.bin of=/dev/ad2 dd if=picobsd.bin of=/dev/ad2s3 dd if=picobsd.bin of=/dev/ad2 oseek=NN
The first form will install the image on the entire disk, and it should work in the same way as for a floppy.
The second form will install the image on slice number 3 (which should be large enough to store the contents of the image). However, the process will only have success if the partition does not contain a valid disklabel, otherwise the kernel will likely prevent overwriting the label. In this case you can use the third form, replacing NN with the actual start of the partition (which you can determine using fdisk(8)). Note that after saving the image to the slice, it will not yet be recognised. You have to use the disklabel(8) command to properly initialize the label (do not ask why!). One way to do this is
disklabel -w ad0s2 auto disklabel -e ad0s2
and from the editor enter a line corresponding to the actual partition, e.g. if the image has 2.88MB (5760 sectors) you need to enter the following line for the partition:
"a: 5760 0 4.2BSD 512 4096"
At this point the partition is bootable. Note that the image size can be smaller than the slice size (indicated as partition ``c: ''
'' image (and burn it) with the following command:
mkisofs -b picobsd.bin -c boot.catalog -d -N -D -R -T \
-o cd.img build_dir-foo
burncd -f /dev/acd0c -s 4 data cd.img fixate
Note that the image size is restricted to 1.44MB or 2.88MB, other sizes most likely will not work.
You can also use etherboot to load the preloaded, uncompressed kernel image which is a byproduct of the build. In this case the load time is a matter of a few seconds, even on a 10Mbit/s ethernet.
After booting, loads the root file system from the memory file system, starts /sbin/init and passes control to a first startup script, /etc/rc The latter populates the /etc and /root directories with the default files, then tries to identify the boot device (floppy, hard disk partition) and possibly override the contents of the root file system with files read from the boot device. This allows you to store local configuration on the same media. After this phase the boot device is no longer used, unless the user specifically does it.
After this, control is transferred to a second script, /etc/rc1 (which can be overridden from the boot device). This script tries to associate a hostname to the system by using the MAC address of the first ethernet interface as a key, and /etc/hosts as a lookup table. Then control is passed to the main user configuration script, /etc/rc.conf which is supposed to override the value of a number of configuration variables which have been pre-set in /etc/rc.conf.defaults You can use the hostname variable to create different configurations from the same file. After taking control back, /etc/rc1 completes the initializations, and as part of this it configures network interfaces and optionally calls the firewall configuration script, /etc/rc.firewall where the user can store his own firewall configuration.
Note that by default runs entirely from main memory, and has no swap space, unless you explicitly request it. The boot device is also not used anymore after /etc/rc1 takes control, again, unless you explicitly request it.
#ethertable start of the ethernet->hostname mapping # mac_address hostname # 00:12:34:56:78:9a pinco # 12:34:56:* pallino # * this-matches-all
where the line containing ``#ethertable '' marks the start of the table.
If the MAC address is not found, the script will prompt you to enter a hostname and IP address for the system, and this information will be stored in the /etc/hosts file (in memory) so you can simply store them on disk later.
Note that you can use wildcards in the address part, so a line like the last one in the example will match any MAC address and avoid the request.
It is worth mentioning that some of the variables let you overwrite the contents of some files in /etc This option is available at the moment for /etc/host.conf and /etc/resolv.conf whose contents are generally very short and suitable for this type of updating. In case you use these variables, remember to use newlines as appropriate, e.g.
host_conf="# this goes into /etc/host.conf hosts bind"
Although not mandatory, in this file you should only set the variables indicated in /etc/rc.conf.defaults and avoid starting services which depend on having the network running. This can be done at a later time: if you set firewall_enable = Qq YES the /etc/rc.firewall script will be run after configuring the network interfaces, so you can set up your firewall and safely start network services or enable things such as routing and bridging.
There is a small script called update which can be used to edit and/or save to disk a copy of the files you have modified after booting. The script takes one or more absolute pathnames, runs the editor on the files passed as arguments, and then saves a compressed copy of the files on the disk (mounting and unmounting the latter around the operation).
If invoked without arguments, update edits and saves rc.conf , rc.firewall and master.passwd
If one of the arguments is /etc (the directory name alone), then the command saves to disk (without editing) all the files in the directory for which a copy already exists on disk (e.g. as a result of a previous update).
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |