[yocto] /etc/inittab generated incorrectly?

[Hans Beckérus]

On Tue, Apr 9, 2013 at 7:20 PM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
> I am having an issue with the /etc/inittab file that seems to be
> incorrectly generated causing the following error at boot:
>    INIT: version 2.88 booting
>    INIT: /etc/inittab[42]: duplicate ID field "1"usb 1-1.1: new
> high-speed USB device number 3 using xusbps-ehci
>
> The reason for this error is due to the 'id' being incorrectly
> assigned to the getty ports in initttab, here is a sample from my
> version of it:
>
> <snip>
> # Normally not reached, but fallthrough in case of emergency.
> z6:6:respawn:/sbin/sulogin
> 0:12345:respawn:/sbin/getty 115200 ttyUSB0
> 1:12345:respawn:/sbin/getty 115200 ttyPS0
> # /sbin/getty invocations for the runlevels.
> #
> # The "id" field MUST be the same as the last
> # characters of the device (after "tty").
> #
> # Format:
> #  <id>:<runlevels>:<action>:<process>
> #
>
> 1:2345:respawn:/sbin/getty 38400 tty1
> <snip>
>
> The getty started for ttyPS0 and tty1 is assigned with the same id.
> I think that for the entries to be unique, the ids should have been
> assigned as 'USB0', 'PS0' and '1' respectively. At least that is what
> is hinted by the comment in inittab itself ;) If I look inside
> sysvinit-inittab_2.88dsf.bb I can see that the tty1 entry was added
> because of having USE_VT=1. The others are coming from SERIAL_CONSOLES
> in my machine .conf.
> Is there some known limitation that USE_VT may not be used in
> combination with SERIAL_CONSOLES? If I use SERIAL_CONSOLE instead it
> works since the id is hardcoded to 'S'. It could be argued if this is
> right or wrong, but at least it avoids the clash in id allocation from
> USE_VT. But I need multiple gettys started so using SERIAL_CONSOLE is
> not an option in this case.
>
> Would this be a bug worth fixing or is my only option here to instead
> set USE_VT=0?
> I guess one possible solution would be to assume 'tty' as prefix and
> then use the rest as suffix in the id field instead of now simply
> using the loop iterator?
> Actually I am not even sure I need a getty to be started on tty1!? Is
> it common praxis to have such an entry? I will only attach to the
> board through the physical serial connections or ssh. The last commit
> I see of this file is
>
> commit 074d49d2cc8bbc1a53a031d9ae0c828596017ed2
> Author: Zhenhua Luo <b19537 at freescale.com>
> Date:   Wed Sep 26 15:18:37 2012 +0800
>

Here is a quick fix of the problem for me.
Of course a .bbappend could also be used with the similar correction.

Hans

>From b5cedfdf2c790007daa8befe523650e66c46fe98 Mon Sep 17 00:00:00 2001
From: hans.beckerus at gmail.com
Date: Wed, 10 Apr 2013 13:05:08 +0200
Subject: [PATCH] Fix id generation in inittab

---
 meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
index b289853..d7b5af9 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
+++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
@@ -21,14 +21,12 @@ do_install() {
         echo "S:2345:respawn:${base_sbindir}/getty ${SERIAL_CONSOLE}"
>> ${D}${sysconfdir}/inittab
     fi

-    idx=0
     tmp="${SERIAL_CONSOLES}"
     for i in $tmp
     do
        j=`echo ${i} | sed s/\;/\ /g`
-       echo "${idx}:12345:respawn:${base_sbindir}/getty ${j}" >>
${D}${sysconfdir}/inittab
-
-       idx=`expr $idx + 1`
+       id=`echo ${j} | sed -r 's/.*tty(\S+)/\1/'`
+       echo "${id}:12345:respawn:${base_sbindir}/getty ${j}" >>
${D}${sysconfdir}/inittab
     done

     if [ "${USE_VT}" = "1" ]; then
--
1.8.1.4

On Tue, Apr 9, 2013 at 7:20 PM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
> I am having an issue with the /etc/inittab file that seems to be
> incorrectly generated causing the following error at boot:
>    INIT: version 2.88 booting
>    INIT: /etc/inittab[42]: duplicate ID field "1"usb 1-1.1: new
> high-speed USB device number 3 using xusbps-ehci
>
> The reason for this error is due to the 'id' being incorrectly
> assigned to the getty ports in initttab, here is a sample from my
> version of it:
>
> <snip>
> # Normally not reached, but fallthrough in case of emergency.
> z6:6:respawn:/sbin/sulogin
> 0:12345:respawn:/sbin/getty 115200 ttyUSB0
> 1:12345:respawn:/sbin/getty 115200 ttyPS0
> # /sbin/getty invocations for the runlevels.
> #
> # The "id" field MUST be the same as the last
> # characters of the device (after "tty").
> #
> # Format:
> #  <id>:<runlevels>:<action>:<process>
> #
>
> 1:2345:respawn:/sbin/getty 38400 tty1
> <snip>
>
> The getty started for ttyPS0 and tty1 is assigned with the same id.
> I think that for the entries to be unique, the ids should have been
> assigned as 'USB0', 'PS0' and '1' respectively. At least that is what
> is hinted by the comment in inittab itself ;) If I look inside
> sysvinit-inittab_2.88dsf.bb I can see that the tty1 entry was added
> because of having USE_VT=1. The others are coming from SERIAL_CONSOLES
> in my machine .conf.
> Is there some known limitation that USE_VT may not be used in
> combination with SERIAL_CONSOLES? If I use SERIAL_CONSOLE instead it
> works since the id is hardcoded to 'S'. It could be argued if this is
> right or wrong, but at least it avoids the clash in id allocation from
> USE_VT. But I need multiple gettys started so using SERIAL_CONSOLE is
> not an option in this case.
>
> Would this be a bug worth fixing or is my only option here to instead
> set USE_VT=0?
> I guess one possible solution would be to assume 'tty' as prefix and
> then use the rest as suffix in the id field instead of now simply
> using the loop iterator?
> Actually I am not even sure I need a getty to be started on tty1!? Is
> it common praxis to have such an entry? I will only attach to the
> board through the physical serial connections or ssh. The last commit
> I see of this file is
>
> commit 074d49d2cc8bbc1a53a031d9ae0c828596017ed2
> Author: Zhenhua Luo <b19537 at freescale.com>
> Date:   Wed Sep 26 15:18:37 2012 +0800
>
> Regards,
> Hans