boot loaders got fatter in the last few days

[Freddie Cash]

On Fri, Mar 18, 2016 at 2:45 PM, Allan Jude <allanjude at freebsd.org> wrote:

> On 2016-03-18 17:41, Freddie Cash wrote:
>
>>
>> On Fri, Mar 18, 2016 at 10:39 AM, Conrad Meyer <cem at freebsd.org
>> <mailto:cem at freebsd.org>> wrote:
>>
>>     On Fri, Mar 18, 2016 at 10:03 AM, Allan Jude <allanjude at freebsd.org
>>     <mailto:allanjude at freebsd.org>> 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):
>>      >>
>>      >> -r--r--r--  1 root  wheel   85794 Mar 18 16:47 /boot/gptboot
>>      >>
>>      >> from a machine I still have not updated(r296719):
>>      >>
>>      >> -r--r--r--  1 root  wheel   16059 Mar 13 21:01 /boot/gptboot
>>
>>     So the loader grew 70 kB.  How big are your disks?
>>
>>      >> I noticed because mu gpt boot partition is 64K and gptzfsboot just
>>      >> passed 100K.
>>      >
>>      > This is a side effect of the loader gaining the ability to boot
>>     from GELI
>>      > encrypted partitions.
>>      >
>>      > ...
>>      >
>>      > 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.
>>
>>
>>     I think we should just suggest that boot partitions be much larger
>>     than 64kB (1MB is still <0.1% of any disk sold today) and not worry
>>     about it too much.  Embedded applications can disable GELI loader
>>     support to save a few bytes.
>>
>>
>> ​The boot partition doesn't necessarily need ​
>> ​to be 1 MB (and can't due to some issues with the assembler used right
>> now, or something like that).  We just need to make sure people have
>> slack space in their partition table to expand into in the future.
>>
>> Using "-a 1M" in your gpart command to create your first data partition
>> gives you that slack space.
>>
>> gpart create -s gpt ada0
>> gpart add -t freebsd-boot -s 256K -l boot ada0
>> gpart add -t freebsd-ufs  -s 10G  -l root -a 1M ada0
>>
>> That leaves ~756 KB of free space between the end of the boot partition
>> and the start of the first data partition.  Increasing the size of the
>> boot partition in the future is as easy as (no formatting of disks
>> required):
>>
>> gpart delete -i 1 ada0
>> gpart add -t freebsd-boot -s 512K -l boot ada0
>> gpart bootcode -b ... -p ... ada0
>>
>> It's a handy pattern I've gotten used to over the years, ever since the
>> first 4K sector harddrives were advertised (as alignment of filesystems
>> was/is *very* important)​.
>>
>> Even on disks that will be used solely for ZFS I've taken to creating
>> GPT partitions starting at 1 MB.  And it's saved me from having to
>> reformat disks when moving from a separate root filesystem (no USB
>> sticks) to root-on-ZFS as there was 1 MB of free space at the start of
>> every disk for creating boot partitions.  :)
>>
>> --
>> Freddie Cash
>> fjwcash at gmail.com <mailto:fjwcash at gmail.com>
>>
>
> This also has the handy side effect of allowing you to switch to booting
> with UEFI, which currently uses an 800kb fat file system


​And I'm pretty sure I read somewhere that the 10.x installer defaults to
using "-a 1M" when partitioning new disks, although I haven't installed ​

​any 10.x systems from scratch yet (just upgrades from 9.x).​

-- 
Freddie Cash
fjwcash at gmail.com