in /etc/inittab line 61 you see this
# Example how to put a getty on a serial line (for a terminal)
#
T0:2345:respawn:/sbin/getty -L ttyS0 115200 vt100
disable that line
matt_max wrote:I think it is related to the lack of eth interface.
fvdw wrote:matt_max wrote:I think it is related to the lack of eth interface.
why do you think that ?
serial interface doesn't need a ethernet interface
18.6 ... respawning too fast: disabled for 5 minutes
What's happening
You see a message on the console like: "Getty respawning too fast: disabled for 5 minutes". Instead of "Getty" it may display a label (such as: Id "S2") where S2 is the label for the line in /etc/inittab from where from where getty was called.
When getty starts up, it tries to send a login message to the serial port. But if there is something seriously wrong, getty will be immediately killed. Since the /etc/inittab file line for getty says to "respawn", getty is started again, only to be killed again, etc. Thus getty respawns over and over. But the operating system intervenes and stops this nonsense (for 5 minutes). The following sections show possible causes and fixes.
Getty line in /etc/inittab file incorrect
Make sure the the line which calls getty in /etc/inittab is correct. A typo in "ttySx" (or "DTxxxx" for uugetty) or in "getty" may cause this problem.
No modem control signal
If the terminal doesn't send the PC a CD signal on one of the pins of the serial port, getty will be killed unless the "local" option has been used with getty. So a quick fix is to just use a "local" option (-L for agetty, "CLOCAL" in /etc/gettydefs for ps_getty).
Another approach is to determine why CD is not being asserted. In many cases the cable to the terminal simply doesn't have a wire for the CD pin so you must use the "local" option. If there is a wire for the CD pin then there may not be any signal on it until the terminal is powered on. Note that the CD pin signal is sometimes supplied by the DTR pin of the terminal (or the PC) by using jumper wires inside the connector.
No such serial device
If the device (such as /dev/ttyS2) is bogus (doesn't physically exist or has been disabled), then getty will be killed. You may use "scanport" (Debian only ??) and/or "setserial" to probe for the device or try another ttyS. Perhaps the device has been disabled in the CMOS. See "Serial-HOWTO".
No serial support
Linux provides serial support either by selecting it when compiling the kernel or by loading the serial module: serial.o. This "respawning" error happens if serial support has neither been built into the kernel nor provided by a serial module. You many use the "lsmod" command to see if the serial module is loaded. To see if serial support is built into the kernel, check a kernel configuration file (in /boot, in the source tree, etc.)
Key shorted
Another possible cause of getty respawning too rapidly is if a keyboard key is shorted. This gives the same result as if the key was continuously held down. With auto-repeat enabled, this "types" thousands of characters to the login prompt. Look for a screen filled with all the same character (in some cases, with 2 or more different characters).
WDMyCloud:~# chroot /chroot /etc/init.d/rcS
Killed
matt_max wrote:Take your time. I'm really happy that I can help and better understand what is going on during booting process. Maybe we can adopt fvdw firmware for other owners of WD Mycloud NAS.
Chroot is still not available
- Code: Select all
WDMyCloud:~# chroot /chroot /etc/init.d/rcS
Killed
Users browsing this forum: No registered users and 11 guests