Given rtw88 and iwlwifi still have firmware in src.git I ran a test with rtw89 which came up booting disc1 as well.
So this part works.

Trying to load binary firmware from /boot/firmware/rtw89/rtw8852a_fw.bin
firmware: '/boot/firmware/rtw89/rtw8852a_fw.bin' version 0: 1423232 bytes loaded at 0xfffffe0051e00000
rtw89/rtw8852a_fw.bin: Loaded binary firmware using /boot/firmware/rtw89/rtw8852a_fw.bin

I also tried memstick and dvd1; I manually (so far) afterwards ran fwget from the shell (and in case of rtw8x added the tunable to loader.conf) and the system came up fine after a reboot.

@cperciva releng do we need to test the NO_ROOT bits as well (I saw other bits are not implemented for it yet either).

@jrtc27 We should make this conditional on "is x86 or arm64" since there's no guarantee that the FreeBSD project will have package sets for any other platforms. Would that address your concern about the availability of a pkg binary?

In D47407#1081558, @cperciva wrote:

@jrtc27 We should make this conditional on "is x86 or arm64" since there's no guarantee that the FreeBSD project will have package sets for any other platforms. Would that address your concern about the availability of a pkg binary?

Well, x86 and arm64 macOS/Linux will still fall under that. But yes, making sure it doesn't fail for architectures without package sets is also a good point.

FYI in the new year I plan to start work on making the whole artifact build process NO_ROOT. If we need to use NO_ROOT as a flag that changes the built artifacts please make the missing functionality explicit (e.g. by leaving the NO_ROOT case with a commented body, or so).

Or even better, have it controlled by whether the build host is FreeBSD or a new flag that controls these cases.

How do we envision a build/install media creation for pkgbase in the future? I would highly assume you'll need to sort that issue somehow anyway.

That said we use pkg for VM images already to my understanding; the simple fact that they use shell scripts but are not integrated into a unified build process just makes it a mood point.

From all I can tell by now and after a brief discussion the artifacts we build today are mostly of historic nature and need overhaul anyway (disc1 being way to big for a CD, memstick not having the pkg-set on it but only the optional dvd1, ...). VM images looking like a 2nd class citizen.

I would love this all to be NO_ROOT @emaste and I don't agree with the view that NO_ROOT is for non-FreeBSD.

This is all discussions for another day and place though I assume.

What .if should we really put around it now?

.if ${.MAKE.OS} == "FreeBSD"

In D47407#1081562, @jrtc27 wrote:

In D47407#1081558, @cperciva wrote:

@jrtc27 We should make this conditional on "is x86 or arm64" since there's no guarantee that the FreeBSD project will have package sets for any other platforms. Would that address your concern about the availability of a pkg binary?

Well, x86 and arm64 macOS/Linux will still fall under that. But yes, making sure it doesn't fail for architectures without package sets is also a good point.

Oh, people are building FreeBSD release images on non-FreeBSD? I didn't realize that. This sounds like even more reason to have pkg in the base system (and as a cross-tool).

In D47407#1081787, @cperciva wrote:

In D47407#1081562, @jrtc27 wrote:

In D47407#1081558, @cperciva wrote:

@jrtc27 We should make this conditional on "is x86 or arm64" since there's no guarantee that the FreeBSD project will have package sets for any other platforms. Would that address your concern about the availability of a pkg binary?

Well, x86 and arm64 macOS/Linux will still fall under that. But yes, making sure it doesn't fail for architectures without package sets is also a good point.

Oh, people are building FreeBSD release images on non-FreeBSD? I didn't realize that. This sounds like even more reason to have pkg in the base system (and as a cross-tool).

Yeah, we do all our CheriBSD CI builds on Linux hosts and also support building release media on macOS for ease of local testing. That’s only (mini-)memstick/bootonly/disc1/ftp though, no dvd1 (due to pkg), and no VM images.

Yeah, we do all our CheriBSD CI builds on Linux hosts and also support building release media on macOS for ease of local testing. That’s only (mini-)memstick/bootonly/disc1/ftp though, no dvd1 (due to pkg), and no VM images.

Are you happy with the added guards?

In D47407#1081914, @bz wrote:

Yeah, we do all our CheriBSD CI builds on Linux hosts and also support building release media on macOS for ease of local testing. That’s only (mini-)memstick/bootonly/disc1/ftp though, no dvd1 (due to pkg), and no VM images.

Are you happy with the added guards?

It deals with the non-FreeBSD problem, but it still assumes that there's a package repo available with an installable wifi-firmware-kmod-release in it. The config file is also release-dvd.conf, which you're making no longer true.

Also, what about bootonly? Surely that's the most important case for having working networking (and dvd the least given it has more distribution sets and some packages)?

What about NOPKG? Should it not be extended to include *installing* third-party packages to the release media, not just *distributing*?

I would love feedback from releng on this at this point as BETA2 is approaching soon...

Do we still want this (and the accompanying bsdinstall change) in 14.2-R or not? As otherwise I'll have to add rtw89 firmware at least there.

Unless releng has any objections I'll commit this around Tue 19.11. afternoon UTC.
I would still hope releng to comment on it before if not at least by accepting or requesting changes.

I understand that mixing this in while the other dust settles was not a good idea so I kept waiting a bit longer...

@jrtc27 Any objections to this patch as it is now? I'd like to get it into the tree ASAP so we can have wifi on 14.2-RC1 ISOs.

I'd prefer some of the other cleanups I suggested to have been done as I see no downside to doing things more properly (beyond taking the time to test, but there's been plenty of that in the past 2 weeks), but I'm not going to block the review on those. There is one other point I do have to make though that I really do object to being here.