works for me, just one nit above

Note I would disagree that make isn't needed in a minimal install, I use make and makefiles for all sorts of use-cases that have nothing to do with building src/

Looks reasonable

In D51447#1175667, @imp wrote:

I do like this better...

But what we're trying to avoid is setting currdir to tftp://1.2.3.4/mumble and having lots of tftp traffic go as we try to open it a bunch of times to see if each of the filesystems can cope... Can you confirm that's the top of this rabbit hole?

Rework to avoid opening dirs via TFTP while not breaking diskless
boot with nfs.

I can't approved, but looks sane - I assume it works ;-)

Move install.c change to D51446
Move misc.c change to D51447

Mention pkgfs_fsops in libsa.3

Add flag to fs_ops for skipping devopen

This review has been broken up and the open review is D51187

Make the code in open() neater

Alternative means of skipping devopen for pkgfs

Rebase after commit DEBUG_PRINTF

In D51269#1173596, @imp wrote:

This looks good.

It would be nice if there was a loader command to set the debug level, but that's a separate thing and isn't universally useful since a lot of this code runs before the OK prompt.

In D51094#1172979, @imp wrote:

I had a note to follow up on this in a "little while"
Where are we? Is this review done? Or have I overlooked some sub-review that split off?

Tweak the #ifdef in stand.h

In D51187#1170063, @imp wrote:

Can you do the debug level stuff first so we get that out of the way? There's also a lot of different fixes bundled together which makes me super nervous for future bisecting...

Tweak comment as suggested

Add a comment about why dev_cleanup needs to be called before bi_load

In D51186#1169361, @imp wrote:

In D51186#1169123, @sjg wrote:

In D51186#1168883, @imp wrote:

So what happens when bi_load() returns an error? Most devices don't have the 'dv_cleanup()' routines, so it doesn't matter that much... But wouldn't this preclude network working if it does cleanup? I think it might be OK.

It looks like the only case for which bi_load() returns an error - vs panic is failure to find rootdev which seems the sort of thing that could have been done earlier?
If that were extracted to some earlier call, then bi_load() looks like a one way trip to boot or panic

It may be a redunant check. But I'm not sure that bi_load is the right place to do exit boot services since I don't want its callers to know that only panics are possible because that changes over time.

But I think your analysis is flawed, since we have

if (retry == 0) {
        BS->FreePages(addr, pages);
        printf("ExitBootServices error %lu\n", EFI_ERROR_CODE(status));
        return (EINVAL);
}

late in the bi_load.

In D51186#1168883, @imp wrote:

So what happens when bi_load() returns an error? Most devices don't have the 'dv_cleanup()' routines, so it doesn't matter that much... But wouldn't this preclude network working if it does cleanup? I think it might be OK.

In D51186#1168883, @imp wrote:

So what happens when bi_load() returns an error? Most devices don't have the 'dv_cleanup()' routines, so it doesn't matter that much... But wouldn't this preclude network working if it does cleanup? I think it might be OK.

In D51094#1168500, @imp wrote:

Usually many of the smaller changes will go in quickly if there are any others the prove to need more discussion. So that can also narrow the focus quickly. Thanks.

In D51094#1168160, @imp wrote:

This mixes a lot of different types of changes all in one big ball that's hard to review.
Any chance you could break them down to approximately what the paragraphs of the description say? At the very least, the debug stuff should be a separate commit, but really there's about 10 commits hiding in this one review by my quick count. It makes bisecting quite a bit simpler to do separate commits.

Make the same change for arm, i386 and riscv

Update comment at start of host.test.mk

Give this a chance of being useful to non-DIRDEPS_BUILD

In D50459#1151661, @emaste wrote:

Is there a reasonable way to have make use bash as the default shell on Linux?

In D50459#1151603, @jrtc27 wrote:

What shell are we using here, the default system sh? dash doesn't support pipefail, so I'm concerned this will break on Linux.

tweak

Add host.test.mk to FILES

Fix typo in log message

Fix typo in log message

A loader.efi with this change does not crash - but there is a long delay before the libsecureboot self tests output:

There are a number of bootinfo's that also getenv("rootdev")

main also needs to double check for empty rootdev.

In D50334#1148471, @imp wrote:

I don't object, but I'd like more details about how this comes to pass

Looks good

In D49193#1121924, @cperciva wrote:

In D49193#1121912, @sjg wrote:

FYI I run freebsd-update cron on 1st of each month, this morning I noted that my home machine did not get the updates that the ones at work got.
I ran freebsd-update fetch which failed claiming there was no support for FreeBSD 14.1 amd64, using fetch -4 fixes this.

I don't know why, but I find from my home network that IPv6 is not as reliable as IPv4.

That sounds like a broken mirror -- they should all have amd64 bits for 14.1. Can you reproduce and tell me which mirror you hit?

FYI I run freebsd-update cron on 1st of each month, this morning I noted that my home machine did not get the updates that the ones at work got.
I ran freebsd-update fetch which failed claiming there was no support for FreeBSD 14.1 amd64, using fetch -4 fixes this.

Ensure scripts are installed executable

Use newlog.sh out of contrib/bmake/mk

Looks ok - fix the items noted by maxim