Date: Sat, 25 Jan 2025 11:48:46 -0700 From: "Edward Sanford Sutton, III" <mirror176@hotmail.com> To: questions@freebsd.org Subject: Re: Can't upgrade 13.3->13.4, kernel hangs at launch, "Loader needs to be updated" with 13.4 loader.efi Message-ID: <CO1PR11MB47704A333D99FD810E588C14E6E22@CO1PR11MB4770.namprd11.prod.outlook.com> In-Reply-To: <7f9ccd06-01cf-230d-598a-1c8d9dcdd1c9@bluerosetech.com> References: <7f9ccd06-01cf-230d-598a-1c8d9dcdd1c9@bluerosetech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/24/25 07:03, list_freebsd@bluerosetech.com wrote: > I have a server currently running 13.3. I'm unable to upgrade it to > 13.4 because when I try to boot the upgraded boot environment, the > loader hangs where it would normally launch the kernel. The graphical > boot menu shows the "Loader needs to be updated" warning despite using > the loader.efi from 13.4. If I recall, there was a false alert giving that message which last I checked had not been added to errata or similar areas. If nothing has changed and you are using ZFS, you should make sure the loader is upgraded before doing a `zpool upgrade` and then just ignore the message. The ZFS boot issue people have doesn't occur until there is an upgrade performed to the pool and no upgrade done to the loader; the older loader doesn't understand the newer pool features so will refuse to read from it to avoid misunderstanding it. Both upgrades are only performed manually and not by freebsd-update so booting isn't broken from that unless you did that upgrade yourself. Boot environments do not protect a user from this mistake; either you had to create a whole pool checkpoint that you could roll back or update the boot loader to be able to fix that issue without having to rebuild the pool from scratch. The installer can setup both a EFI and older MBR boot loaders on the same disk. If your configuration had that and you only upgraded one but it isn't being used for whatever reason then you would be unexpectedly on an older loader. Review `gpart show` to look for for "efi" and "freebsd-boot" to know if you have UEFI and MBR booting setup on that disk. > My setup is EFI boot to a ZFS root (zpool mirror) using boot > environments. Steps: > > 1. Use bectl to create a 13.4 BE > 2. Mount, chroot, freebsd-upgrade 13.3->13.4 as of 24 Jan 2025 > 3. mount EFI partitions > 4. copy loader.efi from 13.4 to both EFI partitions > 5. unmount the aforementioned > 6. bectl activate -t 13.4 > 7. shutdown -r now > 8. Observe loader hang trying to launch the 13.4 kernel > 9. Reset, observe BE safely return to 13.3 > > Watching the console, the pre-graphical part goes by too quickly for me > to read, but I do catch a big box made of asterisks that looks like the > one shown in a forum thread[1] about this issue. When I get to the > graphical boot menu, it has the "Loader needs to be updated" warning > just above the autoboot countdown. If you have access to a video camera (even a cell phone with it) then you could make a recording that you could load into a player to let you stop on the correct frames. Many players let you slow down the video a lot and navigate one frame at a time to make it easier to hit that short moment or else ffmpeg could turn the video into separate jpg images for review. > The loader loads the kernel and modules, shows EFI framebuffer > information, then where it normally would launch the kernel, it > hangs[2]. Hard reset and the system happily boots back into 13.3 (many > gratitudes to those who created Boot Environments). My understanding is that is not the symptoms of the loader being unable to read a new ZFS pool. I thought that was still leaving the loader as a question for the system. A boot environment didn't roll back the efi file so after you upgraded it you should still be on the new loader when you launched 13.3. I'd guess we need to therefore focus on the kernel and its modules. What does your /boot/loader.conf look like? Is your UEFI/BIOS up to date? I'm thinking some kind of kernel module incompatibility/bug, kernel bug, motherboard UEFI bug, or hardware issue. > I've tried recreating the 13.4 BE thinking I broke something, but it's > repeatable. If I try to boot 13.4, I get the loader update warning and > a hung system. Reboot back to 13.3, update warning disappears, kernel > boots without issue. > > I also verified that the loader in each EFI partition is the one from 13.4: > > # bectl mount 13.4 /tmp/BE13.4 > Successfully mounted 13.4 at /tmp/BE13.4 > # mount /boot/efi0 > # mount /boot/efi1 > # ls -l /boot/loader.efi /tmp/BE13.4/boot/loader.efi /boot/efi0/efi/ > freebsd/loader.efi /boot/efi1/efi/freebsd/loader.efi > -r-xr-xr-x 1 root wheel 868352 Jan 24 04:47 /boot/efi0/efi/freebsd/ > loader.efi* > -r-xr-xr-x 1 root wheel 868352 Jan 24 04:47 /boot/efi1/efi/freebsd/ > loader.efi* > -r-xr-xr-x 2 root wheel 906752 Jun 27 2024 /boot/loader.efi* > -r-xr-xr-x 2 root wheel 868352 Jan 24 04:47 /tmp/BE13.4/boot/loader.efi* > > and confirmed those are the only loaders configured: > > # efibootmgr -v > Boot to FW : false > BootCurrent: 0000 > Timeout : 10 seconds > BootOrder : 0000, 0001, 0004, 0014 > +Boot0000* FreeBSD-disk0 HD(2,GPT,fa3c15e1-1bdb-11ee-a300- > ac1f6b6b9e1c,0x28,0x32000)/File(\efi\freebsd\loader.efi) > nvd1p2:/efi/freebsd/loader.efi (null) > Boot0001* FreeBSD-disk1 HD(2,GPT,f6e68146-1bdb-11ee-a300- > ac1f6b6b9e1c,0x28,0x32000)/File(\efi\freebsd\loader.efi) > nvd0p2:/efi/freebsd/loader.efi (null) > Boot0004* UEFI: Built-in EFI Shell VenMedia(5023b95c-db26-429b-a648- > bd47664c8012) > Boot0014 Hard Drive BBS(HD,,0x0) > > > I saw PR/282001 related to this, and I also saw some of the earlier > mailing list about it with the RC versions. But this is a release > version of 13.4, so I figured it would be fixed already. That bug report concludes that the problem is the message always appears despite if the loader is updated or not and will be fixed in 13.5. Once an administrator updates their boot loader they should ignore the message for the remainder of the time they are on 13.4. So its fixed but only for a future version and the bug doesn't interfere with booting. If no release note about it was issued for 13.4 then I don't know why as it seems common enough for users to be able to hit this issue even if it can just be ignored. > What am I missing? Maybe something useful is lurking within unshared hardware specifications > 1: https://forums.freebsd.org/threads/loader-needs-to-be-updated-14- > stable.94857/ > 2: https://pasteboard.co/8gC1qfLY6zmL.png >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CO1PR11MB47704A333D99FD810E588C14E6E22>