[yocto] /etc/inittab generated incorrectly?

[Hans Beckérus]

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