-----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
