Re: boot loaders got fatter in the last few days

2016-03-19 Thread Nikolai Lifanov 
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  wheel8192 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  wheel7680 Mar 18 16:47 /boot/boot2
>> -r--r--r--  1 root  wheel1185 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  wheel8192 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  wheel7680 Mar 13 21:01 /boot/boot2
>> -r--r--r--  1 root  wheel1185 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.

P.S.: Allan, do you plan to enable GELI support for boot1.efi?

- 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"

Re: boot loaders got fatter in the last few days

2016-03-19 Thread Warren Block 

On Fri, 18 Mar 2016, Guido Falsi wrote:


On 03/18/16 17:54, José Pérez wrote:

Hi Guido,
maybe it's because of this:
https://svnweb.freebsd.org/base?view=revision&revision=296963



I see.

There is a problem with this though, we have howtos suggesting 64K for
the size of the freebsd-boot gpt partition:

https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1

now that size isn't sufficient anymore. We should at least update these
information soon.


I have always recommended using the largest possible size for the 
bootcode partition, 512K.  There is no reason to go with a smaller size, 
the space savings are insignificant.  It is safe to guess that bootcode 
will never get smaller.


I also recommend starting the first real partition at 1M.  This also is 
frequently ignored.


Here are my instructions:

http://www.wonkity.com/~wblock/docs/html/disksetup.html

The wiki should be updated.  Better yet, that section should be removed 
and the corrected procedure shown in the Handbook.



Also repartitioning could be problematic in certain scenarios. I think
this change should be at least published in UPDATING and maybe also in
the future release notes for 11.0.

Personally I'll find a way of reorganizing my disks to fit this change,
but it's something that could byte users.

___
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"

Re: boot loaders got fatter in the last few days

2016-03-19 Thread Guido Falsi 
On 03/18/16 17:54, José Pérez wrote:
> Hi Guido,
> maybe it's because of this:
> https://svnweb.freebsd.org/base?view=revision&revision=296963
> 

I see.

There is a problem with this though, we have howtos suggesting 64K for
the size of the freebsd-boot gpt partition:

https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1

now that size isn't sufficient anymore. We should at least update these
information soon.

Also repartitioning could be problematic in certain scenarios. I think
this change should be at least published in UPDATING and maybe also in
the future release notes for 11.0.

Personally I'll find a way of reorganizing my disks to fit this change,
but it's something that could byte users.

-- 
Guido Falsi 
___
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"

Re: boot loaders got fatter in the last few days

2016-03-19 Thread José Pérez 

Hi Guido,
maybe it's because of this:
https://svnweb.freebsd.org/base?view=revision&revision=296963

Regards,

---
José Pérez

El 2016-03-18 17:33, Guido Falsi escribió:

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  wheel8192 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  wheel7680 Mar 18 16:47 /boot/boot2
-r--r--r--  1 root  wheel1185 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  wheel8192 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  wheel7680 Mar 13 21:01 /boot/boot2
-r--r--r--  1 root  wheel1185 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.

___
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"

Re: boot loaders got fatter in the last few days

2016-03-19 Thread Freddie Cash 
On Fri, Mar 18, 2016 at 10:39 AM, Conrad Meyer  wrote:

> On Fri, Mar 18, 2016 at 10:03 AM, 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):
> >>
> >> -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
fjwc...@gmail.com
___
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"

Re: boot loaders got fatter in the last few days

2016-03-19 Thread Freddie Cash 
On Fri, Mar 18, 2016 at 2:45 PM, Allan Jude  wrote:

> On 2016-03-18 17:41, Freddie Cash wrote:
>
>>
>> On Fri, Mar 18, 2016 at 10:39 AM, Conrad Meyer > > wrote:
>>
>> On Fri, Mar 18, 2016 at 10:03 AM, 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):
>>  >>
>>  >> -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
>> fjwc...@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
fjwc...@gmail.com
___
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"

Re: boot loaders got fatter in the last few days

2016-03-19 Thread Allan Jude 

On 2016-03-18 17:48, Freddie Cash wrote:



