ports tree so that programs use libusb from the base by default. Thanks to
Stanislav Sedov for sorting out the ports build.
Bump __FreeBSD_version to 800069
Help and testing by: stas
complains about "Malformed numbers" while unpacking the dists and
what winds up on the disk isn't correct. Use this as an opportunity
to switch over to bsdcpio since at this point we don't even build
and install the gnu cpio by default. Note sysinstall needed to be
tweaked a bit (dropping tape block size setting) because it seems
bsdcpio doesn't do anything with block sizes, at least as far as
reading from archives goes. That wasn't really a problem since
installations from tape have been broken for a while and the rest
of sysinstall's tape support code will be removed shortly.
can't find fsck_4.2bsd because there was no fstab file saying what
filesystem type it is looking at so it got the filesystem type from
the disk's label. When that fails admins who haven't been in this
situation before are most likely to try "fsck -t ufs /dev/ad0s1a" because
ufs is the type used in fstab files on working systems but that also fails
complaining it can't find fsck_ufs.
This just sets it up so /stand in the MFS image (/sbin is a symlink
to /stand) includes hard links pointing fsck_4.2bsd and fsck_ufs to
fsck_ffs which is what is present in /sbin on installed systems.
Prodded by: obrien
MFC after: 1 day
at runtime and to support distributing additional kernels:
o remove kernel from the base tarball
o add new kernel tarballs
o build + package both SMP and GENERIC kernels when an <arch>/conf/SMP
config file is present
o add sysinstall support for multiple kernels
o update sysinstall to probe for the number of cpus on a system
and auto-select smp/up kernel accordingly
o add a post-kernels install hook to fixup /boot/kernel
o add -ldevinfo to boot crunch for sysinstall's cpu probing logic
Notes:
1. On HEAD this code is not currently used because GENERIC kernels
include SMP. This work is mainly intended for RELENG_6 where the
GENERIC kernel is UP. If HEAD changes to match then just enable
WITH_SMP in sysinstall/Makefile.
2. The cpu probing support is done with acpi and MPTable; this means
some systems will require work for auto-detection to work.
3. The handling of /boot/kernel may need to be revisited; for now
we rename one kernel at the last moment (SMP if installed, otherwise
GENERIC). There are other, possibly better, approaches.
Lots of help from ru, emaste, scottl, and jhb.
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
