Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Volodymyr Kostyrko]

Shawn Webb wrote:

On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote:

On 2017-01-27 12:05, Warner Losh wrote:

On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:



On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya)  
wrote:

Hi,
  I tried upgrading one of my workstations and unfortunately the 
freebsd-boot partition is too small (I follow manpage directions, exactly, and 
those seem to be too small as of 10.3-RELEASE timeframe), and I don???t have 
enough space or ability to resize the partition and make it bigger. So, I???m 
in need of a build knob to control the bloat, and/or having an alternative boot 
loader without geli/skein/crypto support compiled in. Would you be opposed to 
the work?
Thanks,
-Ngie



I do agree that since the geli knob is already there, it may do. Of course we 
also can think of additional knobs, but there is an issue - it wont help just 
to exclude some files, the additional features also do sit in the code, so the 
replacement stubs will be needed, also testing them all over will take some 
time. And the preprocessor spaghetti really is nasty thing to deal with;)

And then there is another issue (partly why I did the feature support in first 
place) - as the kernel does not block user from enabling the features, the user 
can end up facing non-bootable setup which is also not good, as user is using 
perfectly legal options, and still the whole thing is just rendered unusable???


I'm curious why you can't find the space for a bigger partition?
Almost all drives these days are partitioned with a little wasted
space, and that wasted space should be more than enough to cover us
here. Also, most drives have a swap partition that can be shrunk a
trivial amount to get space for this...

Warner



I need to do some testing to make a recipe that works for it, but the
other option is to use the ZFS bootcode area.

ZFS it self, reserves something like 3.5 mb of space in the ZFS
partition, for boot code. This is how we boot ZFS on MBR.

It should be possible to use this on GPT as well, we just don't.


In the future, maybe it'd be a good idea for the installer to leave
more space (a few MB, perhaps?) between the freebsd-boot and
freebsd-swap partitions? At least, for ZFS installs.


This would do anything. If you have swap after the boot partition you 
always can drop the swap, make larger boot and create the swap back on 
the free space.


--
Sphinx of black quartz judge my vow.
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Mark Martinec]

2017-01-27 01:09, Allan Jude wrote:

Yeah, most of the size is from the GELI support, not Skein, so that is
your best starting place.


On a tangential ... does the gptzfsboot really support skein checksums
in 11.0?  If so, then why does zfs not allow setting skein on a root 
pool?


  # zfs set checksum=skein xxx
  cannot set property for 'xxx': property setting is not allowed on root 
pools



Mark
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 1:03 PM, Ngie Cooper  wrote:
> On Sat, Jan 28, 2017 at 12:17 PM, Ngie Cooper  wrote:
> ...
>
>> After some creative hacking... tada!
>>
>> # find /usr/obj/usr/src/sys/boot/ -type f -name \*zfsboot -exec ls -l {} \;
>> -rw-r--r--  1 root  wheel  131584 Jan 28 12:07
>> /usr/obj/usr/src/sys/boot/i386/zfsboot/zfsboot
>> -rw-r--r--  1 root  wheel  47527 Jan 28 12:07
>> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
>
> Bah. It's still 2kB too big. I'll see if I can free up some more space
> in the text area (there was a patch kicking around at $work that might
> alleviate this a few more kB).

Ok, found the patch.

After applying all the changes, it's finally under 44kB and I can
write the bootcode to my disk:

$ sudo gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0
partcode written to da0p1
bootcode written to da0

-Ngie
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 12:17 PM, Ngie Cooper  wrote:
...

> After some creative hacking... tada!
>
> # find /usr/obj/usr/src/sys/boot/ -type f -name \*zfsboot -exec ls -l {} \;
> -rw-r--r--  1 root  wheel  131584 Jan 28 12:07
> /usr/obj/usr/src/sys/boot/i386/zfsboot/zfsboot
> -rw-r--r--  1 root  wheel  47527 Jan 28 12:07
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

Bah. It's still 2kB too big. I'll see if I can free up some more space
in the text area (there was a patch kicking around at $work that might
alleviate this a few more kB).
-Ngie
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 12:21 PM, Allan Jude  wrote:

...

> The 'zfsboot' version, is dd's into the zfs boot code area. It is read
> by the assembly code there. It is important the file be the size that
> will be read, so it is padded out. That file is currently only used for
> MBR booting from ZFS.

Thank you for the info -- it would be really nice if this was noted in
the Makefile in more detail for the next soul who wonders why the
sizes are so different.
Thanks!
-Ngie
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Allan Jude]

On 2017-01-28 15:17, Ngie Cooper wrote:
> On Sat, Jan 28, 2017 at 11:22 AM, Ngie Cooper  wrote:
>>> What created a partition that small?
>>
>> Me.
>>
>> gpart up until last summer said that users should create 44kB
>> freebsd-boot partitions -- des@ corrected that in r303289:
>>
>> -This example uses 88 blocks (44 kB) so the next partition will be
>> -aligned on a 64 kB boundary without the need to specify an explicit
>> -offset or alignment.
>> -The boot partition itself is aligned on a 4 kB boundary.
>> +We create a 472-block (236 kB) boot partition at offset 40, which is
>> +the size of the partition table (34 blocks or 17 kB) rounded up to the
>> +nearest 4 kB boundary.
>>  .Bd -literal -offset indent
>> -/sbin/gpart add -b 40 -s 88 -t freebsd-boot ada0
>> +/sbin/gpart add -b 40 -s 472 -t freebsd-boot ada0
> 
> After some creative hacking... tada!
> 
> # find /usr/obj/usr/src/sys/boot/ -type f -name \*zfsboot -exec ls -l {} \;
> -rw-r--r--  1 root  wheel  131584 Jan 28 12:07
> /usr/obj/usr/src/sys/boot/i386/zfsboot/zfsboot
> -rw-r--r--  1 root  wheel  47527 Jan 28 12:07
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
> 
> -- wait, why is the size of zfsboot vs gptzfsboot so different? Oh,
> r304321 added that as `BOOT2SIZE`. Still, it seems a bit silly to only
> increase the size of one bootloader and not the other 4 instances of
> the bootloader :/. I don't understand the point in the size
> restriction 100%, but I'll leave it be.
> 
> Patch will be available sometime next week if my testing goes well.
> 
> Cheers,
> -Ngie
> 

