Re: Error: "Loader need to be updated" on boot in various combinations

From: Edward Sanford Sutton, III <mirror176_at_hotmail.com>
Date: Tue, 24 Dec 2024 17:24:45 UTC
On 12/24/24 09:09, Christopher Sean Hilton wrote:
> I'm in the process of updating a set of machines from FreeBSD 13.2 and FreeBSD 13.3 to
> 13.4. If the machine starts on 13.2, then my process is:
> 
>      ```
>      # freebsd-update upgrade -r 13.3-RELEASE
>      ...
>      # freebsd-update install; reboot
>      ...
>      # freebsd-update install
> 
>      ...
>      # freebsd-update upgrade -r 13.4-RELEASE
>      ...
>      ```
> 
> I haven specifically watched, but I will next time, but when I do this I end up with a
> machine that boots fine but sends the message:
> 
> - "Loader needs to be updated"

   The 'tldr' is likely answered by the second paragraph below as 
'seeing that after updating the code is a bug; it will go away after a 
future update'. Not sure why at least an errata wasn't created.
   This is a newer prompt. freebsd-udpate (among other upgrade steps) 
does not update the boot loader code. Usually boot loader changes are 
slow enough that its nice to have when things change but not a 
requirement; some changes are bugfixes instead of new features or minor 
adjustments that may be beneficial.
   As the prompt itself is newer, it hasn't been a bug free experience. 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282001 covered 
receiving the prompt on 13.4 when it wasn't valid. The false-prompting 
bug will disappear with updates past 13.4.
   If booting a root on ZFS, the bootloader needs to be updated to 
understand newer ZFS features. If the feature requires full 
support+understanding and your boot loader doesn't support that feature 
then a pool upgrade becomes unbootable until updating the boot loader. 
If you update a root-on-zfs pool, you want to make sure you have updated 
the loader accordingly. Otherwise the last thing coming to mind was I 
think ARM related for bootcode changes that seemed of importance.

> All of the machines are VMs running of VMware Fusion or ESXi so I can Snapshot the machines
> leaving me free to do some experimentation in my search for a solution. However, searching
> around the internet hasn't produced a solution to this problem. I'll give two examples:

At a glance your steps below sound like you were on track for how to 
handle those two types.

> One of the machines is an aarch64 VM with ZFS root filesystem.
> 
>      ```
>      $ gpart show
>      =>      40  83886000  nda0  GPT  (40G)
>              40    532480     1  efi  (260M)
>          532520      2008        - free -  (1.0M)
>          534528  33554432     2  freebsd-swap  (16G)
>        34088960  49795072     3  freebsd-zfs  (24G)
>        83884032      2008        - free -  (1.0M)
> 
>      =>       40  268435376  nda1  GPT  (128G)
>               40   33554432     1  freebsd-swap  (16G)
>         33554472  234880944     2  freebsd-zfs  (112G)
> 
>      $ mount | egrep efi
>      /dev/gpt/efiboot0 on /boot/efi (msdosfs, local)
>      $
>      ```
> 
> I've copied `/boot/loader.efi` to both `/boot/efi/efi/freebsd/loader.efi` and
> `/boot/efi/efi/boot/bootaa64.efi`. The `efibootmgr -v` command reports that the
> `.../freebsd/loader.efi` file is the one in use. Unfortunately, this didn't fix the problem.
> 
> ----------------------------------------
> 
> My second machine is an amd64 VM with a UFS root filesystem:
> 
>      ```
>      $ gpart show
>      =>      40  33554352  da0  GPT  (16G)
>              40      1024    1  freebsd-boot  (512K)
>            1064   2096128    2  freebsd-ufs  (1.0G)
>         2097192   8388608    3  freebsd-swap  (4.0G)
>        10485800  12582912    4  freebsd-ufs  (6.0G)
>        23068712   2097152    5  freebsd-ufs  (1.0G)
>        25165864   8388528    6  freebsd-ufs  (4.0G)
> 
>      $
>      ```
> 
> I found a [post on the FreeBSD
> forums](https://forums.freebsd.org/threads/update-of-the-bootcodes-for-a-gpt-scheme-x64-architecture.80163/)
> that suggested using gpart as follows:
> 
>      `gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da0`
> 
> Again, since this is a virtual machine, and honestly not a hard one to rebuild, I took a
> snapshot, fired off the gpart command, and again found the "Loader needs to be updated"
> error message.
> 
> ----------------------------------------
> 
> I understand that there are lots of different situations here. I'm willing to fork my
> question into two questions to keep things easy to follow.
> 
> 
> **Q:** _What's the root cause here?_ It seems like I'm not addressing the root cause.
> 
>