Created attachment 184793 [details] prototype fix for reference when using a readonly filesystem as root filesystem, vfs.root.mountfrom.options="ro" should be the only way to tell kernel mount the filesystem in readonly. This works for UFS but ZFS. Currently, during kernel mountroot, zfs_domount always try to open underlayer device for write when try to import the pool and failed. When kernel try to import pool by calling spa_import_rootpool(pname) in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, there is not parameter to tell spa_load to open underlayer device on readonly. This is the source of this issue. The attachment is a prototype fix for reference. It query vfs.root.mountfrom.options when open underlayer device to set readonly flag. A new parameter for spa_import_rootpool meight be a better solution.
/ gets mounted read-only in single user mode, with a mount flag (so the pool is not imported read-only, but the filesystem is mounted read only), and then it is upgraded to readwrite during the switch to multiuser mode. Are you wanting the entire pool to be imported read only? Or just the one dataset to be mounted readonly?
If I am reading comment #0 correctly, the reporter wants vfs.root.mountfrom.options="ro" to imply the read-only import of the pool. I think that that's not what vfs.root.mountfrom.options is for. We could add a different knob for that as it might be useful in certain situations.
(In reply to Andriy Gapon from comment #2) I would tend to agree, having the entire pool be readonly would be unexpected when the sysctl suggests only the root filesystem will be readonly.
(In reply to Allan Jude from comment #1) I hit this issue when trying to use a zfs as rootfs which use a compressed md_image as underlayer device. A compressed md_image can not be opened in write mode(see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221066). So in this case I want to open the whole zfs pool in readonly. A new kenv entry to control this behavior also make sense.