Re: boot loaders got fatter in the last few days

From: Allan Jude <allanjude_at_freebsd.org>
Date: Fri, 18 Mar 2016 14:03:51 -0400
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_at_ 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_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>


-- 
Allan Jude
Received on Fri Mar 18 2016 - 17:03:59 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:03 UTC