Bug 251121 - rc.d/zfsbe can't properly mount child datasets
Summary: rc.d/zfsbe can't properly mount child datasets
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.2-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-rc (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-14 01:19 UTC by Kevin P. Neal
Modified: 2020-11-15 19:12 UTC (History)
0 users

See Also:


Attachments
Corrected version of the script. (1.71 KB, application/x-shellscript)
2020-11-14 01:19 UTC, Kevin P. Neal
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin P. Neal 2020-11-14 01:19:39 UTC
Created attachment 219663 [details]
Corrected version of the script.

The /etc/rc.d/zfsbe script confuses ZFS dataset names with filesystem paths. As a result it doesn't recognize datasets that are children of the dataset that is mounted at "/". Instead it mounts them at the location they would be at if a different boot environment was used.

This is the broken set of mounts (with other, not relevant mounts omitted):

Filesystem                                  Size    Used   Avail Capacity  Mounted on
gs1p/ROOT/FreeBSD_12.2-RELEASE              459G    391M    459G     0%    /
gs1p/ROOT/FreeBSD_12.2-RELEASE/usr          464G    5.5G    459G     1%    /ROOT/FreeBSD_12.2-RELEASE/usr
gs1p/ROOT/FreeBSD_12.2-RELEASE/usr/local    466G    7.8G    459G     2%    /ROOT/FreeBSD_12.2-RELEASE/usr/local
gs1p/ROOT/FreeBSD_12.2-RELEASE/usr/src      460G    1.2G    459G     0%    /ROOT/FreeBSD_12.2-RELEASE/usr/src

The result is a trip to the datacenter to fix the now broken upgrade.
Comment 1 Andriy Gapon freebsd_committer 2020-11-14 22:07:23 UTC
I want to clarify that the script does not confuse dataset names and mount point names.  The script assumes that for filesystems used as boot environments a mountpoint is always a default one (i.e., $mountpoint == /$ds_name).

I would be helpful if you provided output of zfs list -rH -o mountpoint,name,canmount,mounted -s mountpoint -t filesystem gs1p/ROOT
Comment 2 Kevin P. Neal 2020-11-15 05:03:00 UTC
/ROOT	gs1p/ROOT	on	yes
/ROOT/12.2	gs1p/ROOT/12.2	on	yes
/ROOT/FreeBSD_11.3-RELEASE-p2	gs1p/ROOT/FreeBSD_11.3-RELEASE-p2	noauto	yes
/ROOT/FreeBSD_11.3-RELEASE-p2/usr	gs1p/ROOT/FreeBSD_11.3-RELEASE-p2/usr	noauto	yes
/ROOT/FreeBSD_11.3-RELEASE-p2/usr/local	gs1p/ROOT/FreeBSD_11.3-RELEASE-p2/usr/local	noauto	yes
/ROOT/FreeBSD_11.3-RELEASE-p2/usr/src	gs1p/ROOT/FreeBSD_11.3-RELEASE-p2/usr/src	noauto	yes
/ROOT/FreeBSD_12.2-RELEASE	gs1p/ROOT/FreeBSD_12.2-RELEASE	on	yes
/ROOT/FreeBSD_12.2-RELEASE/usr	gs1p/ROOT/FreeBSD_12.2-RELEASE/usr	on	yes
/ROOT/FreeBSD_12.2-RELEASE/usr/local	gs1p/ROOT/FreeBSD_12.2-RELEASE/usr/local	noauto	yes
/ROOT/FreeBSD_12.2-RELEASE/usr/src	gs1p/ROOT/FreeBSD_12.2-RELEASE/usr/src	on	yes

In my version of the script it compares mountpoints with the boot environment's non-boot mountpoint. Which I believe will accomplish the intended purpose of only matching mountpoints that are children of the boot environment. This in turn should work in both the filesystem "/ROOT" case and the "/<poolname>/ROOT" case.
Comment 3 Andriy Gapon freebsd_committer 2020-11-15 11:52:26 UTC
I don't object against your change.

It's just that you have an unusual / non-standard layout.
Comment 4 Kevin P. Neal 2020-11-15 19:12:00 UTC
It's a server that's been upgraded since 2011. I don't think we had a standard back then, and if we did I didn't know it. I don't recall seeing any documentation on what the filesystem layout was supposed to be, either. So I'm hoping our base system will be more resilient to setups that aren't quite the standard. 

Certainly having a boot fail isn't the best way to find out my setup isn't what one of FreeBSD's scripts expects when tools like FreeBSD's bectl have no complaints.