The 'zfsboot' version, is dd's into the zfs boot code area. It is read
by the assembly code there. It is important the file be the size that
will be read, so it is padded out. That file is currently only used for
MBR booting from ZFS.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 11:22 AM, Ngie Cooper  wrote:
>> What created a partition that small?
>
> Me.
>
> gpart up until last summer said that users should create 44kB
> freebsd-boot partitions -- des@ corrected that in r303289:
>
> -This example uses 88 blocks (44 kB) so the next partition will be
> -aligned on a 64 kB boundary without the need to specify an explicit
> -offset or alignment.
> -The boot partition itself is aligned on a 4 kB boundary.
> +We create a 472-block (236 kB) boot partition at offset 40, which is
> +the size of the partition table (34 blocks or 17 kB) rounded up to the
> +nearest 4 kB boundary.
>  .Bd -literal -offset indent
> -/sbin/gpart add -b 40 -s 88 -t freebsd-boot ada0
> +/sbin/gpart add -b 40 -s 472 -t freebsd-boot ada0

After some creative hacking... tada!

# find /usr/obj/usr/src/sys/boot/ -type f -name \*zfsboot -exec ls -l {} \;
-rw-r--r--  1 root  wheel  131584 Jan 28 12:07
/usr/obj/usr/src/sys/boot/i386/zfsboot/zfsboot
-rw-r--r--  1 root  wheel  47527 Jan 28 12:07
/usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

-- wait, why is the size of zfsboot vs gptzfsboot so different? Oh,
r304321 added that as `BOOT2SIZE`. Still, it seems a bit silly to only
increase the size of one bootloader and not the other 4 instances of
the bootloader :/. I don't understand the point in the size
restriction 100%, but I'll leave it be.

Patch will be available sometime next week if my testing goes well.

Cheers,
-Ngie
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Warner Losh]

On Sat, Jan 28, 2017 at 12:04 PM, Ngie Cooper  wrote:
> On Sat, Jan 28, 2017 at 10:57 AM, Allan Jude  wrote:
>> On 2017-01-28 13:56, Ngie Cooper wrote:
>>> On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh  wrote:
>>>
>>> ...
>>>
 So? It literally doesn't matter where the freebsd-boot partition
 lives, or what it's number is. You can put it at the start or end of
 the swap partition after adjusting its size. I've done this on several
 systems...  NanoBSD plays games with this stuff as well to be bootable
 on old / new systems.
>>>
>>> True. Hopefully my BIOS/disk controller isn't dumb enough to not
>>> support large disks properly.
>>>
>>> *sigh* Unfortunately, in my infinity cleverness I only put 2
>>> partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
>>> need to make backups of my workstation so I don't lose anything
>>> critical.
>>
>> Did gptzfsboot not fall below 64kb when you used the
>> LOADER_NO_GELI_SUPPORT knob?
>
> It did, but unfortunately that's still way too small for my
> freebsd-boot partition (which apparently is only 44kB large :/..):
>
> Before:
>
> $ ls -l `make -V.OBJDIR`/gptzfsboot
> -rw-r--r--  1 ngie  wheel  111662 Jan 28 11:00
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
>
> After:
>
> $ ls -l `make -V.OBJDIR`/gptzfsboot
> -rw-r--r--  1 ngie  wheel  65371 Jan 28 11:05
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
>
> Time to do some more tricks to pare down the bootloader size.

You can tweak the start of your boot loader partition to start at 2,
which would give you 63.5k of space, which is 65024 bytes. Sadly, this
is 300 bytes less space than you have.

The end of the disk usually is a good place to look for space, but it
looks like there's at most 17k there.

> Sidenote to the folks who drive the release notes and upgrade
> instructions for FreeBSD 12.x -- it needs to be clearly explained that
> gptzfsboot has grown considerably in size and mitigation instructions
> should be provided for updating gptzfsboot -- in particular with folks
> who might be using freebsd-update, so don't have the luxury of the
> choice of bootloader build options when upgrading.

Upgrade scripts (including installworld) don't update the bootblocks
ever. Just the files in /boot.

Warner

> Thanks,
> -Ngie
>
> $ gpart list da0
> Geom name: da0
> modified: false
> state: OK
> fwheads: 255
> fwsectors: 63
> last: 250069646
> first: 34
> entries: 128
> scheme: GPT
> Providers:
> 1. Name: da0p1
>Mediasize: 45056 (44K)
>Sectorsize: 512
>Stripesize: 0
>Stripeoffset: 20480
>Mode: r0w0e0
>rawuuid: 29a79300-48b1-11e4-97ff-fc4dd43f2de9
>rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
>label: (null)
>length: 45056
>offset: 20480
>type: freebsd-boot
>index: 1
>end: 127
>start: 40
> 2. Name: da0p2
>Mediasize: 128035593728 (119G)
>Sectorsize: 512
>Stripesize: 0
>Stripeoffset: 65536
>Mode: r1w1e1
>rawuuid: 4416180d-48b1-11e4-97ff-fc4dd43f2de9
>rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
>label: (null)
>length: 128035593728
>offset: 65536
>type: freebsd-zfs
>index: 2
>end: 250069646
>start: 128
> Consumers:
> 1. Name: da0
>Mediasize: 128035676160 (119G)
>Sectorsize: 512
>Mode: r1w1e2
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

> What created a partition that small?

Me.

gpart up until last summer said that users should create 44kB
freebsd-boot partitions -- des@ corrected that in r303289:

-This example uses 88 blocks (44 kB) so the next partition will be
-aligned on a 64 kB boundary without the need to specify an explicit
-offset or alignment.
-The boot partition itself is aligned on a 4 kB boundary.
+We create a 472-block (236 kB) boot partition at offset 40, which is
+the size of the partition table (34 blocks or 17 kB) rounded up to the
+nearest 4 kB boundary.
 .Bd -literal -offset indent
