FreeBSD 13.2 strange colors during kernel startup

MG

MG

On a customized 13.2 amd64 install, the kernel startup output is changing colors for unknown reason.
It happens after the message "ioapic0 <version 2.0> irqs 0-23"
Next message is "Loading APs 2 1 3" where 2, 1 and 3 are shown in different col,ors. After this, the color keeps on changing during further output until we reach user-level. Then everything gets normal again.

What is going on here?
 
smithi said:
I'd tried using sc instead of vt on 12.3-R which showed some ugly red text in boot messages, before finding drm-fbsd12.0-kmod.
Click to expand...
Could be the same thing. Not sure at which point the kernel starts using output colors. I will try that out when I'm back home.
Another issue with this system that I didn't mention is the fact the vt CLI misses a few lines at top and bottom. I was planning on finding that out later too.
 
MG said:
Could be the same thing. Not sure at which point the kernel starts using output colors. I will try that out when I'm back home.
Click to expand...

Hm, maybe. What colours?

With vt I get only plain or bright white on black lines, from the start of boot.

MG said:
Another issue with this system that I didn't mention is the fact the vt CLI misses a few lines at top and bottom. I was planning on finding that out later too.
Click to expand...

So you are using vt? I'm on 12.4 so maybe different, but I found vt unusable on vtys with my eyes until adding to loader.conf:
kern.vt.fb.modes.LVDS-1="800x600"

Perhaps provide more info?
 
smithi said:
Hm, maybe. What colours?

With vt I get only plain or bright white on black lines, from the start of boot.



So you are using vt? I'm on 12.4 so maybe different, but I found vt unusable on vtys with my eyes until adding to loader.conf:
kern.vt.fb.modes.LVDS-1="800x600"

Perhaps provide more info?
Click to expand...
It cycles magenta/red/green at random kernel output lines. At the end, the cursor remains red.

My loader.conf:
Code: 
geom_uzip_load="YES"
debug.acpi.disabled="hostres"
hw.syscons.bell=0
vfs.usermount=1
kern.hz=100
kern.cam.boot_delay=10000
vm.kmem_size="629145600"
mfsroot_load="YES"
mfsroot_type="mfs_root"
mfsroot_name="/boot/mfsroot"
vfs.root.mountfrom.options="rw"
vfs.root.mountfrom="ufs:/dev/md0"
beastie_disable="YES"
autoboot_delay="-1"
nullfs_load="YES"
ums_load="YES"
hostuuid_load="NO"
kern.panic_reboot_wait_time=0
hw.vga.textmode=1

# kern.vty=vt
kern.vty=sc
loader_color="NO"

I can't see any difference between sc and vt.

This color thing now seems to happen on all computers. No idea when it got into my base data. I didn't run a full compile for some time. The strange thing is. it begins within the booting kernel. No other files are opened yet.
 
smithi said:
That's strange. Have you tried vt without textmode?

My memory of fiddling with vt settings until it worked ok is a bit fuzzy.

Can anyone else help?
Click to expand...
No change without textmode value. I don't know what this is. Textmode 1? The name isn't present in /boot/defaults/loader.conf... It might be a obsoleted value that's left in my config files.
 

Attachments

  • scherm.jpg
    scherm.jpg
    296.3 KB · Views: 65
I've had the same issue with NanoBSD since FreeBSD 11. I recently solved the problem by switching to vt(4) and adding these lines to my configuration file:

Code: 
WITH_LOADER_LUA=
WITHOUT_FORTH=

Not sure the second line is important.
 
MG said:
No change without textmode value. I don't know what this is. Textmode 1?
Click to expand...

hw.vga.textmode tunable only applies to vt(4), not to sc. The man is quite thorough.

Value 1 turns on staying in textmode - without copy/ paste ISTR. Default 0 lets vt switch to graphics mode early in the boot.

You may wish to use vt, despite crappy copy/ paste support, and you may need to set other tunables listed there, e.g. picking a graphics mode. That might fix your 'missing lines' in vt issue?

MG said:
The name isn't present in /boot/defaults/loader.conf... It might be a obsoleted value that's left in my config files.
Click to expand...

Yes, that file doesn't even mention vt or sc, on 12.4 at least; refer to vt|sc mans.
 
smithi said:
hw.vga.textmode tunable only applies to vt(4), not to sc. The man is quite thorough.
Click to expand...
When using vt and hw.vga.textmode=0, the colors are gone. Not sure what was going on, though. Why does the kernel change output color while starting up? It looks like there's something with the ioapic init that unintentionally causes this, like palette rotation or something like that.

I still have a console that's larger than the display, with 3 lines outside of view on top and bottom of the screen. I can use the fonts in /usr/share/vt/fonts but the problem remains.
Trying to change the mode using vidcontrol -i results in "inappropriate ioctl for device"
This might have to do with the non-generic kernel, so I have to try 13.2 GENERIC kernel first.
 
oOiOo said:
I've had the same issue with NanoBSD since FreeBSD 11. I recently solved the problem by switching to vt(4) and adding these lines to my configuration file:

Code: 
WITH_LOADER_LUA=
WITHOUT_FORTH=

Not sure the second line is important.
Click to expand...
Those are bootloader options that assure the use of lua and not forth anymore. This is already default in FreeBSD, as far as I know
 
You must log in or register to reply here.
Back
Top