From nobody Sat Apr 13 15:54:44 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 4VGyg86hT2z5Hh2q for ; Sat, 13 Apr 2024 15:54:44 +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 4VGyg84gRPz4Kvg for ; Sat, 13 Apr 2024 15:54:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713023684; a=rsa-sha256; cv=none; b=a/bAG+JP/CPfLgv027MLO/Wy4SzK7f2uYwox7Uwsw53f3fL/gSCY+PQbikbN6dN8ESRELH 2NrxcSERNQadS9tgPLyJMjuvdbWk5k4YhQa8mzn9dhS5QzH2G+GXsVg+j7ii6RcQWUj559 QoLje4wakhgjf0hCSwXt453ZapVe9ofyLKO3oWyJ/XDy5EZfXd0Ec1VoUJ0ztbLxOd/d3C XdOA9glKNoF9mxzd5SkW1EVcATtvruNw0eCkZcSUbinznm6b3S41fbn9iEZgGDUPqMPxmn r65eg3Fm9UxeebXFRIle7xDyU/Oz43aIj8RvDGYDVQK6S066qEV0yGkh36NbqA== 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=1713023684; 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=YyHNaDe2pJRi7O1B0dHBRtUITl6oFUcD7+To6d70JkI=; b=T1BNPPmQauqYUqFqNzJPN5trTOLjo9DrPgeexWjJBZD3Payy5InxR7o7SUpHwu2fZ9J87B JxQX6acMy4UDyS70WJDhDs/Y0EOOVfD7pflacIxrTAE70iJcyOU9oINfdAGtTX8SSGqD+g c9frlgQ89RnSQfsqBsabZ9nE3gbD/YJfJtwhJUcorZVSmV+ZYULSxU4klwMgStYmNHZqCL 2VQ+9fJF2JOxSw7Cr68MfisVilgUB4KnaIo6v/bfseyz3kG6yg2/wkFaX+f3BhfDo5xq1y hBz9ooOE7a+Hke8ieSEBvFCJuR/YMw40ZyqKzeLTbDL56dHhfpewbjC4obcMhQ== 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 4VGyg84BMczfJQ for ; Sat, 13 Apr 2024 15:54:44 +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 43DFsih2078762 for ; Sat, 13 Apr 2024 15:54:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 43DFsi4r078752 for bugs@FreeBSD.org; Sat, 13 Apr 2024 15:54:44 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, 13 Apr 2024 15:54:44 +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: imp@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: 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: MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277886 --- Comment #7 from Warner Losh --- (In reply to Edward Tomasz Napierala from comment #6) > Well of course it's not. But the worst case we're risking here is what i= s currently the only case: a boot failure. I think it's a bad idea. It will transform the boot failure from a well kno= wn one (an error message saying it can't find loader.lua) to some random thing that may work for a while, but then randomly stop working in the future. Or some hang that's hard to notice, or something else entirely. It would be a support nightmare, so I'm very close to a hard no on doing it unconditional= ly because I'll be the one that has the extra work. However, there are other options. First, we could have a built-in command t= hat sets a global flag to force the operation and retry. This isn't terrible to implement, but is somewhat of a pain because we'll need special code in eve= ry single driver to do this. And it can't work in boot1.efi, but I don't care about that because boot1.efi is deprecated. Second, we could prompt the user when we detect the problem whether or not = to continue anyway. I think we always have a console, though it might not be t= he user's preferred console at this point (since that preference is set from t= he very filesystem we're trying to read). We do have conin for EFI, even boot1.efi. Third, for BIOS booting (and to a lessor extent EFI) we have a command line option we can bass in from boot0 that could force it. EFI could have an environment variable that controls it (for those systems that don't let you= set a command line option). Fourth, and this is another of the modify all the boot loaders, would be to= try what we do now, then test to see if we can read loader.lua (the 4th loader won't be modified: it's feature set is frozen and this is a new feature). I= f we can't read loader.lua, we know we're about to fail, so we can try again wit= h a global force flag set (after a brief pause to announce we're doing this and= all bets are off and we might reset or hit an assertion in the ZFS code). This I think I like best because it's the safest one that could be automatic. Plus= we can set a kenv that communicates to an rc file to print a big, ugly warning= on boot to say we had to do this to read the ZFS pool and you got lucky: next update or even next boot you might not be so lucky. Of course, 'don't update the zpool unless the boot blocks support it` is the best option. --=20 You are receiving this mail because: You are the assignee for the bug.=