Re: Using a recovery partition to repair a broken installation of FreeBSD

On Tue, Sep 2, 2025 at 4:03 PM Jordan Gordeev <jgopensource@proton.me>
wrote:

> On Tuesday, 2 September 2025 at 22:27, Warner Losh <imp@bsdimp.com> wrote:
>
> >
> >
> > On Tue, Sep 2, 2025 at 12:53 PM Graham Perrin <grahamperrin@gmail.com>
> wrote:
> >
> > > On 01/09/2025 02:58, Graham Perrin wrote:
> > > > An enhancement to bsdinstall could, before creation of the partition
> > > > table, allow the user to specify an amount of space to be left free
> at
> > > > the end of a device …
> > >
> > >
> > > 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 … and so on. Maybe this
> overlaps
> > > with ZFS-specific bsdinstall report
> > > <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242983>.
> >
> >
> > 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 with
> more features residing in its own dedicated partition. On some machines the
> 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 script
> /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