Created attachment 251535 [details] core-lua-68-error-booting-14.1-release Unable to automatically boot after upgrading to 14.1-RELEASE. There are two cases, one coming from 13.3-RELEASE and the other (mine) coming from 14.0-RELEASE-p6. For reference this thread contains the error in the very first post, picture included (attached here as well). https://forums.freebsd.org/threads/problem-upgrading-from-13-3-release-to-14-1-release-lua-error-upon-booting-kernel.93737/ Both boxes booted after physically inputting 'boot' or 'autoboot', but they did not execute the whole boot process without manual intervention.
(In reply to Albert Valbuena from comment #0) You need to update loader.efi on your EFI System Partition, this was a thing added many versions ago. There will probably be two copies of loader.efi, one in \EFI\FreeBSD and one in \EFI\Boot, and both should be kept up to date if they're both FreeBSD just in case.
(In reply to Kyle Evans from comment #1) The device has become bricked after attempting an overdue BIOS upgrade (non related to FreeBSD). Since it does not equip a backup copy, it's now a paperweight. I can't test further with an EFI equipped system at this time.
(In reply to Albert Valbuena from comment #2) Oof, sorry to hear that. =( I'm going to NOT A BUG this, but feel free to comment back if you or anyone else discovers there's still an issue here.
(In reply to Kyle Evans from comment #3) Thanks. PS: Rebuilt the whole thing on a new box with modern EFI, first reusing the same exact drive without a hassle. Reinstalled just for the sake of starting fresh on a new box.
On an otherwise routine update from 14.0-RELEASE-p6 got bitten by exactly this issue.
Also got hit by this on a 14.2-RELEASE (that was in place upgraded from at least FreeBSD-12. This time on AMD, not intel. Same workaround (i.e. checking for lua_path == nil; set to lua_path = "/boot/lua" fixes it.
And another machine coming from 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 that started its live as a 12.0 in Jan 2019 and was upgraded in place ever since.
Let's get Warner's thoughts here- I don't want to be committed to keeping compat shims around until the end of time, but it appears that we might need to revisit how we document bootloader upgrade procedure.
OK. I've thought through this. We have two strategies here. This is kinda not a bug, but also kinda a huge big rock sticking out for people to trip over that we should do something about, since we've known about it for a while now... (1) People Must Upgrade. Sorry, but they have to. We can't support the long dead hand of the past forever. (2) We Must Document How. We do already, but it needs be greatly improved. Now, having said (1) and (2) there's way too much friction for both. So I'm proposing the following (a) We add a version number checking to the lua scripts. The boot loader already has a loader_version (4th) or loader.version (lua) exported. This is the boot program revision. Right now it's among the jankiest jank[1] still in the jankville part of the boot loader. Proposal: Bump this to 2.0 everywhere. Nobody cares today, really, what it is, but 2.0 is a good starting point. I also propose exporting loader.freebsd_version (being the __FreeBSD_version of the build environment (usually the sources used to build it except). We also compile these version into a vers.lua ala vers.c. We enhance loader.lua to warn if freebsd_version mismatches with the loader. The warning will be "This is old, smelly code, update to new shiny code ASAP, but maybe this will work out for you, good luck with that" or similar, perhaps more word smithed: loader.efi is $loader_freebsd_v than the system you are booting $lua_freebsd_v This may or may not work, please upgrade your ESP. Also, if loader major rev rev != loader rev, and we can read the new root filesystem, and it's EFI and we find a /boot/loader.efi on the new root filesystem, chain load that if the root filesystem != the image location we got the loader.efi from. Proclaim even louder that an upgrade is needed :). But this will get people over the hump if they have really really old loader with shiny new lua scripts. Still working out some of the technical details on this one. Also, all 'backwards compat' workarounds should explicitly whine when they are used so people know they have stale loader(s) afoot. For (2) we need to put it in the loader.efi man page, which is it's how horror show right now. We likely also need a (3) script to update boot blocks no matter where they are, since we've grown at least 4 supported environments that are various forms of popular (x86 BIOS MBR, x86 BIOS GPT, EFI and UBOOT+EFI) that we should cover. We should also strongly encourage people to move to a more standard layout and also look to adding this to installworld (perhaps optionally at first). (2) and (3) are needed to solve the ZFS problem (which we can't just chain-boot away, though other counter measures are needed). [1] https://www.dictionary.com/e/slang/janky/
Hmmm, 3.0. version.veriexec already uses 2.0. And what to do about veriexec... I think in that environment, you lose since it's all supposed to be up-to-date, but I need to socialize that I guess.
https://reviews.freebsd.org/D45890 (and prior reviews) have a patch chain. It's least disruptive to bump all the versions to 3.0. Then complain if we're < 3.0 Although I could check different symbols that we have workarounds for, this is the simplest, catch-all way to proceed. It may give some false positives about needing to upgrade from a strictly functional standpoint, but it will show when you have a mismatch. Check them out. tl;dr: Added back the workarounds, whine if the loader's too old. In the future, we'll do something more, maybe. It was the quickest thing I could do. and once reviewed should be in 14.3
(In reply to Kyle Evans from comment #8) Sorry for not knowing but I really need to ask this. Quote: "it appears that we might need to revisit how we document bootloader upgrade procedure." My first question: What is really needed to upgrade? What is it? I'm getting confused now. On the first reply this was mentioned: "update loader.efi on your EFI System Partition" My second question: Where is that documentation? As a user I expect this update-upgrade things to happen somewhat "automagically" following the handbook documentation for system upgrade. Are we talking about this specific? https://docs.freebsd.org/en/books/handbook/cutting-edge/#updating-bootcode PS: Sorry for my ignorance, but I don't want to be here again in a few years time.
(In reply to Albert Valbuena from comment #12) Yea, that lack of clarity is what needs to be updated. We need to describe how to find the ESP. Most systems there's only one, and it's a FAT partition of type 'efi'. You need to mount this partition somewhere. It's supposed to be mounted on /boot/efi, but older installs don't have that. But I'll assume that you've mounted it by hand here. If you are dual boot, you may need to skip this step (since the dual booting often comes via bootXXX.efi (XXX = x64 on amd64 and aa64 on aarch64)). But if you need to replace it, you'll sudo cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi (amd64). the current installer will put this here if there isn't one already as a fallback to buggy / non-conformant / weird EFI implementations that use this by default. Next, you'll need to sudo cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi. For most people, that's all that needs to be done. For people that have special use cases, or do weird stuff, the instructions may differ. Dual booting is tricky, because some people do it just with efi variables and their bios boot loader, others do it with refind, etc.
I needed to upgrade my bootloader. But reading the release notes (https://www.jan0sch.de/post/freebsd-upgrade-uefi-bootloader/) did not give me confidence I really understood the process. " The ESP may already be mounted on /boot/efi. Otherwise, the partition may be mounted manually, using the partition listed in the efibootmgr output (nda0p1 in this case): mount_msdosfs /dev/nda0p1 /boot/efi. See loader.efi(8) for another example. The value in the File field in the efibootmgr -v output, \EFI\freebsd\loader.efi in this case, is the MS-DOS name for the boot loader in use on the ESP. If the mount point is /boot/efi, this file will translate to /boot/efi/efi/freebsd/loader.efi. (Case does not matter on MS-DOSFS file sytems; FreeBSD uses lower case.) Another common value for File would be \EFI\boot\bootXXX.efi, where XXX is x64 for amd64, aa64 for aarch64, or riscv64 for riscv64; this is the default bootstrap if none is configured. Both the configured and default boot loaders should be updated by copying from /boot/loader.efi to the correct path in /boot/efi. " Although this paragraph seems to contain all the important information, actual commands compared to actual efibootmgr output are a lot more concise and understandable than saying, "to the correct path," which terrifies me to get wrong. Luckily I found the below written in a language I can both understand and validate the sense of: https://www.jan0sch.de/post/freebsd-upgrade-uefi-bootloader/ For argument's sake, why is there no automatic or semi-automatic process to help users upgrade the boot loader, even if it simply is a prompting of "I think you need to type "mount," and them "cp"? Yes, users need to upgrade, but freebsd-update doesn't warn them about that, and neither do the instructions here: https://www.freebsd.org/releases/14.0R/installation/. And yes, I failed to read the release notes the first time...