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

[Ian Lepore]

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