Re: EFI issues

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

Am Sun, 29 Jul 2018 12:09:58 +0400
Roman Bogorodskiy <novel_at_freebsd.org> schrieb:

>   O. Hartmann wrote:
> 
> > -----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.  
> 
> When I reinstalled it yesterday from -CURRENT snapshot mentioned above,
> in guided mode it suggested a similar partitioning schema that I use:
> 
> =>        40  1953525088  ada0  GPT  (932G)  
>           40      409600     1  efi  (200M)
>       409640  1803550720     2  freebsd-ufs  (860G)
>   1803960360   148897792     3  freebsd-swap  (71G)
>   1952858152      666976        - free -  (326M)
> 
> The only difference it that the freebsd-swap size was 3.5G (and
> therefore, freebsd-ufs is large), the order was the same.
> 
> > 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  
> 
> Motherboard is (from dmidecode):
> 
> Handle 0x0000, DMI type 0, 24 bytes
> BIOS Information
>         Vendor: American Megatrends Inc.
>         Version: 0806
>         Release Date: 02/20/2014
>         Address: 0xF0000
>         Runtime Size: 64 kB
>         ROM Size: 16 MB
>         Characteristics:
>                 PCI is supported
>                 APM is supported
>                 BIOS is upgradeable
>                 BIOS shadowing is allowed
>                 Boot from CD is supported
>                 Selectable boot is supported
>                 BIOS ROM is socketed
>                 EDD is supported
>                 5.25"/1.2 MB floppy services are supported (int 13h)
>                 3.5"/720 kB floppy services are supported (int 13h)
>                 3.5"/2.88 MB floppy services are supported (int 13h)
>                 Print screen service is supported (int 5h)
>                 8042 keyboard services are supported (int 9h)
>                 Serial services are supported (int 14h)
>                 Printer services are supported (int 17h)
>                 ACPI is supported
>                 USB legacy is supported
>                 BIOS boot specification is supported
>                 Targeted content distribution is supported
>                 UEFI is supported
>         BIOS Revision: 4.6
> 
> Handle 0x0002, DMI type 2, 15 bytes
> Base Board Information
>         Manufacturer: ASUSTeK COMPUTER INC.
>         Product Name: B85M-E
>         Version: Rev X.0x
>         Serial Number: 140526238405585
>         Asset Tag: To be filled by
> O.E.M.
> Features: Board is a hosting
> board Board is
> replaceable Location In Chassis: To be filled by
> O.E.M. Chassis Handle:
> 0x0003 Type:
> Motherboard Contained Object Handles: 0
> 
> 'efibootmgr -v' output:
> 
> BootCurrent: 0004
> Timeout    : 1 seconds
> BootOrder  : 0001, 0002, 0003, 0004
>  Boot0001* Hard Drive  BBS(HD,,0x0)
>  Boot0002* Network Card  BBS(Network,,0x0)
>  Boot0003* UEFI OS
> HD(1,GPT,78459ec0-9303-11e8-97e6-98ded0009b1c,0x28,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)
> ada0p1:/EFI/BOOT/BOOTX64.EFI (null)
> Path(0,0,ae84b11df581724e85442bab0c2cac5c020000020000) +Boot0004* UEFI: SanDisk
> PciRoot(0x0)/Pci(0x1d,0x0)/USB(0x1,0x0)/USB(0x4,0x0)/HD(1,MBR,0x90909090,0x1,0x640)
> VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,530061006e004400690073006b000000)
> 
> 
> Unreferenced Variables:
> 
> 
> > 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-----  
> 
> Roman Bogorodskiy

The order of the partitions was simply an observation and from the "old days" with HDD as
mass storage/boot storage with rotating platters it was some sort of important for the
access latency where to position the swap partition. With NAND flash based SSD this
became obsolete - so, please don't be bothered about that.

