Bug 264226 - setting kern.vty=sc causes hang during boot
Summary: setting kern.vty=sc causes hang during boot
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 13.0-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-05-25 08:28 UTC by Thomas E. Dickey
Modified: 2022-06-16 14:04 UTC (History)
4 users (show)

See Also:
koobs: maintainer-feedback+
koobs: mfc-stable13?
koobs: mfc-stable12?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas E. Dickey 2022-05-25 08:28:50 UTC
sc(4) https://www.freebsd.org/cgi/man.cgi?query=sc&sektion=4

says that it is possible to set syscons in /boot/loader.conf

With FreeBSD 13.0, that causes it to hang during boot.
Comment 1 Marek Zarychta 2022-05-25 08:54:31 UTC
sc(4) supports only non-EFI boot, on the other hand, it silently should use vt(4) EFI boot.
Comment 2 Thomas E. Dickey 2022-05-25 21:29:34 UTC
I see (documented in UEFI(8)).
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2022-05-26 00:01:28 UTC
What improvements could be made here?

- For EFi boots, if 'sc' is set, use vt and log a console message?

@Thomas Are you able to include a full boot log as an attachment?
Comment 4 Ed Maste freebsd_committer 2022-05-26 00:14:48 UTC
(In reply to Kubilay Kocak from comment #3)

There's no need to include a log - this behaviour is clear from the code.

References:
sys/amd64/amd64/machdep.c
sys/kern/kern_cons.c

The priority order for choosing a console is:

- sc, if kern.vty=sc
- vt, if kern.vt=vt
- vt, if EFI boot (via vty_set_preferred)
- vt
- sc

(there's some redundancy left over, from the iterative approach we took to changing the default)

Moving the vty_set_preferred handling to the top of the list would have the behaviour you describe, but would mean the system ignores the user's setting when it has a preferred choice.

The easiest way to address this will be to just remove sc from GENERIC.
Comment 5 commit-hook freebsd_committer 2022-05-26 00:26:01 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=20b2b464ebb6748756e262d8a421509a2937c74b

commit 20b2b464ebb6748756e262d8a421509a2937c74b
Author:     Ed Maste <emaste@FreeBSD.org>
AuthorDate: 2022-05-26 00:19:24 +0000
Commit:     Ed Maste <emaste@FreeBSD.org>
CommitDate: 2022-05-26 00:25:41 +0000

    syscons: note incompatibility with UEFI

    PR:             264226
    MFC after:      1 week
    Sponsored by:   The FreeBSD Foundation

 share/man/man4/syscons.4 | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2022-05-26 00:33:53 UTC
(In reply to Ed Maste from comment #4)

Thanks Ed.

A log entry would notify the user that the chosen/expected console method was not actually used, in which case they could remove the sysctl entry. Is it too late for 'quality transition messaging' now?

Current understanding of the issue as reported:

- If sc is set, vt should be used but isn't via comment 1. 

Is this not the case?

- There remains a condition where sc can be set, and boot hangs.

What case is this (if true), and what improvement opportunity are there if any? (modulo sc removal)
Comment 7 Ed Maste freebsd_committer 2022-05-26 00:51:15 UTC
(In reply to Kubilay Kocak from comment #6)

If the user tells the kernel to use sc it uses sc, regardless of whether or not it is going to work.

Re comment 1, I am not sure if Marek means they expect vt(4) to be used, or it would be good if vt(4) was used in this case.
Comment 8 Kubilay Kocak freebsd_committer freebsd_triage 2022-05-26 01:14:49 UTC
(In reply to Ed Maste from comment #7)

Understood, thanks. So if I understand correctly, it sounds like two potential routes (modulo sc removal), in context to current reported behaviour 'boot hang', three if one counts hung boot without messaging as a route.

Since sc is incompatible with UEFI (comment 5):

Catch UEFI & kern.vty=sc case, and do something other than hang...

1) "stop", with message: "kern.vty=sc is set, but is incompatible with UEFI boot"

Outcome: system stops, user informed why: incompatible system configuration (for that boot)

2) use vt when sc is specified but its an EFI boot

Outcome: system boots

2.1) Log what happened: 

Outcome: user informed of incompatible system configuration (for that boot)

2.2) Don't log what happened: 

Outcome: the system did some magic, noone is the wiser
Comment 9 Marek Zarychta 2022-05-26 06:33:45 UTC
(In reply to Ed Maste from comment #7)

I presumed that kern.vty="sc" will be silently ignored and vt(4) will always be used when EFI is the boot method.

(In reply to Ed Maste from comment #4)
>The easiest way to address this will be to just remove sc from GENERIC.

Please don't do it, at least yet! Still, probably the main drawback of vt(4) is missing DPMS support.
Comment 10 Eugene Grosbein freebsd_committer 2022-05-26 07:00:37 UTC
Please do not remove sc from GENERIC, not yet.
Comment 11 Ed Maste freebsd_committer 2022-05-26 15:03:48 UTC
(In reply to Kubilay Kocak from comment #8)
> 1) "stop", with message: "kern.vty=sc is set, but is incompatible with UEFI boot"

Not really an option - to implement this we'd have to override kern.vty (at the point in early boot that the choice is made) to use vt, wait for the system to boot far enough that we can print the message, then stop.

> 2) use vt when sc is specified but its an EFI boot

I'd happily review a patch if someone wants to go this route.

> 2.1) Log what happened:

This is a bit tricky for the same reason as #1, the choice is made before we have a way to emit such a message. It could be done, but probably not worth the effort. kern.vty would indicate vt though.
Comment 12 Kubilay Kocak freebsd_committer freebsd_triage 2022-05-27 00:32:13 UTC
(In reply to Ed Maste from comment #11)

How feasible is tracking what happened, and emitting the message later?

Do we have any mechanisms base/kernel/boot/loader/etc for annotating events/actions for later parsing > messaging?

@Reporter/Marek If you'd like to propose automatically using vt in the case where sc is specified in a uefi boot configuration, over the current hang behaviour, please do so
Comment 13 commit-hook freebsd_committer 2022-06-16 12:52:48 UTC
A commit in branch stable/13 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=f918bec0d404ff4e9af61fa8ac8f035936527352

commit f918bec0d404ff4e9af61fa8ac8f035936527352
Author:     Ed Maste <emaste@FreeBSD.org>
AuthorDate: 2022-05-26 00:19:24 +0000
Commit:     Ed Maste <emaste@FreeBSD.org>
CommitDate: 2022-06-16 12:49:54 +0000

    syscons: note incompatibility with UEFI

    PR:             264226
    MFC after:      1 week
    Sponsored by:   The FreeBSD Foundation

    (cherry picked from commit 20b2b464ebb6748756e262d8a421509a2937c74b)

 share/man/man4/syscons.4 | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)
Comment 14 commit-hook freebsd_committer 2022-06-16 13:39:00 UTC
A commit in branch stable/12 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=93c8e4897eaa006fcd6364231c3d908ac1bc3442

commit 93c8e4897eaa006fcd6364231c3d908ac1bc3442
Author:     Ed Maste <emaste@FreeBSD.org>
AuthorDate: 2022-05-26 00:19:24 +0000
Commit:     Ed Maste <emaste@FreeBSD.org>
CommitDate: 2022-06-16 13:37:54 +0000

    syscons: note incompatibility with UEFI

    PR:             264226
    MFC after:      1 week
    Sponsored by:   The FreeBSD Foundation

    (cherry picked from commit 20b2b464ebb6748756e262d8a421509a2937c74b)

 share/man/man4/syscons.4 | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)
Comment 15 Ed Maste freebsd_committer 2022-06-16 14:04:59 UTC
(In reply to Kubilay Kocak from comment #12)
> How feasible is tracking what happened, and emitting the message later?
>
> Do we have any mechanisms base/kernel/boot/loader/etc for annotating
> events/actions for later parsing > messaging?

I'm not aware of any off hand.

It's possible that we could use something along the lines of PRINTF_BUFR_SIZE (which prints to a temporary buffer before emitting to the console, to avoid interspersed output). IMO the most likely way to achieve this will be to include this as a requirement in planning more extensive console rework (imp@ has discussed some plans for true multicons in the past, but nothing concrete is planned as far as I know).