-/sbin/gpart add -b 40 -s 88 -t freebsd-boot ada0
+/sbin/gpart add -b 40 -s 472 -t freebsd-boot ada0

Thanks,
-Ngie
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Allan Jude]

On 2017-01-28 14:04, Ngie Cooper wrote:
> On Sat, Jan 28, 2017 at 10:57 AM, Allan Jude  wrote:
>> On 2017-01-28 13:56, Ngie Cooper wrote:
>>> On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh  wrote:
>>>
>>> ...
>>>
 So? It literally doesn't matter where the freebsd-boot partition
 lives, or what it's number is. You can put it at the start or end of
 the swap partition after adjusting its size. I've done this on several
 systems...  NanoBSD plays games with this stuff as well to be bootable
 on old / new systems.
>>>
>>> True. Hopefully my BIOS/disk controller isn't dumb enough to not
>>> support large disks properly.
>>>
>>> *sigh* Unfortunately, in my infinity cleverness I only put 2
>>> partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
>>> need to make backups of my workstation so I don't lose anything
>>> critical.
>>
>> Did gptzfsboot not fall below 64kb when you used the
>> LOADER_NO_GELI_SUPPORT knob?
> 
> It did, but unfortunately that's still way too small for my
> freebsd-boot partition (which apparently is only 44kB large :/..):
> 
> Before:
> 
> $ ls -l `make -V.OBJDIR`/gptzfsboot
> -rw-r--r--  1 ngie  wheel  111662 Jan 28 11:00
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
> 
> After:
> 
> $ ls -l `make -V.OBJDIR`/gptzfsboot
> -rw-r--r--  1 ngie  wheel  65371 Jan 28 11:05
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
> 
> Time to do some more tricks to pare down the bootloader size.
> 
> Sidenote to the folks who drive the release notes and upgrade
> instructions for FreeBSD 12.x -- it needs to be clearly explained that
> gptzfsboot has grown considerably in size and mitigation instructions
> should be provided for updating gptzfsboot -- in particular with folks
> who might be using freebsd-update, so don't have the luxury of the
> choice of bootloader build options when upgrading.
> 
> Thanks,
> -Ngie
> 
> $ gpart list da0
> Geom name: da0
> modified: false
> state: OK
> fwheads: 255
> fwsectors: 63
> last: 250069646
> first: 34
> entries: 128
> scheme: GPT
> Providers:
> 1. Name: da0p1
>Mediasize: 45056 (44K)
>Sectorsize: 512
>Stripesize: 0
>Stripeoffset: 20480
>Mode: r0w0e0
>rawuuid: 29a79300-48b1-11e4-97ff-fc4dd43f2de9
>rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
>label: (null)
>length: 45056
>offset: 20480
>type: freebsd-boot
>index: 1
>end: 127
>start: 40
> 2. Name: da0p2
>Mediasize: 128035593728 (119G)
>Sectorsize: 512
>Stripesize: 0
>Stripeoffset: 65536
>Mode: r1w1e1
>rawuuid: 4416180d-48b1-11e4-97ff-fc4dd43f2de9
>rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
>label: (null)
>length: 128035593728
>offset: 65536
>type: freebsd-zfs
>index: 2
>end: 250069646
>start: 128
> Consumers:
> 1. Name: da0
>Mediasize: 128035676160 (119G)
>Sectorsize: 512
>Mode: r1w1e2
> 

What created a partition that small?

Even the FreeBSD 9.3 or 10.3 ZFS boot loaders would struggle to fit in
that space:

9.3:
-r--r--r--  1 root  wheel  42083 Jul 30  2015 /boot/gptzfsboot

10.3:
-r--r--r--  1 root  wheel  42143 Mar 25  2016 /boot/gptzfsboot


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 10:57 AM, Allan Jude  wrote:
> On 2017-01-28 13:56, Ngie Cooper wrote:
>> On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh  wrote:
>>
>> ...
>>
>>> So? It literally doesn't matter where the freebsd-boot partition
>>> lives, or what it's number is. You can put it at the start or end of
>>> the swap partition after adjusting its size. I've done this on several
>>> systems...  NanoBSD plays games with this stuff as well to be bootable
>>> on old / new systems.
>>
>> True. Hopefully my BIOS/disk controller isn't dumb enough to not
>> support large disks properly.
>>
>> *sigh* Unfortunately, in my infinity cleverness I only put 2
>> partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
>> need to make backups of my workstation so I don't lose anything
>> critical.
>
> Did gptzfsboot not fall below 64kb when you used the
> LOADER_NO_GELI_SUPPORT knob?

It did, but unfortunately that's still way too small for my
freebsd-boot partition (which apparently is only 44kB large :/..):

Before:

$ ls -l `make -V.OBJDIR`/gptzfsboot
-rw-r--r--  1 ngie  wheel  111662 Jan 28 11:00
/usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

After:

$ ls -l `make -V.OBJDIR`/gptzfsboot
-rw-r--r--  1 ngie  wheel  65371 Jan 28 11:05
/usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

Time to do some more tricks to pare down the bootloader size.

Sidenote to the folks who drive the release notes and upgrade
instructions for FreeBSD 12.x -- it needs to be clearly explained that
gptzfsboot has grown considerably in size and mitigation instructions
should be provided for updating gptzfsboot -- in particular with folks
who might be using freebsd-update, so don't have the luxury of the
choice of bootloader build options when upgrading.

Thanks,
-Ngie

$ gpart list da0
Geom name: da0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 250069646
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: da0p1
   Mediasize: 45056 (44K)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 20480
   Mode: r0w0e0
   rawuuid: 29a79300-48b1-11e4-97ff-fc4dd43f2de9
   rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   label: (null)
   length: 45056
   offset: 20480
   type: freebsd-boot
   index: 1
   end: 127
   start: 40
2. Name: da0p2
   Mediasize: 128035593728 (119G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 65536
   Mode: r1w1e1
   rawuuid: 4416180d-48b1-11e4-97ff-fc4dd43f2de9
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 128035593728
   offset: 65536
   type: freebsd-zfs
   index: 2
   end: 250069646
   start: 128
Consumers:
1. Name: da0
   Mediasize: 128035676160 (119G)
   Sectorsize: 512
   Mode: r1w1e2
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Allan Jude]

