From nobody Tue Sep 02 03:02:45 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 4cG9XZ6PD9z66DWD for ; Tue, 02 Sep 2025 03:02:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cG9XZ4RJcz3M5S for ; Tue, 02 Sep 2025 03:02:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-323266d6f57so5334032a91.0 for ; Mon, 01 Sep 2025 20:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1756782168; x=1757386968; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JFyXhjqjc4qZxDC9c4L1d9Os+sHmEzZoc6Aba3PX2sE=; b=udNtFCjw58ormMdwXXLOJgdMszppteuryY7Qk5qynBcItII9R5Z57cgFE7skqi8lZe /hQeD53YioWr+30HhfPNqRVhAtHuQQI67Y9yRTP2hwb2VYlrL4d0Iru0PdPNar75269w n+NWrWxEvWQK/WPYDpVwQ9NfhW/jT/mdf33FuCrCmdt7RYI/0yuQp53o5rS2QcK+zJa3 tM+e8lxXLgTVgQN1kL35brxCIpionPsF5KM2hV1JYWaEDevAL8Xa0vIW6embw5c7RKbt jAmtZXmHmyBBmBLU6gECEy7vHLwLYz7Ko9bRemw2yOMnjEnjJuaFPouBXZs3vXVDsZt+ 1/dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756782168; x=1757386968; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JFyXhjqjc4qZxDC9c4L1d9Os+sHmEzZoc6Aba3PX2sE=; b=BLvUD/Uc5hk44qtIs6n4n9mBP23OgoIs7w6J4qXhrgyFceE31CI4oebFSJdbOZxWJU 6inL1hH27YOv5WEdhlsKE/Y4VMiEZQrHGz6WIZHnhxBw/icqPDR9Vqvhrr+0TKGPvZrb PGLoVlNMbPcTnne7yck6fH9NRGLJKaLW/RO+4Y9ddBeXLj4fgt8g29T/LniO1OSGnWhs e9MmAgKV2i5VijaHw+Pcbw0tISN0LczIODvgd5drm5+2BvxK2Em2iISOo+sV69rLqOOW 8y+hM9ynOWJHkOEre5KXn4WXWZ6YYvZdJZkMcQzCBK020P9vLv0EvMx7ZHY9liig8EQZ 2pyg== X-Forwarded-Encrypted: i=1; AJvYcCX5fi+kvrDg6GAFNsF6lyTyFio9aMBf6HwjRkKJK9BsKPVZw7JtJoaZUtuBBN/4k6YFNZ5QlBBPfqlMD82zQcs=@freebsd.org X-Gm-Message-State: AOJu0Yzm23F0iSx4uHo0V+u5Ai/Bembvf3gDiPE2OvidpcIBwAtNxc2R SXDGGGQ9OmNstAYeXX+tnSDDMZCgtVIgmz82NEioHJi3j9J4LuloUlE2vovQoV55XAodt32kYcG 5SAQCrqsXjg5PfwSX3xCqeb5y1XbMfOl87DaH1KpJHw== X-Gm-Gg: ASbGncspIHu7tQ6iV97mEjjsyG8Ds39w14Bt2MaBx4IzJ1XIccNNzdTf7fBMwGKaMUS p0c4YxOgdWqyHl75bwyByuhw2l4Oz5rplP1kZ+hX4ZDdG1Ta/Y8VPMpbsazZJwKmEKCCQ08VgPI 7erFfJF/SqvGF6hctNyF7AFP8+OLvUM1u8GqzI5TAbwlI8yaaquCgK5Fpp8nfWLPI1EC9Coo9VJ Wu+hCXGkETidh3oZRBIVinTnENIZi1xHynMFXOri+1adeOAsA== X-Google-Smtp-Source: AGHT+IGHtZX8VPdjsYeYHRenoE1auaNajrVkTrfK6TExZMIg0zd9GeRbZy8AWPN4CZTdTMmqVoD3NAuoQMWKybaPyi0= X-Received: by 2002:a17:90b:4fd0:b0:327:d551:5932 with SMTP id 98e67ed59e1d1-328156c5843mr12370822a91.21.1756782168432; Mon, 01 Sep 2025 20:02:48 -0700 (PDT) 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 References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <20250901175827.73ba0ea24812cebe2263811f@dec.sakura.ne.jp> <202509010904.58194iP2007318@critter.freebsd.dk> <20250901204243.6548150b14d79d2eab04ad3d@dec.sakura.ne.jp> In-Reply-To: <20250901204243.6548150b14d79d2eab04ad3d@dec.sakura.ne.jp> From: Warner Losh Date: Mon, 1 Sep 2025 21:02:45 -0600 X-Gm-Features: Ac12FXxfRSgfEsYI9KDdA0QNh1Mw9Ti2YtJVmZY_rfJVnxNVrsq8ORLidxnqA-8 Message-ID: Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD To: Tomoaki AOKI Cc: Poul-Henning Kamp , Graham Perrin , FreeBSD-CURRENT Content-Type: multipart/alternative; boundary="00000000000018f85d063dc8b91b" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cG9XZ4RJcz3M5S --00000000000018f85d063dc8b91b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 1, 2025 at 5:42=E2=80=AFAM Tomoaki AOKI wrote: > On Mon, 1 Sep 2025 03:15:50 -0600 > Warner Losh wrote: > > > On Mon, Sep 1, 2025, 3:05=E2=80=AFAM Poul-Henning Kamp > wrote: > > > > > -------- > > > Tomoaki AOKI writes: > > > > > > > > > > > > =E2=80=A6 it would be nice to have something like 'recovery pa= rtition', > 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. Rescue is quite small. On the order of 8MB compressed. The trouble is that the kernel is like 12MB compressed, plus we'd need a few more modules. Still, we could likely get something under 25MB that's an MD image that we could boot into, but it would have to be single user. And It's been a while since I did that... Typically I just run /rescue/init or /rescue/sh, which isn't a full system and still uses the system's /etc. If we customized it per system, we could do better, since the kernel can be a bit smaller (compressed our kernels at work are 6MB), so under 20MB could be possible. We'd not need /boot/loader.efi in there. If we could hook into the arch specific traps that cause segv, etc, we could do a setjmp early and set 'safe mode' and restart. Though that may be trickier than I initially am thinking... maybe the best bet is to let uefi catch that failure and have the next bootable BootXXXX environment on the list specify a safe mode. More investigation might be needed. Warner --00000000000018f85d063dc8b91b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 1, = 2025 at 5:42=E2=80=AFAM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
On Mon, 1 Sep 2025 03:15:50 -0600
Warner Losh <imp@bsd= imp.com> wrote:

> On Mon, Sep 1, 2025, 3:05=E2=80=AFAM Poul-Henning Kamp <phk@phk.freebsd.dk> wro= te:
>
> > --------
> > Tomoaki AOKI writes:
> >
> >
> > > >=C2=A0 > =E2=80=A6 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 flas= hstick 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 fo= r 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&quo= t;.

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 "dr= ive"
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.

Rescue is quite = small. On the order of 8MB compressed. The trouble is that the kernel is li= ke 12MB compressed, plus we'd need a few more modules. Still, we could = likely get something under 25MB that's an MD image that we could boot i= nto, but it would have to be single user. And It's been a while since I= did that... Typically I just run /rescue/init or /rescue/sh, which isn'= ;t a full system and still uses the system's /etc. If we customized it = per system, we could do better, since the kernel can be a bit smaller (comp= ressed our kernels at work are 6MB), so under 20MB could be possible. We= 9;d not need /boot/loader.efi in there.

If we coul= d hook into the arch specific traps that cause segv, etc, we could do a set= jmp early and set 'safe mode' and restart.=C2=A0 Though that may be= trickier than I initially am thinking... maybe the best bet is to let uefi= catch that failure=C2=A0and have the next bootable BootXXXX environment on= the list specify a safe mode. More investigation might be needed.

Warner
--00000000000018f85d063dc8b91b--