From owner-svn-src-head@freebsd.org Wed Jun 20 16:05:18 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 4A0621021634 for ; Wed, 20 Jun 2018 16:05:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BDD6D81ECC for ; Wed, 20 Jun 2018 16:05:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id d22-v6so205810iof.13 for ; Wed, 20 Jun 2018 09:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=iGxP+kmEZ3/inUNZaBAPW0+ZedymMIc/mPlWUoepGKw=; b=K6zfz02daisV3pFR/12p1zhFInGlqOvC2DAGLktAwudZrloJw5JOIox6YXZZn12SLb DH8F8jnYBJLP2v/EXQ/con4Q36U+oqYccEHoETy1CCynfIvknaoYGx9i1HtyRSEZzbuS xK3UAJIQViEjL00xg2Hyl6Mg5tTUGhjtPIc542FGXWE11S64KNeL6ALp089cX82iTBxx +n7qeArAigBNVt3hh2zFfZH1XrctDcW5qtWDoaIss/vLnyep4kzR2er+ZUglHO5blXUD eXEvTw6oILSlbmZv2aE5w/3HilqywURTZQvlb3zsGDMHwfQ+SK9GucWn0JGqza4vLzJd QFaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=iGxP+kmEZ3/inUNZaBAPW0+ZedymMIc/mPlWUoepGKw=; b=cM9S2jAMmsA4Ukpi/59u3i4p9+qcxsdLnJyIT0gM3D6krq/apc0fSnFGl8fFqDeOLx 7TQPXVyscyk91i5nmWq0D1gs7TTSoYNkvxRnL/klBpc+Bzx3bm20p029szHwBT3pBF53 Ou3WLQFBUUDlz5mcE5FmlpSB4fnTqMserTTR6YG921StcRhHmGoPd+92RbtJVk+gxWNj SHzB7ADZbqhbi/hC3l0lWp0zPylL2Iq4/dl4eJMVqZRc8INSE30AfGjucP3k2/q0CqMz 4UxqkLrdj8Ekjyx1NEO/jNXpr52hpuPY2oK+qGqi3ewEdvhCzTCAeURUDEKxwdC4xzu0 iKjw== X-Gm-Message-State: APt69E2CceslcAGifSJAhMvQftm9ZgwLeevJVrcewsGCJOuJVG+3bROF bd+D7iarC5VefFgDbzr3vJr6MPk7ph53l6WRAOTM7g== X-Google-Smtp-Source: ADUXVKKjakZxJmLmQXHOxRvAb8AuCYod25qMysb09ncT+WpAk+qVGJCWXNMKfxC1EHueUT1h6GJGlQTiKZjV3mRNHPg= X-Received: by 2002:a6b:29c4:: with SMTP id p187-v6mr17122563iop.299.1529510716963; Wed, 20 Jun 2018 09:05:16 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 09:05:16 -0700 (PDT) X-Originating-IP: [50.227.106.226] In-Reply-To: <20180620160315.GO2430@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> <1529509411.20460.83.camel@freebsd.org> <20180620160315.GO2430@kib.kiev.ua> From: Warner Losh Date: Wed, 20 Jun 2018 10:05:16 -0600 X-Google-Sender-Auth: 5FU9VODdaeCuYaGXXy0IujqMp1s Message-ID: Subject: Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot To: Konstantin Belousov Cc: Ian Lepore , Allan Jude , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 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:05:18 -0000 On Wed, Jun 20, 2018 at 10:03 AM, Konstantin Belousov wrote: > On Wed, Jun 20, 2018 at 09:43:31AM -0600, Ian Lepore wrote: > > 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. > I do not propose to abandon bios boot, or even to declare it legacy > with the proper meaning. I mean that CSM is disappearing on the newest > platforms, and should become only used on old machines or i386. With that > attitude, adding a features for it, esp. by the cost of the user confusion, > is not worth the efforts. It still should be maintained for the foreseable > future. > > If the machines where you get the trouble is newer than say 5 years, > then they should boot with UEFI. If not, the problem in loader.efi > needs to be fixed. > There is no problem in loader.efi that's specific to geli. It already uses the UEFI boot loader config. While there's some issues downstream (eg kernel messages), this specific issue is a non-issue for loader.efi. Warer