Hello,
I hope someone here can help me out..
I have a new Intel DQ77MK motherboard, based on the Intel Q77 chipset. CPU is Intel Ivy Bridge i7-3770. I'm running the latest BIOS version (0048), and UEFI boot is enabled in the BIOS.
I've tried UEFI booting the following operating systems from burned DVDR discs:
- Fedora 16 x64 DVD. - Fedora 17 x64 DVD. - Redhat Enterprise Linux (RHEL) 6.3 Server DVD. (Redhat Linux is supposed to be UEFI supported per the motherboard manuals).
UEFI boot fails with all of the listed operating systems. Symptoms:
- I get the Fedora/RHEL EFI boot menu, and I let it boot with the default options. - I get text on the screen about allocating memory pages for Linux-EFI, loading VMLINUZ, etc. - The screen goes empty/black, there's only a cursor blinking, and nothing happens.. - The boot failed or is stuck with nothing happening. I need to reset the box.
It looks like Linux kernel doesn't get started at all.. so it could be a UEFI firmware or a bootloader problem.
I'm actually expecting this is an Intel BIOS/UEFI firmware bug, because I've seen reports about UEFI boot problems on other Intel 7-series chipset aswell.
Does anyone know how to debug/troubleshoot UEFI boot problems?
The motherboard in question has Intel vPro/AMT, so it has SOL, so I could use a serial console, if there's a way to use it with UEFI/bootloader before Linux is started..
Any help is welcome!
Thanks,
-- Pasi
On 07/26/2012 06:32 AM, Pasi Kärkkäinen wrote:
UEFI boot fails with all of the listed operating systems. Symptoms:
- I get the Fedora/RHEL EFI boot menu, and I let it boot with the default
options.
- I get text on the screen about allocating memory pages for Linux-EFI,
loading VMLINUZ, etc.
- The screen goes empty/black, there's only a cursor blinking, and nothing
happens..
- The boot failed or is stuck with nothing happening. I need to reset the
box.
It looks like Linux kernel doesn't get started at all.. so it could be a UEFI firmware or a bootloader problem.
I'm actually expecting this is an Intel BIOS/UEFI firmware bug, because I've seen reports about UEFI boot problems on other Intel 7-series chipset as well.
Does anyone know how to debug/troubleshoot UEFI boot problems?
The fact that the cursor is blinking is a bit strange; if grub has attempted to boot the kernel, that's unexpected. Nevertheless, one thing to try is to add "noefi" to the kernel command line. If it gets farther, that's an indication that we're hitting a kernel bug.
On Thu, Jul 26, 2012 at 01:17:58PM -0400, Peter Jones wrote:
On 07/26/2012 06:32 AM, Pasi Kärkkäinen wrote:
UEFI boot fails with all of the listed operating systems. Symptoms:
- I get the Fedora/RHEL EFI boot menu, and I let it boot with the default
options.
- I get text on the screen about allocating memory pages for Linux-EFI,
loading VMLINUZ, etc.
- The screen goes empty/black, there's only a cursor blinking, and nothing
happens..
- The boot failed or is stuck with nothing happening. I need to reset the
box.
It looks like Linux kernel doesn't get started at all.. so it could be a UEFI firmware or a bootloader problem.
I'm actually expecting this is an Intel BIOS/UEFI firmware bug, because I've seen reports about UEFI boot problems on other Intel 7-series chipset as well.
Does anyone know how to debug/troubleshoot UEFI boot problems?
The fact that the cursor is blinking is a bit strange; if grub has attempted to boot the kernel, that's unexpected. Nevertheless, one thing to try is to add "noefi" to the kernel command line. If it gets farther, that's an indication that we're hitting a kernel bug.
"noefi" kernel cmdline option didn't help unfortunately.
When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, I let it boot the default entry "Fedora 17", I see it the allocating memory pages, loading VMLINUZ etc, and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking..
Does that ring any bells?
I forgot to mention earlier that fedora/rhel works OK using legacy BIOS boot, so only UEFI is problematic on this box.
I'm pretty sure this is a Intel firmware bug, but it'd be nice to be able to confirm that somehow..
Thanks for the reply!
-- Pasi
I encountered a similar problem when using a new Intel Xeon (Ivy Bridge) CPU.
The issue occurred with Ivy Bridge w/iGPU onboard.
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=840180
.
There are missing Ivy Bridge definitions in the intel_chipset.h file in libdrm which causes machines with Ivy Bridge CPU's w/embedded iGPU to fail when starting X.
As I said in the bug, installing libdrm 2.4.37 from bodhi fixed the issue on my F17 machine.
On 07/26/2012 02:05 PM, Gerry Reno wrote:
I encountered a similar problem when using a new Intel Xeon (Ivy Bridge) CPU.
The issue occurred with Ivy Bridge w/iGPU onboard.
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=840180
.
On Thu, Jul 26, 2012 at 02:44:24PM -0400, Gerry Reno wrote:
There are missing Ivy Bridge definitions in the intel_chipset.h file in libdrm which causes machines with Ivy Bridge CPU's w/embedded iGPU to fail when starting X.
As I said in the bug, installing libdrm 2.4.37 from bodhi fixed the issue on my F17 machine.
bz#840180 is a probably a different issue.
My problem is that I can't even boot the f16/f17/rhel63 installer dvds because the UEFI boot doesn't work (it gets stuck with a blank screen), so I'm not able to install OS in UEFI mode..
Installing the same distros using legacy BIOS boot works OK.
-- Pasi
On 07/26/2012 02:05 PM, Gerry Reno wrote:
I encountered a similar problem when using a new Intel Xeon (Ivy Bridge) CPU.
The issue occurred with Ivy Bridge w/iGPU onboard.
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=840180
.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 07/26/2012 04:31 PM, Pasi Kärkkäinen wrote:
On Thu, Jul 26, 2012 at 02:44:24PM -0400, Gerry Reno wrote:
There are missing Ivy Bridge definitions in the intel_chipset.h file in libdrm which causes machines with Ivy Bridge CPU's w/embedded iGPU to fail when starting X.
As I said in the bug, installing libdrm 2.4.37 from bodhi fixed the issue on my F17 machine.
bz#840180 is a probably a different issue.
My problem is that I can't even boot the f16/f17/rhel63 installer dvds because the UEFI boot doesn't work (it gets stuck with a blank screen), so I'm not able to install OS in UEFI mode..
Installing the same distros using legacy BIOS boot works OK.
-- Pasi
On 07/26/2012 02:05 PM, Gerry Reno wrote:
I encountered a similar problem when using a new Intel Xeon (Ivy Bridge) CPU.
The issue occurred with Ivy Bridge w/iGPU onboard.
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=840180
.
Maybe UEFI is looking for a boot file and not finding it on DVD.
On Thu, Jul 26, 2012 at 04:44:03PM -0400, Gerry Reno wrote:
On 07/26/2012 04:31 PM, Pasi Kärkkäinen wrote:
On Thu, Jul 26, 2012 at 02:44:24PM -0400, Gerry Reno wrote:
There are missing Ivy Bridge definitions in the intel_chipset.h file in libdrm which causes machines with Ivy Bridge CPU's w/embedded iGPU to fail when starting X.
As I said in the bug, installing libdrm 2.4.37 from bodhi fixed the issue on my F17 machine.
bz#840180 is a probably a different issue.
My problem is that I can't even boot the f16/f17/rhel63 installer dvds because the UEFI boot doesn't work (it gets stuck with a blank screen), so I'm not able to install OS in UEFI mode..
Installing the same distros using legacy BIOS boot works OK.
-- Pasi
On 07/26/2012 02:05 PM, Gerry Reno wrote:
I encountered a similar problem when using a new Intel Xeon (Ivy Bridge) CPU.
The issue occurred with Ivy Bridge w/iGPU onboard.
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=840180
.
Maybe UEFI is looking for a boot file and not finding it on DVD.
I don't get any errors about files not found..
When I boot Fedora 16, Fedora 17 or RHEL 6.3 (all x64) installer dvd, I get the following:
- I boot the burned DVDR in UEFI mode. - I get the GRUB menu, I choose the default entry to install the Fedora/RHEL distro. - I get messages about loading VMLINUZ, allocating memory pages for Linux-EFI, etc. - The display gets cleared (or the resolution changes) and screen goes black/blank, there's only a cursor blinking. - Nothing happens after this, the boot is stuck, and I have to reset the system.
So I can't install any Fedora/RHEL Linux in UEFI mode. Installing in legacy BIOS mode works OK.
I've tried enabling serial console etc to get *some* output to figure out what's happening with the UEFI boot but I haven't been successful yet in getting any output from the kernel.. so I'm not sure if the Linux kernel gets booted/started or not.
-- Pasi
On 07/26/2012 01:59 PM, Pasi Kärkkäinen wrote:
"noefi" kernel cmdline option didn't help unfortunately.
When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, I let it boot the default entry "Fedora 17", I see it the allocating memory pages, loading VMLINUZ etc, and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking..
Does that ring any bells?
Not really, no. The fact that you're seeing a mode switch proceeding a blinking cursor makes me think the kernel is probably starting, but you may be seeing a series of failures after that point.
I'm pretty sure this is a Intel firmware bug, but it'd be nice to be able to confirm that somehow..
Well, either the bootloader or the kernel (or something after that) is not succeeding If Windows works in UEFI mode on the machine, then we would still consider it to be a bug we should fix, even if the firmware fails to comply to precisely to our previous interpretation of the spec.
That being said, I doubt if we're going to have a high degree of success debugging this over email.
On Thu, Jul 26, 2012 at 03:52:25PM -0400, Peter Jones wrote:
On 07/26/2012 01:59 PM, Pasi Kärkkäinen wrote:
"noefi" kernel cmdline option didn't help unfortunately.
When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, I let it boot the default entry "Fedora 17", I see it the allocating memory pages, loading VMLINUZ etc, and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking..
Does that ring any bells?
Not really, no. The fact that you're seeing a mode switch proceeding a blinking cursor makes me think the kernel is probably starting, but you may be seeing a series of failures after that point.
Ok. earlier I tried enabling the Linux serial console with "console=ttyS1,115200", but that didn't show any kernel messages on the SOL.
I wonder if commands like "serial --port=0xf0e0" works with the EFI grub and if that'd show anything important.. (I can't try right now).
I'm pretty sure this is a Intel firmware bug, but it'd be nice to be able to confirm that somehow..
Well, either the bootloader or the kernel (or something after that) is not succeeding If Windows works in UEFI mode on the machine, then we would still consider it to be a bug we should fix, even if the firmware fails to comply to precisely to our previous interpretation of the spec.
I'll try installing Windows aswell.
That being said, I doubt if we're going to have a high degree of success debugging this over email.
Yeah.. I'm not very familiar with the EFI stuff yet, so I don't known if/how serial console stuff is supposed to work, or if it's any different from legacy BIOS boot.. and why I didn't see anything on the SOL.
Thanks for the help anyway!
-- Pasi
On Thu, Jul 26, 2012 at 11:02:07PM +0300, Pasi Kärkkäinen wrote:
I'm pretty sure this is a Intel firmware bug, but it'd be nice to be able to confirm that somehow..
Well, either the bootloader or the kernel (or something after that) is not succeeding If Windows works in UEFI mode on the machine, then we would still consider it to be a bug we should fix, even if the firmware fails to comply to precisely to our previous interpretation of the spec.
I'll try installing Windows aswell.
I just tried Win7 SP1 x64, and it seems to install and work OK in UEFI mode. After installation I verified it had created GPT system partition, and also I used "bcdedit" to verify windows has booted using bootmgfw.efi and winload.efi.
So yes, win7 works in UEFI mode, but f16/f17/rhel63 x64 fail in UEFI mode.
Should I open a fedora bugzilla ticket?
-- Pasi
On Mon, 2012-07-30 at 21:23 +0300, Pasi Kärkkäinen wrote:
On Thu, Jul 26, 2012 at 11:02:07PM +0300, Pasi Kärkkäinen wrote:
I'm pretty sure this is a Intel firmware bug, but it'd be nice to be able to confirm that somehow..
Well, either the bootloader or the kernel (or something after that) is not succeeding If Windows works in UEFI mode on the machine, then we would still consider it to be a bug we should fix, even if the firmware fails to comply to precisely to our previous interpretation of the spec.
I'll try installing Windows aswell.
I just tried Win7 SP1 x64, and it seems to install and work OK in UEFI mode. After installation I verified it had created GPT system partition, and also I used "bcdedit" to verify windows has booted using bootmgfw.efi and winload.efi.
So yes, win7 works in UEFI mode, but f16/f17/rhel63 x64 fail in UEFI mode.
Should I open a fedora bugzilla ticket?
Probably - but first, could you try booting the iso at http://pjones.fedorapeople.org/sb/boot-sb4.iso ? It's using a boot process that's a bit different (and more like what F18 will have), so and the code is different enough that there's some chance any given bug is incidentally fixed.
On Tue, Jul 31, 2012 at 11:11:07AM -0400, Peter Jones wrote:
On Mon, 2012-07-30 at 21:23 +0300, Pasi Kärkkäinen wrote:
On Thu, Jul 26, 2012 at 11:02:07PM +0300, Pasi Kärkkäinen wrote:
I'm pretty sure this is a Intel firmware bug, but it'd be nice to be able to confirm that somehow..
Well, either the bootloader or the kernel (or something after that) is not succeeding If Windows works in UEFI mode on the machine, then we would still consider it to be a bug we should fix, even if the firmware fails to comply to precisely to our previous interpretation of the spec.
I'll try installing Windows aswell.
I just tried Win7 SP1 x64, and it seems to install and work OK in UEFI mode. After installation I verified it had created GPT system partition, and also I used "bcdedit" to verify windows has booted using bootmgfw.efi and winload.efi.
So yes, win7 works in UEFI mode, but f16/f17/rhel63 x64 fail in UEFI mode.
Should I open a fedora bugzilla ticket?
Probably - but first, could you try booting the iso at http://pjones.fedorapeople.org/sb/boot-sb4.iso ? It's using a boot process that's a bit different (and more like what F18 will have), so and the code is different enough that there's some chance any given bug is incidentally fixed.
with that boot-sb4.iso I get first the grub 2.00 menu, and after choosing Fedora 17 entry:
---------------------------------------------- Booting `Fedora 17`
Secure boot not enabled error: failure reading sector 0x40 from `cd0Ž.
Press any key to continue... ----------------------------------------------
And it's stuck there.. pressing "any key" doesn't help, and ctrl+alt+del doesn't work either. I have to press Reset button.
I tried burning the iso image twice to different cdr's.. didn't help. Any ideas?
-- Pasi
On Tue, Jul 31, 2012 at 09:41:48PM +0300, Pasi Kärkkäinen wrote:
Secure boot not enabled error: failure reading sector 0x40 from `cd0Ž.
Try changing the firmware from AHCI to IDE mode. We're pretty sure this is a bug in Intel's AHCI driver, but we'll try to figure out a workaround in grub.
On Tue, Jul 31, 2012 at 08:16:29PM +0100, Matthew Garrett wrote:
On Tue, Jul 31, 2012 at 09:41:48PM +0300, Pasi Kärkkäinen wrote:
Secure boot not enabled error: failure reading sector 0x40 from `cd0Ž.
Try changing the firmware from AHCI to IDE mode. We're pretty sure this is a bug in Intel's AHCI driver, but we'll try to figure out a workaround in grub.
Ok, I changed from AHCI to IDE mode, and now I get:
----------------------------- Booting `Fedora 17Ž
Secure boot not enabled -----------------------------
.. and it's stuck there. I need to press Reset button to continue. It did read the CD for a while until it got frozen.
-- Pasi
On Tue, Jul 31, 2012 at 10:27:54PM +0300, Pasi Kärkkäinen wrote:
.. and it's stuck there. I need to press Reset button to continue. It did read the CD for a while until it got frozen.
Yeah, that's definitely a bug then. We'll see if we can reproduce it.
On Tue, Jul 31, 2012 at 08:33:04PM +0100, Matthew Garrett wrote:
On Tue, Jul 31, 2012 at 10:27:54PM +0300, Pasi Kärkkäinen wrote:
.. and it's stuck there. I need to press Reset button to continue. It did read the CD for a while until it got frozen.
Yeah, that's definitely a bug then. We'll see if we can reproduce it.
Any luck reproducing? Anything else I should try?
-- Pasi
On Thu, Aug 09, 2012 at 09:05:26PM +0300, Pasi Kärkkäinen wrote:
On Tue, Jul 31, 2012 at 08:33:04PM +0100, Matthew Garrett wrote:
On Tue, Jul 31, 2012 at 10:27:54PM +0300, Pasi Kärkkäinen wrote:
.. and it's stuck there. I need to press Reset button to continue. It did read the CD for a while until it got frozen.
Yeah, that's definitely a bug then. We'll see if we can reproduce it.
Any luck reproducing? Anything else I should try?
Ok, this issue is now resolved. It was an Intel BIOS/firmware bug.
DQ77MK BIOS v0050 has this in the changelog/releasenotes: "Fixed issue with UEFI Linux* installation."
And indeed, with BIOS 0050 I can now successfully UEFI boot both Fedora 17 and RHEL 6.3.
Thanks a lot to everyone involved!
-- Pasi
On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote:
When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, I let it boot the default entry "Fedora 17", I see it the allocating memory pages, loading VMLINUZ etc, and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking..
If you see a resoution change then try booting with nomodeset.
On 07/26/2012 05:12 PM, Matthew Garrett wrote:
On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote:
When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, I let it boot the default entry "Fedora 17", I see it the allocating memory pages, loading VMLINUZ etc, and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking..
If you see a resoution change then try booting with nomodeset.
You might also see if you can get one of the alternate terminals. If that works then the kernel is booted and its just X which is not starting.
On Thu, Jul 26, 2012 at 05:35:20PM -0400, Gerry Reno wrote:
On 07/26/2012 05:12 PM, Matthew Garrett wrote:
On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote:
When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, I let it boot the default entry "Fedora 17", I see it the allocating memory pages, loading VMLINUZ etc, and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking..
If you see a resoution change then try booting with nomodeset.
You might also see if you can get one of the alternate terminals. If that works then the kernel is booted and its just X which is not starting.
I can't change terminals. I assume the kernel doesn't boot at all, or crashes very early. I can't see any kind of activity from Linux kernel after GRUB-efi messages and the screen switches to blank..
-- Pasi
On 07/30/2012 10:58 AM, Pasi Kärkkäinen wrote:
On Thu, Jul 26, 2012 at 05:35:20PM -0400, Gerry Reno wrote:
On 07/26/2012 05:12 PM, Matthew Garrett wrote:
On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote:
When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, I let it boot the default entry "Fedora 17", I see it the allocating memory pages, loading VMLINUZ etc, and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking..
If you see a resoution change then try booting with nomodeset.
You might also see if you can get one of the alternate terminals. If that works then the kernel is booted and its just X which is not starting.
I can't change terminals. I assume the kernel doesn't boot at all, or crashes very early. I can't see any kind of activity from Linux kernel after GRUB-efi messages and the screen switches to blank..
-- Pasi
Have you tried booting with more logging? Without "quiet" param?
.
On Mon, Jul 30, 2012 at 11:21:54AM -0400, Gerry Reno wrote:
On 07/30/2012 10:58 AM, Pasi Kärkkäinen wrote:
On Thu, Jul 26, 2012 at 05:35:20PM -0400, Gerry Reno wrote:
On 07/26/2012 05:12 PM, Matthew Garrett wrote:
On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote:
When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, I let it boot the default entry "Fedora 17", I see it the allocating memory pages, loading VMLINUZ etc, and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking..
If you see a resoution change then try booting with nomodeset.
You might also see if you can get one of the alternate terminals. If that works then the kernel is booted and its just X which is not starting.
I can't change terminals. I assume the kernel doesn't boot at all, or crashes very early. I can't see any kind of activity from Linux kernel after GRUB-efi messages and the screen switches to blank..
-- Pasi
Have you tried booting with more logging? Without "quiet" param?
There's no "quiet" param. The default UEFI boot options are "verbose" as a default.
I can't see *any* output from Linux kernel. Also I tried settings up SOL serial console, but I can't see any Linux messages there either. SOL stays empty/silent.
Is serial console supposed to work OK in the usual way, with UEFI boot?
And again: Booting in legacy BIOS mode works OK, and the serial console works there aswell. I have problems only in UEFI mode, where I can't get *any* output from Linux.
-- Pasi
On 07/30/2012 11:28 AM, Pasi Kärkkäinen wrote:
On Mon, Jul 30, 2012 at 11:21:54AM -0400, Gerry Reno wrote:
On 07/30/2012 10:58 AM, Pasi Kärkkäinen wrote:
On Thu, Jul 26, 2012 at 05:35:20PM -0400, Gerry Reno wrote:
On 07/26/2012 05:12 PM, Matthew Garrett wrote:
On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote:
When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, I let it boot the default entry "Fedora 17", I see it the allocating memory pages, loading VMLINUZ etc, and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking..
If you see a resoution change then try booting with nomodeset.
You might also see if you can get one of the alternate terminals. If that works then the kernel is booted and its just X which is not starting.
I can't change terminals. I assume the kernel doesn't boot at all, or crashes very early. I can't see any kind of activity from Linux kernel after GRUB-efi messages and the screen switches to blank..
-- Pasi
Have you tried booting with more logging? Without "quiet" param?
There's no "quiet" param. The default UEFI boot options are "verbose" as a default.
I can't see *any* output from Linux kernel. Also I tried settings up SOL serial console, but I can't see any Linux messages there either. SOL stays empty/silent.
Is serial console supposed to work OK in the usual way, with UEFI boot?
And again: Booting in legacy BIOS mode works OK, and the serial console works there aswell. I have problems only in UEFI mode, where I can't get *any* output from Linux.
-- Pasi
Are you booting x86 or x86_64 version?
I don't think x86 is supported for UEFI boot.
.
On Mon, Jul 30, 2012 at 11:34:12AM -0400, Gerry Reno wrote:
On 07/30/2012 11:28 AM, Pasi Kärkkäinen wrote:
On Mon, Jul 30, 2012 at 11:21:54AM -0400, Gerry Reno wrote:
On 07/30/2012 10:58 AM, Pasi Kärkkäinen wrote:
On Thu, Jul 26, 2012 at 05:35:20PM -0400, Gerry Reno wrote:
On 07/26/2012 05:12 PM, Matthew Garrett wrote:
On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote:
> When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, > I let it boot the default entry "Fedora 17", I see it the allocating memory pages, loading VMLINUZ etc, > and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking.. If you see a resoution change then try booting with nomodeset.
You might also see if you can get one of the alternate terminals. If that works then the kernel is booted and its just X which is not starting.
I can't change terminals. I assume the kernel doesn't boot at all, or crashes very early. I can't see any kind of activity from Linux kernel after GRUB-efi messages and the screen switches to blank..
-- Pasi
Have you tried booting with more logging? Without "quiet" param?
There's no "quiet" param. The default UEFI boot options are "verbose" as a default.
I can't see *any* output from Linux kernel. Also I tried settings up SOL serial console, but I can't see any Linux messages there either. SOL stays empty/silent.
Is serial console supposed to work OK in the usual way, with UEFI boot?
And again: Booting in legacy BIOS mode works OK, and the serial console works there aswell. I have problems only in UEFI mode, where I can't get *any* output from Linux.
-- Pasi
Are you booting x86 or x86_64 version?
I don't think x86 is supported for UEFI boot.
x86_64 (64bit), of course.
I get grub-EFI boot menu from the DVD, I choose Fedora, I get the grub-EFI texts about allocating memory pages for LINUX-EFI, loading VMLINUZ, etc.. and then the screen goes blank and everything stops there.
Multiple people have confirmed UEFI boot is broken on Intel 7-series motherboards, so I believe this is Intel BIOS/firmware bug.
-- Pasi
On Mon, Jul 30, 2012 at 09:59:11AM -0600, Chris Murphy wrote:
On Jul 30, 2012, at 9:36 AM, Pasi Kärkkäinen wrote:
Multiple people have confirmed UEFI boot is broken on Intel 7-series motherboards, so I believe this is Intel BIOS/firmware bug.
Does it UEFI boot a Windows 7 X86_64 install disk?
I just tried it, and yes, Win7 SP1 x64 seems to install and work in UEFI mode. After win7 x64 installation I verified there is a GPT system partition on the hdd, and also I used "bcdedit" to verify Windows has booted using bootmgfw.efi and winload.efi.
Does Intel think it's broken?
I opened a thread about it on Intel forums/communities, where a person from Intel asked if "supported operating system" worked OK..
It seems RHEL is "supported", and RHEL 6.3 server x64 shows the same problem as Fedora, so that's good in a way. I guess I need to figure out how to open a proper bugreport to Intel.
http://communities.intel.com/message/162124
so in short: Win7 x64 UEFI works, but fedora16/fedora17/rhel63 x64 fail in UEFI mode.
-- Pasi
On Thu, Jul 26, 2012 at 10:12:19PM +0100, Matthew Garrett wrote:
On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote:
When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, I let it boot the default entry "Fedora 17", I see it the allocating memory pages, loading VMLINUZ etc, and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking..
If you see a resoution change then try booting with nomodeset.
"nomodeset" doesn't help or change anything unfortunately..
-- Pasi
On 07/26/2012 06:32 AM, Pasi Kärkkäinen wrote:
I have a new Intel DQ77MK motherboard, based on the Intel Q77 chipset. CPU is Intel Ivy Bridge i7-3770. I'm running the latest BIOS version (0048), and UEFI boot is enabled in the BIOS.
I take it that this one doesn't have the secure boot yet? The secure UEFI boot is almost certainly not the cause here---AFAIK there aren't any publicly available secure UEFI implementations yet, and your board seemed to execute the bootloader just fine and got bogged down during the kernel startup.
If secure boot was the issue, it would fail to boot because the bootloader is not yet signed. BTW, is the behavior in such case prescribed by the secure UEFI spec? Can the system lock up black or does it have to print a message and return to UEFI prompt?
On 07/26/2012 02:36 PM, Przemek Klosowski wrote:
On 07/26/2012 06:32 AM, Pasi Kärkkäinen wrote:
I have a new Intel DQ77MK motherboard, based on the Intel Q77 chipset. CPU is Intel Ivy Bridge i7-3770. I'm running the latest BIOS version (0048), and UEFI boot is enabled in the BIOS.
I take it that this one doesn't have the secure boot yet? The secure UEFI boot is almost certainly not the cause here---AFAIK there aren't any publicly available secure UEFI implementations yet, and your board seemed to execute the bootloader just fine and got bogged down during the kernel startup.
If secure boot was the issue, it would fail to boot because the bootloader is not yet signed. BTW, is the behavior in such case prescribed by the secure UEFI spec? Can the system lock up black or does it have to print a message and return to UEFI prompt?
There's no mandated UI, no. In this case grub would fail to run, so we can be sure that's not what's going on.
On Thu, Jul 26, 2012 at 02:36:39PM -0400, Przemek Klosowski wrote:
On 07/26/2012 06:32 AM, Pasi Kärkkäinen wrote:
I have a new Intel DQ77MK motherboard, based on the Intel Q77 chipset. CPU is Intel Ivy Bridge i7-3770. I'm running the latest BIOS version (0048), and UEFI boot is enabled in the BIOS.
I take it that this one doesn't have the secure boot yet? The secure UEFI boot is almost certainly not the cause here---AFAIK there aren't any publicly available secure UEFI implementations yet, and your board seemed to execute the bootloader just fine and got bogged down during the kernel startup.
Yep, no secure boot involved here. Just "normal" UEFI.
-- Pasi
-
Chris Murphy -
Gerry Reno -
Matthew Garrett -
Pasi Kärkkäinen -
Peter Jones -
Przemek Klosowski