Date: Wed, 20 Jun 2018 19:03:15 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: Allan Jude <allanjude@freebsd.org>, 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: <20180620160315.GO2430@kib.kiev.ua> In-Reply-To: <1529509411.20460.83.camel@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180620160315.GO2430>