From nobody Tue Sep 02 22:16:21 2025 X-Original-To: freebsd-current@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 4cGg7l3Pktz65p8C for ; Tue, 02 Sep 2025 22:16:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGg7l0XTMz3H6g for ; Tue, 02 Sep 2025 22:16:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-7726c7ff7e5so1502630b3a.3 for ; Tue, 02 Sep 2025 15:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1756851392; x=1757456192; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=m6CgK5eqQCIFGukDdKwFfo3pcR+SCRcWc77+WxUwhZY=; b=VQZb5ysW6wXUQC0JZEOJMh4Oks89PXwEXTRxjjWarU/SJGYtH+1x15TcmytxK0Oycp UKaxEHoidukdeijJ4+86tb2VaBdwQcZd04Q3O9RXRKCwTjBHVDsOlAXQ7JUkurR5j7k2 fv0nYhaLwuksPE4vRsqryoAsCkbrEWfhk5ZmTNfBWgVgW7+fWBukhejScFbM+W3FO/IK dE7PWP8IyKtm3NP1mVYn/kRVPFLEU15bD0bZ2eD1K0fLok9v2ZHhOEuCOI4GDeLXL1TP RjH9Fc4lORhp5Hy/8Cf3nPJ/RGWpfvRfbw9zS2sogaDVa9rnARxjvid7Jux5f1tRAeup tRXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756851393; x=1757456193; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=m6CgK5eqQCIFGukDdKwFfo3pcR+SCRcWc77+WxUwhZY=; b=C80RwEiKVv+JsfhdOmaHIklkBt7vxxnCL+g7txx84tH/3yG0IBnWGdDRiBkDgrvMyb 1XZAi8ap83ys0imih/+LjCKMLBOIrAmI/439f6BFF+9xZqe2kdMjtfAnm6DzdEWk+9WP ZLRFwKneOlVMwPA3I3JKuQN8ErQY9UcCkdAHFtslLCDAd1swf2/mccO4lDPUnQFtBL8y qjQ/OoatzgbpDoeygQqqoE1Qw1aH1yY6QJ3Hq/zogQo0h4wAzlsSTgf78nZ3utFs5uJU 8dCpWWyeURRx+8x9kchpI6j9vKoCmXTGGTNrktmfMZ+8e2ObFpyx8tXghs9J8IDPlbUf xqew== X-Gm-Message-State: AOJu0Yxy3kgUisg2qvkNsd8bNUd6kAngM8KCNF5Pt7rXKNeL1kOVSg6U HQm2cn8hN3eszIeOd6xgORLZkyqeaigGElCPELFP7FUIfA1My5kXYVPsazXubl1P6YuVqNeh71+ DolwE/pmTLzpJNPoidfHyzl9WwVsCWk5lUzLmtFfFkA== X-Gm-Gg: ASbGnctv1Vh+CW/X4b/5LUQi+pmHXjkjMaIwq64Ie2Qy7Nqc6mbGnPdJnPGDqpN1jdw NYQisDrhkL5q8yhangV4dS3vhC9I8aV3UejfkJIQTBpaiuZDoEP6Oxsb2EElxNyEtyKRDKuzLzO xaeZB69psvULwSgZCZn8PAy2xgtB0kvF2VPofup03LbLdAbD5ghFyIYwzz6fuhU1cEadvTKj0Vq EgWIwWkFnDK7BvN0YkyjmR9RFU0XHztZEUNFTY= X-Google-Smtp-Source: AGHT+IFDqHJoWaaby81sdbpQ0v5hKDaqL/jSyeje8lpoo1IUuChLB1qqJDuC1SdpB6mOuzWcrLPyeded5vH4w9u8x5E= X-Received: by 2002:a05:6a20:394b:b0:240:489:be9a with SMTP id adf61e73a8af0-243d6e0110emr16919438637.23.1756851392483; Tue, 02 Sep 2025 15:16:32 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <98890564-ad8f-411a-9c00-45326a9d6ff5@gmail.com> In-Reply-To: From: Warner Losh Date: Tue, 2 Sep 2025 16:16:21 -0600 X-Gm-Features: Ac12FXxpQ8NtthJsyVaktBL9UGMJuhDxhq1RId77Q4S0Mx8tiPsx3sPZ3WNSvgQ Message-ID: Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD To: Jordan Gordeev Cc: FreeBSD-CURRENT Content-Type: multipart/alternative; boundary="0000000000002c24c9063dd8d744" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cGg7l0XTMz3H6g --0000000000002c24c9063dd8d744 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 2, 2025 at 4:03=E2=80=AFPM Jordan Gordeev wrote: > On Tuesday, 2 September 2025 at 22:27, Warner Losh wrote= : > > > > > > > On Tue, Sep 2, 2025 at 12:53=E2=80=AFPM Graham Perrin > wrote: > > > > > On 01/09/2025 02:58, Graham Perrin wrote: > > > > An enhancement to bsdinstall could, before creation of the partitio= n > > > > table, allow the user to specify an amount of space to be left free > at > > > > the end of a device =E2=80=A6 > > > > > > > > > For now, short term, is the (simple) free space idea attractive? > > > > > > Longer term: I'm not averse to more complex enhancements around e.g. > > > /rescue/, however I _do_ like the idea of free space. > > > > > > Freedom for the user to do whatever they want. They might, or might > not, > > > want to use the space for the content of > > > FreeBSD-15.0-RELEASE-amd64-memstick.img =E2=80=A6 and so on. Maybe th= is > overlaps > > > with ZFS-specific bsdinstall report > > > . > > > > > > Things are small enough, I'd rather just create it in the ESP directly. > Special reserved space on disks are nothing but a pain. > > > > I think the user should have a choice between a small rescue image > residing as a file in the EFI System Partition and a big rescue image wit= h > more features residing in its own dedicated partition. On some machines t= he > ESP will be too small for the first option so the option for a separate > partition should definitely be supported. > I disagree. Or rather, I'm implementing the first thing only, and somebody else will have to deal with the second. > I want to suggest an enhancement to the default loader.efi (the one with > the Lua interpreter) which will work for all styles of rescue images. Let= 's > add a "rescue" command to the loader which will read and execute the scri= pt > /efi/freebsd/rescue.lua from the ESP. The user can place a small rescue > image in the ESP and write there a suitable rescue.lua script that can > activate it, or they can create a whole rescue partition and write a > different rescue.lua script to the ESP that knows how to activate the > rescue partition. It will be a small change to the loader but at the same > time it will be quite flexible. > By making it its own partition, you have a lot of hair: The loader is stupid. It doesn't have a lot of smarts or protection and gets into trouble often (it's why we're having this discussion at all). Making the partition robust for recovery would be hard, and having it be unreliable isn't something I'll sign up for. And I'm not sure we have everything in Lua to write that script, so there'd likely be some efforts there. I do like the well defined 'rescue' option. > From the user's perspective, if the boot fails and you are left at the > loader's prompt, you just type "rescue". Users will probably pick from > ready-made rescue images, each one coming with the necessary rescue.lua > script, so there will be nothing difficult for the user to do. > Yes. But if they haven't setup the rescue with your plan, they'd be out of luck. That's why I'd like a small, targeted environment that's well defined that we can boot to. It will be without bells and whistles, but will be enough to recover. There will be an editor, commands to interact with the network, the storage stack, etc. But we'll need to be careful what else is in there. And it will be different choices from /rescue (though maybe rescue needs a rethink for several items, like including ipf). So I'd strongly suggest that we walk before we can run. Let's get something with a small, well-defined remit working, and we can iterate from there. Warner --0000000000002c24c9063dd8d744 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 2, = 2025 at 4:03=E2=80=AFPM Jordan Gordeev <jgopensource@proton.me> wrote:
On Tuesday, 2 September 2025 at 22:27, War= ner Losh <imp@bsdimp= .com> wrote:

