EFI issues
O. Hartmann
ohartmann at walstatt.org
Sun Jul 29 07:50:20 UTC 2018
-----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-----
More information about the freebsd-current
mailing list