Bug 10491 - sysv init 'respawing too fast' on system startup
Summary: sysv init 'respawing too fast' on system startup
Status: VERIFIED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: virtual machines (show other bugs)
Version: 2.2
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 2.3 M3
Assignee: Aníbal Limón
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2016-10-24 17:09 UTC by Leonardo Sandoval Gonzalez
Modified: 2017-03-14 18:29 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Leonardo Sandoval Gonzalez 2016-10-24 17:09:20 UTC
Building a core-image-minimal just with base layers, then launching it with runquemu and nographic as arguments, after a few seconds or minutes, one can see the following message

"INIT: Entering runlevel: 5
Configuring network interfaces... done.
Starting syslogd/klogd: done

Poky (Yocto Project Reference Distro) 2.2 qemux86-64 /dev/ttyS0

INIT: Id "S1" respawning too fast: disabled for 5 minutes
[  131.580175] random: crng init done

Poky (Yocto Project Reference Distro) 2.2 qemux86-64 /dev/ttyS0

qemux86-64 login: "
Comment 1 Leonardo Sandoval Gonzalez 2016-10-24 17:14:03 UTC
Description is incomplete, here are more details:

Commit where the issue was found:
 

commit ef627ab364d52fe19994c94c1a78fbe21620a32c
Author: Joshua Lock <joshua.g.lock@intel.com>
Date:   Wed Oct 12 21:46:42 2016 +0100

    local.conf.sample.extended: remove RM_OLD_IMAGE
    
    RM_OLD_IMAGE has been removed so don't include this variable in
    sample local.conf
    
    (From meta-yocto rev: 0a881d01ab2b0a3f721323447b4c970ab3fd4755)
    
    Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Comment 2 Saul Wold 2016-10-24 17:48:26 UTC
This could also be related to SERIAL_CONSOLES and CHECK_SERIAL_CONSOLES for qemu.
Comment 3 Leonardo Sandoval Gonzalez 2016-10-24 20:25:06 UTC
(In reply to comment #2)
> This could also be related to SERIAL_CONSOLES and CHECK_SERIAL_CONSOLES for
> qemu.

Right, enabling SERIAL_CONSOLES_CHECK = "115200;ttyS0 115200;ttyS1" at local.conf, the problem is not present.  Sending the patch to the mailing list, doing the following 

SERIAL_CONSOLES_CHECK ?= "${SERIAL_CONSOLES}" 

at qemu.inc file.
Comment 4 California Sullivan 2016-10-24 22:01:16 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > This could also be related to SERIAL_CONSOLES and CHECK_SERIAL_CONSOLES for
> > qemu.
> 
> Right, enabling SERIAL_CONSOLES_CHECK = "115200;ttyS0 115200;ttyS1" at
> local.conf, the problem is not present.  Sending the patch to the mailing
> list, doing the following 
> 
> SERIAL_CONSOLES_CHECK ?= "${SERIAL_CONSOLES}" 
> 
> at qemu.inc file.

I don't think this is the correct solution.

SERIAL_CONSOLES_CHECK basically checks if a tty is an output for the kernel's console. qemurunner specifically wants to look at a tty without the kernel's console output so it can cleanly find a login prompt.

If using this variable removes the start_getty on ttyS1 from inittab, this would break qemurunner because its looking for the login prompt on ttyS1.

If using this variable does not remove the start_getty on ttyS1, qemurunner would still break because you would have had to add console=ttyS1 to the kernel command line, giving us kernel console output on the tty we are expecting a clean login prompt on.
Comment 5 Leonardo Sandoval Gonzalez 2016-10-25 14:14:30 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > This could also be related to SERIAL_CONSOLES and CHECK_SERIAL_CONSOLES for
> > > qemu.
> > 
> > Right, enabling SERIAL_CONSOLES_CHECK = "115200;ttyS0 115200;ttyS1" at
> > local.conf, the problem is not present.  Sending the patch to the mailing
> > list, doing the following 
> > 
> > SERIAL_CONSOLES_CHECK ?= "${SERIAL_CONSOLES}" 
> > 
> > at qemu.inc file.
> 
> I don't think this is the correct solution.
> 
> SERIAL_CONSOLES_CHECK basically checks if a tty is an output for the
> kernel's console. qemurunner specifically wants to look at a tty without the
> kernel's console output so it can cleanly find a login prompt.
> 

Got it.

> If using this variable removes the start_getty on ttyS1 from inittab, this
> would break qemurunner because its looking for the login prompt on ttyS1.
> 

Yes, it removes the ttyS1 line from inittab

> If using this variable does not remove the start_getty on ttyS1, qemurunner
> would still break because you would have had to add console=ttyS1 to the
> kernel command line, giving us kernel console output on the tty we are
> expecting a clean login prompt on.

Leaving this bug in the same status. I need to investigate other options. In the meantime, for my specific task, I can include that variable my local.conf
Comment 6 Aníbal Limón 2016-12-01 16:52:30 UTC
Adding serial option the problem isn't present because adds another serial console redirected to terminal and the start_getty works.

For summarize,

serial - Adds one console to QEMU SDL X11 and another one for serial to terminal.
nographic - Adds only one console to terminal.
default - Adds only one console to QEMU SDL X11.

The last two shows the failure because one serial console is missing, i suggest to modify the runqmeu in nographic and default to add one serial console to null, since is a runtime decision and the inittab needs to have the two consoles.
Comment 7 Aníbal Limón 2017-02-15 22:50:54 UTC
I will modify runqemu to provide two serial consoles as specified in machine qemu confs.
Comment 10 Jose Perez C 2017-03-14 18:29:00 UTC
Verified on commit: 6e20b31d5d17133e0fca086e12a0ad06ab5c4cc8 and working as expected