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.
sc(4) supports only non-EFI boot, on the other hand, it silently should use vt(4) EFI boot.
I see (documented in UEFI(8)).
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?
(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.
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(-)
(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)
(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.
(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
(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.
Please do not remove sc from GENERIC, not yet.
(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.
(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
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(-)
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(-)
(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).