Adjust notes to describe new boot floppy scheme.
This commit is contained in:
parent
50156effd9
commit
c49127f127
Notes:
svn2git
2020-12-20 02:59:44 +00:00
svn path=/head/; revision=43470
@ -1,57 +1,59 @@
|
|||||||
For a normal CDROM or network installation, all you need to copy onto an
|
For a normal CDROM or network installation, all you need to copy onto
|
||||||
actual floppy from this directory is the boot.flp image (for 1.44MB floppies).
|
actual floppies from this directory are the kern.flp and mfsroot.flp
|
||||||
|
images (for 1.44MB floppies).
|
||||||
|
|
||||||
If you're on the ALPHA then the boot.flp image is probably larger
|
Get two blank, freshly formatted floppies and image copy kern.flp
|
||||||
than any kind of floppy you have available and you will need to
|
onto one and mfsroot.flp onto the other. These images are NOT DOS
|
||||||
either netboot it, load it from some other type of media (such
|
files! You cannot simply copy them to a DOS or UFS floppy as
|
||||||
as a jaz drive) or use the kern.flp image described below.
|
regular files, you need to "image" copy them to the floppy with
|
||||||
|
fdimage.exe under DOS (see the tools/ directory on your CDROM or
|
||||||
This release still uses only one installation floppy, the boot.flp
|
FreeBSD FTP mirror) or the `dd' command in UNIX.
|
||||||
image. For convenience (and for the DEC ALPHA architecture, on which
|
|
||||||
binaries are quite a bit larger), however, we also provide the
|
|
||||||
functionality of boot.flp now "decoupled" into a kern.flp image,
|
|
||||||
which contains just the boot kernel, and mfsroot.flp, which contains
|
|
||||||
the compressed MFS root image that is normally stored as part of
|
|
||||||
the kernel itself on the boot.flp image. This allows you to boot
|
|
||||||
from kern.flp, which will fit on a 1.44MB floppy even on the alpha,
|
|
||||||
and then use mfsroot.flp from a 2nd floppy. This also allows you
|
|
||||||
to easily make your own boot or MFS floppies should you need to customize
|
|
||||||
some aspect of the installation process. As long as the kernel is compiled
|
|
||||||
with ``options MFS'' and ``options MFS_ROOT'', it will properly look for
|
|
||||||
and boot an mfsroot.flp image when run. The mfsroot.flp image is simply
|
|
||||||
a gzip'd filesystem image, something which can be made rather
|
|
||||||
easily using vnconfig(8). If none of this makes any sense to you,
|
|
||||||
don't worry about it - just use the boot.flp image as always; nothing
|
|
||||||
has changed there.
|
|
||||||
|
|
||||||
|
|
||||||
NOTE: The *.flp images are NOT DOS files! You cannot simply copy them
|
|
||||||
to a DOS or UFS floppy as regular files, you need to *image* copy them
|
|
||||||
to the floppy with fdimage.exe under DOS or `dd' under UNIX.
|
|
||||||
|
|
||||||
For example:
|
For example:
|
||||||
|
|
||||||
To create the boot floppy image from DOS, you'd do something like
|
To create the kern floppy image from DOS, you'd do something like
|
||||||
this:
|
this:
|
||||||
|
|
||||||
C> fdimage boot.flp a:
|
C> fdimage kern.flp a:
|
||||||
|
|
||||||
Assuming that you'd copied fdimage.exe and boot.flp into a directory
|
|
||||||
somewhere. If you were doing this from the base of a CD distribution,
|
|
||||||
then the *exact* command would be:
|
|
||||||
|
|
||||||
E> tools\fdimage floppies\boot.flp a:
|
|
||||||
|
|
||||||
|
Assuming that you'd copied fdimage.exe and kern.flp into a directory
|
||||||
|
somewhere. You would do the same for mfsroot.flp, of course.
|
||||||
|
|
||||||
If you're creating the boot floppy from a UNIX machine, you may find
|
If you're creating the boot floppy from a UNIX machine, you may find
|
||||||
that:
|
that:
|
||||||
|
|
||||||
dd if=floppies/boot.flp of=/dev/rfd0
|
dd if=floppies/kern.flp of=/dev/rfd0
|
||||||
|
|
||||||
or
|
or
|
||||||
|
|
||||||
dd if=floppies/boot.flp of=/dev/floppy
|
dd if=floppies/kern.flp of=/dev/floppy
|
||||||
|
|
||||||
work well, depending on your hardware and operating system environment
|
work well, depending on your hardware and operating system environment
|
||||||
(different versions of UNIX have totally different names for the
|
(different versions of UNIX have totally different names for the
|
||||||
floppy drive - neat, huh? :-).
|
floppy drive - neat, huh? :-).
|
||||||
|
|
||||||
|
If you're on an ALPHA machine which netboots its floppy images or
|
||||||
|
you have a 2.88MB or LS-120 floppy capable of taking a 2.88MB image
|
||||||
|
on an x86 machine, you may still wish to use the older (but now
|
||||||
|
twice as large) boot.flp image which we also provide. That contains
|
||||||
|
the contents of kern.flp and mfsroot.flp on a single floppy,
|
||||||
|
essentially, and can be used in all of the above scenarios as well
|
||||||
|
as a handy boot image for those mastering "El Torito" bootable CD
|
||||||
|
images. See the mkisofs(1) command for more information.
|
||||||
|
|
||||||
|
Going to two installation boot floppies is a step we definitely
|
||||||
|
would have rather avoided but we simply no longer could due to
|
||||||
|
general code bloat and FreeBSD's many new device drivers in GENERIC.
|
||||||
|
|
||||||
|
One positive side-effect of this new organizational scheme, however,
|
||||||
|
is that it also allows one to easily make one's own kern or MFS
|
||||||
|
floppies should a need to customize some aspect of the installation
|
||||||
|
process or use a custom kernel for an otherwise unsupported piece of
|
||||||
|
hardware arise. As long as the kernel is compiled with
|
||||||
|
``options MFS'' and ``options MFS_ROOT'', it will properly look for
|
||||||
|
and boot an mfsroot.flp image in memory when run (see how the
|
||||||
|
/boot/loader.rc file in kern.flp does its thing). The mfsroot.flp
|
||||||
|
image is also just a gzip'd filesystem image which is used as root,
|
||||||
|
something which can be made rather easily using vnconfig(8).
|
||||||
|
If none of that makes any sense to you then don't worry about it -
|
||||||
|
just use the kern.flp and mfsroot.flp images as described above.
|
||||||
|
Loading…
Reference in New Issue
Block a user