On 2016-03-18 13:42, Nikolai Lifanov wrote:
On 03/18/16 13:03, Allan Jude wrote:
On 2016-03-18 12:33, Guido Falsi wrote:
Hi,
I have just update one of my machines and noticed the booloaders files
got quite fat in the last few days, some by a big margin.
on an updated machine(r296993):
ls -l /boot/*boot*
-r--r--r-- 1 root wheel 8192 Mar 18 16:47 /boot/boot
-r--r--r-- 1 root wheel 512 Mar 18 16:47 /boot/boot0
-r--r--r-- 1 root wheel 512 Mar 18 16:47 /boot/boot0sio
-r--r--r-- 1 root wheel 512 Mar 18 16:47 /boot/boot1
-r-xr-xr-x 1 root wheel 72152 Mar 18 16:47 /boot/boot1.efi
-r--r--r-- 1 root wheel 819200 Mar 18 16:47 /boot/boot1.efifat
-r--r--r-- 1 root wheel 7680 Mar 18 16:47 /boot/boot2
-r--r--r-- 1 root wheel 1185 Mar 18 16:47 /boot/cdboot
-r--r--r-- 1 root wheel 85794 Mar 18 16:47 /boot/gptboot
-r--r--r-- 1 root wheel 110546 Mar 18 16:47 /boot/gptzfsboot
-r--r--r-- 1 root wheel 358400 Mar 18 16:47 /boot/pxeboot
-r--r--r-- 1 root wheel 341248 Mar 18 16:47 /boot/userboot.so
-r--r--r-- 1 root wheel 66048 Mar 18 16:47 /boot/zfsboot
from a machine I still have not updated(r296719):
ls -l /boot/*boot*
-r--r--r-- 1 root wheel 8192 Mar 13 21:01 /boot/boot
-r--r--r-- 1 root wheel 512 Mar 13 21:01 /boot/boot0
-r--r--r-- 1 root wheel 512 Mar 13 21:01 /boot/boot0sio
-r--r--r-- 1 root wheel 512 Mar 13 21:01 /boot/boot1
-r-xr-xr-x 1 root wheel 72152 Mar 13 21:01 /boot/boot1.efi
-r--r--r-- 1 root wheel 819200 Mar 13 21:01 /boot/boot1.efifat
-r--r--r-- 1 root wheel 7680 Mar 13 21:01 /boot/boot2
-r--r--r-- 1 root wheel 1185 Mar 13 21:01 /boot/cdboot
-r--r--r-- 1 root wheel 16059 Mar 13 21:01 /boot/gptboot
-r--r--r-- 1 root wheel 41511 Mar 13 21:01 /boot/gptzfsboot
-r--r--r-- 1 root wheel 288768 Mar 13 21:01 /boot/pxeboot
-r--r--r-- 1 root wheel 341208 Mar 13 21:01 /boot/userboot.so
-r--r--r-- 1 root wheel 66048 Mar 13 21:01 /boot/zfsboot
I noticed because mu gpt boot partition is 64K and gptzfsboot just
passed 100K.
Is this expected and I'm supposed to repartition or is this an unwanted
mistake?
Thanks in advance.
This is a side effect of the loader gaining the ability to boot from
GELI encrypted partitions.
You can compile with LOADER_NO_GELI_SUPPORT to disable this to get back
to a smaller one if you need.
Maybe we should be putting the GELI enabled boot blocks in a different
filename? I generally wanted to avoid creating a new version of each
bootcode with GELI support.
My goal somewhere down the road is to create a single bootcode that can
do UFS and ZFS, then maybe we can have gptboot and gptgeliboot or
something.
Maybe a single gptbootlite for minimum viable case of UFS+nothing fancy?
At some point in the near future users that want additional features
will re-partition and bsdinstall will create larger partitions for boot
and this won't be a problem.
'gptbootlite' would be what gptboot was until recently. I Agree with
smh@ that we don't want to end up offering 10 different bootcode options.
The installer, since 10.1 has created 512kb freebsd-boot partitions,
specifically to allow the boot loader to grow in the future.
P.S.: Allan, do you plan to enable GELI support for boot1.efi?
Yes, I hope to have this done and present it at BSDCan. Hopefully
committed earlier than that, so it will ship as part of 11.0
- Nikolai Lifanov
_______________________________________________
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"
--
Allan Jude
_______________________________________________
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"
