STATUS: IDLE BUILD: 1.8.2: c9f0a99050ec0050f0dbcd55d0cd2ab18848113f ENVIRONMENT: genericx86-64-lsb-sdk - on NUC6I5SYH STEPS TO REPRODUCE: 1. plugin usb which contains live image burned 2. configure device BIOS to firstly boot from USB if necessary 3. boot the device and select option "Install" from boot menu 4. proceed through default install process 5. Remove USB, and reboot into new installed system. EXPECTED OUTCOME: 1. User can choose install system from usb stick onto harddisk from boot menu or command line option 2. Installed system can boot up ACTUAL OUTCOME: After install option is selected on GRUB, black screen is displayed and the installation does not continue.
Saul: do you or Tom have access to the right hardware for this ?
I rebuilt image from the same tip and I can reproduce the issue. With some troubleshooting I should say it is a graphic problem. The most possible reason could be there is no skylake i915 support in the 3.14 kernel in the build. On NUC Gen 6: () boot with "boot" option, with or without preliminary hw support in driver, issue can be reporduced. () Boot with "install" option, I got same result. But the same build is working on an older NUC Gen 4 which should have an previous gen of graphic. () Boot with "boot" option, boot is okay with working graphic, no any tweaks needed. () "Install" is not tested. Are we going to bring 4.x kernel on 1.8 fido?
(In reply to comment #2) > I rebuilt image from the same tip and I can reproduce the issue. With some > troubleshooting I should say it is a graphic problem. The most possible > reason could be there is no skylake i915 support in the 3.14 kernel in the > build. > > On NUC Gen 6: > () boot with "boot" option, with or without preliminary hw support in > driver, issue can be reporduced. > > () Boot with "install" option, I got same result. > > But the same build is working on an older NUC Gen 4 which should have an > previous gen of graphic. > > () Boot with "boot" option, boot is okay with working graphic, no any tweaks > needed. > > () "Install" is not tested. > > Are we going to bring 4.x kernel on 1.8 fido? I just verified again with NUC D54250WYK, the image can be installed. However a message is displayed before the image boots. Here you have the message that is displayed: "i8042: No controller found INIT: Version 2.88 booting uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) uvesafb: vbe_init() failed with -22"
Francisco, The log you mentioned is a mixed bag of different topics. I just try to clarify some here. () i8042: No controller found i8042 is for PS/2 keyboard and mice. I don't think NUC has it (correct me if it does). This is not related to issue in this bz () uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) uvesafb: vbe_init() failed with -22" I think it is https://bugzilla.yoctoproject.org/show_bug.cgi?id=6584 which is fixed with a workaround to make error msg disappear. But this old fido tip doesn't have it. This should not be related to this issue since you can get display. I still think it is a classic issue that an old kernel doesn't have support of a newer graphic hardware.
(In reply to comment #4) > Francisco, > > The log you mentioned is a mixed bag of different topics. I just try to > clarify some here. > > () i8042: No controller found > i8042 is for PS/2 keyboard and mice. I don't think NUC has it (correct me if > it does). This is not related to issue in this bz > > () uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) > uvesafb: vbe_init() failed with -22" > I think it is https://bugzilla.yoctoproject.org/show_bug.cgi?id=6584 which > is fixed with a workaround to make error msg disappear. But this old fido > tip doesn't have it. This should not be related to this issue since you can > get display. > > I still think it is a classic issue that an old kernel doesn't have support > of a newer graphic hardware. Hi Thanks for you response, I am agree with you, I just wanted to add more details about this.
Closed as invalid, the newer hardware NUC6I5SYH with fido release. This is not supported on fido.
I think there is some way to let system fall back to legacy fb driver, so that we should be able see display working in this case (though you won't have adequate resolution or other advanced support from drm). I reopen this and am working on an acceptable patch. We can close it later if I hit on another wall...
Issue can be fixed by falling back to legacy EFI FB driver when required drm driver for a newer hardware is not present in kernel. Patch to 3.14 meta for Fido (this bug on) 1.89 has been merged: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.14/commit/?h=meta&id=2d6bc0817c3d5cf4d7427c55399a9823414301d5 Same change to kernel-cache for 4.x kernel: https://lists.yoctoproject.org/pipermail/linux-yocto/2016-June/005261.html