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

From: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>
Date: Mon, 01 Sep 2025 11:42:43 UTC
On Mon, 1 Sep 2025 03:15:50 -0600
Warner Losh <imp@bsdimp.com> wrote:

> On Mon, Sep 1, 2025, 3:05 AM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> 
> > --------
> > Tomoaki AOKI writes:
> >
> >
> > > >  > … it would be nice to have something like 'recovery partition', as
> > > > some OSes have. or at least some tiny fail-safe feature. having remote
> > > > machine in some distant datacenter, booting from a flashstick is
> > always
> > > > a problem.
> >
> > I thought that is what /rescue is for ?
> >
> 
> That only works if your boot loader can read it... I've thought for a
> while now that maybe we should move that into a ram disk image that we fall
> back to if the boot loader can't read anything else...
> 
> Warner

Exactly. If the loader (or bootcode to kick the loader in the
partition/pool) can sanely read the partition/pool to boot from,
I think /rescue is enough and no need for rescue "partition / pool".

But once the partition / pool to boot is broken (including lost
decryption key for encrypted partitions/drives from regular place),
something others are needed.

And what can be chosen to boot from BIOS/UEFI firmware depends on
the implementation (some could restrict per-drive only, instead of
every entry in EFI boot manager table).

If BIOS/firmware allow to choose "drive" to boot, rescue "drive"
is useful, if multiple physical drives are available.

Yes, rescue mfsroot embedded into loader.efi would be a candidate, too,
if the size of ESP allows.


> > --
> > Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> > phk@FreeBSD.ORG         | TCP/IP since RFC 956
> > FreeBSD committer       | BSD since 4.3-tahoe
> > Never attribute to malice what can adequately be explained by incompetence.


-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>