Tim Tassonis wrote:
On 03/11/2017 10:41 PM, Pierre Labastie wrote:
On 11/03/2017 22:11, Tim Tassonis wrote:
On 03/11/2017 09:17 PM, Pierre Labastie wrote:
On 11/03/2017 21:11, Tim Tassonis wrote:
On 03/11/2017 09:00 PM, Tim Tassonis wrote:
Hi all
I tried to upgrade my lfs machine to kbd 2.0.4 and after a reboot init
reported a failure (rc = 1) and needed a return press to continue.
Unfortunately, I haven't been able to find the reason for this. I use
the exact console bootscript from LFS-Bootscripts (20150222) and
after a
downgrade to kbd 2.0.3, the issue went away again.
My bootscript order is:
ls -1 /etc/rc.d/rcS.d
S00mountvirtfs
S01sysctl
S02modules
S03udev
S04swap
S05checkfs
S06mountfs
S07cleanfs
S08localnet
S09udev_retry
S10console
My /etc/sysconfig/console is:
cat /etc/sysconfig/console
# Begin /etc/sysconfig/console
UNICODE="1"
KEYMAP="qwertz/de_CH-latin1"
LEGACY_CHARSET="iso-8859-1"
FONT="LatGrkCyr-8x16 -m 8859-1"
# End /etc/sysconfig/console
Has somene expierienced similar problems upon upgrade of kbd?
Upon debugging the script further, I found out that the section
[ -z "$LEGACY_CHARSET" ] ||
dumpkeys -c "$LEGACY_CHARSET" | loadkeys -u >/dev/null 2>&1 ||
failed=1
is causing the error: when calling it with my configuration, this
leads to:
dumpkeys -c iso-8859-1 |loadkeys -u
adding map 3 violates explicit keymaps line
This error goes away after a downgrade to 2.0.3
Seen that IIRC. I think nowadays legacy charset and - m switch are not
needed (at least for roman languages). I only have:
UNICODE="1"
KEYMAP="fr-latin9"
FONT="lat0-16"
I'm almost sure UNICODE is the default now, but I have not tested.
Thanks. I'm however not quite sure what to do. I was under the
impression that if I (and you apparently, too) load a keymap called
qwertz/de_CH-latin1 or fr-latin9
that they are not in UNICODE and therefore according to chapter 7.6
would need a line
LEGACY_CHARSET="iso-8859-1"
LEGACY_CHARSET="iso-8859-9"
This will then trigger the dumpkeys|loadkeys, which fails. So, I
wonder what is wrong:
- Is qwertz/de_CH-latin1 not really encoded in latin1, but in utf-8
and therefore named wrong? (upstream bug)
- Is chapter 7.6 wrong in saying that any non-utf8 keymap has to be
converted, by setting LEGACY_CHARSET?
The keymap maps key codes (from the keyboard, usually starting at 01) to
character names like 'agrave' of 'parenright'. So it does not have much
to do with whatever encoding. Maybe, instead of names, some keys can be
associated to numeric codes ( "man keymaps" says so). But for our
keymaps (fr-latin9 or de_CH-latin1), I think they mainly use symbolic
forms as above. What code is sent to the kernel for a given symbolic
name may depend on whether unicode is enabled or not (so UNICODE=1 may
be required).
Not sure it is clear. It's not completely clear to me actually... But I
am almost sure you can remove the legacy charset (and also the -m option
in setfont).
In that case I think I will go for a solution where the console init
script will return 0 on a failure of
dumpkeys -c "$LEGACY_CHARSET" | loadkeys -u >/dev/null 2>&1
It seems, if this works, that's good, and if it doesn't work, then it's
not necessary.
Thanks a lot for all the explanations.
Just comment out LEGACY_CHARSET in the appropriate /etc/sysconfig file.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
