Dear Maintainer,

The current zfs initramfs script (/usr/share/initramfs-tools/scripts/zfs)
skips filesystems with canmount=off but not filesystems with
canmount=noauto.

This is especially annoying with encrypted filesystems on headless systems.

A simple extra check around line 342 should fix this. Or perhaps it
could check for canmount=on and skip mounting for all other values.

Steps to reproduce:

1) zfs create -o canmount=noauto pool/foo
2) reboot
3) error during boot that /root//foo can't be mounted because the directory
   does not exist.
4) mkdir /foo
5) reboot
6) notice how /foo is mounted even though it shouldn't be

Many thanks for the hard work!

The problem have been identified as a commit five (!) years ago
that removed Bashisms.

Bashisms are obviously wrong, so the commit was correct in that
way, but it caused an unforeseen problem with making variables
global, where they needed to be local.

As in, the variable `${fs}` was used in two loops in the main function
to track the file systems to mount, but was overwritten by two support
functions that also used it as a parameter.

See https://github.com/openzfs/zfs/issues/17963#issuecomment-3596171871
and the solution is to rename those function and make their use
of the `${fs}` variable unique. As in, renaming it in the functions.

A patch have been proposed, see https://github.com/FransUrbo/zfs/commit/8b79a6e231d2dd88e360d1ad114b8fcac6029be2,
which are included in this PR (which also does some code
cleanup):

https://github.com/openzfs/zfs/pull/18000

I think I may have spoken too soon.

After spending almost a day setting up Trixie to have a ZFS root and
then almost two days trying to reproduce the problem, I have failed to
do so!

The only difference between Trixie and Testing (in regards to the initrd
script) is this commit, which is irrelevant:

https://github.com/openzfs/zfs/commit/f8bc01c79f377f6c777af98c0107bdf778d18d73


Wessel, I need you to add the `zfsdebug=yes` on the kernel command line
and try to see where this is happening. Is it indeed in the initrd or once the
zfs mount happens??

If you could give me the output from the following commands, I’d also appreciate
it. I have no idea what I’m looking at, but at least then I can start to compare
it with what I have..

	* zpool get bootfs <pool>
	* zfs list -o name,canmount,encryption,mounted,mountpoint


The important thing I need to know, is it *really* the initrd that is at fault
here??! I’m not so sure it is..

But if you run it with `zfsdebug=yes`, it will give you a list of filesystems
mounted at the very end, then ask you if you want to drop into a shell,
reboot or continue..

Hi Turbo,

Thank you so much for looking into this. Apologies for no replying sooner,
apparently I do not get e-mail from the debian bug tracker (no, it's not in
my spambox either). Perhaps best to Cc me explicitly if you need a quick
reaction.

Not to be outdone in terms of expended effort, I've put up a
more-or-less self-contained installation script at
https://www.fruit.je/y/zfs-initramfs-1110397/install which should have
everything you need to reproduce the issue. I've also captured the
output (see the links below) so that hopefully you don't have to. ;)

But even if you don't actually run it, you can at least see the exact
steps that lead to the issue.
https://www.fruit.je/y/zfs-initramfs-1110397/reboot-log

You'll find this output at the bottom of
https://www.fruit.je/y/zfs-initramfs-1110397/install-log

Please note that the bootfs property is not used by grub.
https://www.fruit.je/y/zfs-initramfs-1110397/patch resolves the issue
completely (it's basically a more explicit rendering of what I wrote in
the original report).

Kind regards,

[Wessel Dankers]

No surprise there.  Only the package maintainer email address get
messages sent to <bugnumber>@bugs.debian.org.  Once can reach the
currenty registered submitter using submitter@bugs.debian.org.  If one
want to reach other addresses, they need to be listed in To/Cc/Bcc.