svn commit: r335276 - in head/stand/i386: gptboot zfsboot

[Konstantin Belousov]

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.