From owner-svn-src-head@freebsd.org Wed Jun 20 16:00:02 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 75CA41021076 for ; Wed, 20 Jun 2018 16:00:02 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 046CA8184F for ; Wed, 20 Jun 2018 16:00:01 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: f5b54d26-74a2-11e8-afd2-4ddcc8249dd4 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id f5b54d26-74a2-11e8-afd2-4ddcc8249dd4; Wed, 20 Jun 2018 15:59:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w5KFxm8U082038; Wed, 20 Jun 2018 09:59:48 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1529510388.24573.6.camel@freebsd.org> Subject: Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot From: Ian Lepore To: Konstantin Belousov , Allan Jude Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Wed, 20 Jun 2018 09:59:48 -0600 In-Reply-To: <20180620092238.GK2430@kib.kiev.ua> References: <201806170318.w5H3IvJP090557@repo.freebsd.org> <5B2646B3.4020200@grosbein.net> <93b03eb5-326b-5df1-5d41-ae3da163e894@freebsd.org> <20180620092238.GK2430@kib.kiev.ua> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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 16:00:02 -0000 On Wed, 2018-06-20 at 12:22 +0300, Konstantin Belousov wrote: > 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. > I think it is far too early to say that the code for booting without efi is abandonware. I have half a dozen x86 boxes in use here, and only one of them is even able to boot efi, and its default resolution in efi mode confuses the kvm switch it's connected to, so even on that I have to use legacy bios boot. However, I'm not sure we need to make a prepackaged gptboot binary that has serial prompting for geli passwords. That's a pretty specialized need that can be handled by people building WITH_GPTBOOT_SERIAL or some similar option and installing it themselves.  -- Ian