From nobody Tue Sep 20 20:36:02 2022 X-Original-To: freebsd-arm@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 4MXCxW2JL4z4dMFF for ; Tue, 20 Sep 2022 20:36:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 4MXCxV3lh7z3J2b for ; Tue, 20 Sep 2022 20:36:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2a.google.com with SMTP id m66so4461149vsm.12 for ; Tue, 20 Sep 2022 13:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=AWbPqSH+k+9G31tGoFda1Tej9TrahrH8WgFd42ZEE6c=; b=79S7JNDXGXb5FlSUf7fwNdM1jyYaTdP4ACoG/Uca1DdnhEgMPV5s8jAe5saJuLZDbU CChTaUJYOBZifDOKhQ7VGiNymVKLWn8eTNM5X4OkM31YYPX9L4feyci+RpXfEQ0jPHa5 skrC6rBckNl6SfCyaP4v2SdManw445Cj7oX5+2MqTR2Z/VY+wMOUVVLEOmH6oXh4+4EA TVhD5iNOnqR/VAIabopld/Dar++OZerWaS5BjvFzNE1UtfBEFZx/EZ6zS0z4o78aVw2x r3fc+anb+fhFoo37Cv6HlmTBrOBe4m3XJVYhNb24m/aYd/1KGOaXAvzDMglNw/eTkfri sz8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=AWbPqSH+k+9G31tGoFda1Tej9TrahrH8WgFd42ZEE6c=; b=nVwCKsNTiq12uGqCklHJRuMffPpEilh/rm8AT6Ezn4RwB58TVhjUJYzrx0xfjVPUqN u6Gkx2ry7SiL5uehORbad00dAZgpYa8CnsnqbydwWrEQXyKew6bC9z2J5UbHHI8DaEKw WIgU/HeSaTIAX9Y65SmsG0pyWCpo2mDDSfqnNd448gXoMCXUNckAiIjQ56zIQQCzKy6c YAPQbgimZCAj75FB6UrsP1N/MuHx3WPhT3gO3kevtJmtjHgarqJqSafufWkbMvasKHhj rIkh9v4b2hHqLmRwGONzmkd+qkR/sWIp8YcJNUcx46ifVQ+xh5ucxZcq0raR43BiUK8o ggLg== X-Gm-Message-State: ACrzQf0Aw/oV2e8MV3J5xWw2AH60i5gWFI5ouUnmJNoUXGVVnte+pgka uREHbZfA4NQL4gU6HDqJKtqblCdDuKXZPG+XhQ6/flzYjWc= X-Google-Smtp-Source: AMsMyM6e7e7piwkHO9x5TCCvzayTbQkIa95AT0wN8IW35Ph96kqDJ9S+thEsFdkvzk7NliXZIeg/iY5Qa9e/I9KlNFg= X-Received: by 2002:a67:b209:0:b0:397:1b01:4223 with SMTP id b9-20020a67b209000000b003971b014223mr9143993vsf.67.1663706173732; Tue, 20 Sep 2022 13:36:13 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 20 Sep 2022 14:36:02 -0600 Message-ID: Subject: Re: following -current on rpi4 with zfs-on-root To: Marek Zarychta Cc: "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000007f0fe905e921c7eb" X-Rspamd-Queue-Id: 4MXCxV3lh7z3J2b X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=79S7JNDX; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2a) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.99)[-0.991]; NEURAL_HAM_LONG(-0.98)[-0.984]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2a:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000007f0fe905e921c7eb Content-Type: text/plain; charset="UTF-8" On Tue, Sep 20, 2022 at 10:29 AM Marek Zarychta < zarychtam@plan-b.pwste.edu.pl> wrote: > W dniu 20.09.2022 o 14:33, void pisze: > > On Mon, Sep 19, 2022 at 09:48:42PM -0600, Warner Losh wrote: > > > >> I've updated UPDATING in https://reviews.freebsd.org/D36629. Please > >> review. > > > >> For EFI, there are many choices. The default installation places > >> loader.efi into the ESP in EFI\FREEBSD\LOADER.EFI. The following > >> updates it (assuming the ESP is on p1, and isn't already mounted): > >> mount -t msdos /dev/ada0p1 /boot/efi > >> cp /boot/efi/loader.efi /boot/efi/efi/freebsd > >> If you have a non-standard setup, please see the EFI notes section. > > > > My non-expert opinion: > > > > 1. ideally there should be an indication in what circumstances > > the above is required, because it might not be possible to infer > > for the non-expert (with regards to the above) user > > While following CURRENT branch, updates of the ESP loader have to be > done quite often. For STABLE branches, it might not be required at all > for the whole lifecycle. Reading UPDATING and commit messages could help. > They are only ever needed after 'zfs upgrade' on the zpool that you are booting from. > > 2. if it needs to happen, where in the buildworld/kernel/install/ > > etcupdate/reboot sequence is it required? I would guess after > > etcupdate and before reboot, but guessing isn't the same as knowing. > > It would be great if this was in the Source of Truth(tm). > Yes, the order should be: buildworld, buildkernel, installkernel, reboot, installworld, install new ESP loader, zfs upgrade. You don't need to do the last two steps if you don't do the last step. > There is no official HOWTO upgrade for arm64 on ZFS. Upgrading from > sources is a pretty straightforward and standard procedure described in > the handbook[1]. Usually, such an upgrade is done not in-place, but by > cross-building and cross-instaling on amd64 machine, so rebooting is not > required. > > To upgrade the loader, you need to copy _newly_ built file > /boot/loader_lua.efi to EFI/BOOT/bootaa64.efi on ESP partition. So > upgrading loader on ESP partition can be performed no earlier than after > completing installworld, which is too late if you are going to strictly > follow[1] and reboot between installkernel and installworld steps. If > you are going to follow the handbook, you can find in the OBJDIR freshly > built loader > (/usr/obj/usr/src/arm64.aarch64/stand/efi/loader_lua/loader_lua.efi) and > copy it to the ESP prior to rebooting as described in review D36629[2]. > My order doesn't require copying from the objtree :). Warner > [1] https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld > [2] https://reviews.freebsd.org/D36629 > > -- > Marek Zarychta > --0000000000007f0fe905e921c7eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Sep 20, 2022 at 10:29 AM Mare= k Zarychta <zarychtam@p= lan-b.pwste.edu.pl> wrote:
W dniu 20.09.2022 o=C2=A014:33, void pisze:
> On Mon, Sep 19, 2022 at 09:48:42PM -0600, Warner Losh wrote:
>
>> I've updated UPDATING in https://reviews.freebsd.org/= D36629. Please
>> review.
>
>> For EFI, there are many choices. The default installation places >> loader.efi into the ESP in EFI\FREEBSD\LOADER.EFI. The following >> updates it (assuming the ESP is on p1, and isn't already mount= ed):
>> mount -t msdos /dev/ada0p1 /boot/efi
>> cp /boot/efi/loader.efi /boot/efi/efi/freebsd
>> If you have a non-standard setup, please see the EFI notes section= .
>
> My non-expert opinion:
>
> 1. ideally there should be an indication in what circumstances
>=C2=A0 =C2=A0=C2=A0 the above is required, because it might not be poss= ible to infer
>=C2=A0 =C2=A0=C2=A0 for the non-expert (with regards to the above) user=

While following CURRENT branch, updates of the ESP loader have to be
done quite often. For STABLE branches, it might not be required at all
for the whole lifecycle. Reading UPDATING and commit messages could help.

They are only ever needed after 'zfs= upgrade' on the zpool that you are
booting from.=C2=A0
=
=C2=A0
> 2. if it needs to happen, where in the buildworld/kernel/install/
>=C2=A0 =C2=A0=C2=A0 etcupdate/reboot sequence is it required? I would g= uess after
>=C2=A0 =C2=A0=C2=A0 etcupdate and before reboot, but guessing isn't= the same as knowing.
>=C2=A0 =C2=A0=C2=A0 It would be great if this was in the Source of Trut= h(tm).

Yes, the order should be:
<= div>
buildworld, buildkernel, installkernel, reboot, installw= orld, install new ESP
loader, zfs upgrade. You don't need to = do the last two steps if you don't
do the last step.


There is no official HOWTO upgrade for arm64 on ZFS. Upgrading from
sources is a pretty straightforward and standard procedure described in the handbook[1]. Usually, such an upgrade is done not in-place, but by
cross-building and cross-instaling on amd64 machine, so rebooting is not required.

To upgrade the loader, you need to copy _newly_ built file
/boot/loader_lua.efi to EFI/BOOT/bootaa64.efi on ESP partition. So
upgrading loader on ESP partition can be performed no earlier than after completing installworld, which is too late if you are going to strictly follow[1] and reboot between installkernel and installworld steps. If
you are going to follow the handbook, you can find in the OBJDIR freshly built loader
(/usr/obj/usr/src/arm64.aarch64/stand/efi/loader_lua/loader_lua.efi) and copy it to the ESP prior to rebooting as described in review D36629[2].
=

My order doesn't require copying from = the objtree :).

Warner


[1] https://docs.freebsd.org/en/bo= oks/handbook/cutting-edge/#makeworld
[2] https://reviews.freebsd.org/D36629

--
Marek Zarychta
--0000000000007f0fe905e921c7eb--