But doesn't KMountPoint::currentMountPoints() use mtab?

Yes it does, and that's where I get the "zfs" information from.

But the test that fails is in the following method, which uses possibleMountPoints() i.e. fstab.

In D14707#305749, @dfaure wrote:

Yes it does, and that's where I get the "zfs" information from.

But the test that fails is in the following method, which uses possibleMountPoints() i.e. fstab.

Yes, I see. But this is in no way tied to the filesystem type. IMHO the test should check if there is an entry for the rootfs and do the tests, and skip it with a warning otherwise.

OK maybe I misunderstood the comment "Welcome to the wondeful world of / on zfs with boot-environments :)."

If it's not related to zfs then two options:

1. allowing for no root possible mountpoint, as you suggest, but I don't like it, it could hide a major regression in KMountPoint one day.
2. somehow finding that we're in the zpool/bootfs/whatever case where this can happen (so the test still runs in the "normal case").

Any idea how to do the latter?
Is this a FreeBSD-specific thing? We could allow "no root" only on FreeBSD, if nothing else...

In D14707#305773, @dfaure wrote:

OK maybe I misunderstood the comment "Welcome to the wondeful world of / on zfs with boot-environments :)."

If it's not related to zfs then two options:

1. allowing for no root possible mountpoint, as you suggest, but I don't like it, it could hide a major regression in KMountPoint one day.
2. somehow finding that we're in the zpool/bootfs/whatever case where this can happen (so the test still runs in the "normal case").
   
   Any idea how to do the latter? Is this a FreeBSD-specific thing? We could allow "no root" only on FreeBSD, if nothing else...

The question is what this check is supposed to assert. In general, there is no guarantee how the fstab looks like, it can be completely empty. You only need a root fs, and that can be given e.g. using kernel parameters. Think of e.g. Live images, which is copied to an optical medium (/dev/srN on Linux) or a USB stick (/dev/sdX).

Probably the code should check against a well known string/file instead of the fstab of the running system, i.e. pass something else than /etc/fstab to setmntent.

Oh, and maybe we should get rid of anything #if defined(_OS_SOLARIS_), defined(_AIX) or defined(WIN32_WCE) ...

The check is trying to verify that possibleMountPoints() works, by picking a mount point that we know has to exist, the root mount point. Anything else is hard to rely on, in a unittest ;)
At least that was the logic in the old days, before all this magic that circumvents having entries in fstab...

I don't think Live USB sticks are an issue (nobody is going to run unittests on them), but clearly containers are a valid use case which shouldn't break unittests.

I'm not sure how to fix this without just removing any automated verification from this test method... :(

That is strange - as our FreeBSD Builders definitely have an /etc/fstab file:

root@FreeBSDBuilderIota:~ # cat /etc/fstab 
# Device                Mountpoint      FStype  Options         Dump    Pass#
/dev/vtbd0p2            none    swap    sw              0       0

I've checked and the file is definitely world-readable - and is the same on all three builders.

Yep, that's exactly what I see in the output from kmountpointtest. One entry for swap, but no entry for "/".
So any file on the filesystem doesn't look like it comes from a partition that was mounted at boot time.

In other words it looks like everything is from a USB key or CD -- which means no monitoring for changes, since that would prevent ejecting the USB key or CD. Therefore all tests that test for the monitoring features failed.

Now I make it skip the swap entry, so there's nothing left ;)