EFI issues
Roman Bogorodskiy
novel at freebsd.org
Sun Jul 29 11:18:01 UTC 2018
O. Hartmann wrote:
> -----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
I've updated BIOS (which alone didn't change anything) and executed
commands you suggested, and it helped! Thanks!
Now 'efibootmgr -v' output looks like this:
BootCurrent: 0000
Timeout : 1 seconds
BootOrder : 0000, 0004, 0006, 0003, 0007
+Boot0000* FreeBSD HD(1,GPT,78459ec0-9303-11e8-97e6-98ded0009b1c,0x28,0x64000)/File(\efi\boot\BOOTx64.efi)
ada0p1:/efi/boot/BOOTx64.efi (null)
Boot0004* Hard Drive BBS(HD,,0x0)
Boot0006* 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,ef47642dc93ba041ac194d51d01b4ce65200650061006c00740065006b00200042006f006f00740020004100670065006e0074000000)
Boot0007* UEFI: SanDisk PciRoot(0x0)/Pci(0x14,0x0)/USB(0x9,0x0)/HD(1,MBR,0x90909090,0x1,0x640)
VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,340043003500330031003000300031003500340031003000310035003100300039003000390035000000)
Unreferenced Variables:
This is strange, because the only difference I see is that Boot0000 has
lowercase filenames ('/efi/boot/BOOTx64.efi' vs
'/EFI/BOOT/BOOTX64.EFI'). I'm wondering if that's the only reason it
wasn't working before?
> - --
> 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-----
Roman Bogorodskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20180729/190fa55c/attachment.sig>
More information about the freebsd-current
mailing list