Re: EFI issues

From: O. Hartmann <ohartmann_at_walstatt.org>
Date: Sun, 29 Jul 2018 09:44:35 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am Sat, 28 Jul 2018 11:29:40 +0400
Roman Bogorodskiy <novel_at_freebsd.org> schrieb:

> Hi,
> 
> I have a test box that's updated to -CURRENT usually once in a week or
> two. This box boots using UEFI. After a regular update about two weeks
> ago it started to panic on boot frequently (not UEFI related), but I
> could not get a crash dump because my swap partition was too small. So I
> moved data to the backup drive, repartitioned the main drive and boot
> again. This went fine, so I decided to upgrade to fresh -CURRENT from
> ~Jul 27th. Booting with the new kernel went fine, but after installworld
> machine stopped booting, and on the screen I see:
> 
> FreeBSD/amd64 EFI loader, ...
> 
> ..
> 
> BootOrder: ....
> 
> And then it gets stuck and nothing happens.
> 
> As I already have a fresh backup, I decided that it'd be easier to
> just re-install and copy data back over (maybe I messed up with
> repartitioning). So I've downloaded a fresh snapshot:
> 
> FreeBSD-12.0-CURRENT-amd64-20180726-r336739-memstick.img
> 
> And re-installed. In the installer I choose all the same settings that
> were before: UEFI + GPT, default partition scheme it suggested (efi
> followed by freebsd-ufs followed by freebsd-swap), just increased the
> swap size.
> 
> And the newly installed system won't boot just like a previous one:
> 
> https://people.freebsd.org/~novel/misc/freebsd_efi_lookup.jpg

> 
> Is there a way to recover this?
> 
> Roman Bogorodskiy

Just curious:

When I installed FreeBSD last time from the recent (2018-07-26) USB flash drive on a SSD,
the freebsd-swap partition followed immediately after the ESP and/or freebsd-boot GPT
loader partition. But in most cases I used to use ZFS for testing.

Since I had my UEFI adventure of my own these days and received valuable hints from the
development/maintenance team on some UEFI aspects, it would be of interest to know your
recent hardware and, more importantly since I see the boot order presented in you
screenshot, a dump of the efi variable settings. Just for curiosity. For that, you have
to boot the recent USB flash drive image with UEFI-only, then logon as root and perform

kldload efirt

and then issue 

# efibootmgr -v

In my case, it looks like

[...]
[ohartmann]: sudo efibootmgr -v
BootCurrent: 0001
Timeout    : 3 seconds
BootOrder  : 0001, 0002, 0003, 0004, 0005, 0000
+Boot0001* FreeBSD-12 \
   HD(1,GPT,e1460941-e2e9-11e5-b913-d0509907ef09,0x28,0x640)/File(\efi\boot\BOOTx64.efi) \
   ada0p1:/efi/boot/BOOTx64.efi (null) 
 Boot0002* Hard Drive  BBS(HD,,0x0)
 Boot0003* CD/DVD Drive  BBS(CDROM,,0x0)
 Boot0004* USB  BBS(USB,,0x0)
 Boot0005* Network Card  BBS(Network,,0x0)
 Boot0000  FreeBSD-12
HD(1,GPT,e1460941-e2e9-11e5-b913-d0509907ef09,0x28,0x640)/File(\efi\boot\BOOTx64.efi)
ada0p1:/efi/boot/BOOTx64.efi (null)


Unreferenced Variables:
[...]

Boot0000 is the same as Boot0001 and is defined due to some "bug" Warner Losh has fixed
recently, it is the same as Boot0001

Kind regards,

oh

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-----BEGIN PGP SIGNATURE-----

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW11wfgAKCRDS528fyFhY
lMojAf929USx1x7I/sSGLtEWKO8rm9IXf1JEpQ7GSdI6YHid364x7fbrUBhDZYuT
JVanY57Li2oLOXogHtMw6eDUyD+aAf9GTE30LUNRhmcJ7el62Vwpm0oUBG2as52i
+v58EZ9c20yKQKuXt446dhbILyODDPKmc9ykAvnE0TtMiTHk6vRn
=M7vi
-----END PGP SIGNATURE-----
Received on Sun Jul 29 2018 - 05:50:20 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:17 UTC