From nobody Sat Apr 6 09:04:58 2024 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VBTvb6pkMz5GC9g for ; Sat, 6 Apr 2024 09:04:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VBTvb5mnhz4G82 for ; Sat, 6 Apr 2024 09:04:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1712394299; a=rsa-sha256; cv=none; b=Ov62uigbG10Opb/Jt/AdgyfdBHv1rdRRPv+BahOCsEMJ7GEemb8j4PZF2guB5buK7xR+9P BnAdhNM+r/fvQdlsdz9RDa0tjU0zAaPlg4ypzB9WGT5WaciOD0oQIDAL+TMk6TCtHGM/wS a1chESV6049xf3PaX2ycJtD6PamzjVUmg1J/jNEBz3jzjNvDJu3NFK7o1wwB59JdPGvPZ6 xoQYdm61iLWBfMB1emtwL8PQvJqDI+N3gbHCbZnccJeu1chUBhSYlECj98hoJKyddMX2tx EPID2lS5MMYybTt8nz2lutASzNfBB7LopergqEenPHYFMvSyiUiD6ONttJakjA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1712394299; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nW3bFnt8bE1RlWdc1NcM9uMyzsoooqJKyZQmI0yoGV4=; b=fULB2k/mAbGVwTGbJyo5HHyoKeDTNHh4QznJ7tqrPMCYrp+bACUuxQJOSFR2PefuGLW5tY GyWADYxC5TvgNTaXKha9LmA25fq+Wrf0MwM5qtDooykWiuF7E198NmIKejnKlrvy1x1vv+ LeSmCaeETGGJFEOln7L9YsPWRsOB+7M95/AOb6jBJQxQE1WMNoeE/zehSZ7SdbAM9NcUHz A76Ml/EtecIbR32LzR+ClFs5Rhcv4d2xcopFT7nCIwTfuJ2JilIk98/U8a0wz6I0xaGi5e iM3bNfbiYYTx6av4KaB8M1Pia9FflgEvosT071TzlM7YQLaOsVbK+/o8C3zckQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4VBTvb5NX2zdbZ for ; Sat, 6 Apr 2024 09:04:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 43694xC3080716 for ; Sat, 6 Apr 2024 09:04:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 43694x4o080712 for bugs@FreeBSD.org; Sat, 6 Apr 2024 09:04:59 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 277886] ZFS boot loader gives up too easily on unsupported zpool flags Date: Sat, 06 Apr 2024 09:04:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: loader X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: delphij@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277886 Xin LI changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |delphij@FreeBSD.org, | |mahrens@FreeBSD.org, | |tsoome@freebsd.org --- Comment #2 from Xin LI --- (In reply to Tomoaki AOKI from comment #1) I think the ask is simply make check_feature() and check_mos_features() (/stand/libsa/zfs/zfsimpl.c) to always return 0 instead of EIO even if the feature is not supported, so probably the boot code would emit a lot of err= ors, but eventually somehow able to read in the kernel (which is supposed to have the support, as the upgrade happened when the kernel is running). There may be some useful scenarios, for example, if a boot code that can't support zstd compression is used, and boot file system never had zstd compression, then the boot code should, in theory, be able to have sufficie= nt ability to boot from the pool. Personally I don't really like this idea, though, because it is not guarant= eed to work and may expose bugs of the read-only code (because we now broke the calling contract). It would be much better to prevent the upgrade from happening on the boot pool, and only allow it when boot environment is upda= ted, instead. If I was tasked to implement something for this, I'd probably do it by extending zpool utility to ask an OS dependent binary about "Is feature X supported by the current boot environment" for each read-only incompatible features, if the pool have 'bootfs' set, and refuse to upgrade (unless -f is specified) these boot pools if any feature is not supported. A naive implementation of the checker can be done by doing something like: 1. Gather a list of all partitions that is "freebsd-boot" type or "efi" type (this is actually not right; the EFI partition should be mounted and the ac= tual EFI/BOOT/BOOT${ARCH}.EFI should be checked instead), and append /boot/loader 2. Check if the feature string is present in the listed files, and return f= alse if any of them do not have the string. --=20 You are receiving this mail because: You are the assignee for the bug.=