From owner-freebsd-current@freebsd.org Fri Mar 18 17:42:52 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F015AD4269 for ; Fri, 18 Mar 2016 17:42:52 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F1751E43 for ; Fri, 18 Mar 2016 17:42:52 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: by mail.lifanov.com (Postfix, from userid 58) id 06EC8239E54; Fri, 18 Mar 2016 13:42:45 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.lifanov.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.1 Received: from [127.0.0.1] (vnat600.ejoco.com [166.108.32.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id A0547239E52 for ; Fri, 18 Mar 2016 13:42:38 -0400 (EDT) Subject: Re: boot loaders got fatter in the last few days To: freebsd-current@freebsd.org References: <56EC2DD3.6050803@madpilot.net> <56EC34CE.1000002@freebsd.org> From: Nikolai Lifanov Message-ID: <56EC3E0C.2080507@mail.lifanov.com> Date: Fri, 18 Mar 2016 13:42:36 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56EC34CE.1000002@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 17:42:52 -0000 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 wheel 8192 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 wheel 7680 Mar 18 16:47 /boot/boot2 >> -r--r--r-- 1 root wheel 1185 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 wheel 8192 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 wheel 7680 Mar 13 21:01 /boot/boot2 >> -r--r--r-- 1 root wheel 1185 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