| Summary: | genericx86 auth.err getty[615]: tcgetattr: Input/output | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BSPs | Reporter: | Stoicescu Cornel <corneliux.stoicescu> |
| Component: | bsps-runtime | Assignee: | Jianxun Zhang <jianxun.zhang> |
| Status: | RESOLVED FIXED | QA Contact: | Juan Ramos <juan.fernandox.ramos.frayle> |
| Severity: | normal | ||
| Priority: | Medium | CC: | 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 |
| Version: | 1.5 | ||
| Target Milestone: | 2.2 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
| Bug Depends on: | 6362 | ||
| Bug Blocks: | |||
|
Description
Stoicescu Cornel
2013-10-14 13:40:58 UTC
I believe a fix has been accepted for this. Is this still being seen? Still reproduces on dora 1.5.3.rc1 dc743744d8e3a9caef577aeab6b7f51bc08ded17 Is this fixed in a newer version and needs a back port? 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. Saul, can you dig into this and see if you can reproduce? 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 *** Bug 8993 has been marked as a duplicate of this bug. *** Assume RMC related per discussion in BSP meeting. Update to 2.1M4 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) 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. 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 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. 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.
|