Strange behavior in a graphical VT: at boot setfont does'nt change the font, but in interactive shell do this.

[yars068]

Hello. How to reproduce: set up a framebuffer console, configure the font ,boot into text mode (aka runlevel 3). In my system (Slackware64-15.0) I get the message setfont: graphics console skipped and the font is not changed. My /etc/rc.d/rc.font contains only a so-called she-bang and a setfont -v ter-c16n.psf.gz command. But, after login, do source /etc/rc.d/rc.font and it will change the font without errors. Bug? UPD. I upgraded kbd package from Slackware-current (rebuild and then upgrade) from 1.15.3 to 2.6.3, nothing changed.

[legionus]

It seems more likely that setfont from the /etc/rc.d/rc.font did not find the terminal on which it was launched. If the terminal was not passed through the -C option, then the search order will be as follows: /proc/self/fd/0, /dev/tty, /dev/tty0, /dev/vc/0, /dev/systty, /dev/console.

You can either try to specify the option -C /dev/console, or check in what environment the script is launched.

[yars068]

I tried to figure out on which VT I'm running. I invoked tty and it shows I'm is on /dev/tty1. Using -C option at boot results is only graphics console /dev/tty1 skipped, but again, running rc.font manually works as mentioned above. UPD. I tried to add a some automation in my rc.font. I added a readlink /proc/self/fd/0 call, and it points me to /dev/console. I substitute the point in setfont call with appropriate -C option via a variable. That again not works, setfont do a exit with the same message graphics console /dev/console skipped. The only change is in manual invoking rc.font. During boot /proc/self/fd/0 points to /dev/console, but after login, it points to /dev/tty1.

[legionus]

During boot /proc/self/fd/0 points to /dev/console, but after login, it points to /dev/tty1.

As I mentioned above the /dev/console is the last option in the list that tries setfont. The /dev/console points to the active device. It could be /dev/fb* which is not suitable for setfont. The /dev/tty0 is the current virtual console, but setfont tried it and it looks like the /dev/tty0 doesn't exist.

So, it looks like your script is executing too early.

Are you using devtmpfs for /dev or do you create the device files by hand?

[yars068]

It is not too eary starting rc.font, because after this, started only gpm and load the keyboard layout rc-scripts, and then I got a login prompt. So this is late stage of system booting, and almost all devices already initialized, and their drivers are loaded. Yes, I am using devtmpfs and eudev for managing it. So, need a more diagnostic here. Have setfont options to increase a verbosity?

[legionus]

It is not too eary starting rc.font, beause after this, started only gpm and load the keyboard layout rc-scripts, and then I got a login prompt.

Well, however no suitable devices were found at the time the script was executed.

Have setfont options to increase a verbosity?

No. But in this case this is not necessary.

[yars068]

Looks like this is mainly a hardware specific issue, not a setfont itself. I boot same system on another hardware configuration and everything works properly. Machine that running into problem is a kvm (qemu) guest, that uses a qxl framebuffer device, so I need to try with a native DRM\KMS drivers, and virtio. In any case, thank you very much.

[legionus]

No problem.

[yars068]

And finally, I found a complete solution. This is not a hardware problem, and not a bug :) but is a order of launching programs in the rc scripts. On this VM I studied how to integrate plymouth, and it is the real reason why setfont can not open proper device. I just moved the rc.font call after plymouth call and now it works out-of-the-box. Thanks again, and sorry for lost of time.

[legionus]

Yey! I'm glad you found the reason :)