From nobody Wed Sep 03 23:15:44 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cHJQ34ygDz66LWt for ; Wed, 03 Sep 2025 23:16:11 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cHJQ30gJfz3vGk for ; Wed, 03 Sep 2025 23:16:10 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 583NFiwR080961; Thu, 4 Sep 2025 08:15:45 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1756941346; bh=AicSDQ4qrEzvAX29Yskmy+ru8daGobKl3VHB2lMjncY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=E5Em5IQxV0dn2Kub6V8Cqfi9JRV4OOTGfyx0DfqB3kJmD+KaQhqSQRskx3pL2GXdA eGhFxZnXKzCbEYAVN5oUhjL9uhja+Ty6bEamKswwIOvqIWSl4Ng3E9UO3UdxiPSmg1 9F5mpXwlYhk02JzK9bDXW59eFPyurwMS4iPcp37o= Date: Thu, 4 Sep 2025 08:15:44 +0900 From: Tomoaki AOKI To: Chris Cc: Graham Perrin , FreeBSD-CURRENT Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD Message-Id: <20250904081544.4e1ac6d13377dac565aa434d@dec.sakura.ne.jp> In-Reply-To: References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <20250901175827.73ba0ea24812cebe2263811f@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.3) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cHJQ30gJfz3vGk On Wed, 03 Sep 2025 11:03:53 -0700 Chris wrote: > On 2025-09-01 01:58, Tomoaki AOKI wrote: > > On Mon, 1 Sep 2025 02:58:58 +0100 > > Graham Perrin 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 > >> > >> > > >> > >> > >> 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. > >> > >> > >> > >> 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