Re: CURRENT: EFI boot failure
Am Tue, 23 Sep 2014 17:14:46 +0200
Dimitry Andric d...@freebsd.org schrieb:
On 23 Sep 2014, at 17:00, Nathan Whitehorn nwhiteh...@freebsd.org wrote:
On 09/23/14 07:28, Harald Schmalzbauer wrote:
Bezüglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime):
…
The problem I reported about in the first place is triggered by a faulty
loader.efi
that arises, when optimisation level is -O3. -O2 works fine.
I can confirm that this problem also shows up when using
'CPUTYPE?=core-avx2'
Setting CPUTYPE to core-avx-i doesnt ehibit the problem.
I could narrow down the cause to libefi.a (sys/boot/efi).
But I don't understand the things going on there, so no clue how to fix
besides maybe
--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.0 +0200
@@ -2,6 +2,10 @@
BINDIR?= /boot
+.ifdef CPUTYPE
+.undef CPUTYPE
+.endif
+
.if ${MACHINE_CPUARCH} == i386
CFLAGS+= -march=i386
.endif
Could you try adding -mno-avx2 to /sys/boot/amd64/Makefile.inc line 9?
-Nathan
IMHO CPUTYPE should be ignored for any boot loader program, and the
lowest common denominator should be used instead (i486 for 32-bit, plain
x86_64 for 64-bit). It makes no sense to optimize boot loaders for e.g.
core-avx2. :-)
But indeed, it appears that we need to add more -mno-foo magic flags...
-Dimitry
I repoted a bug at
Bug 194641 - [EFI] boot/loader.efi: miscompilation on Intel Haswell with AVX2
Please feel free to comment and replenish my superficial observation.
Hopefullz, this doesn't get lost. This nasty bug on Haswell CPU bothers me all
the days I
update world.
pgpXizPiSBZKe.pgp
Description: OpenPGP digital signature
Re: CURRENT: EFI boot failure
Bezüglich O. Hartmann's Nachricht vom 04.10.2014 08:47 (localtime):
…
Sorry, forget the suggestion, it doesn't work since it leads to CFLAG
-march= and the same problem occurs.
For my case this works:
--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc 2014-09-23 16:46:30.0 +0200
@@ -2,6 +2,10 @@
BINDIR?= /boot
+.if ${CPUTYPE} == core-avx2
+CPUTYPE= core-avx-i
+.endif
+
.if ${MACHINE_CPUARCH} == i386
CFLAGS+=-march=i386
.endif
JFI
-Harry
Has this problem anyhow seriously been addressed? I run into this very often
on several
platforms with HAswell-based CPUs (other systems with IvyBridge or
SandyBridge are still
to be migrated to UEFI boot, so I do not have any older architectures at hand
to proof
whether this issue is still present or not on Non-AVX2 systems.
If there is no progress so far, would it be well-advised to open a PR?
Unofrtunately I don't really have qualified knwoledge about compiler
optimazations nor any efi binary knwoledge.
Opening a PR is really needed, this issue shouldn't be left unchecked.
But I'd prefer if someone does it, who understands what Matt Fleming
answered in
http://lists.freebsd.org/pipermail/freebsd-current/2014-September/052354.html
Anyone?
Thanks,
-Harry
signature.asc
Description: OpenPGP digital signature
Re: CURRENT: EFI boot failure
Am Tue, 23 Sep 2014 16:51:08 +0200
Harald Schmalzbauer h.schmalzba...@omnilan.de schrieb:
Bezüglich Harald Schmalzbauer's Nachricht vom 23.09.2014 16:28
(localtime):
Bezüglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime):
…
The problem I reported about in the first place is triggered by a faulty
loader.efi
that arises, when optimisation level is -O3. -O2 works fine.
I can confirm that this problem also shows up when using
'CPUTYPE?=core-avx2'
Setting CPUTYPE to core-avx-i doesnt ehibit the problem.
I could narrow down the cause to libefi.a (sys/boot/efi).
But I don't understand the things going on there, so no clue how to fix
besides maybe
--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.0 +0200
@@ -2,6 +2,10 @@
BINDIR?= /boot
+.ifdef CPUTYPE
+.undef CPUTYPE
+.endif
Sorry, forget the suggestion, it doesn't work since it leads to CFLAG
-march= and the same problem occurs.
For my case this works:
--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc 2014-09-23 16:46:30.0 +0200
@@ -2,6 +2,10 @@
BINDIR?= /boot
+.if ${CPUTYPE} == core-avx2
+CPUTYPE= core-avx-i
+.endif
+
.if ${MACHINE_CPUARCH} == i386
CFLAGS+=-march=i386
.endif
JFI
-Harry
Has this problem anyhow seriously been addressed? I run into this very often on
several
platforms with HAswell-based CPUs (other systems with IvyBridge or SandyBridge
are still
to be migrated to UEFI boot, so I do not have any older architectures at hand
to proof
whether this issue is still present or not on Non-AVX2 systems.
If there is no progress so far, would it be well-advised to open a PR?
Regards,
Oliver
signature.asc
Description: PGP signature
Re: CURRENT: EFI boot failure
On Tue, 23 Sep, at 08:00:31AM, Nathan Whitehorn wrote: Could you try adding -mno-avx2 to /sys/boot/amd64/Makefile.inc line 9? Do you pull the -mno-redzone flag anywhere? I'm looking through the loader sources now, and I see that switch in sys/conf/kern.mk, but it doesn't look like that's being pulled in for the boot loader source. Calling into EFI will trash the x86-64 redzone, if you've got it enabled. -- Matt Fleming, Intel Open Source Technology Center ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: EFI boot failure
Bezüglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime):
…
The problem I reported about in the first place is triggered by a faulty
loader.efi that
arises, when optimisation level is -O3. -O2 works fine.
I can confirm that this problem also shows up when using
'CPUTYPE?=core-avx2'
Setting CPUTYPE to core-avx-i doesnt ehibit the problem.
I could narrow down the cause to libefi.a (sys/boot/efi).
But I don't understand the things going on there, so no clue how to fix
besides maybe
--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.0 +0200
@@ -2,6 +2,10 @@
BINDIR?= /boot
+.ifdef CPUTYPE
+.undef CPUTYPE
+.endif
+
.if ${MACHINE_CPUARCH} == i386
CFLAGS+= -march=i386
.endif
-Harry
signature.asc
Description: OpenPGP digital signature
Re: CURRENT: EFI boot failure
Bezüglich Harald Schmalzbauer's Nachricht vom 23.09.2014 16:28
(localtime):
Bezüglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime):
…
The problem I reported about in the first place is triggered by a faulty
loader.efi that
arises, when optimisation level is -O3. -O2 works fine.
I can confirm that this problem also shows up when using
'CPUTYPE?=core-avx2'
Setting CPUTYPE to core-avx-i doesnt ehibit the problem.
I could narrow down the cause to libefi.a (sys/boot/efi).
But I don't understand the things going on there, so no clue how to fix
besides maybe
--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.0 +0200
@@ -2,6 +2,10 @@
BINDIR?= /boot
+.ifdef CPUTYPE
+.undef CPUTYPE
+.endif
Sorry, forget the suggestion, it doesn't work since it leads to CFLAG
-march= and the same problem occurs.
For my case this works:
--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc 2014-09-23 16:46:30.0 +0200
@@ -2,6 +2,10 @@
BINDIR?= /boot
+.if ${CPUTYPE} == core-avx2
+CPUTYPE= core-avx-i
+.endif
+
.if ${MACHINE_CPUARCH} == i386
CFLAGS+=-march=i386
.endif
JFI
-Harry
signature.asc
Description: OpenPGP digital signature
Re: CURRENT: EFI boot failure
Could you try adding -mno-avx2 to /sys/boot/amd64/Makefile.inc line 9?
-Nathan
On 09/23/14 07:28, Harald Schmalzbauer wrote:
Bezüglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime):
…
The problem I reported about in the first place is triggered by a faulty
loader.efi that
arises, when optimisation level is -O3. -O2 works fine.
I can confirm that this problem also shows up when using
'CPUTYPE?=core-avx2'
Setting CPUTYPE to core-avx-i doesnt ehibit the problem.
I could narrow down the cause to libefi.a (sys/boot/efi).
But I don't understand the things going on there, so no clue how to fix
besides maybe
--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.0 +0200
@@ -2,6 +2,10 @@
BINDIR?= /boot
+.ifdef CPUTYPE
+.undef CPUTYPE
+.endif
+
.if ${MACHINE_CPUARCH} == i386
CFLAGS+= -march=i386
.endif
-Harry
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: EFI boot failure
On 23 Sep 2014, at 17:00, Nathan Whitehorn nwhiteh...@freebsd.org wrote:
On 09/23/14 07:28, Harald Schmalzbauer wrote:
Bezüglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime):
…
The problem I reported about in the first place is triggered by a faulty
loader.efi that
arises, when optimisation level is -O3. -O2 works fine.
I can confirm that this problem also shows up when using
'CPUTYPE?=core-avx2'
Setting CPUTYPE to core-avx-i doesnt ehibit the problem.
I could narrow down the cause to libefi.a (sys/boot/efi).
But I don't understand the things going on there, so no clue how to fix
besides maybe
--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.0 +0200
@@ -2,6 +2,10 @@
BINDIR?= /boot
+.ifdef CPUTYPE
+.undef CPUTYPE
+.endif
+
.if ${MACHINE_CPUARCH} == i386
CFLAGS+= -march=i386
.endif
Could you try adding -mno-avx2 to /sys/boot/amd64/Makefile.inc line 9?
-Nathan
IMHO CPUTYPE should be ignored for any boot loader program, and the
lowest common denominator should be used instead (i486 for 32-bit, plain
x86_64 for 64-bit). It makes no sense to optimize boot loaders for e.g.
core-avx2. :-)
But indeed, it appears that we need to add more -mno-foo magic flags...
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: CURRENT: EFI boot failure
Bezüglich Nathan Whitehorn's Nachricht vom 23.09.2014 17:00 (localtime): Could you try adding -mno-avx2 to /sys/boot/amd64/Makefile.inc line 9? Done so, but it doesn't fix the problem with halting loader.efi when compiled with CPUTYPE=core-avx2. The whole -mno-xyz isn't applied to sys/boot/efi/libefi: cc -O2 -pipe -march=core-avx2 -fPIC -I/usr/src/sys/boot/efi/libefi/../include -I/usr/src/sys/boot/efi/libefi/../include/amd64 -I/usr/src/sys/boot/efi/libefi/../../../../lib/libstand -I/usr/src/sys/boot/efi/libefi/../../common -DNO_PCI -fformat-extensions -ffreestanding -fshort-wchar -Wformat -std=gnu99-Qunused-arguments -c delay.c -o delay.o Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: CURRENT: EFI boot failure
Am Wed, 17 Sep 2014 01:25:07 +0300 Andriy Gapon a...@freebsd.org schrieb: On 17/09/2014 00:32, Ed Maste wrote: On 16 September 2014 17:03, O. Hartmann ohart...@zedat.fu-berlin.de wrote: In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What is the difference? Is the efi partition FAT? An EFI system partition (ESP) is a FAT-formatted partition with a specific GPT or MBR identifier and file system hierarchy; EFI firmware will try to load /EFI/BOOT/BOOTX64.EFI from the ESP. A very useful read about how EFI boot process works and how different OSes boot on top of it: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html boot1.efi is an EFI application - that is, a PECOFF format binary. It searches for a UFS filesystem and loads loader.efi from that. It is intended to simplify the UEFI boot process, so that loader.efi, the .4th files, loader.conf etc. do not all need to be installed in the ESP. boot1.efifat is a FAT filesystem image that contains a copy of boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer can treat it as opaque bootcode, like other boot schemes. It's certainly possible to create a partition, use newfs_msdos to format it, and copy in boot1.efi instead. It is one disk, dedicated to FreeBSD (a laptop disk). Is there any documentation readable for non-developer for that matter? I'm curious about how EFI works on FreeBSD. Better user-facing documentation is in progress; for now the best source is probably the wik. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org The problem I reported about in the first place is triggered by a faulty loader.efi that arises, when optimisation level is -O3. -O2 works fine. I also realized that there is a kind of inconsistency in how COPTFLAGS and CFLAGS are handled in reality compared to that what the manpage of make.conf states. Setting COPTFLAGS=-O2 for compiling kernel stuff only ALWAYS incorporates CFLAGS, which is set to CFLAGS=-O3 in make.conf in my case. loader.efi is, in my opinion, kernel stuff only as well as kernel modules, which also gets compiled with CFLAGS. signature.asc Description: PGP signature
Re: CURRENT: EFI boot failure
On 09/17/2014 00:54, Nathan Whitehorn wrote: Try xf86-video-scfb instead? I also had the same problem (mentioned in another thread called Problems starting X on Mac using vesa, radeon or intel drivers when running FreeBSD-CURRENT in EFI), and following your suggestion to install the xf86-video-scfb driver is working for me using a Radeon HD 6770M and a built-in Intel HD 3000 graphics card. Neither the Intel or Radeon driver worked for me in EFI mode, but the driver you mentioned seems to work without problems. :) So thank you for that tip. :) Have a good night or day, everyone. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: EFI boot failure
Am Tue, 16 Sep 2014 02:05:41 +0200 O. Hartmann ohart...@zedat.fu-berlin.de schrieb: 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? after today's make world (revision 271800) and two days of normal operation, I run into the same situation as described above! This is more than annoying! The screen show simply FreeBSD EFI boot block Loader path: /boot/loader.efi and nothing happens forever. Usually, the loader/console shows up. This time the system gets stuck as I reported earlier. I can not afford another two days of installing the laptop again. How can I get rid of this immature EFI and run the system in the traditional way? It seems two immature systems meet each other, vt() and EFI and this ends up in a desaster. What is the fallback procedure? How to save the system and circumvent this problem? Is there a way to interrupt the boot process and drop out into some kind of emergency screen/console? BTW, I temporarily fixed this issu by copying the USB drive image's loader.efi into boot. This seems to be a bug in the compiler/compiling loader.efi. signature.asc Description: PGP signature
Re: CURRENT: EFI boot failure
Am Tue, 16 Sep 2014 15:54:31 -0700 Nathan Whitehorn nwhiteh...@freebsd.org schrieb: On 09/16/14 14:50, O. Hartmann wrote: Am Tue, 16 Sep 2014 00:09:01 -0700 Nathan Whitehorn nwhiteh...@freebsd.org schrieb: On 09/15/14 22:51, O. Hartmann wrote: Am Mon, 15 Sep 2014 17:39:26 -0700 Nathan Whitehorn nwhiteh...@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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@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. Good to know. 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 x stride masks 0xfff [...] and the rest of the screen is blank. System remains unusable, the HDD is working and obviously
Re: CURRENT: EFI boot failure
On 16 September 2014 17:50, O. Hartmann ohart...@zedat.fu-berlin.de wrote: ... hw.vga.textmode=1 hw.vty=sc (tried also hw.vty=vt). ... One clarification for the archives: there's no tunable hw.vty, it's kern.vty. From vt(4): kern.vty When both vt and sc(4) have been compiled into the kernel, the one to use for the system console can be selected by setting this value to ‘vt’ or ‘sc’. If this value is not set, sc(4) is used. Although I see that needs an update, since the situation is now: If this value is not set, sc(4) is used, unless the system is booted via UEFI. In the UEFI-boot case vt(4) is used. (Tracked in PR 193710) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: EFI boot failure
On 09/15/14 22:51, O. Hartmann wrote: Am Mon, 15 Sep 2014 17:39:26 -0700 Nathan Whitehorn nwhiteh...@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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: EFI boot failure
On 16 Sep 2014, at 00:05 , O. Hartmann ohart...@zedat.fu-berlin.de 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. The reboot comes from the EFI watchdog. What happened and how can this problem be solved? One important thing for the people looking into this will be to know what hardware and if possible firmware revision you have. — Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: EFI boot failure
Am Tue, 16 Sep 2014 00:09:01 -0700 Nathan Whitehorn nwhiteh...@freebsd.org schrieb: On 09/15/14 22:51, O. Hartmann wrote: Am Mon, 15 Sep 2014 17:39:26 -0700 Nathan Whitehorn nwhiteh...@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. Well, I have to worry about because the system is stuck and completely unusable. I installed the system from the very same USB drive image as mentioned above again. Then, after the newtork issue has been fixed, I was able to update sources and built world. As long as I do not attempt to use to use X, everything is fine. 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. The setup was plain and vanilla. I used the installer of the USB image (see above). Creating GPT partition scheme and two partitions of type efi and freebsd-boot, first 1MB, latter 512KB. All other partitions are freebsd-ufs, exept freebsd-swap. In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What is the difference? Is the efi partition FAT? 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 It is one disk, dedicated to FreeBSD (a laptop disk). Is there any documentation readable for non-developer for that matter? I'm curious about how EFI works on FreeBSD. Oliver signature.asc Description: PGP signature
Re: CURRENT: EFI boot failure
Am Mon, 15 Sep 2014 20:36:23 -0400 Allan Jude allanj...@freebsd.org schrieb: 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 Is it boot1.efi or is it boot1.efifat? signature.asc Description: PGP signature
Re: CURRENT: EFI boot failure
On 16 September 2014 17:03, O. Hartmann ohart...@zedat.fu-berlin.de wrote: In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What is the difference? Is the efi partition FAT? An EFI system partition (ESP) is a FAT-formatted partition with a specific GPT or MBR identifier and file system hierarchy; EFI firmware will try to load /EFI/BOOT/BOOTX64.EFI from the ESP. boot1.efi is an EFI application - that is, a PECOFF format binary. It searches for a UFS filesystem and loads loader.efi from that. It is intended to simplify the UEFI boot process, so that loader.efi, the .4th files, loader.conf etc. do not all need to be installed in the ESP. boot1.efifat is a FAT filesystem image that contains a copy of boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer can treat it as opaque bootcode, like other boot schemes. It's certainly possible to create a partition, use newfs_msdos to format it, and copy in boot1.efi instead. It is one disk, dedicated to FreeBSD (a laptop disk). Is there any documentation readable for non-developer for that matter? I'm curious about how EFI works on FreeBSD. Better user-facing documentation is in progress; for now the best source is probably the wik. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: EFI boot failure
Am Tue, 16 Sep 2014 00:09:01 -0700 Nathan Whitehorn nwhiteh...@freebsd.org schrieb: On 09/15/14 22:51, O. Hartmann wrote: Am Mon, 15 Sep 2014 17:39:26 -0700 Nathan Whitehorn nwhiteh...@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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@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. 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? 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 x stride masks 0xfff [...] 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. 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,
Re: CURRENT: EFI boot failure
Am Tue, 16 Sep 2014 17:32:12 -0400 Ed Maste ema...@freebsd.org schrieb: On 16 September 2014 17:03, O. Hartmann ohart...@zedat.fu-berlin.de wrote: In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What is the difference? Is the efi partition FAT? An EFI system partition (ESP) is a FAT-formatted partition with a specific GPT or MBR identifier and file system hierarchy; EFI firmware will try to load /EFI/BOOT/BOOTX64.EFI from the ESP. boot1.efi is an EFI application - that is, a PECOFF format binary. It searches for a UFS filesystem and loads loader.efi from that. It is intended to simplify the UEFI boot process, so that loader.efi, the .4th files, loader.conf etc. do not all need to be installed in the ESP. Thank you very much for the explanation. Well, since I never see the loader screen as we are used to, were is that gone? There are no boot options anymore (like single user mode, ACPI off et cetera). Is this intended? Besides, checking both boot1.efi and loader.efi with file() shows something like loader.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows. So both are PECOFF format files? boot1.efifat is a FAT filesystem image that contains a copy of boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer can treat it as opaque bootcode, like other boot schemes. It's certainly possible to create a partition, use newfs_msdos to format it, and copy in boot1.efi instead. All right, here you lost me ... sorry. The partition created by the installes with type efi is then the /EFI/ partition, which then contains a folder BOOT and in which the boot1.efi is located? As I understand, I can manually mount this partition as FAT and copy boot1.efi as BOOTX64.EFI into it? This knowledge could come in handy if something goes very bad. It is one disk, dedicated to FreeBSD (a laptop disk). Is there any documentation readable for non-developer for that matter? I'm curious about how EFI works on FreeBSD. Better user-facing documentation is in progress; for now the best source is probably the wik. Thank you. signature.asc Description: PGP signature
Re: CURRENT: EFI boot failure
On 17/09/2014 00:32, Ed Maste wrote: On 16 September 2014 17:03, O. Hartmann ohart...@zedat.fu-berlin.de wrote: In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What is the difference? Is the efi partition FAT? An EFI system partition (ESP) is a FAT-formatted partition with a specific GPT or MBR identifier and file system hierarchy; EFI firmware will try to load /EFI/BOOT/BOOTX64.EFI from the ESP. A very useful read about how EFI boot process works and how different OSes boot on top of it: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html boot1.efi is an EFI application - that is, a PECOFF format binary. It searches for a UFS filesystem and loads loader.efi from that. It is intended to simplify the UEFI boot process, so that loader.efi, the .4th files, loader.conf etc. do not all need to be installed in the ESP. boot1.efifat is a FAT filesystem image that contains a copy of boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer can treat it as opaque bootcode, like other boot schemes. It's certainly possible to create a partition, use newfs_msdos to format it, and copy in boot1.efi instead. It is one disk, dedicated to FreeBSD (a laptop disk). Is there any documentation readable for non-developer for that matter? I'm curious about how EFI works on FreeBSD. Better user-facing documentation is in progress; for now the best source is probably the wik. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: EFI boot failure
Am Wed, 17 Sep 2014 01:25:07 +0300 Andriy Gapon a...@freebsd.org schrieb: On 17/09/2014 00:32, Ed Maste wrote: On 16 September 2014 17:03, O. Hartmann ohart...@zedat.fu-berlin.de wrote: In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What is the difference? Is the efi partition FAT? An EFI system partition (ESP) is a FAT-formatted partition with a specific GPT or MBR identifier and file system hierarchy; EFI firmware will try to load /EFI/BOOT/BOOTX64.EFI from the ESP. A very useful read about how EFI boot process works and how different OSes boot on top of it: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html Great! boot1.efi is an EFI application - that is, a PECOFF format binary. It searches for a UFS filesystem and loads loader.efi from that. It is intended to simplify the UEFI boot process, so that loader.efi, the .4th files, loader.conf etc. do not all need to be installed in the ESP. boot1.efifat is a FAT filesystem image that contains a copy of boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer can treat it as opaque bootcode, like other boot schemes. It's certainly possible to create a partition, use newfs_msdos to format it, and copy in boot1.efi instead. It is one disk, dedicated to FreeBSD (a laptop disk). Is there any documentation readable for non-developer for that matter? I'm curious about how EFI works on FreeBSD. Better user-facing documentation is in progress; for now the best source is probably the wik. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org signature.asc Description: PGP signature
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 nwhiteh...@freebsd.org schrieb: On 09/15/14 22:51, O. Hartmann wrote: Am Mon, 15 Sep 2014 17:39:26 -0700 Nathan Whitehorn nwhiteh...@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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@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 x stride masks 0xfff [...] 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
Re: CURRENT: EFI boot failure
On 16 September 2014 18:25, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Besides, checking both boot1.efi and loader.efi with file() shows something like loader.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows. So both are PECOFF format files? That is correct. boot1.efifat is a FAT filesystem image that contains a copy of boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer can treat it as opaque bootcode, like other boot schemes. It's certainly possible to create a partition, use newfs_msdos to format it, and copy in boot1.efi instead. All right, here you lost me ... sorry. The partition created by the installes with type efi is then the /EFI/ partition, which then contains a folder BOOT and in which the boot1.efi is located? As I understand, I can manually mount this partition as FAT and copy boot1.efi as BOOTX64.EFI into it? This knowledge could come in handy if something goes very bad. Sorry, not quite; an ESP is a separate partition formatted with FAT. The file system in that partition has EFI/ in the root directory, BOOT/ under that, and BOOTX64.EFI in there. We don't (yet) mount the ESP inside of FreeBSD by default. At least some Linuxes do mount the ESP at /boot/efi, so you end up with /boot/efi/EFI/BOOT/BOOTX64.EFI. We might start doing something similar when fleshing out dual-boot configuration support. boot1.efifat is a copy (image) of the ESP, as it exists on the disk. You can see what's inside: # mdconfig -a -f /boot/boot1.efifat md0 # mount_msdosfs /dev/md0 /mnt # ls -l /mnt/efi/boot/BOOTx64.efi -rwxr-xr-x 1 root wheel 65536 Apr 26 20:43 /mnt/efi/boot/BOOTx64.efi # umount /mnt # mdconfig -d -u 0 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: EFI boot failure
On 16 September 2014 18:54, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 09/16/14 14:50, O. Hartmann wrote: 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. As Nathan says there's no beastie menu, but you should still see the loader. If you get a Hit [Enter] to boot immediately, or any other key for command prompt. message, you're seeing the loader. There is an additional complication that affects some systems, where we do not switch to text mode. In this case you truly won't see the loader. This is described in the link Andriy provided (along with a workaround), and we have a patch in progress for this. So far this mainly known to affect MacBooks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: EFI boot failure
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 -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: CURRENT: EFI boot failure
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: EFI boot failure
Am Mon, 15 Sep 2014 17:39:26 -0700 Nathan Whitehorn nwhiteh...@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). 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. 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. Oliver signature.asc Description: PGP signature