On 2017-01-28 13:56, Ngie Cooper wrote:
> On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh  wrote:
> 
> ...
> 
>> So? It literally doesn't matter where the freebsd-boot partition
>> lives, or what it's number is. You can put it at the start or end of
>> the swap partition after adjusting its size. I've done this on several
>> systems...  NanoBSD plays games with this stuff as well to be bootable
>> on old / new systems.
> 
> True. Hopefully my BIOS/disk controller isn't dumb enough to not
> support large disks properly.
> 
> *sigh* Unfortunately, in my infinity cleverness I only put 2
> partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
> need to make backups of my workstation so I don't lose anything
> critical.
> 
> -Ngie
> 

Did gptzfsboot not fall below 64kb when you used the
LOADER_NO_GELI_SUPPORT knob?

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh  wrote:

...

> So? It literally doesn't matter where the freebsd-boot partition
> lives, or what it's number is. You can put it at the start or end of
> the swap partition after adjusting its size. I've done this on several
> systems...  NanoBSD plays games with this stuff as well to be bootable
> on old / new systems.

True. Hopefully my BIOS/disk controller isn't dumb enough to not
support large disks properly.

*sigh* Unfortunately, in my infinity cleverness I only put 2
partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
need to make backups of my workstation so I don't lose anything
critical.

-Ngie
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Toomas Soome]

> On 28. jaan 2017, at 18:56, Warner Losh  wrote:
> 
>> 
>> 
>> at $JOB we are just testing a script that expands the root zfs partition on
>> in-field appliances by shaving a bit off swap and cannibalising a small data
>> partition we don't really use. I see we only left 64K for the boot part.
>> It's big enough for us for now, but possibly we should fix that as well.
>> We have a mirror setup for system disks so we have the ability to take each
>> system drive offline one at a time and rearrange it and then re-add the root
>> partition to the mirror.
>> What are the chances a regular gpt+ZFS (no encrypt) bootblock will grow over
>> 64K?
> 
> Hard to say. Given boot1/boot2 growth over time, I'd peg that close to 100%.
> 
> 


There are few things to consider. First of all, the job of the boot2 is 
actually really small - read out the loader binary by using file system 
specific reader code and start it; and, on bios system, provide quite simple 
prompt for few options. Nothing more, nothing less. So in that sense, it should 
not grow too much.

The problem is, from historical reasons, the boot2 programs are using their own 
personal support functions for IO, and that means that boot loader has some 
duplication of the internal API. Mostly it does not disturb us too much, but 
zfs is complex software and bundling some other features like GELI, does not 
make things more easier. So thats one aspect where the “bloat” is appearing - 
to be able to implement some things, the “thin” implementations are just not 
enough, or some “unexpected” additions are needed.

For the illumos port I actually did something different - I did build one 
single gptzfsboot binary, capable of handling zfs, ufs and pcfs (as those are 
ones needed), and using libstand. Still it does use thin version of keyboard 
input and screen output.

The size of such combined boot2 is (this one is including both skein and edonr):

-r--r--r--   1 root sys   153600 jaan 24 14:08 gptzfsboot

Note, it does not have GELI, so if the same would be done for fbsd, the size 
would be a bit larger because of the crypto functions. But this setup also has 
a bit different strategy;  in case of zfs, the boot2 is *always* installed to 
3.5MB zfs bootblock area and in case of ufs, either boot partition (same idea 
as freebsd-boot) or if the MBR+VTOC schema is used, free space between MBR 
partition and VTOC. Since in most cases the default boot is zfs, it means the 
boot size is not an issue (3.5MB is more than enough;)

rgds,
toomas
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Warner Losh]

On Sat, Jan 28, 2017 at 6:43 AM, Julian Elischer  wrote:
> On 28/1/17 4:16 am, Ngie Cooper wrote:
>>>
>>> On Jan 27, 2017, at 09:05, Warner Losh  wrote:
>>
>> ...
>>
>>> I'm curious why you can't find the space for a bigger partition?
>>> Almost all drives these days are partitioned with a little wasted
>>> space, and that wasted space should be more than enough to cover us
>>> here. Also, most drives have a swap partition that can be shrunk a
>>> trivial amount to get space for this...
>>
>> Unfortunately, in my infinite wisdom (IIRC) I put the zfs partition before
>> the swap partition.

So? It literally doesn't matter where the freebsd-boot partition
lives, or what it's number is. You can put it at the start or end of
the swap partition after adjusting its size. I've done this on several
systems...  NanoBSD plays games with this stuff as well to be bootable
on old / new systems.

>> We have a similar problem at work with sys/boot unfortunately, but that's
>> a side discussion for another time/place.
>>
>> Thank you for the idea though -- I'll check when I get back to work.
>
>
> at $JOB we are just testing a script that expands the root zfs partition on
> in-field appliances by shaving a bit off swap and cannibalising a small data
> partition we don't really use. I see we only left 64K for the boot part.
> It's big enough for us for now, but possibly we should fix that as well.
> We have a mirror setup for system disks so we have the ability to take each
> system drive offline one at a time and rearrange it and then re-add the root
> partition to the mirror.
> What are the chances a regular gpt+ZFS (no encrypt) bootblock will grow over
> 64K?

Hard to say. Given boot1/boot2 growth over time, I'd peg that close to 100%.

Warner

>> -Ngie
>> ___
>> 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"
>>
>
>
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Julian Elischer]

On 28/1/17 1:35 am, Allan Jude wrote:

On 2017-01-27 12:33, Shawn Webb wrote:

On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote:

On 2017-01-27 12:05, Warner Losh wrote:

On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:

On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya)  
wrote:

Hi,
   I tried upgrading one of my workstations and unfortunately the 
freebsd-boot partition is too small (I follow manpage directions, exactly, and 
those seem to be too small as of 10.3-RELEASE timeframe), and I don???t have 
enough space or ability to resize the partition and make it bigger. So, I???m 
in need of a build knob to control the bloat, and/or having an alternative boot 
loader without geli/skein/crypto support compiled in. Would you be opposed to 
the work?
Thanks,
-Ngie


