Re: Using a recovery partition to repair a broken installation of FreeBSD
- In reply to: Chris : "Re: Using a recovery partition to repair a broken installation of FreeBSD"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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>