Hi!> > Unfortunately it contains an old version of the boot loader:[...]> We should be better about upgrading boot blocks, but EFI is kinda new and > kinda different than the other out-of-root-filesystem boot blocks we've had > in the past, so there's still some rough edges.We run many systems at remote sites. If we can't remotely upgrade without drama from 12.x to 13.x, that would be a catastrophe. Any chance this can be fixed before 13.0-REL ? -- pi at opsec.eu +49 171 3101372 Now what ?
Hi, On 19/02/2021 19:24, Kurt Jaeger wrote: > I suspect that your 'zpool upgrade' enabled things that weren't enabled > before. This caused the old boot blocks to no longer work. Correct. That' s definitely the source of the booting issue. > We should be better about upgrading boot blocks, but EFI is kinda new and > kinda different EFI is able to boot any FreeBSD box for a while. The main issue is that the legacy way to upgrade these /bootcode and partcode/ not only does not work, but do bad things. # gpart bootcode -p /boot/gptzfsboot -i 1? ada0s1 will install an old and inappropriate /partcode/. IMO, 'gptzfsboot' should be sweep off? along with 'boot1.efifat' ( by calling 'make delete-old') or be built with the right 'BOOTx64.EFI', which actually is`/boot/loader.efi` . -- David Marec http://wiki.fug-fr.org/doku.php?id=start https://diaspora.lapinbilly.eu/
On Friday, 19 February 2021 12:24:24 CST Kurt Jaeger wrote:> > > Unfortunately it contains an old version of the boot loader: > [...] > > We should be better about upgrading boot blocks, but EFI is kinda new and > > kinda different than the other out-of-root-filesystem boot blocks we've had > > in the past, so there's still some rough edges. > > We run many systems at remote sites. If we can't remotely upgrade > without drama from 12.x to 13.x, that would be a catastrophe. > > Any chance this can be fixed before 13.0-REL ? >Informed by reading the bsdinstall(8) scripts, I've been creating my own boot1.efifat thusly: #!/usr/bin/env sh TMPDIR=/mnt rm -f /boot/boot1.efifat newfs_msdos -F 32 -c 1 -L EFISYS -C 200m /boot/boot1.efifat MD=$(mdconfig -f /boot/boot1.efifat) mount -t msdosfs /dev/${MD} ${TMPDIR} mkdir -p ${TMPDIR}/efi/boot ${TMPDIR}/efi/freebsd cp -a /boot/loader.efi ${TMPDIR}/efi/boot/bootx64.efi cp -a /boot/loader.efi ${TMPDIR}/efi/freebsd/ umount ${TMPDIR} mdconfig -d -u ${MD} Then I use `gpart bootcode -p /boot/boot1.efifat ...` as usual. To avoid confusion and errors, I think a proper boot1.efifat should be put back into the base system so that people don't have to track the above recipe (which is likely to change). -- Greg
On Fri, Feb 19, 2021 at 11:24 AM Kurt Jaeger <pi at freebsd.org> wrote:> Hi! > > > > Unfortunately it contains an old version of the boot loader: > [...] > > We should be better about upgrading boot blocks, but EFI is kinda new and > > kinda different than the other out-of-root-filesystem boot blocks we've > had > > in the past, so there's still some rough edges. > > We run many systems at remote sites. If we can't remotely upgrade > without drama from 12.x to 13.x, that would be a catastrophe. > > Any chance this can be fixed before 13.0-REL ? >You can upgrade to 13 w/o hassle. The upgrade process doesn't automatically upgrade the zpools. The only problem is if you also do a 'zpool upgrade' which will change your zpool features. The fix is easy: upgrade your boot loader (bootx64.efi) on the ESP at the same time before rebooting... There's nothing really to fix here. All the code is there. It all works. The upgrade is fail safe up until the point you do the zpool upgrade, which has to be done by the system administrator. It's not done in the installer or as part of 'make installworld'. Warner
On Fri, Feb 19, 2021 at 1:41 PM David Marec <david.marec at lapinbilly.eu> wrote:> Hi, > > On 19/02/2021 19:24, Kurt Jaeger wrote: > > > I suspect that your 'zpool upgrade' enabled things that weren't enabled > > before. This caused the old boot blocks to no longer work. > > Correct. That' s definitely the source of the booting issue. > > > We should be better about upgrading boot blocks, but EFI is kinda new > and > > kinda different > > EFI is able to boot any FreeBSD box for a while. > > The main issue is that the legacy way to upgrade these /bootcode and > partcode/ not only does not work, but do bad things. > > # gpart bootcode -p /boot/gptzfsboot -i 1 ada0s1 > > will install an old and inappropriate /partcode/. >Yes. it was a mistake to try to make EFI fit into that paradigm originally. All the efifat stuff should be gone, but you misunderstand what gptzfsboot is or can do. When booting with EFI, the above command will have no effect because those boot blocks will be ignored. IMO,> 'gptzfsboot' should be sweep off along with 'boot1.efifat' ( by calling > 'make delete-old') or be built with the right 'BOOTx64.EFI', which > actually is`/boot/loader.efi` . >We can't do that. gptzfsboot is for something else that we can't get rid of: BIOS/CMS booting. It's never been used for EFI booting at all. There's no way to for EFI to use it, nor is there anyway for us to build it to just work. You have to copy BOOTx64.efi to your ESP. What we could do, but don't currently, is automate this process. That's been bogged down in implementation details. It's easy if there's only one, but if you have a USB stick installed, you don't want that to accidentally be upgraded, for example... and I have test boxes with a dozen ESPs to test different boot scenarios... And multiboot systems also can be screwed up by automatically copying things into the ESP... Warner