From owner-svn-src-head@freebsd.org Wed Jun 20 09:22:54 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17B46100D8B0; Wed, 20 Jun 2018 09:22:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 956ED729D2; Wed, 20 Jun 2018 09:22:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTP id w5K9McSa026699; Wed, 20 Jun 2018 12:22:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w5K9McSa026699 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w5K9McfK026698; Wed, 20 Jun 2018 12:22:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Jun 2018 12:22:38 +0300 From: Konstantin Belousov To: Allan Jude Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot Message-ID: <20180620092238.GK2430@kib.kiev.ua> References: <201806170318.w5H3IvJP090557@repo.freebsd.org> <5B2646B3.4020200@grosbein.net> <93b03eb5-326b-5df1-5d41-ae3da163e894@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <93b03eb5-326b-5df1-5d41-ae3da163e894@freebsd.org> User-Agent: Mutt/1.10.0 (2018-05-17) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 09:22:54 -0000 On Tue, Jun 19, 2018 at 08:34:18PM -0400, Allan Jude wrote: > On 2018-06-17 07:32, Eugene Grosbein wrote: > > 17.06.2018 10:18, Allan Jude wrote: > > > >> Author: allanjude > >> Date: Sun Jun 17 03:18:56 2018 > >> New Revision: 335276 > >> URL: https://svnweb.freebsd.org/changeset/base/335276 > >> > >> Log: > >> gptboot, zfsboot, gptzfsboot: Enable the video and serial consoles early > >> > >> Normally the serial console is not enabled until /boot.config is read and > >> we know how the serial console should be configured. Initialize the > >> consoles early in 'dual' mode (serial & keyboard) with a default serial > >> rate of 115200. Then serial is re-initialized once the disk is decrypted > >> and the /boot.config file can be read. > >> > >> This allows the GELIBoot passphrase to be provided via the serial console. > >> > >> PR: 221526 > >> Requested by: many > >> Reviewed by: imp > >> Sponsored by: Klara Systems > >> Differential Revision: https://reviews.freebsd.org/D15862 > > > > I had several cases when booting FreeBSD/amd64 with motherboard having no serial ports > > hang hard early at boot unless I rebuilt boot media configuring it to NOT try accessing > > missing serial ports. I even could reproduce that with VirtualBox machine configured > > with no serial ports (not same as existing bug inactive serial port). > > > > Should there be some way to disable this serial ports configuration at compile time? > > > > > > > > I think what we'll do it compile it both ways, and use the non-serial > one by default, because it is safer. Then you can just use > 'gptboot-serial' if you want serial support. > > This will likely make Warner a bit sad, since we are just finally > getting around to reducing the number of different bootcode files. I think we should follow the hardware trends there and apply a policy where new features are not added to the CSM boot. All modern machines can be booted in UEFI mode, and if some modern machine cannot, then we need it fixed. We should encourage users to make new installs boot by UEFI. The feature from the commit is only relevant for machines that require CSM boot or do not have UEFI option at all, am I right ? With the policy applied, an additional CSM-boot bootblock would be not shipped.