This set is only installed on amd64,i386,evbarm.
This set is installed on minimal installs and on install media, in
case someone needs it for basic driver functionality.
Comments:
Switched to a single MK tunable for it - that is probably unneeded.
An upcoming DRM update will include even fatter firmware, and we'd
like to minimize the impact of it.
/netbsd/modules respectively instead of /netbsd and
/stand/<arch>/<version>/modules. This is only supported for x86,
and is turned off by default. To try it, add KERNEL_DIR=yes in your
/mk.conf and install a system from that build.
It's been determined that it's too magical and it's either the job
of the bootloader or you compile it into the kernel yourself.
This entry works in /boot.cfg:
menu=Boot ZFS Root:load solaris;load zfs;fs /ramdisk-zfsroot.fs;boot
Rather than copying the needed modules from FFS to the ramdisk,
load then directly from FFS instead.
This way, we can symlink ramdisk stand into /altroot and let nature take
it's course like loading firmware.
Set shell exit on error rather than using chained commands.
zpool import seems to SIGBUS randomly on amd64 and if we didn't do the
former then zpool would hang the init. Now at least we exit to the shell.
Until we get ZFS integrated into our boot loader, this is the next best
thing. The idea is simple - have a small FFS partition with a kernel,
modules and this ramdisk. Once the ramdisk boots it will mount the FFS
partition read only, copy the needed ZFS modules to the ramdisk and then
unmount the partition. Then we import the ZFS root pool, mount the
ZFS root filesystem and then pivot to it.
Because the initial FFS partition is not mounted at this point, we
can mount it in /altroot so we can replace the kernel and modules with
newer ones so it's easily maintainable.
This ZFS boot strapper currently makes the following assumptions:
* The device NAME=boot is the FFS with kernel, modules and this ramdisk.
* The ZFS root pool and root filesystem are called rpool/ROOT.
A boot.cfg menu entry can then be added like so:
menu=Boot ZFS root:fs /ramdisk-zfsroot.fs;boot
were dealing with DBG (-d) LDSTATIC/NOPIE (-p), and the rest with
disabling/enabling sanitizers.
2. Use emalloc/estrdup for all the allocators instead of only some cases.
3. Add -V varspec which passes variables on the command line (as DBG
and LDSTATIC used to be passed before) instead of appending them
to the on-the-fly Makefile using -v varspec.
4. Change the distrib and rescue Makefiles to use -V instead of the removed
flags.
The motivation of this is to make variable handling consistent, less magical,
and remove the need for changing crunchgen each time we want to add disabling
an option by default.
(as proposed in tech-toolchain)
doing the tmpfs / MAKEDEV magic.
On images for machines with serious ram shortage (where the additional
tmpfs hurts, like VAX) override this with CDDEV_POPULATE=true.
Should fix PR port-amd64/54776.
try mounting gpt label "cgdroot" as a root filesystem first and
only mount /dev/cgd0a if that gpt label doesn't exist or fails
to mount.
XXX pullup to 8 and 9.
other, so .WAIT after creating one before moving on to the next.
Case at hand: evbarm/installation/instkernel:
netbsd-RPI_INSTALL.bin needs to be complete before netbsd-RPI_INSTALL.img
can be created.
Better solutions welcome...
images, but also on the bootable disk images of other ports, so that
they can be booted from differently named devices. Merge the i386 and
amd64 -live-sd0root and -live-wd0root images into a single live image
per port, bootable both from usb media and in qemu. Drop the -xx0root
suffixes from image names as they are no longer meaningful.
NetBSD gzip is not toolified so we can't assume the host gzip will be able
to decompress xz files. Use the toolified xz instead in the USE_XZ_SETS case.
ISO image.
Set this for sparc64 install CDs - many of the supported machines have
SCSI CD drives and it is impossible to get DVD replacements for those.
This is a pitty, but in the end a working install medium is more worth
than debug sets (which can be downloaded later).
mrg