Ah, that makes sense then
** Changed in: upstart (Ubuntu)
Status: Incomplete = Triaged
** Summary changed:
- non-ascii layout/encoding problems at login line
+ event.d: non-ascii layout/encoding problems at login line
** Summary changed:
- event.d: non-ascii layout/encoding problems at
getty and locales might be one problem. I have not looked into that.
But another problem are non-ASCII characters being corrupted on the
console. I believe you might see a combination of both problems. The
character corruption problem has been reported as
** Tags added: qa-jaunty-foundations
--
non-ascii layout/encoding problems at login line
https://bugs.launchpad.net/bugs/273189
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
I'm not convinced that we got this right in the sysvinit era either!
--
non-ascii layout/encoding problems at login line
https://bugs.launchpad.net/bugs/273189
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
When did we start to need -8? I don't remember seeing that in inittab
--
non-ascii layout/encoding problems at login line
https://bugs.launchpad.net/bugs/273189
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
Scott, unless getty is run with -8, it'll use the top bit for parity
detection regardless of how upstart set up the console before it.
There's a task on upstart because system-services owns /etc/event.d/tty*
which governs how getty is started.
Gökdeniz, the bug is not yet fixed so you're not
OK, I've tracked this down to a combination of a bug in getty, which is
shipped by util-linux, and a bug in the way we start getty. Here's the
relevant code in get_logname:
if (op-eightbits) {
ascval = c;
} else if (c != (ascval = (c 0177))) {/* parity
Upstart isn't setting the system console correctly?
It runs this on /dev/console when it first starts to attempt to set it
up in the usual way.
static void
reset_console (void)
{
struct termios tty;
tcgetattr (0, tty);
tty.c_cflag = (CBAUD | CBAUDEX | CSIZE | CSTOPB |
This bug was fixed in the package finish-install - 2.18ubuntu1
---
finish-install (2.18ubuntu1) intrepid; urgency=low
* Remove -8 (if present) from getty options for serial terminals
(LP: #273189).
-- Colin Watson [EMAIL PROTECTED] Thu, 25 Sep 2008 13:59:33 +0100
**
I added -8 manually to /etc/event.d/ttyX and it ignored non-ascii
characters I typed, so the fix is OK.
But I only managed to find the following diff for this fix, and it removes
the -8 for serial consoles. I think the real fix is elsewhere and I couldn't
find it ? Does it getes applied at
I'm seeing the same thing in bash, and it really seems to be at the
application level. Here's an strace of it trying to read the £ sign:
read(0, \302, 1) = 1
write(2, \302, 1) = 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
read(0, \243, 1)
Ah! bash was a red herring and entirely my fault. I had this in
.inputrc, left over from a previous era:
Meta-#: \C-v£
This mapped byte 0xA3 to C-v £, which caused great confusion. Removing
it fixed both £ and ğ (I think the latter was because I'd got bash's
internal state in a muddle).
Back
** Summary changed:
- Turkish layout problems at login line
+ non-ascii layout/encoding problems at login line
** Description changed:
Binary package hint: console-setup
The default console font was problematic with Turkish language characters
(latin5, iso-8859-9)
I changed the
13 matches
Mail list logo
