From nobody Fri Jul 5 17:22:42 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 4WG0hL2YPrz5Q0gY for ; Fri, 05 Jul 2024 17:22:42 +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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WG0hK6h3Fz4X69 for ; Fri, 5 Jul 2024 17:22:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1720200161; a=rsa-sha256; cv=none; b=A45v2XhTCeObACyRXLnoSkNyApugILtXHU8Lvl+WZNdoCATaAUGRIVnWYI4RDyOCo6pV3K DeYJz+ValfK//pUv0R6nidOBntF5vMAxI97aKyqDauZn6LYdCid9ok1Kbbt2rRV0GdE/Lx 7JJHJZ99s9vWp1WRvW41JoXOfKCH0RI97hYzRRsttj20wY75oUIoophI/gs0WHWfaOBiMC rldHuQrhmd5MP1aDOjj7zntdFpockrnTSj1tw6YjB2TxJF8lz8dX7gm31mgWGgJJO6La6c moX7qQb3iCM9CrlwAq3UvFfLOqv1j9GIIN08Ioz0FXmsyspsH1WCQG7n0nF2YQ== 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=1720200161; 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=dikQJIfhFjSxaYGkHFumV6qCj1wJjzNSVuC26Q86/Uw=; b=dwXWY+0YRaKe3ZnJeFeD7nCaomcmq9qsCYxjTauJ+hOI20YplAxl8UfbF+JOg7gOvfSmbl 1fos1SaF+TsE10AMjfv0L6BZdsBAUWSshcaqlf3EKROkr7hnkHhL7UIQWmg8Cdj/d1hBhZ v9dYK74K9mzw1ekgT5sXwgpUj7i4RivQjldbxtfCFG8HbnM/julYUMHRnS3bgndbmLM194 lulU2BZdzzCbu0MeEYXGx5+2iBoFPnpDDyLJaZRYHEYBxtPH2PKMis9uqYJAYna24RtjTn U0Z0wWEhNRgcfSvV96mGsQ5IT1Mz/OS7drD3WaVgJSxaPDoHGLlmItgx5TUGgg== 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 4WG0hK6HYGz14vx for ; Fri, 5 Jul 2024 17:22:41 +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 465HMfGx040837 for ; Fri, 5 Jul 2024 17:22:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 465HMfD2040836 for bugs@FreeBSD.org; Fri, 5 Jul 2024 17:22:41 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 279829] Unable to automatically boot after upgrading to 14.1-RELEASE Date: Fri, 05 Jul 2024 17:22:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: 14.1-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: imp@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug 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: Sender: owner-freebsd-bugs@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279829 --- Comment #9 from Warner Losh --- OK. I've thought through this. We have two strategies here. This is kinda n= ot a bug, but also kinda a huge big rock sticking out for people to trip over th= at we should do something about, since we've known about it for a while now... (1) People Must Upgrade. Sorry, but they have to. We can't support the long dead hand of the past forever. (2) We Must Document How. We do already, but it needs be greatly improved. Now, having said (1) and (2) there's way too much friction for both. So I'm proposing the following (a) We add a version number checking to the lua scripts. The boot loader already has a loader_version (4th) or loader.version (lua) exported. This is the boot program revision. Right now it's among the jankiest jank[1] still = in the jankville part of the boot loader. Proposal: Bump this to 2.0 everywhere. Nobody cares today, really, what it = is, but 2.0 is a good starting point. I also propose exporting loader.freebsd_version (being the __FreeBSD_version of the build environment (usually the sources used to build it except). We also compile these version into a vers.lua ala vers.c. We enhance loader.lua to warn if freebsd_version mismatches with the loader. The warning will be "This is old, smelly code, update to new shiny code ASA= P, but maybe this will work out for you, good luck with that" or similar, perh= aps more word smithed: loader.efi is $loader_freebsd_v than the system you are booting $lua_freebs= d_v This may or may not work, please upgrade your ESP. Also, if loader major rev rev !=3D loader rev, and we can read the new root filesystem, and it's EFI and we find a /boot/loader.efi on the new root filesystem, chain load that if the root filesystem !=3D the image location = we got the loader.efi from. Proclaim even louder that an upgrade is needed :). But this will get people over the hump if they have really really old loader wi= th shiny new lua scripts. Still working out some of the technical details on t= his one. Also, all 'backwards compat' workarounds should explicitly whine when they = are used so people know they have stale loader(s) afoot. For (2) we need to put it in the loader.efi man page, which is it's how hor= ror show right now. We likely also need a (3) script to update boot blocks no matter where they are, since we've grown at least 4 supported environments that are various f= orms of popular (x86 BIOS MBR, x86 BIOS GPT, EFI and UBOOT+EFI) that we should cover. We should also strongly encourage people to move to a more standard layout and also look to adding this to installworld (perhaps optionally at first). (2) and (3) are needed to solve the ZFS problem (which we can't just chain-= boot away, though other counter measures are needed). [1] https://www.dictionary.com/e/slang/janky/ --=20 You are receiving this mail because: You are the assignee for the bug.=