I do agree that since the geli knob is already there, it may do. Of course we 
also can think of additional knobs, but there is an issue - it wont help just 
to exclude some files, the additional features also do sit in the code, so the 
replacement stubs will be needed, also testing them all over will take some 
time. And the preprocessor spaghetti really is nasty thing to deal with;)

And then there is another issue (partly why I did the feature support in first 
place) - as the kernel does not block user from enabling the features, the user 
can end up facing non-bootable setup which is also not good, as user is using 
perfectly legal options, and still the whole thing is just rendered unusable???

I'm curious why you can't find the space for a bigger partition?
Almost all drives these days are partitioned with a little wasted
space, and that wasted space should be more than enough to cover us
here. Also, most drives have a swap partition that can be shrunk a
trivial amount to get space for this...

Warner


I need to do some testing to make a recipe that works for it, but the
other option is to use the ZFS bootcode area.

ZFS it self, reserves something like 3.5 mb of space in the ZFS
partition, for boot code. This is how we boot ZFS on MBR.

It should be possible to use this on GPT as well, we just don't.

In the future, maybe it'd be a good idea for the installer to leave
more space (a few MB, perhaps?) between the freebsd-boot and
freebsd-swap partitions? At least, for ZFS installs.

Thanks,


The PMBR code has a limitation for 536kb, and it all has to fit under
the 640k barrier, so the current 512kb size is plenty. The issue is some
people are upgrading from systems that were isntalled long ago, when
64kb or less was the default.

with 512K we can append a copy of FreeBSD1.0 on the end of the 
bootblock and leave us the option of bringing up a networked NFS based 
system for debugging.


maybe we could fall back to that after a crash...



___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Julian Elischer]

On 28/1/17 4:16 am, Ngie Cooper wrote:

On Jan 27, 2017, at 09:05, Warner Losh  wrote:

...


I'm curious why you can't find the space for a bigger partition?
Almost all drives these days are partitioned with a little wasted
space, and that wasted space should be more than enough to cover us
here. Also, most drives have a swap partition that can be shrunk a
trivial amount to get space for this...

Unfortunately, in my infinite wisdom (IIRC) I put the zfs partition before the 
swap partition.

We have a similar problem at work with sys/boot unfortunately, but that's a 
side discussion for another time/place.

Thank you for the idea though -- I'll check when I get back to work.


at $JOB we are just testing a script that expands the root zfs 
partition on in-field appliances by shaving a bit off swap and 
cannibalising a small data partition we don't really use. I see we 
only left 64K for the boot part. It's big enough for us for now, but 
possibly we should fix that as well.
We have a mirror setup for system disks so we have the ability to take 
each system drive offline one at a time and rearrange it and then 
re-add the root partition to the mirror.
What are the chances a regular gpt+ZFS (no encrypt) bootblock will 
grow over 64K?





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




___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Toomas Soome]

> On 27. jaan 2017, at 22:16, Ngie Cooper  wrote:
> 
> 
>> On Jan 27, 2017, at 09:05, Warner Losh  wrote:
> 
> ...
> 
>> I'm curious why you can't find the space for a bigger partition?
>> Almost all drives these days are partitioned with a little wasted
>> space, and that wasted space should be more than enough to cover us
>> here. Also, most drives have a swap partition that can be shrunk a
>> trivial amount to get space for this...
> 
> Unfortunately, in my infinite wisdom (IIRC) I put the zfs partition before 
> the swap partition.
> 
> We have a similar problem at work with sys/boot unfortunately, but that's a 
> side discussion for another time/place.
> 
> Thank you for the idea though -- I'll check when I get back to work.
> 
> -Ngie

Note the order of the partitions is not important, at least on paper anyhow. Of 
course there are preferences in sense that it does look nice if freebsd-boot is 
in front. Also, if you do have mirror setup, it is some work, but you can 
re-arrange mirror side partitioning (with usual cautions like having scrub 
done, having backup, having third disk would be helpful).

rgds,
toomas
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

> On Jan 27, 2017, at 12:23, Toomas Soome  wrote:

...

>> Unfortunately, in my infinite wisdom (IIRC) I put the zfs partition before 
>> the swap partition.
>> 
>> We have a similar problem at work with sys/boot unfortunately, but that's a 
>> side discussion for another time/place.
>> 
>> Thank you for the idea though -- I'll check when I get back to work.
>> 
>> -Ngie
> 
> Note the order of the partitions is not important, at least on paper anyhow. 
> Of course there are preferences in sense that it does look nice if 
> freebsd-boot is in front. Also, if you do have mirror setup, it is some work, 
> but you can re-arrange mirror side partitioning (with usual cautions like 
> having scrub done, having backup, having third disk would be helpful).

I have a raidz with 3 SSDs on it IIRC. Removing the SSD from the pool and 
readjusting partitions would probably be ok, but I'm not really keen on doing 
potentially destructive things like that, unless I absolutely have to do them 
:/..

Thanks!
-Ngie
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

> On Jan 27, 2017, at 09:05, Warner Losh  wrote:

...

> I'm curious why you can't find the space for a bigger partition?
> Almost all drives these days are partitioned with a little wasted
> space, and that wasted space should be more than enough to cover us
> here. Also, most drives have a swap partition that can be shrunk a
> trivial amount to get space for this...

Unfortunately, in my infinite wisdom (IIRC) I put the zfs partition before the 
swap partition.

We have a similar problem at work with sys/boot unfortunately, but that's a 
side discussion for another time/place.

Thank you for the idea though -- I'll check when I get back to work.

-Ngie
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Toomas Soome]

> On 27. jaan 2017, at 19:30, Allan Jude  wrote:
> 
> On 2017-01-27 12:05, Warner Losh wrote:
>> On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome > > wrote:
>>> 
 On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) 
  wrote:
 
 Hi,
  I tried upgrading one of my workstations and unfortunately the 
 freebsd-boot partition is too small (I follow manpage directions, exactly, 
 and those seem to be too small as of 10.3-RELEASE timeframe), and I don’t 
 have enough space or ability to resize the partition and make it bigger. 
 So, I’m in need of a build knob to control the bloat, and/or having an 
 alternative boot loader without geli/skein/crypto support compiled in. 
 Would you be opposed to the work?
 Thanks,
 -Ngie
