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

[Warner Losh]

On Tue, Jun 19, 2018 at 6:34 PM, Allan Jude <allanjude at freebsd.org> 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 *NOT* do that.

There is a niche market for this stuff, and we should support building
serial-enabled bootblocks on an opt-in basis. The support is really already
there, this just enables it early.

I agree with kib@ that the target market here is too small to justify a
proliferation of new boot blocks.

Warner