Hi, I had the same problems, however, there is one more regression after these changes. It stably reproduces if you use EFI_STAGING_SIZE. I have custom FreeBSD distributive which has a sufficiently large mfsroot which is loaded through UEFI mode.
To solve the problem, it was suggested to increase this variable and rebuild /sys/boot: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209944 Also, it has to be increased periodically for some reason: https://svnweb.freebsd.org/base/stable/11/sys/boot/efi/loader/copy.c?r1=305779&r2=305778&pathrev=305779 I've try to ask why than threatens to increase this parameter at once large (or make it dependent on RAM): https://lists.freebsd.org/pipermail/freebsd-hackers/2016-November/050142.html but there are no answer options. At the moment, on r315141 boot via UEFI is fixed without EFI_STAGING_SIZE. With EFI_STAGING_SIZE=768 i got regression after last changes in panic with follow message: failed to allocate staging area:9 failed to allocate stating area Failed to start image provided by ZFS (5) http://pasteboard.co/IvbhU9Ffu.jpg I believe that there mfsroot may be greater than 64MB soon or later. Also there are no problems with loading big mfsroot images when MBR method is used. PS: I have ZFS-on-root system. With EFI_STAGING_SIZE=768 I lived with constant CURRENT svnup/rebuilds for about a year. So I will be glad if you pay attention to this. PPS: How to reproduce: 1) EFI_STAGING_SIZE=768 in /etc/make.conf 2) make -C /sys/boot clean 3) make -C /sys/boot 4) make -C /sys/boot install 5) reboot Thanks! _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
