Anyone know why /etc/rc.d/lockd REQUIRES nfsd?

[Rick Macklem]

Hi,

PR#254282 reports a problem where nullfs mounts cannot be
exported via mountd for FreeBSD 13.0.

The problem seems to be that, to do the nullfs mounts in
/etc/fstab, they require the "late" mount option, so that the
underlying filesystem is mounted (ZFS for the PR).

Adding "mountlate" to the REQUIRE list in /etc/rc.d/mountd
fixes the problem, but that results in a dependency cycle
because /etc/rc.d/lockd specifies:
# REQUIRE: nfsd
# BEFORE: DAEMON
--> which forces mountd to preceed DAEMON.

I think I know why lockd specifies:
# BEFORE: DAEMON
--> I suspect that some daemon requires file locking and that
   requires lockd to be running, for an NFS mounted root fs.

However, I cannot think of any reason that nfsd must be running
before lockd is started. The "REQUIRE: nfsd" seems to have been
inherited from NetBSD when first imported to FreeBSD about 20
years ago.

So, can anyone see why lockd might need nfsd running first?
(Without "# REQUIRE: nfsd" in lockd and statd, "# REQUIRE: mountlate"
 can be added to /etc/rc.d/mountd without creating a dependency cycle
and seems to fix the problem in the PR during limited testing.)


rick

Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main

[Ed Maste]

On Sat, 20 Nov 2021 at 20:00, Ed Maste  wrote:
>
> On Thu, 18 Nov 2021 at 13:09, Li-Wen Hsu  wrote:
> >
> > The mkimg ones are a bit tricky, it seems the output is changed in
> > each run. We may need a way to generate reproducible results..
>
> Hopefully fixed by 036af1053acd6cae68c5fb6bed30508f2e40be13.

The mkimg failures are indeed fixed by the above commit - it was just
a latent bug in mkimg.

I've opened PR 259968 as a tracking bug for outstanding issues found
as a result of enabling ASLR by default, and submitted a PR for each
of the three outstanding issues.

Re: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?)

[Mark Millard via freebsd-current]

On 2021-Nov-20, at 11:54, Mark Millard  wrote:

> On 2021-Nov-19, at 22:20, Mark Millard  wrote:
> 
>> On 2021-Nov-18, at 12:15, Mark Millard  wrote:
>> 
>>> On 2021-Nov-17, at 11:17, Mark Millard  wrote:
>>> 
 On 2021-Nov-15, at 15:43, Mark Millard  wrote:
 
> On 2021-Nov-15, at 13:13, Mark Millard  wrote:
> 
>> On 2021-Nov-15, at 12:51, Mark Millard  wrote:
>> 
>>> On 2021-Nov-15, at 11:31, Mark Millard  wrote:
>>> 
 I updated from (shown a system that I've not updated yet):
 
 # uname -apKU
 FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 
 main-n250455-890cae197737-dirty: Thu Nov  4 13:43:17 PDT 2021 
 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
   arm64 aarch64 
 1400040 1400040
 
 to:
 
 # uname -apKU
 FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 
 main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 
 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
   arm64 aarch64 1400042 1400042
 
 and then updated /usr/ports/ and started poudriere-devel based builds 
 of
 the ports I's set up to use. However my last round of port builds from
 a general update of /usr/ports/ were on 2021-10-23 before either of the
 above.
 
 I've had at least two files that seem to be corrupted, where a later 
 part
 of the build hits problematical file(s) from earlier build activity. 
 For
 example:
 
 /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null character 
 ignored [-Wnull-character]
  
 ^
 /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null character 
 ignored [-Wnull-character]
 
 ^
 /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null character 
 ignored [-Wnull-character]
  
 ^   
 /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null character 
 ignored [-Wnull-character]
 
 ^
 . . .
 
 Removing the xorgproto-2021.4 package and rebuilding via
 poudiere-devel did not get a failure of any ports dependent
 on it.
 
 This was from a use of:
 
 # poudriere jail -j13_0R-CA7 -i
 Jail name: 13_0R-CA7
 Jail version:  13.0-RELEASE-p5
 Jail arch: arm.armv7
 Jail method:   null
 Jail mount:/usr/obj/DESTDIRs/13_0R-CA7-poud
 Jail fs:   
 Jail updated:  2021-11-04 01:48:49
 Jail pkgbase:  disabled
 
 but another not-investigated example was from:
 
 # poudriere jail -j13_0R-CA72 -i
 Jail name: 13_0R-CA72
 Jail version:  13.0-RELEASE-p5
 Jail arch: arm64.aarch64
 Jail method:   null
 Jail mount:/usr/obj/DESTDIRs/13_0R-CA72-poud
 Jail fs:   
 Jail updated:  2021-11-04 01:48:01
 Jail pkgbase:  disabled
 
 (so no 32-bit COMPAT involved). The apparent corruption
 was in a different port (autoconfig, noticed by the
 build of automake failing via config reporting
 /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f
 being rejected).
 
 /usr/obj/DESTDIRs/13_0R-CA7-poud/ and
 /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the
 system versions.
 
 The media is an Optane 960 in the PCIe slot of a HoneyComb
 (16 Cortex-A72's). The context is a root on ZFS one, ZFS
 used in order to have bectl, not redundancy.
 
 The ThreadRipper 1950X (so amd64) port builds did not give
 evidence of such problems based on the updated system. (Also
 Optane media in a PCIe slot, also root on ZFS.) But the
 errors seem rare enough to not be able to conclude much.
>>> 
>>> For aarch64 targeting aarch64 there was also this
>>> explicit corruption notice during the poudriere(-devel)
>>> bulk build:
>>> 
>>> . . .
>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: .
>>> pkg-static: Fail to extract 
>>> /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma 
>>> library error: Corrupted input data
>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done
>>> 
>>> Failed to install the following 1 package(s): 
>>> /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg
>>> *** Error code 1
>>> Stop.
>>> make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e
>>> 
>>> I'm not yet to the point of