Jump to content
Read the Funtoo Newsletter: Summer 2023 ×
  • 0

TTY (console) colour changed after OpenRC start


digifuzzy

Question

I just finished the update (kernel 4.14.2-1). Out of this I got one thing that is annoying and noobish.

The boot process goes along nicely in TTY. OpenRC starts up. All the while the screen is white text on black background. Then video driver is loaded...
The presentation is just horrible after that with light grey text on a white background!!!

Not sure how that came about as the console default was white text on black background and I didn't make any changes or customizations.
Maybe someone can help? Point me in the right direction?

Edit #1:
setterm does not affect display
contents of dmesg/message or xorg log are "unremarkable"

Edit #2:
Changed Title - Xorg is not installed on system.

Link to comment
Share on other sites

Recommended Posts

  • 0

Further experimenting...

Used kernel boot parameters:
nofb - no change to appearance - get 1920x1080 presentation grey text on white background
nomodeset - get normal colours but old-style console display (80 cols x 2? rows)

I then found an article about using setterm in the inittab.
Experimenting with the setterm command I discovered there is some kind of colour masking in play.
 

setterm -clear all -background cyan

produced a screen with a purple background. Using `-background black` returned the screen to the white background.

Link to comment
Share on other sites

  • 0
USE=binary emerge -av debian-sources-lts 

should install a working copy of kernel.

You can add binary useflag to /etc/portage/package.use

sys-kernel/debian-sources-lts binary

kernel config = kconfig can be usually found /proc/config.gz once you have booted. you can save the file to your home directory and boot the second kernel and do the same and then compare, or paste the diff -u <kconfig1> <kconfig2>

Link to comment
Share on other sites

  • 0
2 minutes ago, palica said:

hard to debug without logs :)

Focus was on getting a working kernel without the console problem. Jumping to debugging why the LTS kernel didn't build seemed off-topic/off-task at the time.
I can revisit later after getting current situation under control.

Link to comment
Share on other sites

  • 0

@palica - it occurred to me that it might be useful to extend your suggestion about /proc/config.gz. As I mentioned earlier, my desktop system doesn't exhibit the behaviour that the funtoo system shows. For completeness, I'm uploading the diff file of the config for the funtoo kernel 4.14.2 and the desktop kernel 4.14.12.

kernel_funtoo_artix.diff.gz

Link to comment
Share on other sites

  • 0

start by removing

CONFIG_FB_RADEON

howto:

eselect kernel list

eselect kernel set your-preferred-kernel

cd /usr/src/linux

zcat /proc/config.gz > .config

genkernel --menuconfig all

search for fb_radeon

hit N for no (not built-in, no module)

save

let genkernel build kernel and initrd

check it built and installed in /boot

reboot

Link to comment
Share on other sites

  • 0

@palica - so I'm building a custom kernel because of glitch in the handling of a video card?

Okay. I'll deal.

FTR - genkernel menu showed the ATI  Radeon framebuffer as "< >" or no value. I hit 'N' anyway. I'll see what the value of config shows after the reboot but I suspect it will be unchanged.

Link to comment
Share on other sites

  • 0

ok, sorry then I probably interpreted the kernel configs wrong. or you were building it from desktop? and thus applied the /proc/config.gz from the running desktop config and actually duplicated the desktop config.

hrm? so if this is the case then with the same desktop kernel config your server didn't got fixed. am I right?

try switching the real_root or root in grub

you probably have a line there (/boot/grub/grub.cfg)

  linux /kernel-genkernel-x86_64-4.14.12-2-dl3x0-g7-r1 rootfstype=auto real_root=UUID="e8d10a64-c541-45cc-8502-0b84c40f9c69" rootfstype=f2fs
  initrd /early_ucode.cpio /initramfs-genkernel-x86_64-4.14.12-2-dl3x0-g7-r1

so use the kernel lines from artrix and switch the real_root from server

test and report (so you would take the whole kernel package from artrix and boot it)

Link to comment
Share on other sites

  • 0

@palica - I'm trying not to confuse the descriptions here. The desktop box(w/ Artix) is a separate machine. I included it's config as I thought it would be helpful comparison because it is not exhibiting the behaviour as the Funtoo box.

I built the genkernel on Funtoo via SSH. Quite certain I followed the instructions you gave me accurately. It just didn't work.
Cleaning up afterwards was messy - not up on all the details of kernel handling. Ended up un-merging and re-merging debian-sources. Made me appreciate what the folks at SystemRescueCD have done even more.

I'm not sure what you're asking me to do next.

Link to comment
Share on other sites

  • 0
6 minutes ago, jhan said:

When trying out new kernels it is always a good idea to leave the current and working kernel on the system as well, in case the new kernel does not work.

For that I have two entries in the grub config. One for the new and one for the old. If the new one does not work I can simply reboot and boot the old kernel. No need for a rescue cd then.

Please correlate this statement to the instructions I was given from palica above. Then detail how you would peel back the non-working kernel, please.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...