From nobody Fri Mar 18 04:31:04 2022 X-Original-To: freebsd-fs@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 468CC1A18675 for ; Fri, 18 Mar 2022 04:31:18 +0000 (UTC) (envelope-from ggm@algebras.org) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KKWKx1r1Hz4S5b for ; Fri, 18 Mar 2022 04:31:16 +0000 (UTC) (envelope-from ggm@algebras.org) Received: by mail-lf1-x12c.google.com with SMTP id g17so12322641lfh.2 for ; Thu, 17 Mar 2022 21:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rzyeP2Bh+c1vNLm09BOq9wtFeHvJZuKUs8HwjmXB68s=; b=qimGFrTwlDo8+zB78QA/cSACV24gZAmZfpQgRVdgJOUldItRtj0prOtov2OgjXQN1o SLZz2KxDJI0YCX3DyfZrDXc/UeoVt4cAp3/mmwmOuR8Tp0/MOiWZD/P2wKXIcOQ4o1lj ZBix1lb8rPEyUlRYRDpG9e6UE48Xg0pzIDVciNmUBzd/Q2ckw1V3EYk4qW5jV38nLNR2 QX6PWKMAWUD2YhTP2VnTD9oooRuv4CnQ9v7p9kZ7SjX7IorBADHpnsn+y31Tpq7m37+x m3CdIBqfAtzJRSoUEIQ3y1+2ETyhWjs99i/jcRZkiSVJz+6iry3S5vtLAGRCsNglAosm 3T6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rzyeP2Bh+c1vNLm09BOq9wtFeHvJZuKUs8HwjmXB68s=; b=22Rgc3R2XsK0zl8HXBpTA7eN8KU0Z6n6rx85qgwG1mgpGqP0FF9bJ2+gST7ThQg8EJ y7PfT0SYMaMuEIXdsnVZ+lDRcnIHFaa/4WsZGGrrGIH4a90WhH63V8KoIWvKlMSJYtc2 QAFkCLjAuowf2ZP2geZWRLeIiRUBc0SDQjv0lzkBoK/wmGSwmR6dDACtDM7F/YIhFm2V AcWyNmuguOKuLK1GU+gN6Q1+rq4JsXQbXFEgGyXh25wTfJ1L8h7L4CaIBd85MFhM0ES1 qD4QPJE9MrBP6ggZWt9Z6FYsBU888WaWpyxvzSQgUH7f0+iqIr3DYJscJwiR+oTmI09n Uucw== X-Gm-Message-State: AOAM533/2UiUn6Y1L6GaDNn7aivBQ0fZ2/lBrltDOUw4+63DiRD8NW2K DqsUrmG7xkqvUGBwUPCR9UqQ9LUa/agqfiyr3cfWgY9rSK8= X-Google-Smtp-Source: ABdhPJyRpeLJ3f04zxcCN+B0jYNZLQiacm0IWYg+UZShNMjttQgM2ex1D3Xk1CpZwHCp9/CeZ0riRJI3CLv0D3jitWg= X-Received: by 2002:a05:6512:2253:b0:449:f7ea:4ed7 with SMTP id i19-20020a056512225300b00449f7ea4ed7mr3606439lfu.73.1647577874992; Thu, 17 Mar 2022 21:31:14 -0700 (PDT) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 References: <68449cab-c5d7-47ff-99e1-d0e6963374d0@denninger.net> In-Reply-To: From: George Michaelson Date: Fri, 18 Mar 2022 14:31:04 +1000 Message-ID: Subject: Re: Hybrid partition tables -- can gpart make them? To: Warner Losh Cc: Karl Denninger , FreeBSD FS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4KKWKx1r1Hz4S5b X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=algebras-org.20210112.gappssmtp.com header.s=20210112 header.b=qimGFrTw; dmarc=none; spf=pass (mx1.freebsd.org: domain of ggm@algebras.org designates 2a00:1450:4864:20::12c as permitted sender) smtp.mailfrom=ggm@algebras.org X-Spamd-Result: default: False [-0.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[algebras-org.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; DMARC_NA(0.00)[algebras.org]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[algebras-org.20210112.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12c:from]; MLMMJ_DEST(0.00)[freebsd-fs]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N not an FS developer, mostly an occasional FBsd installer these days on bigger hw but I do run Pi and want. to run FBsd on Pi. I got a P4, wound up on (unhappy!) Ubuntu for ZFS on a radxa SATA hat. I really wanted FreeBSD but it wasn't ready for prime time when I commissioned the system. FWIW I would really appreciate the installer logic making this kind of protective MBR+GPT outcome work, especially on the hardware like the PI which has its own peculiarities in boot. Having to work out the special cases for each box is a pain, but if I can incur the pain in "you" rather than in me, its pain once, works everywhere. I think thats the kind of incurred pain we want! -G On Fri, Mar 18, 2022 at 2:19 PM Warner Losh wrote: > > > > On Thu, Mar 17, 2022 at 7:20 AM Karl Denninger wrote= : >> >> First, the "why" -- I wish to have *two* OS partitions, a data partition= and a config partition under NanoBSD on a Pi3 or 4. Both boot using EFI a= nd the "3", at least, appears to refuse to do so off a GPT-labeled disk. T= his means I need *five* slices and MBR can only do 4. >> >> I attempted to have one slice be "Freebsd" with the two OS partitions in= side it, which would work *except* it doesn't because I can't set "bootme" = on those; the EFI loader always finds the first usable UFS partition and bo= ots it. I need to be able to toggle that to boot the *second* partition. >> >> I've replaced boot1.efi (quite some time ago) with loader_lua.efi in the= EFI partition. This works, but there does not appear to be a way to tell = it that I want it to default to something other than the first bootable par= tition it finds > > > It follows the EFI Boot Manager protocol, but the RPi doesn't give a good= way to persist that data. > > If you could get GPT working, you could use gptboot.efi, which allows you= to set which GPT partition to boot. We use that at Netflix for this exact = scenario. > > More, see below... > >> The intent is to enable the capability to upgrade the OS without having = to wipe/reload the card the unit boots from, then set the other partition a= s the "next boot." This works quite nicely with nanoBSD generally for MBR= -bootable devices (and I use it with the pcEngines boards), but doesn't on = the Pi due to requiring the EFI partition which means I run out of slots, n= ever mind that the loader will still find andn boot the first one. > > So, we read in \efi\freebsd\loader.efi off the ESP by default. We use it = to set boot environment variable (not UEFI ones, though there's a UEFI over= ride for this filename) > > This lets you set currdev to be the device that you wish to boot off of i= n there. This will load all the /boot files off that partition (at least al= l the lua scripts, config, etc). I've tested this, but wound up using the G= PT method for selecting partitions because that's operationally better for = the purpose that I'd needed this for. > > This won't help with the gpart creation question, nor with the mkimage is= sue. The RPi requires the MBR partitioning to find things. GPT goes hand in= hand with MBR, since we put a 'protective mbr' on the disk in addition to = the GPT tables. That's part of the GPT spec. mkimage could be hacked to cre= ate this hybrid, where you'd have one FAT slice in the MBR world, and you c= ould have the full layout you want with GPT. However, that's kinda weird, a= nd I don't know how our code would cope with that (I've never tried it, tho= ugh I have discussed it theoretically with benno when he was trying to have= a unified gpt/iso boot loader in BIOS land).... > > Warner