digit beyond your time.
Various sysinstall dependencies (e.g. libftpio, libdisk, libodialog, etc.)
will be cleaned up in coming days. Some will take longer than others due to
a few other consumers (tzsetup and sade).
changes, and backport the new logic (ISO images are TARGET dependant, not
TARGET_CPUARCH dependant) to Makefile.sysinstall. While modifying ISO
image scripts, change several archs to use makefs (from base) instead of
mkisofs (from ports) which makes release CD generation both faster and
self-hosting.
makes booting more reliable (and working at all on USB sticks). While here,
move responsibility for setting up fstab into the various platform mk-*.sh
scripts.
Suggested by: many
i386 and amd64. This involved moving the memstick generation script to
the arch directories from scripts/, in analogy to mkisoimages.sh. This
script was never called from /usr/src/release/Makefile, so that hasn't
been updated.
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.
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
the BOOTMFS kernel. These help reduce the kernel size so things fit
in a floppy image. There are more low-hanging fruit to be had here
if things fail to fit again.
into the install kernel. Unfortunately pcn(4) also needs mii(4) so that
would also have to added to install kernel, which will bloat it up so that it
doesn't fit on the floppy any more. Turns out we grew a lnc(4) module since
I last looked. So handle it as a kld loadable module during install rather
than have it statically compiled into the kernel.
