Jump to content
  • 0
Sign in to follow this  
digifuzzy

TTY (console) colour changed after OpenRC start

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.

Share this post


Link to post
Share on other sites

Recommended Posts

  • 0

I blacklisted the radeon module and rebooted. Screen stayed white text on black background through out boot process.

However, console stayed at 80 cols wide (looks ugly on a 1920x1080 monitor).

Share this post


Link to post
Share on other sites
  • 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.

Share this post


Link to post
Share on other sites
  • 0

Further experimenting...

sys-kernel/debian-sources downgraded from 4.14.12 to next kernel below 4.14.2 (upgrade when the problems first observed).
Version debian-sources-4.8.15 was the only package available. Problem did not persist after a reboot.

 

Share this post


Link to post
Share on other sites
  • 0

@palica I tried that. LTS is at 4.9.65 and I thought it would be a better choice. Unfortunately, I did something wrong and got a pile of errors back. Custom kernel building is new territory for me.

I'm not sure about kconfig. I'll research and retrieve.

Share this post


Link to post
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>

Share this post


Link to post
Share on other sites
  • 0

@palica I tried that last night but it balked at me when it got to the drivers (IIRC - realtek was shown).

The info about kernel config is useful. I was looking here for a path ahead. Your way seems easier.

Appreciate the help - will report back with more.

Share this post


Link to post
Share on other sites
  • 0

you probably need to install linux-firmware package for the realtek firmware to be available for kernel on boot up, it that is what you mean by:

2 minutes ago, digifuzzy said:

it got to the drivers (IIRC - realtek was shown).

 

Share this post


Link to post
Share on other sites
  • 0
Just now, palica said:

you probably need to install linux-firmware package for the realtek firmware to be available for kernel on boot up

firmware package is already installed. Something went wrong during emerge and I didn't dig into why.

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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)

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites
  • 0

Hi!

Its very difficult to follow the entire thread.

To understand the patterns of a problem a following information could help:

1. using same kernel but different OpenRC versions will reproduce the bug.

2. using same OpenRC version but different kernel will reproduce the bug

Share this post


Link to post
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
Sign in to follow this  

×
×
  • Create New...