从映像文件引导，使用ramdisk为根目录的freebsd。

YIWUTIAN

网上有老外问道：
Could someone point me to some examples for how to use MD_ROOT with 5.1
Release?

What I am trying to do is create a system which:

1) Boots off of a hard drive
2) Copies a full filesystem into RAM (I've got lots)
3) Boots the kernel and mounts the RAM as its filesystem
4) Shuts down the hard drive completely

I've seen a few things for creating read-only systems, but I don't want to
have to access the media after boot.

There are some references to the old MFS stuff, but I'm not finding any
obvious references to doing similar stuff with MD.

Any pointers would be appreciated.

Thanks,
有人研究吗，我保证很多人希望了解，知道得老大说说嘛。
但是好象md_root的工作方式不是这样的，是loader直接从一个映像文件启动系统。
我
man md
man loader
man mdconfig
都没有什么线索。只有man md提到有loader启动mdimage方面的内容。

YIWUTIAN

呵呵，刚发完贴子就看到这篇文章，献上：

Building Monolithic Kernels and Root Filesystems for FreeBSD
David Yeske <dyeske@yahoo.com>;

This article explains an alternative method of creating a kernel that contains a root file system image within it. This single-file kernel and file system can be used in many ways beyond what usual FreeBSD kernels allow, just as having the root file system loaded along with the kernel enables you to have more flexibility in the boot process.

A utility called write_mfs_in_kernel was once used to create a monolithic kernel and mfsroot (memory resident root file system). However, write_mfs_in_kernel has been removed from FreeBSD. Since the functionality was still important, I needed a replacement.

Here are examples of basic uses of this mechanism:

    * Network booting with a preloaded root file system without needing a PXE client or NFS server
    * Loading PicoBSD from a TFTP image
    * Thin terminals
    * Embedded systems
    * Data recovery
    * Fully automated and unattended FreeBSD installation that works with any network device supported by grub or etherboot
    * Any other method where /boot/loader or /boot/pxeboot cannot be used

The flexibility of a monolithic kernel allows FreeBSD to be loaded in many situations. Here are additional examples where this can be used.

    * If a floppy disk has grub or etherboot installed, then FreeBSD can be loaded over tftp and is not required to be in the same subnet as the tftp server. This allows any computer with an internet connection to run picobsd or the FreeBSD installer with one floppy disk. The size of the FreeBSD kernel with mfsroot is not limited to the size of the floppy, either.
    * An image could be made containing the FreeBSD installer with sshd added. This allows for a remote install using an inbound ssh connection. Access control configuration could be stored on a FAT formatted floppy disk. Users could modify the configuration on a machine that is not running FreeBSD and enter in information provided by a remote administrator.
    * A machine can download a monolithic kernel onto a drive formatted with FAT32, ext2, or anything else supported by grub or etherboot. This permits installation onto a machine that does not have a bootable 1.44M floppy drive or a bootable cdrom drive. Some laptops and older machines could benefit from this.
    * An average PC could quickly become a router, firewall, mp3 server, or X terminal that would not need to modify or remove the existing operating system.

Comparison

The alternative method uses the objcopy program, which is part of GNU binutils. It is used to convert a mfsroot image into an ELF object that can be linked into the FreeBSD kernel. The md device is modified so that it can reference both the beginning and end of the mfsroot from weak symbols that objcopy adds to the mfsroot image before the kernel is linked. Currently this requires the kernel to be recompiled every time you want to replace the image; once a kernel is compiled using this method, the root file system might be able to be replaced by relinking the kernel rather than recompiling it.

The write_mfs_in_kernel method required padding (options MD_ROOT_SIZE) to be added to a kernel, the kernel compiled, and the root file system inserted into it via write_mfs_in_kernel. This allowed a mfsroot image to be inserted into a kernel as long as it was less than the size of the padding. The mfsroot image could also be replaced without having to recompile or relink the kernel. A mfsroot image larger than the size of the padding would require the kernel to be recompiled with more padding though. NetBSD and OpenBSD currently use a similar technique.

I am also working on adding additional functionality so that an arbitrary file can be linked into the kernel and attached to a vnode backed md device during the kernel load. Another benefit to the objcopy method is that it can be extended to have more than one root file system per kernel, which can be referenced via ufs:/dev/md0c, ufs:/dev/md1c, etc... Further development could lead to a distribution of FreeBSD that can live in a file that is not on a drive formatted with ufs. QNX can live in a file on a FAT32 partition, and BeOS was also able to. There are also Linux distributions that can live in a file via the loopback interface. Novice users might want to initially try out FreeBSD in a symbiotic way that does not require another partition, especially if their drive is already formatted with FAT32.
Kernel Construction Overview

The following steps were used to create a FreeBSD kernel and mfsroot image from the 4.7-RELEASE install sets. There is a link to a usable image here that can be used to install FreeBSD 4.7-RELEASE. First, the following patch must be applied so the kernel and md device will have support for the objcopy method. This patch should apply clean to RELENG_4_7_0_RELEASE and not have any effect on a system when MD_ROOT_IMAGE is not defined. This method also works on FreeBSD current, but the code is slightly different. Next the BOOTMFS kernel config file that is created during a make release was modified by adding these 2 lines:


makeoptions     MD_ROOT_IMAGE="/tmp/mdimage.o"
options         MD_ROOT_IMAGE

