On Tue, Apr 9, 2013 at 7:20 PM, Hans Beckérus <hans.becke...@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 <b19...@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.becke...@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.becke...@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 <b19...@freescale.com> > Date: Wed Sep 26 15:18:37 2012 +0800 > > Regards, > Hans _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto