This does indeed fix the problem with building 12 on a 10-stable system, can we please get it committed asap?

UEFI testing completed; this code now passes all the tests generated by tools/boot/rootgen.sh, and has also been tested on armv7 systems with ubldr. I think it is ready to commit.

In D16237#344541, @manu wrote:

In D16237#344539, @ian wrote:

Does this mean that cubox-humingboard images will no longer be available for download?

Yeah.
It is still popular enough so we leave it ?

Does this mean that cubox-humingboard images will no longer be available for download?

By popular demand (on irc), support a special MAN_ARCH value of "all" to install all available arches. Also, update the wording of the make.conf entry to use MACHINE and MACHINE_ARCH, to match the terms used in man(1).

In D14646#324502, @trasz wrote:

My only worry is this: what if we had a zpool with devices that require different time to go online, and we mount rootfs while one of them is still offline? Wouldn't this result in a degraded root pool?

In D15743#341739, @eric_metricspace.net wrote:

I get compile errors trying to build the latest

Update the diff to fix a couple bugs.

I am abandoning this change in favor of D16050 which is a more complete solution.

BTW, here's some information that took a while to figure out, so I want to capture it for future reference, somewhere other than a .txt file I'm sure to lose over time.

Okay, after some experimenting, here's what I've learned today...

I think it's all moot, and we simply don't support dropping priveleges and running in a chroot at all. Part of the reason for that is that ntpd itself inappropriately binds those two concepts together. It will not chroot unless it can also drop root privs afterwards, and it will not drop root privs without linux, solaris, or netbsd-clockctl mechanisms to set the time. IMO, that's bogus, I think ntpd could chroot to limit its access to the filesystem without dropping root privs, but that's not how it's coded now.

Well, it turns out the clockctl driver isn't an elegant solution whereby ntpd uses ioctl() calls to manipulate the clock based on filesytem permissions. Instead it's closer to a horrible hack where the clock setting functions in netbsd's libc react to EPERM errors by opening the clockctl device and doing it that way. I want no part of that. There are even netbsd email threads about how fragile the scheme is because of O_CLOEXEC and the order ntpd does things. And what it enables is basically a semi-solution, because once the daemon drops privs it's unable to bind to priveleged sockets, so if an interface goes down/up or you switch to a different wifi network or something, ntpd stops working until you manually restart it.

The symlinks the script wants to set up link the inside-chroot files to the corresponding outside-chroot locations. I guess so you can do "vi /etc/ntp.conf" and be editing the real inside-chroot config file. It looks like the code we've got now is a straight import from netbsd in 2001 and untouched since then. Their code has been revised since then to do more setup of the chroot.

In D15987#338950, @cy wrote:

What about the corresponding statements in ntp.conf? e.g.

leapfile "/var/db/ntpd.leap-seconds.list"
logfile "/var/log/ntpd"
keys "/var/db/ntp.keys"

Wow, that named-state stuff was even easier than I thought, and it makes a much cleaner solution than the various hacks we considered.

Reworked to only try to make symlinks if there isn't already a file/dir/link at the target location.