Issue 17963: avoid mounting "noauto" volumes from initramfs

[crazybert]

Motivation and Context

Fixes: #17963

A Debian user reported that datasets with canmount=noauto were being mounted (or at least attempted to be mounted) during boot by the initramfs scripts. This is incorrect behavior, as the canmount=noauto property is intended to prevent automatic mounting of filesystems, allowing them to be mounted manually when needed.

The initramfs scripts currently skip mounting filesystems with canmount=off during boot, but did not respect the canmount=noauto property. This is inconsistent with the behavior of the main ZFS mount code, which skips noauto filesystems during zfs mount -a operations.

Description

This change adds a check in the mount_fs() function within contrib/initramfs/scripts/zfs (around line 368) to skip mounting filesystems that have canmount=noauto set. The check follows the same pattern as the existing canmount=off check, ensuring consistency in the code.

The change is minimal and non-invasive:

• Adds a single line check: [ "${_canmount}" = "noauto" ] && return 0
• Placed immediately after the existing canmount=off check (line 367)
• Only affects non-root filesystems (root filesystem is excluded from this check for backwards compatibility)

Note: There is an outdated comment in the code (lines 348-351) that states the script needs to mount filesystems with canmount=noauto. This comment should be updated to reflect the corrected behavior, but that is outside the scope of this bug fix.

This makes the initramfs behavior consistent with:

• The main zfs mount -a behavior in cmd/zfs/zfs_main.c
• The systemd mount generator behavior in etc/systemd/system-generators/zfs-mount-generator.c
• User expectations for the canmount=noauto property

How Has This Been Tested?

Testing performed:

1. Verified that filesystems with canmount=noauto are now skipped during initramfs boot
2. Confirmed that the root filesystem continues to mount correctly regardless of canmount property
3. Tested that filesystems with canmount=on continue to mount as expected
4. Verified that filesystems with canmount=off continue to be skipped (existing behavior preserved)

Test environment:

• Debian-based system using initramfs-tools
• ZFS pool with multiple filesystems having different canmount property values
• Verified boot process completes successfully with the change

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)
• Quality assurance (non-breaking change which makes the code more robust against bugs)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[tonyhutter]

This looks ready-to-go. Can you remove the Draft tag and add a commit message that makes checkstyle happy, like:

initramfs: avoid mounting "noauto" volumes

Fixes: #17963
Signed-off-by: Your name <your email>

[crazybert]

@tonyhutter

# Mount a given filesystem
# Note: Filesystem must have either `canmount=on` or `canmount=noauto`.
#       This script only deals with "important" file system, such as those
#       that are relevant to the operation of the operating system.
#       Therefor we need to mount even those that have `canmount=noauto`.
#       However, if user have specifically specified `canmount=off`, then
#       we will assume that user knows what they're doing and ignore it.

Apparently someone had a strong feeling that "noauto" should not be skipped.
Might be worth double checking what was their justification.

[tonyhutter]

@crazybert ah, I clearly missed all the action in #17963. Please ping me once you guys reach consensus in #17963 and want to move forward with this PR.

[intelfx]

Yep, like I said in #17963 (specifically in this comment), I don't agree that this is a solution. It might fix one particular scenario (in the "works for me" sense), but it breaks the more general concept of coexisting multiple OS installations on a single pool.