Date: Fri, 27 Jan 2017 19:39:16 +0200 From: Toomas Soome <tsoome@me.com> To: Allan Jude <allanjude@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, "Ngie Cooper (yaneurabeya)" <yaneurabeya@gmail.com>, FreeBSD Current <current@freebsd.org> Subject: Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat Message-ID: <A8AEB974-4221-4471-8E69-81C83B92CFE9@me.com> In-Reply-To: <444df1a4-1f27-49a8-6fa6-81f5853e6d80@freebsd.org> References: <A33154F2-70E1-4047-8496-7D4D85CFF292@gmail.com> <EF719374-BF9D-44EF-9F45-53B2B506047C@me.com> <CANCZdfrzOr3YdbAKRrwUXsFDhdQ3hErf1vbYSG7MdpV_m%2B=YRQ@mail.gmail.com> <444df1a4-1f27-49a8-6fa6-81f5853e6d80@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 27. jaan 2017, at 19:30, Allan Jude <allanjude@freebsd.org> wrote: >=20 > On 2017-01-27 12:05, Warner Losh wrote: >> On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome <tsoome@me.com = <mailto:tsoome@me.com>> wrote: >>>=20 >>>> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) = <yaneurabeya@gmail.com> wrote: >>>>=20 >>>> 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=E2=80=99t have enough space or ability to resize the partition = and make it bigger. So, I=E2=80=99m 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 >>>=20 >>>=20 >>> 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;) >>>=20 >>> 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=E2=80=A6 >>=20 >> 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... >>=20 >> Warner >>=20 >=20 > 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. >=20 > 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. >=20 > It should be possible to use this on GPT as well, we just don't. >=20 >=20 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A8AEB974-4221-4471-8E69-81C83B92CFE9>