>>> 
>>> 
>>> I do agree that since the geli knob is already there, it may do. Of course 
>>> we also can think of additional knobs, but there is an issue - it wont help 
>>> just to exclude some files, the additional features also do sit in the 
>>> code, so the replacement stubs will be needed, also testing them all over 
>>> will take some time. And the preprocessor spaghetti really is nasty thing 
>>> to deal with;)
>>> 
>>> And then there is another issue (partly why I did the feature support in 
>>> first place) - as the kernel does not block user from enabling the 
>>> features, the user can end up facing non-bootable setup which is also not 
>>> good, as user is using perfectly legal options, and still the whole thing 
>>> is just rendered unusable…
>> 
>> I'm curious why you can't find the space for a bigger partition?
>> Almost all drives these days are partitioned with a little wasted
>> space, and that wasted space should be more than enough to cover us
>> here. Also, most drives have a swap partition that can be shrunk a
>> trivial amount to get space for this...
>> 
>> Warner
>> 
> 
> I need to do some testing to make a recipe that works for it, but the
> other option is to use the ZFS bootcode area.
> 
> ZFS it self, reserves something like 3.5 mb of space in the ZFS
> partition, for boot code. This is how we boot ZFS on MBR.
> 
> It should be possible to use this on GPT as well, we just don't.
> 
> 

Indeed it is. this is how the illumos is doing, except that what in illumos, we 
use also a bit different boot method - instead of browsing the partition table, 
we record the boot2 start and size in pmbr, and the partition start in 
gptzfsboot, and we always boot based on recorded location - that does simplify 
the boot code in pmbr, but needs install tool, to detect and record the LBA.

And for fbsd case, the bootblock install must be able to distinguish 
geli/non-geli setups, and .. well, there are some complications:)

rgds,
toomas


___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Warner Losh]

On Fri, Jan 27, 2017 at 10:35 AM, Allan Jude  wrote:
> On 2017-01-27 12:33, Shawn Webb wrote:
>> On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote:
>>> On 2017-01-27 12:05, Warner Losh wrote:
 On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:
>
>> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) 
>>  wrote:
>>
>> Hi,
>>   I tried upgrading one of my workstations and unfortunately the 
>> freebsd-boot partition is too small (I follow manpage directions, 
>> exactly, and those seem to be too small as of 10.3-RELEASE timeframe), 
>> and I don???t have enough space or ability to resize the partition and 
>> make it bigger. So, I???m in need of a build knob to control the bloat, 
>> and/or having an alternative boot loader without geli/skein/crypto 
>> support compiled in. Would you be opposed to the work?
>> Thanks,
>> -Ngie
>
>
> I do agree that since the geli knob is already there, it may do. Of 
> course we also can think of additional knobs, but there is an issue - it 
> wont help just to exclude some files, the additional features also do sit 
> in the code, so the replacement stubs will be needed, also testing them 
> all over will take some time. And the preprocessor spaghetti really is 
> nasty thing to deal with;)
>
> And then there is another issue (partly why I did the feature support in 
> first place) - as the kernel does not block user from enabling the 
> features, the user can end up facing non-bootable setup which is also not 
> good, as user is using perfectly legal options, and still the whole thing 
> is just rendered unusable???

 I'm curious why you can't find the space for a bigger partition?
 Almost all drives these days are partitioned with a little wasted
 space, and that wasted space should be more than enough to cover us
 here. Also, most drives have a swap partition that can be shrunk a
 trivial amount to get space for this...

 Warner

>>>
>>> I need to do some testing to make a recipe that works for it, but the
>>> other option is to use the ZFS bootcode area.
>>>
>>> ZFS it self, reserves something like 3.5 mb of space in the ZFS
>>> partition, for boot code. This is how we boot ZFS on MBR.
>>>
>>> It should be possible to use this on GPT as well, we just don't.
>>
>> In the future, maybe it'd be a good idea for the installer to leave
>> more space (a few MB, perhaps?) between the freebsd-boot and
>> freebsd-swap partitions? At least, for ZFS installs.
>>
>> Thanks,
>>
>
> The PMBR code has a limitation for 536kb, and it all has to fit under
> the 640k barrier, so the current 512kb size is plenty. The issue is some
> people are upgrading from systems that were isntalled long ago, when
> 64kb or less was the default.

it's a limitation for the entire partition size, not just the code
size. Which is a trap that's hard to understand at first...

Warner
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Allan Jude]

On 2017-01-27 12:05, Warner Losh wrote:
> On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:
>>
>>> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) 
>>>  wrote:
>>>
>>> Hi,
>>>   I tried upgrading one of my workstations and unfortunately the 
>>> freebsd-boot partition is too small (I follow manpage directions, exactly, 
>>> and those seem to be too small as of 10.3-RELEASE timeframe), and I don’t 
>>> have enough space or ability to resize the partition and make it bigger. 
>>> So, I’m in need of a build knob to control the bloat, and/or having an 
>>> alternative boot loader without geli/skein/crypto support compiled in. 
>>> Would you be opposed to the work?
>>> Thanks,
>>> -Ngie
>>
>>
>> I do agree that since the geli knob is already there, it may do. Of course 
>> we also can think of additional knobs, but there is an issue - it wont help 
>> just to exclude some files, the additional features also do sit in the code, 
>> so the replacement stubs will be needed, also testing them all over will 
>> take some time. And the preprocessor spaghetti really is nasty thing to deal 
>> with;)
>>
>> And then there is another issue (partly why I did the feature support in 
>> first place) - as the kernel does not block user from enabling the features, 
>> the user can end up facing non-bootable setup which is also not good, as 
>> user is using perfectly legal options, and still the whole thing is just 
>> rendered unusable…
> 
> I'm curious why you can't find the space for a bigger partition?
> Almost all drives these days are partitioned with a little wasted
> space, and that wasted space should be more than enough to cover us
> here. Also, most drives have a swap partition that can be shrunk a
> trivial amount to get space for this...
> 
> Warner
> 

