-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ubuntu 17.04, initramfs zfs script does not honor datasets with canmount property set to none #221
Comments
Relevant code in https://github.com/zfsonlinux/zfs/blob/master/contrib/initramfs/scripts/zfs: mount_fs()
} |
I'm not sure this pkg-zfs repo is the correct place to file these bugs. If the bug exists in upstream ZFS (and your URL suggests it does), that's probably the right issue tracker. |
Can you provide your |
I used to have datasets underneath the root filesystem, but the topology of my pools changed in the meantime (I have multiple root filesystems in the pool now) so that is no longer the case. Said this: while we can agree on eventual best practices about it, there is absolutely nothing wrong with having children on the root filesystem dataset. There is no reason for this script to break that, it overrides settings I explicitly configured to avoid running into this. |
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. This is part of the fix for: zfsonlinux/pkg-zfs#221 Signed-off-by: Richard Laager <rlaager@wiktel.com>
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. This is the remainder of the fix for: zfsonlinux/pkg-zfs#221 Signed-off-by: Richard Laager <rlaager@wiktel.com>
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. This is part of the fix for: zfsonlinux/pkg-zfs#221 Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes #6897
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. This is the remainder of the fix for: zfsonlinux/pkg-zfs#221 Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes #6897
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. This is part of the fix for: zfsonlinux/pkg-zfs#221 Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes openzfs#6897
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. This is the remainder of the fix for: zfsonlinux/pkg-zfs#221 Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes openzfs#6897
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. This is part of the fix for: zfsonlinux/pkg-zfs#221 Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes openzfs#6897
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. This is the remainder of the fix for: zfsonlinux/pkg-zfs#221 Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes openzfs#6897
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. This is part of the fix for: zfsonlinux/pkg-zfs#221 Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes #6897
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. This is the remainder of the fix for: zfsonlinux/pkg-zfs#221 Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes #6897
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. This is part of the fix for: zfsonlinux/pkg-zfs#221 Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes openzfs#6897
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. This is the remainder of the fix for: zfsonlinux/pkg-zfs#221 Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes openzfs#6897
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. This is part of the fix for: zfsonlinux/pkg-zfs#221 Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes openzfs#6897
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. This is the remainder of the fix for: zfsonlinux/pkg-zfs#221 Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes openzfs#6897
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. This is part of the fix for: zfsonlinux/pkg-zfs#221 Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes openzfs#6897
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. This is the remainder of the fix for: zfsonlinux/pkg-zfs#221 Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes openzfs#6897
This was fixed in openzfs/zfs#6897 right? |
Yep, that was my use case. |
I hope this is the right place for this.
The zfs script in the Ubuntu 17.04 initramfs defines and uses a "mount_fs" function that doesn't honor the canmount property, mounting all datasets (even those with the canmount property set to "off") using "mount -o zfsutil -t zfs". This can cause the boot process to fail when processing subsequent datasets.
Update: the mountpoint gets overruled in some cases as well. Datasets with canmount set to off and mountpoint set to none, still get mounted.
My expectation would be that, other than the rootfs, mount_fs does not proces datasets that do not have mountable options set.
The text was updated successfully, but these errors were encountered: