From Bugzilla Helper: User-Agent: Mozilla/4.75 [en] (Windows NT 5.0; U) Description of problem: Minicom won't connect to mgetty over a nullmodem cable. This used to work under 7.3. There are other bugs as well: with LANG=en_US.UTF-8 and LANG=C minicom won't always recognise Ctrl-A to get into the menu, and after running minicom, I need to reset my terminal with reset. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install a Red Hat 8.0 with mgetty and run mgetty on the serial port (in /etc/inittab: s1:2345:respawn:/sbin/mgetty -r ttyS0) 2. Install another Red Hat 8.0 and connect both with a (known working) null-modem cable 3. Start minicom. Set serial port options to 38400 8N1, and disable Init and Reset strings. Actual Results: Should show a login prompt and behave correctly w/ regards to keyboard input Expected Results: Does not show a login prompt. Ctrl-A works only occasionally. Afterwards the terminal is in a "echo off" state and needs a "reset" to work properly. Additional info: I have tried this under LANG=en_US.UTF=8 and LANG=C. No difference. I have also downgraded to the minicom supplied with Red Hat 7.3. No difference either. I suspect it's got to do with the change of locale from iso<something> to UTF-8, but can't confirm this.
Run minicom with LANG=en_US Most likely it is not UTF-8 aware
Does the above work for you?
I couldn't reproduce the exact error. Both with and without LANG=en_US minicom works fine - well, at least it connects properly. I think I did something wrong the first time. In an xterm (GNOME terminal) minicom now works OK, but on a VT, the borders around the menus don't show up. So there *IS* a problem related to the terminal, but it is not as severe as I thought. Running minicom in an xterm is good enough for me. AFAIC, the bug can be closed.
minicom has some problems regarding drawing boxes with ncurses, which should be fixed with an ncurses upgrade. I was, however, able to use Ctrl-A and connect.