I need to do some testing to make a recipe that works for it, but the
other option is to use the ZFS bootcode area.

ZFS it self, reserves something like 3.5 mb of space in the ZFS
partition, for boot code. This is how we boot ZFS on MBR.

It should be possible to use this on GPT as well, we just don't.


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Shawn Webb]

On Fri, Jan 27, 2017 at 12:35:21PM -0500, Allan Jude wrote:
> On 2017-01-27 12:33, Shawn Webb wrote:
> > On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote:
> >> On 2017-01-27 12:05, Warner Losh wrote:
> >>> On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:
> 
> > On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) 
> >  wrote:
> >
> > Hi,
> >   I tried upgrading one of my workstations and unfortunately the 
> > freebsd-boot partition is too small (I follow manpage directions, 
> > exactly, and those seem to be too small as of 10.3-RELEASE timeframe), 
> > and I don???t have enough space or ability to resize the partition and 
> > make it bigger. So, I???m in need of a build knob to control the bloat, 
> > and/or having an alternative boot loader without geli/skein/crypto 
> > support compiled in. Would you be opposed to the work?
> > Thanks,
> > -Ngie
> 
> 
>  I do agree that since the geli knob is already there, it may do. Of 
>  course we also can think of additional knobs, but there is an issue - it 
>  wont help just to exclude some files, the additional features also do 
>  sit in the code, so the replacement stubs will be needed, also testing 
>  them all over will take some time. And the preprocessor spaghetti really 
>  is nasty thing to deal with;)
> 
>  And then there is another issue (partly why I did the feature support in 
>  first place) - as the kernel does not block user from enabling the 
>  features, the user can end up facing non-bootable setup which is also 
>  not good, as user is using perfectly legal options, and still the whole 
>  thing is just rendered unusable???
> >>>
> >>> I'm curious why you can't find the space for a bigger partition?
> >>> Almost all drives these days are partitioned with a little wasted
> >>> space, and that wasted space should be more than enough to cover us
> >>> here. Also, most drives have a swap partition that can be shrunk a
> >>> trivial amount to get space for this...
> >>>
> >>> Warner
> >>>
> >>
> >> I need to do some testing to make a recipe that works for it, but the
> >> other option is to use the ZFS bootcode area.
> >>
> >> ZFS it self, reserves something like 3.5 mb of space in the ZFS
> >> partition, for boot code. This is how we boot ZFS on MBR.
> >>
> >> It should be possible to use this on GPT as well, we just don't.
> > 
> > In the future, maybe it'd be a good idea for the installer to leave
> > more space (a few MB, perhaps?) between the freebsd-boot and
> > freebsd-swap partitions? At least, for ZFS installs.
> > 
> > Thanks,
> > 
> 
> The PMBR code has a limitation for 536kb, and it all has to fit under
> the 640k barrier, so the current 512kb size is plenty. The issue is some
> people are upgrading from systems that were isntalled long ago, when
> 64kb or less was the default.

Gotcha. Thanks for the explanation.

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Allan Jude]

On 2017-01-27 12:33, Shawn Webb wrote:
> On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote:
>> On 2017-01-27 12:05, Warner Losh wrote:
>>> On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:

> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) 
>  wrote:
>
> Hi,
>   I tried upgrading one of my workstations and unfortunately the 
> freebsd-boot partition is too small (I follow manpage directions, 
> exactly, and those seem to be too small as of 10.3-RELEASE timeframe), 
> and I don???t have enough space or ability to resize the partition and 
> make it bigger. So, I???m in need of a build knob to control the bloat, 
> and/or having an alternative boot loader without geli/skein/crypto 
> support compiled in. Would you be opposed to the work?
> Thanks,
> -Ngie


 I do agree that since the geli knob is already there, it may do. Of course 
 we also can think of additional knobs, but there is an issue - it wont 
 help just to exclude some files, the additional features also do sit in 
 the code, so the replacement stubs will be needed, also testing them all 
 over will take some time. And the preprocessor spaghetti really is nasty 
 thing to deal with;)

 And then there is another issue (partly why I did the feature support in 
 first place) - as the kernel does not block user from enabling the 
 features, the user can end up facing non-bootable setup which is also not 
 good, as user is using perfectly legal options, and still the whole thing 
 is just rendered unusable???
>>>
>>> I'm curious why you can't find the space for a bigger partition?
>>> Almost all drives these days are partitioned with a little wasted
>>> space, and that wasted space should be more than enough to cover us
>>> here. Also, most drives have a swap partition that can be shrunk a
>>> trivial amount to get space for this...
>>>
>>> Warner
>>>
>>
>> I need to do some testing to make a recipe that works for it, but the
>> other option is to use the ZFS bootcode area.
>>
>> ZFS it self, reserves something like 3.5 mb of space in the ZFS
>> partition, for boot code. This is how we boot ZFS on MBR.
>>
>> It should be possible to use this on GPT as well, we just don't.
> 
> In the future, maybe it'd be a good idea for the installer to leave
> more space (a few MB, perhaps?) between the freebsd-boot and
> freebsd-swap partitions? At least, for ZFS installs.
> 
> Thanks,
> 

The PMBR code has a limitation for 536kb, and it all has to fit under
the 640k barrier, so the current 512kb size is plenty. The issue is some
people are upgrading from systems that were isntalled long ago, when
64kb or less was the default.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Shawn Webb]

