Initramfs fixes

[rlaager]

Description

mountpoint

For filesystems that are children of the rootfs, when mountpoint=none or mountpoint=legacy, the initrafms script would assume a mountpoint based on the dataset path. Given that the rootfs should have mountpoint=/ and mountpoint inheritance is is the default behavior of ZFS, this behavior seems unnecessary. In any event, it turns mountpoint=none into a no-op. That removes this option from the administrator, and if someone uses it, it does not work as expected. Worse yet, if the mountpoint directory does not exist (which is the typical case for mountpoint=none), the mounting and thus the boot process will fail. For the case of mountpoint=legacy, the assumed mountpoint may not be the correct value set in /etc/fstab.

This change makes the initramfs script not mount the filesystem in either case. For mountpoint=none, this means we are correctly honoring the setting. For mountpoint=legacy, there are two scenarios: If canmount=on, the filesystem will be mounted by the normal mechanisms later in the boot process. If canmount=noauto, the filesystem will not be mounted at all, unless the administrator has done something special. If they're not doing something special and they want it mounted by the initramfs, they can simply not set mountpoint=legacy.

canmount

The initramfs script was not honoring canmount=off. With this change, it does. If the administrator has asked that a filesystem not be mounted, that should be honored.

As an exception, the initramfs script ignores canmount=off on the rootfs. The rootfs should not have canmount=off set either. However, mounting it anyway seems harmless because it is being asked for explicitly. The point of this exception is to avoid the risk of breaking existing systems, just in case someone has canmount=off set on their rootfs.

The initramfs still mounts filesystems with canmount=noauto. This is necessary because it is typical to set that on the rootfs so that it can be cloned. Without canmount=noauto, the clones' duplicate mountpoints would conflict.

Motivation and Context

These changes fix:
zfsonlinux/pkg-zfs#221

How Has This Been Tested?

I tested on Ubuntu 17.10 (artful).

zfs create -o canmount=noauto rpool/ROOT/ubuntu/test1
zfs create -o canmount=noauto rpool/ROOT/ubuntu/test2
zfs create -o canmount=noauto rpool/ROOT/ubuntu/test3
zfs create -o canmount=noauto rpool/ROOT/ubuntu/test4
zfs create -o canmount=off rpool/ROOT/ubuntu/test5
zfs set mountpoint=none rpool/ROOT/ubuntu/test2
zfs set mountpoint=/TEST3 rpool/ROOT/ubuntu/test3

Before the change, mounting and thus booting fails on test2 and test5. Creating the directories fixes the boot. All 5 are mounted. After the change, even without creating the directories, the boot succeeds. Only 1, 3, and 4 are mounted.

The mountpoint=legacy tests:

zfs create -o canmount=noauto rpool/ROOT/ubuntu/test6
zfs create -o canmount=noauto rpool/ROOT/ubuntu/test7
zfs set mountpoint=legacy rpool/ROOT/ubuntu/test6
zfs set mountpoint=legacy rpool/ROOT/ubuntu/test7
echo rpool/ROOT/ubuntu/test7 /test7 zfs defaults 0 0 >> /etc/fstab
mkdir /test7

Before the change, test6 fails to mount (for lack of a directory), and test7 is mounted. I added some logging to the initramfs, and test7 was mounted by the initramfs. After the change, there was no failure, test6 was not mounted (as expected), and test7 was mounted. The same logging indicated that test7 was not mounted by the initramfs, meaning it was mounted later in the boot process (as expected).

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (a change to man pages or other documentation)

I have marked this as a breaking change because it does change the existing behavior. I think I have minimized the potential for breakage as much as possible while fixing the underlying issue.

Checklist:

• My code follows the ZFS on Linux code style requirements.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• All commit messages are properly formatted and contain Signed-off-by.
• Change has been approved by a ZFS on Linux member.

[codecov]

Codecov Report

Merging #6897 into master will increase coverage by 0.13%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #6897      +/-   ##
==========================================
+ Coverage    75.1%   75.23%   +0.13%     
==========================================
  Files         298      298              
  Lines       95270    95270              
==========================================
+ Hits        71555    71680     +125     
+ Misses      23715    23590     -125

Flag	Coverage Δ
#kernel	74.74% <ø> (+0.23%)	⬆️
#user	67.38% <ø> (+0.14%)	⬆️

Impacted Files	Coverage Δ
module/zfs/zfs_rlock.c	90.16% <0%> (-5.74%)	⬇️
module/zfs/arc.c	86.83% <0%> (-1.57%)	⬇️
module/zfs/spa_stats.c	68.5% <0%> (-1.25%)	⬇️
cmd/zed/agents/zfs_diagnosis.c	73.02% <0%> (-1.18%)	⬇️
module/zfs/dnode_sync.c	91.53% <0%> (-0.55%)	⬇️
module/zfs/zap_leaf.c	84.9% <0%> (-0.48%)	⬇️
module/zfs/zil.c	92.69% <0%> (-0.43%)	⬇️
module/zfs/vdev_disk.c	70.81% <0%> (-0.36%)	⬇️
module/zfs/dmu_objset.c	90.16% <0%> (-0.35%)	⬇️
module/zfs/zap.c	65.47% <0%> (-0.35%)	⬇️
... and 35 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 94183a9...029214c. Read the comment docs.