Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 338968 - sys-apps/openrc-0.6.3 bug in early init font loading system prevents it from working
Summary: sys-apps/openrc-0.6.3 bug in early init font loading system prevents it from ...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: OpenRC Team
URL:
Whiteboard:
Keywords: InOverlay
Depends on:
Blocks:
 
Reported: 2010-09-28 00:38 UTC by Witold Piłat
Modified: 2010-09-30 12:35 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
init-early.sh simple patch (openrc-0.6.3.patch,1007 bytes, patch)
2010-09-28 00:42 UTC, Witold Piłat
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Witold Piłat 2010-09-28 00:38:46 UTC
There is a bug in openrc-0.2.6/sh/init-early.sh.Linux.in (/lib/rc/init-early.sh), which prevents it from doing it's job - loading consolefont from previous session at the beginning of init sequence. In my installation setfont isn't in /bin/setfont but rather in /usr/bin/setfont. I've removed whole check as there wont be any output or system failure anyway. (few lines below there isn't any check for loadkeys, I've added -q option here as it produces message).

I have some other thoughts on whole consolefont/keymaps system in openrc, but I didn't want to write a patch right now as I've never done it before so I'm a little bit shaky about introducing big changes and I would like to know someone's more experienced opinion.

1. init-early font/keymap script
In my opinion it should reproduce whole procedure of setting up fonts, keymaps and translation tables because now it simply doesn't work in many scenarios and it isn't much more work to fix it anyway. It doesn't break anything important only because of standard latin/numbers layout in every charset, but we can have the same effect without it. I think that consolefont and keymaps init scripts should dump whole font, unimap and cmap using setfont utility, not only copy font and dump keymap. Besides there is unused (since openrc) variable dumpkey_charset in conf.d/keymaps which should be used when dumping non unicode keymap in keymap initscript.
I'll give here an example of situation when it doesn't work in current state: I use ter-v20b 512 glif unicode font. Unfortunately polish keymaps aren't unicode ones, all of them are iso-8859-2. Therefore I set 8859-2 unicode console map (with setfont -m) since it translates keys after keymap to ucs2 correctly and doesn't affect console driver as it is in unicode mode. Now in init-early phase my keymap is loaded (and fortunately recognised as 8859-2 since it uses special names), but the unicode console map is lost so keycodes aren't translated after keymap and are treated as iso-8859-1 ones so I end up without polish characters. I know that not having polish characters before default runlevel isn't a big deal, but there is such script so it should work properly.

2. Non-unicode keymaps:
Wouldn't it be good to add -u (implicit conversion to unicode) to loadkeys in case unicode is on? It doesn't affect unicode keymaps and reduces confusion due to unicode console map affect on keyboard input (because of that confusion I went through all of this to understand how it works :) ) I can't think of any possible scenario when someone wants non unicode keymap when console and keyboard works in unicode mode anyway.



Reproducible: Always

Steps to Reproduce:
1. Set up custom font in /etc/conf.d/consolefont
2. Reboot
Comment 1 Witold Piłat 2010-09-28 00:42:38 UTC
Created attachment 248851 [details, diff]
init-early.sh simple patch
Comment 2 Jory A. Pratt gentoo-dev 2010-09-30 12:35:13 UTC
loadkeys is suppressed, and path is updated, thanks for reporting.