Fix typo and update man page

In D46717#1387434, @des wrote:

What is the point of this? cmp -s will do the same job faster.

In D60620#1390003, @fuz wrote:

I would personally prefer if it said “supported until” instead of “EOL,” but I think this way is ok, too.

Could these macros also be used for the “Supported FreeBSD releases” section so that there is a single source of truth?

Thank you for coding this up so quickly.

Add -w to periodic.conf instead

In D46716#1385902, @michaelo wrote:

why not change security_status_diff_flags directly?

In D46716#1385902, @michaelo wrote:

In D46716#1385899, @allanjude wrote:

In D46716#1385799, @michaelo wrote:

The code has changed meanwhile. Please rebase.

Are you seeing something out-of-date? I did rebase the diff when I updated it.

My bad, I misread the review. All is fine!

There is only one hit:

osipovmi@deblndw011x:~/var/Projekte/freebsd/src (main =)
$ grep -r security_status_diff_flags .
./share/man/man5/periodic.conf.5:.It Va security_status_diff_flags
./usr.sbin/periodic/etc/security/security.functions:    diff ${security_status_diff_flags} ${LOG}/${label}.today \
./usr.sbin/periodic/periodic.conf:security_status_diff_flags="-b -U 0"                  # flags for diff output

why not change security_status_diff_flags directly?

In D46716#1385799, @michaelo wrote:

The code has changed meanwhile. Please rebase.

Update with feedback

Address markj's feedback

Reviewed by: allanjude

Need to make sure this doesn't cause problems in bsdinstall, I think the only other place where we might need to explicitly load the module.

In D57657#1321988, @kevans wrote:

Do we need to have rc.d/zfs kldload zfs as-needed in case someone's implicitly relying on this and running ZFS strictly for data pools rather than root? I think that would make this a non-event for 98%+ of our users if it wasn't already.

In D57657#1323400, @markmi_dsl-only.net wrote:

It was determined that zpool status and zfs list are not the commands used in the original context. Instead:

zpool upgrade -v
and:
zfs upgrade -v

An upstream change has been proposed:

https://github.com/openzfs/zfs/pull/18694/changes/3c971d9b219ac135767802c5c014fdd687dacf5b

Because, unlike FreeBSD, the Linux zpool upgrade -v does depends on some kernel module results ( /sys/module/zfs/features.pool ), that part of the proposed change is FreeBSD OS specific and Linux would still load its kernel module.

Linux does not use kernel module results for zfs upgrade -v and, so, that part is more general.

Would it maybe make more sense to keep the list, but install the services they enabled but have not installed?

In D40816#1164504, @jhb wrote:

In D40816#1155652, @allanjude wrote:

I am not sure how the import of OpenZFS would have changed any of this, but, for MBR we hide the 256kb /boot/zfsboot file in the slack space between the end of the ZFS uberblocks, and the start of the data area (4 MiB offset from the start of the partition).

The first 1kb, is installed in the slack at the start of the partition.

So basically:

1. mbr reads first 1kb of partition
2. first 512b of zfsboot knows where to find the rest of zfsboot
3. the rest of zfsboot is installed at an offset of 1024x512b where the first part of zfsboot knows where to find it.

1. mbr actually reads the first 512b of the partition

However, this change seems to not trust ZFS to do what you claim above. Rather than letting ZFS start at the start of the MBR slice, it is creating an explicit gap so that s1a doesn't start at the the start of a slice but leaves a 2048 sector (1MB) "hole" (between the start of the MBR slice, and the first BSD label partition ("s1a"). It then places the rest of the zfsboot payload at an offset (1024 sectors in) to the rest of that "hole" before the actual ZFS partition starts. So, clearly it seems like OpenZFS is not preserving the same layout for some reason and this change is trying to avoid interacting with ZFS entirely. If we really want ZFS + MBR to work this way, we should just change zfsboot to stop assuming the 1024 offset so we can write zfsboot contiguously to the start of the MBR slice. Then we could at least leave a smaller "hole" prior to "s1a". I'm also not sure how wise it is to leave unallocated space in the BSD label at the start of the slice. If you happen to fat finger a gpart command in the future, you could end up adding a new partition in the "hole" and end up overwriting the zfsboot contents. :(

Given all that, I wonder if we shouldn't just punt and say that ZFS + MBR isn't supported anymore. It hasn't worked in years and is pretty fragile.

I wonder if the -q ends up hiding too much useful context for the error, but better to avoid the console spam in the happy case.

Very useful functionality

The description says 'patched' (if an tagged incoming frame does not patch the port's pvid) where I think you meant 'matched'

I am not sure how the import of OpenZFS would have changed any of this, but, for MBR we hide the 256kb /boot/zfsboot file in the slack space between the end of the ZFS uberblocks, and the start of the data area (4 MiB offset from the start of the partition).

I didn't realize we had added -l to /bin/sh.

Looks good

Otherwise looks good to me.

This seems fine, is there a reason it is not moving forward?

silly GNU getopt

In D48874#1115208, @ronald_klop.ws wrote:

In D48874#1114805, @dsl wrote:

Could you add a short test plan to follow?

I hope the test plan is as expected. Otherwise please let me know.

In D10320#1111754, @glebius wrote:

https://reviews.freebsd.org/D48729