Jump to content
funtoo forums
  • 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
2 hours ago, dhudson said:

you might look at openrc seems like it updated lately? my log says dec 27 but I think its updated since then.

*  sys-apps/openrc
      Latest version available: 0.35.0_beta1
      Latest version installed: 0.35.0_beta1
      Repository:    core-kit
      Size of files: 0 KiB
      Homepage:      https://github.com/openrc/openrc/
      Description:   OpenRC manages the services, startup and shutdown of a host
      License:       BSD-2

 

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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...