On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote:
> On 2017-01-27 12:05, Warner Losh wrote:
> > On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:
> >>
> >>> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) 
> >>>  wrote:
> >>>
> >>> Hi,
> >>>   I tried upgrading one of my workstations and unfortunately the 
> >>> freebsd-boot partition is too small (I follow manpage directions, 
> >>> exactly, and those seem to be too small as of 10.3-RELEASE timeframe), 
> >>> and I don???t have enough space or ability to resize the partition and 
> >>> make it bigger. So, I???m in need of a build knob to control the bloat, 
> >>> and/or having an alternative boot loader without geli/skein/crypto 
> >>> support compiled in. Would you be opposed to the work?
> >>> Thanks,
> >>> -Ngie
> >>
> >>
> >> I do agree that since the geli knob is already there, it may do. Of course 
> >> we also can think of additional knobs, but there is an issue - it wont 
> >> help just to exclude some files, the additional features also do sit in 
> >> the code, so the replacement stubs will be needed, also testing them all 
> >> over will take some time. And the preprocessor spaghetti really is nasty 
> >> thing to deal with;)
> >>
> >> And then there is another issue (partly why I did the feature support in 
> >> first place) - as the kernel does not block user from enabling the 
> >> features, the user can end up facing non-bootable setup which is also not 
> >> good, as user is using perfectly legal options, and still the whole thing 
> >> is just rendered unusable???
> > 
> > I'm curious why you can't find the space for a bigger partition?
> > Almost all drives these days are partitioned with a little wasted
> > space, and that wasted space should be more than enough to cover us
> > here. Also, most drives have a swap partition that can be shrunk a
> > trivial amount to get space for this...
> > 
> > Warner
> > 
> 
> I need to do some testing to make a recipe that works for it, but the
> other option is to use the ZFS bootcode area.
> 
> ZFS it self, reserves something like 3.5 mb of space in the ZFS
> partition, for boot code. This is how we boot ZFS on MBR.
> 
> It should be possible to use this on GPT as well, we just don't.

In the future, maybe it'd be a good idea for the installer to leave
more space (a few MB, perhaps?) between the freebsd-boot and
freebsd-swap partitions? At least, for ZFS installs.

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Warner Losh]

On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:
>
>> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya)  
>> wrote:
>>
>> Hi,
>>   I tried upgrading one of my workstations and unfortunately the 
>> freebsd-boot partition is too small (I follow manpage directions, exactly, 
>> and those seem to be too small as of 10.3-RELEASE timeframe), and I don’t 
>> have enough space or ability to resize the partition and make it bigger. So, 
>> I’m in need of a build knob to control the bloat, and/or having an 
>> alternative boot loader without geli/skein/crypto support compiled in. Would 
>> you be opposed to the work?
>> Thanks,
>> -Ngie
>
>
> I do agree that since the geli knob is already there, it may do. Of course we 
> also can think of additional knobs, but there is an issue - it wont help just 
> to exclude some files, the additional features also do sit in the code, so 
> the replacement stubs will be needed, also testing them all over will take 
> some time. And the preprocessor spaghetti really is nasty thing to deal with;)
>
> And then there is another issue (partly why I did the feature support in 
> first place) - as the kernel does not block user from enabling the features, 
> the user can end up facing non-bootable setup which is also not good, as user 
> is using perfectly legal options, and still the whole thing is just rendered 
> unusable…

I'm curious why you can't find the space for a bigger partition?
Almost all drives these days are partitioned with a little wasted
space, and that wasted space should be more than enough to cover us
here. Also, most drives have a swap partition that can be shrunk a
trivial amount to get space for this...

Warner
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Toomas Soome]

> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> Hi,
>   I tried upgrading one of my workstations and unfortunately the 
> freebsd-boot partition is too small (I follow manpage directions, exactly, 
> and those seem to be too small as of 10.3-RELEASE timeframe), and I don’t 
> have enough space or ability to resize the partition and make it bigger. So, 
> I’m in need of a build knob to control the bloat, and/or having an 
> alternative boot loader without geli/skein/crypto support compiled in. Would 
> you be opposed to the work?
> Thanks,
> -Ngie


I do agree that since the geli knob is already there, it may do. Of course we 
also can think of additional knobs, but there is an issue - it wont help just 
to exclude some files, the additional features also do sit in the code, so the 
replacement stubs will be needed, also testing them all over will take some 
time. And the preprocessor spaghetti really is nasty thing to deal with;)

And then there is another issue (partly why I did the feature support in first 
place) - as the kernel does not block user from enabling the features, the user 
can end up facing non-bootable setup which is also not good, as user is using 
perfectly legal options, and still the whole thing is just rendered unusable…

rgds,
toomas
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Allan Jude]

On 2017-01-26 18:50, Alan Somers wrote:
> On Thu, Jan 26, 2017 at 4:40 PM, Ngie Cooper (yaneurabeya)
>  wrote:
>> Hi,
>> I tried upgrading one of my workstations and unfortunately the 
>> freebsd-boot partition is too small (I follow manpage directions, exactly, 
>> and those seem to be too small as of 10.3-RELEASE timeframe), and I don’t 
>> have enough space or ability to resize the partition and make it bigger. So, 
>> I’m in need of a build knob to control the bloat, and/or having an 
>> alternative boot loader without geli/skein/crypto support compiled in. Would 
>> you be opposed to the work?
>> Thanks,
>> -Ngie
> 
> We have this problem at work too.  We deal with it by defining the
> following in src.conf.  The build system already knows about this
> variable, though it isn't in src.conf's manpage.
> 
> LOADER_NO_GELI_SUPPORT=1
> 
> -Alan
> ___
> 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"
> 

Yeah, most of the size is from the GELI support, not Skein, so that is
your best starting place.

I also have some work in progress with tsoome@ to further shrink things
for you.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Alan Somers]

On Thu, Jan 26, 2017 at 4:40 PM, Ngie Cooper (yaneurabeya)
 wrote:
> Hi,
> I tried upgrading one of my workstations and unfortunately the 
> freebsd-boot partition is too small (I follow manpage directions, exactly, 
> and those seem to be too small as of 10.3-RELEASE timeframe), and I don’t 
> have enough space or ability to resize the partition and make it bigger. So, 
> I’m in need of a build knob to control the bloat, and/or having an 
> alternative boot loader without geli/skein/crypto support compiled in. Would 
> you be opposed to the work?
> Thanks,
> -Ngie

We have this problem at work too.  We deal with it by defining the
following in src.conf.  The build system already knows about this
variable, though it isn't in src.conf's manpage.

LOADER_NO_GELI_SUPPORT=1

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