Re: CURRENT: EFI boot failure

On 09/16/14 14:50, O. Hartmann wrote:
> Am Tue, 16 Sep 2014 00:09:01 -0700
> Nathan Whitehorn <nwhitehorn_at_freebsd.org> schrieb:
>
>> On 09/15/14 22:51, O. Hartmann wrote:
>>> Am Mon, 15 Sep 2014 17:39:26 -0700
>>> Nathan Whitehorn <nwhitehorn_at_freebsd.org> schrieb:
>>>
>>>> On 09/15/14 17:36, Allan Jude wrote:
>>>>> On 2014-09-15 20:05, O. Hartmann wrote:
>>>>>> Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works for UEFI
>>>>>> fine. After I updated the sources to  r271649, recompiled world and kernel (as well
>>>>>> as installed), now I get stuck with the screen message:
>>>>>>
>>>>>>>> FreeBSD EFI boot block
>>>>>>       Loader path: /boot/loader.efi
>>>>>>
>>>>>> and nothing happens. After a couple of minutes, the system reboots.
>>>>>>
>>>>>> What happened and how can this problem be solved?
>>>>>>
>>>>> You might need to update the boot1.efi file on the UEFI partition (small
>>>>> FAT partition on the disk)
>>>>>
>>>>> I am not sure how 'in sync' boot1.efi (on the fat partiton) and
>>>>> loader.efi have to be.
>>>>>
>>>>> https://wiki.freebsd.org/UEFI
>>>>>
>>>> boot1.efi is designed never to need updating. (It also hasn't changed
>>>> since April)
>>>> -Nathan
>>> But it has changed bytesize when I recompiled world with recent sources compared to
>>> the boot.efi size from the USB image I installed from (revision see above).
>> Probably compiler updates or something? I really wouldn't worry about it
>> too much. I'd worry more about loader, since we know boot1 could use the
>> console but loader doesn't show up.
>>
>>> How to update bootcode on UEFI layout? I created a GPT partition with type efi (1 GB)
>>> as well as a 512KB partition typed freebsd-boot.
>> How did you set it up in the first place? If you have a FreeBSD-only
>> system partition (like the installer sets up), you just dd
>> /boot/boot1.efifat to the EFI partition. Otherwise, it's FAT and you
>> copy /boot/boot1.efi to somewhere your boot manager can find it.
>>
>>> I'm new to EFI and the way the notebook now behaves is really strange. While the USB
>>> drive image used to boot with new console enabled, it now boots again with the old
>>> console and 800x640 resolution. This might indicate some minor but very effective
>>> mistake I made.
>>>
>> The EFI boot block finds the first UFS partition -- on any disk -- and
>> tries to boot from it. If you have multiple FreeBSD disks connected,
>> that will very likely result in madness.
>> -Nathan
>> _______________________________________________
>> freebsd-current_at_freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> After I managed to install the OS and updated to the most recent world, it took two days
> to have all the installations prepared. Now I'm about the configure X11 and run into
> another very annoying situation.
>
> The Laptop is a Lenovo ThinkPad Edge E540 equipted with the following CPU/iGPU and
> dedicated GPU:
>
> CPU Intel i5-4200M (Haswell) at 2.5 GHz with iGPU Intel HD Graphics 4600
>
> GPU: nVidia GT 740M mobile GPU.
>
> EFI Version 2.31
> EFI Firmware: Lenovo (rev. 05648)
>
> In the Firmware/EFI/BIOS the primary GPU is selected to be the nVidia GT 740M. Boot is
> EFI only, no CSM support. With CSM support enabled a VGA screen with 640x400 pixel shows
> up. Non UEFI options doesn't boot this system at all!
>
> Any attempt to bring up the nVidia GPU (starting X for testing) ends up in a blank
> screen, stuck mousepointer, no keyboard. I even can not switch to another console!
> When X server started the first time on tty9, I can switch to another console. But the
> moment I switch back to ttyv9 everything is frozen and as described above.

Try xf86-video-scfb instead?

> When the system boots, I do not see a loader! Where is the loader I'm used to see when I
> have the chance to switch to single user mode, console or switch off ACPI?

There is no beastie menu for UEFI, and will not be, since it UEFI's 
terminal emulation does not provide the required features. You can boot 
single user from the loader command line, however, with boot -s, for 
example. The interface is identical to what you get if you choose 
"Loader prompt" in the usual menu.

> Because I need X11 up (and it should be running on the nVidia GPU for performance
> reasons), I tried to get back to the legacy "sc" console in textmode since I read about
> several issues and immature vt() system, so I put those lines in the /boot/loader.conf:
>
> hw.vga.textmode=1
> hw.vty=sc
>
> (tried also hw.vty=vt).
>
> But with either of those lines in the loader thing get more annoying and nasty: The
> system doesn't show even a console, it is stuck with this sparse EFI boot message, last
> lines are
>
> dimensions xxxx x yyyy
> stride xxxx
> masks 0xfffffff [...]
>
> and the rest of the screen is blank. System remains unusable, the HDD is working and
> obviously booting the system but incapable of presenting a screen. When booting the USB
> drive image, this initial EFI message gets overwritten (no screen blanking, the kernel
> messages starts writing over this message like in the first days of computers ...). In
> the case described above that doesn't happen at all.

syscons does not support UEFI systems at all. Since it can't initialize 
the VGA hardware, you get a blank screen. hw.vga.textmode also won't 
have any effect since EFI systems don't use the vga driver for console, 
instead using an EFI-provided framebuffer structure through the vt_efifb 
driver.

> After I deleted.commented out the lines
>
> hw.vga.textmode=1
> hw.vty=sc
>
> in loader.conf the system is booting again - and clears the initial EFI messages before
> dumping the screen with kernel messages, as expected.
>
> Well, at the end, it seems I sit in front of two days useless labor, new hardware, UEFI
> and no X11.

One thing you might want to try that got my Haswell laptop up is to use 
the x11-drivers/xf86-video-scfb driver. This uses the vt framebuffer 
directly. It's more or less the equivalent of the VESA driver since it 
is unaccelerated, but it will work. We really need actual Haswell 
graphics drivers (I suspect they are required to get the multiple GPU 
handoff to work as well).
-Nathan