> On May 4, 2026, at 15:08, Mark Millard <[email protected]> wrote: > > On 5/4/26 13:52, Eugene Grosbein wrote: >> 02.05.2026 13:42, Doug Hardie wrote: >> >>> I have one server (Raspberry Pi 4) which during boot shows all the hardware >>> configuration, >>> but then stops until the Login prompt appears. The other servers show the >>> startup of each service >>> and various other outputs. There is a 10 minute gap on the one server >>> and I would like to see where it is during that process for that time. > > QUOTE from loader.efi's man page > . . . the FreeBSD kernel has a limitation when more than one console > is present. The kernel outputs to all configured consoles. Only the > primary console will get the log messages from the rc(8) system, and > prompts for things like geli(8) passwords. > ENDQUOTE > > So control over which console that you want to be used as primary is at > issue here. > > QUOTE > Primary Console > The primary console is set using the boot flags. These command line > arguments set corresponding flags for the kernel. These flags can be > controlled by setting loader environment variables to “yes” or “no”. > Boot flags may be set on the command line to the boot command. Inside > the kernel, the RB_ flags are used to control behavior, sometimes in > architecturally specific ways and are included to aid in discovery > of any > behavior not covered in this document. > > boot flag loader variable Kernel RB_ flag > -a boot_askme RB_ASKNAME > -c boot_cdrom RB_CDROM > -d boot_ddb RB_KDB > -r boot_dfltroot RB_DFLTROOT > -D boot_multiple RB_MULTIPLE > -m boot_mute RB_MUTE > -g boot_gdb RB_GDB > -h boot_serial RB_SERIAL > -p boot_pause RB_PAUSE > -P boot_probe RB_PROBE > -s boot_single RB_SINGLE > -v boot_verbose RB_VERBOSE > > And the following flags determine the primary console: > > Flags Kernel Flags Kernel Consoles Primary > Console > none 0 Video Video > -h RB_SERIAL Serial Serial > -D RB_MULTIPLE Serial, Video Video > -Dh RB_SERIAL | RB_MULTIPLE Serial, Video Serial > END QUOTE > > There is also notation that can go in /boot/loader.conf . (More later > below.) > >> >> Then you may find useful to put the following to /boot/loader.conf: >> >> kern.msgbuf_show_timestamp=1 >> >>> I have tried to find differences between the server configurations and >>> haven't found the one >>> that controls the startup output. What controls that? Thanks, >> >> It's kernel console settings that you can check out in multiuser mode >> with "conscontrol" command, in my case: >> >> # conscontrol >> Configured: ttyu1,ttyv0 >> Available: ttyu1,ttyv0 >> Muting: off >> >> This corresponds to another loader.conf knob: >> >> comconsole_port=0x2f8 >> boot_multicons="YES" >> console="comconsole vidconsole" > > comconsole has not been supported for aarch64 for some time: the updates > creating eficom span 2023-05-11 .. 2023-05-28 or so and the shim was > temporary in how its code was structured. RPi4B's are aarch64. > > One of the commits was a comconsole compatibility shim for aarch64, but > the shim is set up only via code of the structure: > > #if defined(__aarch64__) && __FreeBSD_version < 1500000 > . . . > #endif > > As for comments about the overall change . . . > > QUOTE (from the first of the series of commits) > Fix the 'renaming kludge' that we absolutely cannot do going forward > (it's cost us days of engineering time). > > console=comconsole talks to the hardware directly. This is available > only on amd64. It is not available anywhere else (and so requires > changes for people doing comconsole on aarch64) > > console=eficom talks to the console via EFI protocols. It's available > on amd64, aarch64 and riscv64. It's the first port that we find, though > it can be overriden by efi_com_port (which should be set to the UID of > the serial port, not the I/O port, despite the name). devinfo -v > will give the UID to uartX mapping. > > This is an incompatible change for HYPER-V on amd64. It only works with > eficom console, so you'll need to change your configuration in > loader.conf. No compatibility hack will ever be provided for this (since > it requires renamig, which the loader cannot reliably do). > > It's also an incompatible change for aarch64. comconsole will need to > change to eficom. There might be a comconsole "shim" for this. > > All the interlock to keep only eficom and comconsole from both attaching > have been removed. > END QUOTE > > On an RPi5B using main I have in use: > > boot_multicons="YES" > #boot_serial="YES" > console="eficom,efi" > > (eficom only works when listed first, as I remember, at least for the > context I have been using.) > > But the RPi5B context is based on a draft EDK2 that was never completed > and I normally use the serial console without a graphics console. The > EDK2 has a selection for graphics vs. serial console and things need to > match up appropriately. > > FYI: /usr/share/man/man8/loader.efi.8.gz does not mention eficom . Nor > do the other loader man pages. > > On the rare occasions when I add a new context, I have to experiment to > get the behavior I happen to be interested in --be it aarch64 or amd64 > for the type of context. Once set up, I normally do not need to change > it for the type of context. > >> >> That is, "primary" console is serial one (COM2 A.K.A. uart1, /dev/cuau1) >> and vidconsole is secondary that does not get messages you want. >> >> Use similar settings but change accordingly. >> Possible values for the "console" setting are documented in the >> loader.conf(5) >> manual page: >> >>> "comconsole" selects serial console, "vidconsole" selects the video console, >> "efi" selects the EFI console etc. >>
I switched to: > boot_multicons="YES" > #boot_serial="YES" > console="eficom,efi" in /boot/loader.conf and it now works. Thanks to all. -- Doug
