boot loaders got fatter in the last few days
Allan Jude
allanjude at freebsd.org
Fri Mar 18 21:49:20 UTC 2016
On 2016-03-18 17:48, Freddie Cash wrote:
>
>
> On Fri, Mar 18, 2016 at 2:45 PM, Allan Jude <allanjude at freebsd.org
> <mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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 <mailto:fjwcash at gmail.com>
Yes, when I built the 10.x 'ZFS' installer mode, I set it to do the
right thing. I'll have to look into making sure UFS via 'sade' does the
right thing though
--
Allan Jude
More information about the freebsd-current
mailing list