On Sat, Oct 13, 2018 at 4:44 PM, Garry T. Williams <gtwilliams@xxxxxxxxx> wrote:
> On Saturday, October 13, 2018 5:42:15 PM EDT Chris Murphy wrote:
>> On Sat, Oct 13, 2018 at 1:30 PM, Garry T. Williams
>> <gtwilliams@xxxxxxxxx> wrote:
>> > On Saturday, October 13, 2018 3:12:44 PM EDT Samuel Sieb wrote:
>> >> On 10/13/18 10:39 AM, Garry T. Williams wrote:
>> >>
>> >> > What am I doing wrong here that I cannot boot after a
>> >> > system-upgrade?
>> >>
>> >> "Doesn't boot" is no information. What exactly is happening?
>> >
>> > Sorry, the boot record is gone.
>>
>> You determined this how?
>
> The machine did not boot the Fedora OS. Instead, it booted the OS on
> /dev/sda.
That is not evidence the boot record is gone. If this is a UEFI
system, it's suggestive that an NVRAM variable has been altered, such
as BootOrder, or an entry removed. But NVRAM modification are also
something that dnf system upgrade cannot do.
>
> Admittedly, this is output from the now-recovered system, but I can
> attest that the same was displayed when the command was done using the
> Ubuntu system that loaded from /dev/sda.
>
>> > The system-upgrade somehow wiped out my boot record on /dev/sdb.
>>
>> "boot record" is a BIOS term, so this could mean the code on LBA 0
>> or in the MBR gap or BIOS Boot partition has been stepped on; but
>> dnf system upgrade doesn't have such an ability. In fact it's a bit
>> of a security and bug endurance problem that 'grub2-install' isn't
>> run on BIOS upgrades. Whereas on UEFI the bootloader binaries on
>> the EFI System partition are replaced during updates, so what
>> you're describing might be a GRUB bug.
>
> OK, the system was able to boot from /dev/sdb only after I reinstalled
> grub2-efi and shim.
>
> I assumed that was what restored the boot record (or whatever it's
> called).
On UEFI there's NVRAM which contains boot entries that point to
bootloader location by device, partition, and path.
But yeah you're right, autopsy is difficult now that the system is
working again. In any case, there's no single thing that really
qualifies as boot record on UEFI.
> garry@vfr$ efibootmgr -v
> BootCurrent: 0002
> Timeout: 1 seconds
> BootOrder: 0002,0000,0003,0004,0005,0006,0007,0008,0009
> Boot0000 ubuntu HD(1,GPT,3252a9ab-23eb-4fd4-9d11-6dc13c6f50ec,
> 0x800,0xfa000)/File(\EFI\ubuntu\shimx64.efi)
> Boot0002* Fedora HD(1,GPT,0534ef43-afb9-409c-8dc8-a1eff1e396ef,
> 0x800,0x64000)/File(\EFI\fedora\shim.efi)
Entry 0002 is stale; shim.efi is still valid for Fedora 29 but new
installations refer to shimx64.efi the same as the 0000 entry for
Ubuntu. Thing is, dnf system upgrade doesn't change NVRAM menu
entries. Anyway, it may be unrelated. It's just a data point for now.
But everything you provided looks sane, which is probably why it's
booting, and evidence of the unworking state isn't available so we can
only guess what happened.
- BootOrder shouldn't be changed by anything dnf system upgrade does
- Deleting boot entries from NVRAM should be anything dnf system upgrade does
- dnf system upgrade should have replaced pretty much all the binary
files on the /dev/sdb EFI System partition, same as you reinstalling
shim and grub2-efi
I suspect a detail is missing that seems innocuous and unintuitive as
to it's relationship to the failure; but is actually related.
For example, on my HP with Windows 10 and Fedora 29:
[chris@flap ~]$ sudo efibootmgr -v
[sudo] password for chris:
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,3000,0002,2001,2002,2004
Boot0000* Fedora
HD(2,GPT,0273e9d0-2c96-49fc-a046-b67914664deb,0xfa000,0x32000)/File(\EFI\fedora\shimx64.efi)
Boot0002* Windows Boot Manager
HD(2,GPT,0273e9d0-2c96-49fc-a046-b67914664deb,0xfa000,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...r................
Boot2001* EFI USB Device RC
Boot3000* Internal Hard Disk or Solid State Disk RC
Boot3002* Internal Hard Disk or Solid State Disk RC
[chris@flap ~]$
Fedora should boot first. However, if I enter firmware setup and
close, whether I change anything or not? It always boots Windows by
default from then on. The BootOrder variable is changed, just by
virtue of entering firmware setup (not the firmware's boot manager).
That's fakaked! However, I have to change BootOrder with efibootmgr,
reinstalling shim and grub2-efi doesn't fix it, because installing
those packages doesn't change EFI NVRAM variables.
--
Chris Murphy
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
