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

From: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>
Date: Wed, 03 Sep 2025 23:15:44 UTC
On Wed, 03 Sep 2025 11:03:53 -0700
Chris <bsd-lists@bsdforge.com> wrote:

> On 2025-09-01 01:58, Tomoaki AOKI wrote:
> > On Mon, 1 Sep 2025 02:58:58 +0100
> > Graham Perrin <grahamperrin@gmail.com> wrote:
> > 
> >> On 17/08/2025 01:55, Graham Perrin wrote to freebsd-pkgbase:
> >> 
> >> > Subject: Using pkgbasify to repair a broken installation of FreeBSD
> >> > 14.3-RELEASE
> >> 
> >> > <https://gist.github.com/grahamperrin/9570092c127bd43777961b6f016e75ba>
> >> 
> >> 
> >> The routine is effective, to the best of my knowledge, however it's not
> >> particularly attractive. At least:
> >> 
> >> - the condensed steps will be too long for some users
> >> 
> >> - the first step assumes that the operator will have local access
> >>    and a USB memory stick.
> >> 
> >> I love this response to the Foundation's recent Community Check-In:
> >> 
> >>  > … 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.
> >> 
> >> <https://witter.cz/@klokanek/115083259795252616>
> >> 
> >> 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 …
> > 
> > On legacy BIOS boots, using MBR (boot0) of FreeBSD allows selecting
> > which base 4 partition "in the drive" to boot.
> > So keeping this limitation in mind, rescue partition is possible
> > and if there's KVM switch accessible via netowork, selections
> > can be done on boot (not sure about IPMI: no experience).
> > 
> > Currently, both UEFI boot1.efi and loader.efi don't have something
> > alike "on stock". Ability to choose BE from loader is available,
> > but IIUC, it can do nothing when the pool itself is causing problem.
> > 
> > 
> > On the other hand, boot1.efi has patch to choose partition / pool
> > to boot at Bug 207940, which is not landed but I'm always using.
> > 
> >   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940
> > 
> > But unfortunately, boot1.efi is deprecated (no expiration target
> > defined, though) and no merge would be expected.
> > 
> > 
> > So it would be nice if loader.efi has this kind of feature.
> > 
> > Implementing with lua and/or forth shouldn't be an option,
> > as it wouldn't work once the pool / partition loader.efi
> > looks into is somehow broken.
> > 
> > So should be implemented as the functionality of loader.efi itself and
> > show its selection menu BEFORE usual boot menu by lua/forth is shown.
> 
> I was thinking of bolting something onto loader when I first read this too. 
> But to my mind,
> wouldn't being able to load an image file be a more versatile choice? The 
> ability to load
> and boot into a minimal FreeBSD environment from say an mfs image would be 
> fantastic. You
> could place it on your FreeBSD root slice or on the ESP. If on the ESP, it's 
> as if you're
> already using a special "boot" partition. Apologies if I'm dragging this too 
> far off topic.
> 
> --Chris
> 
> -- 
> The internet is not a place.

It should be what's discussed starting from here.

  https://lists.freebsd.org/archives/freebsd-current/2025-September/008675.html


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