FreeBSD-current, panic on UEFI boot after recent changes
Subbsd
subbsd at gmail.com
Sun Mar 12 18:22:49 UTC 2017
Hi,
( I apologize if this is a duplicate - first I wrote this as reply-all
on https://lists.freebsd.org/pipermail/freebsd-current/2017-March/064971.html
thread )
After recent changes and fixes (
https://lists.freebsd.org/pipermail/freebsd-current/2017-March/065093.html
) I still had problems on host with increased EFI_STAGING_SIZE value.
I have custom FreeBSD distribution 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 fine with default
EFI_STAGING_SIZE (64)
With EFI_STAGING_SIZE=768 i got panic after recent changes 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!
More information about the freebsd-current
mailing list