Add fsck_4.2bsd and fsck_ufs as hard links to fsck_ffs in /stand on
the MFS image so that (for example) "fsck /dev/ad0s1a" will work.
Without this you needed (for example) "fsck -t ffs /dev/ad0s1a" (or
needed to run fsck_ffs instead of fsck).
Versions being MFCed:
1.62 src/release/amd64/boot_crunch.conf
1.62 src/release/i386/boot_crunch.conf
1.12 src/release/ia64/boot_crunch.conf
1.63 src/release/pc98/boot_crunch.conf
1.5 src/release/powerpc/boot_crunch.conf
1.9 src/release/sparc64/boot_crunch.conf
1.2 src/release/sun4v/boot_crunch.conf
boot.flp in 5.3 and later is not self-contained and thus not suitable for
CD booting. /boot/cdboot is now the only way to boot the install CDs.
MFC after: 2 weeks
*BANG* *BANG* *BANG* *BANG* *BANG* *BANG* *CLICK* *CLICK* *CLICK*
Death to the stripped down BOOTMFS kernel for boot floppies and all the
cruft that goes along with it.
that causes the bootable ISO images to be created using the floppy
emulation (the old method) as opposed to the new "cdboot" method.
Only copy boot.flp to the 2nd CD-ROM if this variable is defined.
Reviewed by: murray
Also make sure bsdlabel(8) (along with the disklabel(8) compat
link) still appear on the fixit floppies of platforms that use
it natively (alpha, i386, and pc98).
Approved by: re (scottl)
If we have no UFS_ACL kernel, users who already uses UFS1/2 attributes
get confused since no access control is performed for an update install.
Still, pc98 and alpha doesn't have UFS_ACL since I don't know about them.
Nyan-san, if kern.flp on tatsu has enough spaces (4k or more spaces),
please back UFS_ACL for pc98 also.
Data collected from: 5.0-CURRENT-20030221-JPSNAP on snapshots.jp.FreeBSD.org
aacp is a passthrough driver for aac, but it seems that aac kernel
module has a feature provided by aacp; so it can be removed safely.
_KPOSIX_PRIORITY_SCHEDULING provides P1003.1B realtime extension.
However, in an installation phase, it seems that it helps a little
for us, so we can remove this option from a kernel for floppy installation.
I know _KPOSIX_PRIORITY_SCHEDULING option is defined in other architecture.
However, I don't touch them at this time; I can't test it.
Anyway here's result.
Before diet:
-rwxr-xr-x 1 matusita matusita 4849883 Feb 18 11:22 kernel
-rwxr-xr-x 1 matusita matusita 1727143 Feb 18 11:47 kernel.kgz
After diet:
-rwxr-xr-x 1 matusita matusita 4840949 Feb 18 09:48 kernel
-rwxr-xr-x 1 matusita matusita 1723911 Feb 18 11:47 kernel.kgz
We've got extra 3232 bytes (using 5-current as of Feb/18/2003).
In cooperation with: jwd (test ISO installation image)
Boot tested on: several PCs around myself
Installation tested on: VMware Workstation e.x.p build-4099