On Fri, Mar 18, 2016 at 2:45 PM, Allan Jude mailto:allanj...@freebsd.org>> wrote:

On 2016-03-18 17:41, Freddie Cash wrote:


On Fri, Mar 18, 2016 at 10:39 AM, Conrad Meyer mailto:c...@freebsd.org>
>> wrote:

 On Fri, Mar 18, 2016 at 10:03 AM, Allan Jude
mailto:allanj...@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
fjwc...@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
fjwc...@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
___
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"

Re: boot loaders got fatter in the last few days

2016-03-19 Thread Guido Falsi 
On 03/18/16 19:05, Allan Jude wrote:
> On 2016-03-18 13:51, Guido Falsi wrote:
>> On 03/18/16 17:54, José Pérez wrote:
>>> Hi Guido,
>>> maybe it's because of this:
>>> https://svnweb.freebsd.org/base?view=revision&revision=296963
>>>
>>
>> I see.
>>
>> There is a problem with this though, we have howtos suggesting 64K for
>> the size of the freebsd-boot gpt partition:
>>
>> https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1
>>
>> now that size isn't sufficient anymore. We should at least update these
>> information soon.
>>
>> Also repartitioning could be problematic in certain scenarios. I think
>> this change should be at least published in UPDATING and maybe also in
>> the future release notes for 11.0.
>>
>> Personally I'll find a way of reorganizing my disks to fit this change,
>> but it's something that could byte users.
>>
> 
> Those old bits of the wiki should be burned with fire. The one you link
> to is from 2009 and is full of bad advice, and only covers how to
> install FreeBSD 8.x

I agree with you, having installed this one system following such advice
and having discovered also other problems.

Just yesterday I installed a ZFS system (using UEFI) straight from an
head snapshot and it did everything perfect, so I'm quite happy about
how things evolved.

What I was trying to express is that, just like me, other people could
get bitten by this change. Too me it's just an annoyance of shuffling
partitions around a little, but we should at least have a small warning
for the forthcoming release.

-- 
Guido Falsi 
___
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"

Re: boot loaders got fatter in the last few days

2016-03-19 Thread Allan Jude 

On 2016-03-18 17:41, Freddie Cash wrote:


On Fri, Mar 18, 2016 at 10:39 AM, Conrad Meyer mailto:c...@freebsd.org>> wrote:

On Fri, Mar 18, 2016 at 10:03 AM, Allan Jude mailto:allanj...@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
fjwc...@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


--
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"

Re: boot loaders got fatter in the last few days

2016-03-19 Thread Allan Jude 

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  wheel8192 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  wheel7680 Mar 18 16:47 /boot/boot2
-r--r--r--  1 root  wheel1185 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  wheel8192 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  wheel7680 Mar 13 21:01 /boot/boot2
-r--r--r--  1 root  wheel1185 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"

Re: boot loaders got fatter in the last few days

2016-03-19 Thread Steven Hartland 


On 18/03/2016 17:51, Guido Falsi wrote:

On 03/18/16 17:54, José Pérez wrote:

Hi Guido,
maybe it's because of this:
https://svnweb.freebsd.org/base?view=revision&revision=296963


I see.

There is a problem with this though, we have howtos suggesting 64K for
the size of the freebsd-boot gpt partition:

https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1

now that size isn't sufficient anymore. We should at least update these
information soon.

Also repartitioning could be problematic in certain scenarios. I think
this change should be at least published in UPDATING and maybe also in
the future release notes for 11.0.

Personally I'll find a way of reorganizing my disks to fit this change,
but it's something that could byte users.

Yes indeed I would suggest if we increase it we do by a decent amount 
e.g. jump straight to 1MB.


Regards
Steve
___
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"

boot loaders got fatter in the last few days

2016-03-19 Thread Guido Falsi 
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  wheel8192 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  wheel7680 Mar 18 16:47 /boot/boot2
-r--r--r--  1 root  wheel1185 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  wheel8192 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  wheel7680 Mar 13 21:01 /boot/boot2
-r--r--r--  1 root  wheel1185 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.

