5351 2013-10-14 13:40:58 +0000 genericx86 auth.err getty[615]: tcgetattr: Input/output 2016-11-16 20:03:33 +0000 1 1 7 Build System, Metadata & Runtime BSPs bsps-runtime 1.5 x86 Multiple RESOLVED FIXED Medium normal 2.2 6362 1 corneliux.stoicescu jianxun.zhang alejandro.hernandez benjamin.esquivel cristina-danielax.agurida dvhart georgex.l.musat jessica.zhang jose.perez.carranza leonardo.sandoval.gonzalez sgw yp.kernel.watcher yp.watcher juan.fernandox.ramos.frayle --- --- No (bug/feature does not impact docs) oldest_to_newest 37892 0 corneliux.stoicescu 2013-10-14 13:40:58 +0000 STATUS: FAILED BUILD: dora-10.0.0.final:cb2836fee444bf5f7bd74d0612a4cd8f1b5d2e89.tar.bz2 ENVIRONMENT: generic-x86 on AtomPC and genericx86-64 on Sugarbay STEPS TO REPRODUCE: 1. Boot image 2. Check file /var/log/messages for errors Outcome: Notice errors: Oct 14 12:19:45 genericx86 auth.err getty[615]: tcgetattr: Input/output error^M Oct 14 12:19:55 genericx86 auth.err getty[679]: tcgetattr: Input/output error^M Oct 14 12:20:05 genericx86 auth.err getty[680]: tcgetattr: Input/output error^M Oct 14 12:20:15 genericx86 auth.err getty[686]: tcgetattr: Input/output error^M NOTE: The errors continue to show up as long as the BSP is running. 43831 1 dvhart 2014-06-09 22:41:15 +0000 I believe a fix has been accepted for this. Is this still being seen? 44508 2 georgex.l.musat 2014-07-16 11:18:49 +0000 Still reproduces on dora 1.5.3.rc1 dc743744d8e3a9caef577aeab6b7f51bc08ded17 44668 3 sgw 2014-07-24 15:12:39 +0000 Is this fixed in a newer version and needs a back port? 44858 4 dvhart 2014-07-31 14:01:54 +0000 I'm drawing a complete blank as to what I was referring to in Comment 1. My hunch would be that the these BSPs use a serial TTY by default and that the hardware doesn't provide the one they specify, causing the serial getty in inittab to fail. 50758 5 dvhart 2015-05-04 16:27:55 +0000 Saul, can you dig into this and see if you can reproduce? 50806 6 sgw 2015-05-05 23:17:37 +0000 This is related to the fact that not all hardware have an actual tty wired up, for example the MinnowMax has a serial console therefore does not have this error. However the Sugarbay laptop does not have one. If we can detect the fact that's there and then update the inittab at boot up time this could be resolved. This is dependant on the Runtime Machine Config enhancement 58207 7 sgw 2016-01-25 18:12:06 +0000 *** Bug 8993 has been marked as a duplicate of this bug. *** 59842 8 jianxun.zhang 2016-03-09 22:17:14 +0000 Assume RMC related per discussion in BSP meeting. Update to 2.1M4 60849 9 jianxun.zhang 2016-04-06 16:52:21 +0000 Saul, I am not sure if the new targeted milestone 2.2 could be met because we assume it should be fixed by RMC but RMC development is suspended in these days. (Ref to bz8761) 62785 10 jianxun.zhang 2016-06-08 18:21:35 +0000 Saul, I can produce it with sugar bay for this old bug. RMC is based on EFI firmware and bootloader per design. The sugar bay on my hand doesn't seem to have an EFI bios. We could need an EFI bios for this board first. 64482 11 jose.perez.carranza 2016-07-26 13:01:37 +0000 Issue still reproducible on a NUC in 2.2 M2 commit: 36feb38045b7a2af86ece147fec54b0db3bf491f http://autobuilder.yoctoproject.org/pub/releases/yocto-2.2_M2.rc1/machines/genericx86-64/core-image-sato-sdk-genericx86-64.hddimg 64790 12 jianxun.zhang 2016-08-02 17:19:40 +0000 So far we have two platforms with this issue as QA tested. As old analysis pointed out, it happens because when boards don't have any serial port, and inittab generated contains tty lines. OE provides some variables to configure no to add serial tty lines in inittab, but you have to create a static conf delta to deal with these boards. With new RMC feature which is pending on merge, we can retouch the inittab during installation based on type of board at runtime, so you don't have to create a board configuration, but just put a hook script in RMC to apply the change for the specific board. I have patch staged on meta-intel-contrib for NUC and tested it. These patches depend on RMC feature which is still in review and submission. For 5yr+ old sugarbay platform, I still cannot find suitable UEFI FW to support RMC. I suggest we close this issue once patches I mentioned are completed merged for NUC. At least, we have a low-cost approach to do such customization for NUC series and other platforms. 64957 13 jianxun.zhang 2016-08-08 17:44:33 +0000 This is a summary to change its state to "Resolved" and "fixed" I believe this issue is common on platforms don't have any serial port console with default OE configuration. The line with "start_getty" in generated inittab causes the error log on such platforms. There are static or runtime methods to get rid of this line, depending on the platforms too. () Static approach is to put SERIAL_CONSOLES = "" in conf file so the inittab recipe won't put any start_getty lines (traditional OE way). But this is not fitted in a generic machine configuration for a permanent setup (e.g. intel-core-* machines in meta-intel), which also supports boards having serial consoles. () With new feature RMC recently merged in meta-intel, developers can deploy board-specific changes with a single build image according to board types at runtime. A special customization for NUC Gen 6 is included in builtin examples of RMC, to remove these start_getty lines in installation of a generic intel-corei7-64 image. No other OE configuration variables are required in this way. RMC is not enabled by default in meta-intel, so you need to enable it in conf file to verify NUC Gen 6: DISTRO_FEATURES_append = " rmc" EFI_PROVIDER = "rmc-systemd-boot" Then install (not live-boot) image for intel-corei7-64 machine on NUC Gen 6. You should not see these error messages any more. Refer to meta-intel/documentation/rmc/README for how to add new boards' data when necessary. () We haven't found a UEFI FW required by RMC to support old Sugarbay platform, so the static way should be the only solution. But since we have decided to stop support sugarbay due to its age in meta-intel, we recommend you to try RMC on any platforms with UEFI and SMBIOS in FW to resolve similar board-specific issues in a generic build.