It is not particularly useful to be able to load modules while
installing on i386, probably the most useful one is dtrace,
and this takes up about 20mb on a port that is already exceeding
CD limits. Most stuff you'd want to use while installing is already
in GENERIC.
The modules set is still available compressed for installing into
a target system, meaning modules are available after installation.
While here, add man set to the installation DVD, it's helpful to be able
to read e.g. the man page for fdisk when rescuing a system.
we need to resize_gpt now, as it takes precedence over mbr/disklabel
this change brings us to behave like the evbarm images.
XXX: we don't seem to touch disklabel and MBR, but they exist. Not sure whether
that has any negative repercussions, maybe another system might regard MBR as the
sole source of truth when GPT also exists.
The biggest caveat is that there's a small number of machines that try to
EFI boot but fail, so would prefer a BIOS only image. I'm not adding a
separate BIOS only image because the live image is pretty niche.
(For regular installation images, we do create a separate BIOS-only version)
This is very limited -- it does not supplant postinstall to rehash
certificates on upgrade; it only runs certctl rehash if
/etc/openssl/certs is an empty directory, as you get in live images
not created with sysinst.
We could also have a more general-purpose way to run postinstall(8)
on first boot of an image, but that has a lot more moving parts to
think about, so let's start with this limited-scope low-risk
approach.
PR install/57629
XXX pullup-10
The installimage sizes were bumped in 2022 because of some growth, and
the case for not-xz sets went to 4000 (MiB). That's just over what a
lot of "4 GB" flash drives are, but seems obviously intended to fit.
The actual usage of the filesystem, from a current build from earlier
this year (with non-xz sets) is:
/dev/dk1 3.7G 833M 2.7G 23% /mnt
and similar for netbsd-10 built yesterday, so we can afford to shrink
slightly. Drop to 3800, which is still huge, but will make 4 GB flash
drives work.
When a user selects "exist installer" or hits ^Z in sysinst, the
calling install.sh runs a shell, plus shows a message indicating
they can type "exit" to return to the installer.
Add -E to the arguments to this shell, to enable command line editing,
(primarily for arrow keys, but basic emacs sequences will also work)
At this point this is only on amd64, as this is the port which is
least likely to be installing on particularly esoteric terminal
hardware, and is also likely to have the highest proportion of less
experienced users
bump the size of images if USE_XZ_SETS != no. consolidate a lot of
the code between installimage/Makefile and installimage-bios/Makefile
into installimage/installimage.mk.
Several people reported having hardware that struggles booting the mix
EFI+BIOS image, and it's better to offer them a working image.
Keeping the EFI image as having the obvious name, this is going to become
more likely to work by default as newer hardware may not support BIOS boot.
(XXX pullup-9)
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.
outgrown the previous size specification when the system was built
with all of MKDEBUG, MKKDEBUG, and MKDEBUGLIB set to "yes" (and
also when in-tree X11 is included).
So, bump the size a bit.
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)
enabled and don't warn our users that it might not and already suggest
workarounds.
The ability to disable ACPI and SMP is still there, by dropping to
the boot prompt.
nia