>
>
> On Tue, Sep 2, 2025 at 12:53=E2=80=AFPM Graham Perrin <grahamperrin@gmail.com&= gt; wrote:
>
> > On 01/09/2025 02:58, Graham Perrin wrote:
> > > An enhancement to bsdinstall could, before creation of the p= artition
> > > table, allow the user to specify an amount of space to be le= ft free at
> > > the end of a device =E2=80=A6
> >
> >
> > For now, short term, is the (simple) free space idea attractive?<= br> > >
> > Longer term: I'm not averse to more complex enhancements arou= nd e.g.
> > /rescue/, however I _do_ like the idea of free space.
> >
> > Freedom for the user to do whatever they want. They might, or mig= ht not,
> > want to use the space for the content of
> > FreeBSD-15.0-RELEASE-amd64-memstick.img =E2=80=A6 and so on. Mayb= e this overlaps
> > with ZFS-specific bsdinstall report
> > <https://bugs.freebsd.org/bu= gzilla/show_bug.cgi?id=3D242983>.
>
>
> Things are small enough, I'd rather just create it in the ESP dire= ctly. Special reserved space on disks are nothing but a pain.
>

I think the user should have a choice between a small rescue image residing= as a file in the EFI System Partition and a big rescue image with more fea= tures residing in its own dedicated partition. On some machines the ESP wil= l be too small for the first option so the option for a separate partition = should definitely be supported.

I disag= ree. Or rather, I'm implementing the first thing only, and somebody els= e will have to deal with the second.
=C2=A0
I want to suggest an enhancement to the default loader.efi (the one with th= e Lua interpreter) which will work for all styles of rescue images. Let'= ;s add a "rescue" command to the loader which will read and execu= te the script /efi/freebsd/rescue.lua from the ESP. The user can place a sm= all rescue image in the ESP and write there a suitable rescue.lua script th= at can activate it, or they can create a whole rescue partition and write a= different rescue.lua script to the ESP that knows how to activate the resc= ue partition. It will be a small change to the loader but at the same time = it will be quite flexible.

By making it= its own partition, you have a lot of hair: The loader is stupid. It doesn&= #39;t have a lot of smarts or protection and gets into trouble often (it= 9;s why we're having this discussion at all). Making the partition robu= st for recovery would be hard, and having it be unreliable isn't someth= ing I'll sign up for.

And I'm not sure we = have everything in Lua to write that script, so there'd likely be some = efforts there.

I do like the well defined 'res= cue' option.
=C2=A0
From the user's perspective, if the boot fails and you are left at the = loader's prompt, you just type "rescue". Users will probably = pick from ready-made rescue images, each one coming with the necessary resc= ue.lua script, so there will be nothing difficult for the user to do.

Yes. But if they haven't setup the rescu= e with your plan, they'd be out of luck. That's why I'd like a = small, targeted environment that's well defined that we can boot to. It= will be without bells and whistles, but will be enough to recover. There w= ill be an editor, commands to interact with the network, the storage stack,= etc. But we'll need to be careful what else is in there. And it will b= e different choices from /rescue (though maybe rescue needs a rethink for s= everal items, like including ipf).

So I'd stro= ngly suggest that we walk before we can run. Let's get something with a= small, well-defined remit working, and we can iterate from there.

Warner
--0000000000002c24c9063dd8d744--