getty fails to prompt for login on ttyu0

[Anton Shterenlikht]

On Fri, Jul 30, 2010 at 07:13:30AM -0700, Zach Wilkinson wrote:
> On first boot off hard disk, kernel messages print to serial console and at the end it prints the time/date but no login prompt.
> 
> I SSH in as a standard user and I see getty is running on ttyu0:
> 
> $ ps awux |grep getty
> root   1087  0.0  0.0  5584  2392  ??  I 0:20PM  :00.00 /usr/libexec/getty std.9600 ttyu0
> 
> And that config is reflected in /etc/ttys:
> 
> $ grep ttyu0 /etc/ttys
> ttyu0   "/usr/libexec/getty std.9600"   vt100   on  secure
> 
> I believe the terminal (minicom) is configured correctly since I was able to interact with and complete the install over serial console. And system messages (su failures) continue to print to serial console.
> 
> However, I'm not able to get any direct response from input in serial console. And to make matters worse I didn't enable root auth over SSH, and I forgot to add my non-root account to the wheel group.
> 
> So, before I boot off CD, any recommendations on what else I should check?

yes, this happened to me (three times I think..)

This must be in the archives.

The problem is that the default /etc/ttys doesn't
enable your default console, e.g. from my rx2600
dmesg:

% dmesg|grep uart
GDB: debug ports: uart
GDB: current port: uart
uart0: <16550 or compatible> mem 0xf4051000-0xf405100f irq 82 at device 1.0 on pci224
uart0: [FILTER]
uart1: <Non-standard ns8250 class UART with FIFOs> on puc0
uart1: [FILTER]
uart1: console (9600,n,8,1)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
uart2: <Non-standard ns8250 class UART with FIFOs> on puc0
uart2: [FILTER]
uart3: <16550 or compatible> iomem 0xff5e0000-0xff5e0007 irq 34 on acpi0
uart3: [FILTER]
uart4: <16550 or compatible> iomem 0xff5e2000-0xff5e2007 irq 35 on acpi0
uart4: [FILTER]
uart4: debug port (9600,n,8,1)
%

i.e. I need to enable logins on ttyu1, so I have in /etc/ttys:
 
ttyu0   "/usr/libexec/getty std.9600"   vt100   on  secure
ttyu1   "/usr/libexec/getty std.9600"   dialup  on secure

I think you should be able to connect to MP
via ethernet still, provided you know the
ip address of your MP.


-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423