The makeoptions MD_ROOT_IMAGE="/tmp/mdimage.o" line adds the mdimage.o object file to the list of files to be linked into the kernel.
The options MD_ROOT_IMAGE line is needed so the md device will compile with some extra definitions.

The next step is to run the following commands that remove the mfsroot image from the mfsroot.flp floppy image.

# vnconfig -v vn1 mfsroot.flp
/dev/vn1: 0 bytes on mfsroot.flp
# mount /dev/vn1 /mnt
# cp /mnt/mfsroot.gz .
# umount /mnt
# vnconfig -v -u vn1
/dev/vn1: cleared
# gzip -d mfsroot.gz

An ELF object must be created from the mfsroot image and symbols added to it so the kernel can mount it as the root file system. The mfsroot file is copied to a file called mdimage so that the symbols will work properly. Objcopy is then used to create the ELF object file with symbols that can be linked in with the kernel.

      # cp mfsroot /tmp/mdimage
      # cd /tmp
      # objcopy -v -I binary -O elf32-i386 -B i386 --redefine-sym _binary_mdimage_start=__md_root_image_start --redefine-sym _binary_mdimage_end=__md_root_image_end mdimage mdimage.o
      copy from mdimage(binary) to mdimage.o(elf32-i386)


The __md_root_image_start and __md_root_image_end arguments redefine the the start and end address of the mdimage.o object file so that the md device can reference the weak symbols.

The mdimage.o file is slightly larger (428 bytes) than the original mfsroot image that was copied to mdimage.

4423680 mdimage compared with 4424108 mdimage.o

Make release was run in order to get the BOOTMFS kernel definition file and test this after 4.7-RELEASE was tagged. A kernel was built as follows without modules because they are already on the mfsroot image file system in /stand/modules.

      # cd /usr/src && make buildkernel KERNCONF=BOOTMFS NO_MODULES=yes

The result of applying these steps resulted in a kernel of the following size :
7815765 kernel

Size difference between new kernel compared with original BOOTMFS kernel:


3363818 BOOTMFS

      # echo $((7815765 - 336381) 4451947


Increase in size of kernel for objcopy method not including mfsroot image:

      # echo $((4451947 - 4423680)) 28267

Approximately 28k was lost using this process which is less than the size of the /boot/loader file on the boot.flp image:

84875 Oct  9 11:22 loader

A kernel image created with this method can be loaded using /boot/loader or /boot/pxeboot just like a normal kernel can, but it can also be loaded from grub or etherboot. This method has also been tested after running strip on a kernel.

Acknowledgments

I would like to thank Poul-Henning Kamp and Jerry Hicks for all their effort and input. They made it possible for me to progress this far. I would also like to thank everyone that provided me with technical feedback.

YIWUTIAN

汉化加精吧。

zyme

哪位汉化一下...

YIWUTIAN

还汉化什么，发觉这个东东太复杂，不好用。
每次改动都需要编译内核，麻烦。而且有些命令5.x还不能用(vnconfig被mdconfig代替)。算了还是自己搞：

环境：vmware4.5+freebsd-5.2.1

1：mount /cdrom && cd /tmp && cp /cdrom/boot/mfsroot.gz /tmp
(实际上mfsroot.gz就是普通的磁盘映象文件经过gzip压缩，这里也可以用其他freebsd启动盘用dd做映象代替)
2: gzip -d /tmp/mfsroot.gz
3: mdconfig -a -t vnode -f /tmp/mfsroot -u 0
(建立设备名为md0，以/tmp/mfsroot为映像的ramdisk)
(参考
man md
man mdconfig
)
4: mount /dev/md0 /mnt/ram(自己建个ram)
(如果是disklable -w过，可能是md0a 或md0c,看newfs哪个了)
5: 修改ram的内容复合您的要求
6: umount /mnt/ram && mdconfig -d -u 0
7: cp /tmp/mfsroot /boot
8: reboot
9: 启动选6(prompt... ... )
10:unload
11:load /boot/kernel/kernel
12:load -t md_image /boot/mfsroot
(参考
man loader
)
13:set vfs.root.mountfrom=ufs:/dev/md0c
(参考
man loader
)
14:autoboot 3
启动后用df检验/是否是md0或md0a或md0c

15:启动成功后可以直接修改/boot/defaults/loader.conf
exec="unload"
exec="load /boot/kernel/kernel"
exec="load /boot/xxxxxx.img"
exec="set vfs.root.mountfrom=ufs:/dev/md0c"
(这条也可以直接修改vfs.root选项。)
exec="boot"

16:好象这个映像文件还可以用gzip 压缩。

改完收工！

YIWUTIAN

刚刚把以前做的u盘版freebsd的镜像：
直接拿来用，发觉基本上可以启动（可能需要修改rc)。

结合U盘版FREEBSD，将使FREEBSD在普通PC上制作商业化防火墙、拨号服务器等成为可能 。
1:软盘太容易坏，容量太小，价格没有优势：优质的软驱+N张好的软盘  可能 比一个64M的U盘贵。
2:光盘维护太麻烦。价格自然也贵。
3：硬盘？
5：flash硬盘，可能贵了点。而且也失去了维护的优势。
6：可以利用这个技术+PXE技术制作无盘防火墙（？？？不知到有没有意义）。
5.x巴实！