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

From: Chris <bsd-lists_at_bsdforge.com>
Date: Wed, 03 Sep 2025 18:03:53 UTC
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.