-- 
Guido Falsi 
___
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"

Re: boot loaders got fatter in the last few days

2016-03-19 Thread Steven Hartland 



On 18/03/2016 17: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  wheel8192 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  wheel7680 Mar 18 16:47 /boot/boot2
-r--r--r--  1 root  wheel1185 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  wheel8192 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  wheel7680 Mar 13 21:01 /boot/boot2
-r--r--r--  1 root  wheel1185 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.

P.S.: Allan, do you plan to enable GELI support for boot1.efi?

Makes it harder to use more features, so I would vote don't do this, 
keep a single boot image its bad enough we have separate zfs ufs loaders 
already.

___
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"

Re: boot loaders got fatter in the last few days

2016-03-19 Thread Conrad Meyer 
On Fri, Mar 18, 2016 at 10:03 AM, 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):
>>
>> -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.

Best,
Conrad
___
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"

Re: boot loaders got fatter in the last few days

2016-03-19 Thread Hans Petter Selasky 
Would the boot loaders be smaller if we had an amd64 linker with garbage 
collection?


--HPS
___
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"

Re: boot loaders got fatter in the last few days

2016-03-19 Thread Allan Jude 

On 2016-03-18 14:01, Steven Hartland wrote:


On 18/03/2016 17:51, Guido Falsi wrote:

On 03/18/16 17:54, José Pérez wrote:

Hi Guido,
maybe it's because of this:
https://svnweb.freebsd.org/base?view=revision&revision=296963


I see.

There is a problem with this though, we have howtos suggesting 64K for
the size of the freebsd-boot gpt partition:

https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1

now that size isn't sufficient anymore. We should at least update these
information soon.

Also repartitioning could be problematic in certain scenarios. I think
this change should be at least published in UPDATING and maybe also in
the future release notes for 11.0.

Personally I'll find a way of reorganizing my disks to fit this change,
but it's something that could byte users.


Yes indeed I would suggest if we increase it we do by a decent amount
e.g. jump straight to 1MB.

 Regards
 Steve
___
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"


Due to limitations in the assembly bits (pmbr.S) the maximum size is 
545kb, so the zfsboot part of the install creates 512kb partitions by 
default


--
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"

Re: boot loaders got fatter in the last few days

2016-03-18 Thread Guido Falsi 
On 03/18/16 22:41, Freddie Cash wrote:
> On Fri, Mar 18, 2016 at 10:39 AM, Conrad Meyer  wrote:
> 
>> On Fri, Mar 18, 2016 at 10:03 AM, 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):

 -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.

My strategy, which helped me in this case, is having swap space just
after the boot partition, in this way I can just resize the swap space
and boot partition and reorganize the system.

The OS will not comply about a few hundred Kilobytes swap less :)

-- 
Guido Falsi 
___
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"

Re: boot loaders got fatter in the last few days

2016-03-18 Thread Allan Jude 

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  wheel8192 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  wheel7680 Mar 18 16:47 /boot/boot2
-r--r--r--  1 root  wheel1185 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  wheel8192 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  wheel7680 Mar 13 21:01 /boot/boot2
-r--r--r--  1 root  wheel1185 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.



--
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"

Re: boot loaders got fatter in the last few days

2016-03-18 Thread Allan Jude 

On 2016-03-18 13:51, Guido Falsi wrote:

On 03/18/16 17:54, José Pérez wrote:

Hi Guido,
maybe it's because of this:
https://svnweb.freebsd.org/base?view=revision&revision=296963



I see.

There is a problem with this though, we have howtos suggesting 64K for
the size of the freebsd-boot gpt partition:

https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1

now that size isn't sufficient anymore. We should at least update these
information soon.

Also repartitioning could be problematic in certain scenarios. I think
this change should be at least published in UPDATING and maybe also in
the future release notes for 11.0.

Personally I'll find a way of reorganizing my disks to fit this change,
but it's something that could byte users.



Those old bits of the wiki should be burned with fire. The one you link 
to is from 2009 and is full of bad advice, and only covers how to 
install FreeBSD 8.x


--
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"