- From my (non-expert) point of view, you UEFI variables look "normal" (according to what
I see on my boxes at home), but I was wondering about the "aged" firmware of you
mainboard. Checking out at ASUS' website/support, they claim they have a more recent
firmare from 2018! This would be on par with the Spectre/Meltdown mitigation promises
made by most valuable/reliable mainboard vendors and Intel:

https://www.asus.com/Motherboards/B85ME/HelpDesk_BIOS/


 Version 3602 2018/05/25 7.29 MByte B85M-E BIOS 3602

Since dmidecode reports on my ASRock crap mainboard also

BIOS Revision: 4.6

I guess this one is fake or some "default" from the dmidecode program not identifying
the correct revision - or it's another semantic not known to me.

But my dmidecode looks like this, with the latest BETA ASrock provides for this long
time ago discontinued Z77 Pro4-board: 

[...]

# dmidecode 3.1
# SMBIOS entry point at 0x000f04c0
Found SMBIOS entry point in EFI, reading table from /dev/mem.
SMBIOS 2.7 present.
26 structures occupying 1523 bytes.
Table at 0x000EE7F0.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
        Vendor: American Megatrends Inc.
        Version: P2.00
        Release Date: 03/13/2018
        Address: 0xF0000
        Runtime Size: 64 kB
        ROM Size: 8192 kB
        Characteristics:
                PCI is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                Boot from CD is supported
                Selectable boot is supported
                BIOS ROM is socketed
                EDD is supported
                5.25"/1.2 MB floppy services are supported (int 13h)
                3.5"/720 kB floppy services are supported (int 13h)
                3.5"/2.88 MB floppy services are supported (int 13h)
                Print screen service is supported (int 5h)
                8042 keyboard services are supported (int 9h)
                Serial services are supported (int 14h)
                Printer services are supported (int 17h)
                ACPI is supported
                USB legacy is supported
                BIOS boot specification is supported
                Targeted content distribution is supported
                UEFI is supported
        BIOS Revision: 4.6
[...]

Watch out the Version: P2.00 entry, which is indeed the version number of the firmware.
So, in your case, the firmware is also a bit outdated, from 2014. I'd update the firmware
prior to any further action if there are no obligations from hardware incompatibilities
so far to meet the neccessity of lates Intel/AMD microcode updates and/or other UEFI
vulnerabilities of which I have no active memories about, but they hit me 2015/2016 on
our servers. There is no guarantee that the firmware update will salvage your problem,
but that might be worth a shot. Also, ASUS mention to have solved performance issues
with the latest firmware, please consider consulting the description of the latest
firmware release. 

As the next step, as from my "naive" point of view, I would perform the steps recommended
to me by FreeBSD's developers to set the UEFI variables again:

Boot in UEFI mode from the USB flash device
Logon as root
mount -uw /
kldload efirt
mount -t msdosfs /dev/ada0p1 /mnt

efibootmgr -c -l /mnt/efi/boot/BOOTx64.efi -L FreeBSD
efibootmgr -v

Look for the "Boot000X" entry labeled with "FreeBSD", take the number portion of the that
Boot000X variable (000X) and perform

efibootmgr -a 000X
efibootmgr -n 000X (this one is "extra" and can be ommited, it means "next boot", see
manpage efibootmgr(8))

and check again with 

efibootmgr -v

The "maneuver" above is only in case the settings of UEFI variables has gone rogue.

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/86TrS528fyFhYlAUCW12BFgAKCRDS528fyFhY
lLZOAf0V9r/0LzMoKOJfxNhBNsLGFkVRxB6zv9OQV3ytAczGb4alGJRMv8PqDlPi
Vxgp3D+Aq5J9B/Thh2PCEX9v8AFuAgCoUztwd7APBeCaW1TVivWl7X9PpuSZIclU
PhiaxxU51DYekjKZEEUiwJiq75KZH+6SGdzvfEN+0a5H1BK2awgP
=fzRU
-----END PGP SIGNATURE-----
Received on Sun Jul 29 2018 - 07:01:17 UTC

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