Re: Cannot Boot After Doing system-upgrade
On Sat, 2018-10-13 at 17:34 -0600, Chris Murphy wrote: > On Sat, Oct 13, 2018 at 5:01 PM, Garry T. Williams < > gtwilli...@gmail.com> wrote: > > By the way, from the journal during the dnf system-upgrade reboot: > > > > ... > > Sep 30 10:02:28 vfr dnf[831]: shim-x64.x86_64 15-5 > > > > And now: > > ... > > shim-x64-15-7.x86_64 > > > > Good catch. It's vaguely possible there's a bug in either shim 15-5 There is a known bug in shim 15-5 which caused the same symptoms on my machine. Adam Williamson explains what went wrong in this comment: https://bugzilla.redhat.com/show_bug.cgi?id=1631989#c6 Jon ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org
Re: Cannot Boot After Doing system-upgrade
On Sat, Oct 13, 2018 at 5:57 PM, Garry T. Williams wrote: > On Saturday, October 13, 2018 7:34:44 PM EDT Chris Murphy wrote: >> Good catch. It's vaguely possible there's a bug in either shim 15-5 >> or grub2-efi 2.02-58 as it relates to your firmware, that caused >> it to silently fail, and the firmware did a fallback to the 2nd >> BootOrder, which is the Ubuntu entry. > > I want to emphasize that it was *not* boot order that changed. I > manually attempted to boot Fedora, but it failed (oh how I wish I had > paid attention to the details). > > Anyway, I can manually change the boot order to either OS and it > respects my change. My problem was something else entirely since a > manual change didn't boot Fedora. I'd expect any failure (due to bug or general disagreement between firmware and shim and grub) to result in the firmware using the next boot entry in BootOrder. This fallback behavior is in the UEFI specification for all firmware to follow and supposedly behave consistently, it's not something you're doing. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org
Re: Cannot Boot After Doing system-upgrade
On Saturday, October 13, 2018 7:34:44 PM EDT Chris Murphy wrote: > Good catch. It's vaguely possible there's a bug in either shim 15-5 > or grub2-efi 2.02-58 as it relates to your firmware, that caused > it to silently fail, and the firmware did a fallback to the 2nd > BootOrder, which is the Ubuntu entry. I want to emphasize that it was *not* boot order that changed. I manually attempted to boot Fedora, but it failed (oh how I wish I had paid attention to the details). Anyway, I can manually change the boot order to either OS and it respects my change. My problem was something else entirely since a manual change didn't boot Fedora. I may try the manual downgrade, if I get time. I am usually physically away from this system so I will retrieve the old versions and be ready when I can get the time. Again, thank you for your thoughtful follow-ups. -- Garry T. Williams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org
Re: Cannot Boot After Doing system-upgrade
On Sat, Oct 13, 2018 at 5:01 PM, Garry T. Williams wrote: > By the way, from the journal during the dnf system-upgrade reboot: > > Sep 30 10:02:27 vfr dnf[831]: grub2-common.noarch 1:2.02-58.fc29 > Sep 30 10:02:27 vfr dnf[831]: grub2-efi-x64.x86_64 1:2.02-58.fc29 > Sep 30 10:02:27 vfr dnf[831]: grub2-pc.x86_64 1:2.02-58.fc29 > Sep 30 10:02:27 vfr dnf[831]: grub2-pc-modules.noarch 1:2.02-58.fc29 > Sep 30 10:02:27 vfr dnf[831]: grub2-tools.x86_64 1:2.02-58.fc29 > Sep 30 10:02:27 vfr dnf[831]: grub2-tools-efi.x86_64 1:2.02-58.fc29 > Sep 30 10:02:27 vfr dnf[831]: grub2-tools-extra.x86_64 > 1:2.02-58.fc29 > Sep 30 10:02:27 vfr dnf[831]: grub2-tools-minimal.x86_64 > 1:2.02-58.fc29 > > Sep 30 10:02:28 vfr dnf[831]: shim-x64.x86_64 15-5 > > And now: > > garry@vfr$ rpm -q grub2-common grub2-efi-x64 grub2-pc grub2-pc-modules > grub2-tools grub2-tools-efi grub2-tools-extra grub2-tools-minimal > shim-x64 > grub2-common-2.02-62.fc29.noarch > grub2-efi-x64-2.02-62.fc29.x86_64 > grub2-pc-2.02-62.fc29.x86_64 > grub2-pc-modules-2.02-62.fc29.noarch > grub2-tools-2.02-62.fc29.x86_64 > grub2-tools-efi-2.02-62.fc29.x86_64 > grub2-tools-extra-2.02-62.fc29.x86_64 > grub2-tools-minimal-2.02-62.fc29.x86_64 > shim-x64-15-7.x86_64 > garry@vfr$ Good catch. It's vaguely possible there's a bug in either shim 15-5 or grub2-efi 2.02-58 as it relates to your firmware, that caused it to silently fail, and the firmware did a fallback to the 2nd BootOrder, which is the Ubuntu entry. One way to find out, that probably isn't worth it, is to manually downgrade to those versions, separately, to see which one (if any) restores the problem. But, it's fixed so I probably wouldn't test it as those versions have been superseded now. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org
Re: Cannot Boot After Doing system-upgrade
On Sat, Oct 13, 2018 at 4:44 PM, Garry T. Williams 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
>> 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,,0003,0004,0005,0006,0007,0008,0009
> Boot ubuntuHD(1,GPT,3252a9ab-23eb-4fd4-9d11-6dc13c6f50ec,
> 0x800,0xfa000)/File(\EFI\ubuntu\shimx64.efi)
> Boot0002* FedoraHD(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 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:
Timeout: 0 seconds
BootOrder: ,3000,0002,2001,2002,2004
Boot* 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 DeviceRC
Boot3000* Internal Hard Disk or Solid State DiskRC
Boot3002* Internal Hard Disk or Solid State DiskRC
[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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/devel@lists.fedoraproject.org
Re: Cannot Boot After Doing system-upgrade
By the way, from the journal during the dnf system-upgrade reboot: Sep 30 10:02:27 vfr dnf[831]: grub2-common.noarch 1:2.02-58.fc29 Sep 30 10:02:27 vfr dnf[831]: grub2-efi-x64.x86_64 1:2.02-58.fc29 Sep 30 10:02:27 vfr dnf[831]: grub2-pc.x86_64 1:2.02-58.fc29 Sep 30 10:02:27 vfr dnf[831]: grub2-pc-modules.noarch 1:2.02-58.fc29 Sep 30 10:02:27 vfr dnf[831]: grub2-tools.x86_64 1:2.02-58.fc29 Sep 30 10:02:27 vfr dnf[831]: grub2-tools-efi.x86_64 1:2.02-58.fc29 Sep 30 10:02:27 vfr dnf[831]: grub2-tools-extra.x86_64 1:2.02-58.fc29 Sep 30 10:02:27 vfr dnf[831]: grub2-tools-minimal.x86_64 1:2.02-58.fc29 Sep 30 10:02:28 vfr dnf[831]: shim-x64.x86_64 15-5 And now: garry@vfr$ rpm -q grub2-common grub2-efi-x64 grub2-pc grub2-pc-modules grub2-tools grub2-tools-efi grub2-tools-extra grub2-tools-minimal shim-x64 grub2-common-2.02-62.fc29.noarch grub2-efi-x64-2.02-62.fc29.x86_64 grub2-pc-2.02-62.fc29.x86_64 grub2-pc-modules-2.02-62.fc29.noarch grub2-tools-2.02-62.fc29.x86_64 grub2-tools-efi-2.02-62.fc29.x86_64 grub2-tools-extra-2.02-62.fc29.x86_64 grub2-tools-minimal-2.02-62.fc29.x86_64 shim-x64-15-7.x86_64 garry@vfr$ -- Garry T. Williams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org
Re: Cannot Boot After Doing system-upgrade
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 > 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. Of course, I attempted to boot from the Fedora disk by using the boot device configuration screen by hitting F12 during reboot. This failed. (A photograph of the error would have been a good idea.) I assumed that the reason was the boot record was missing. > >I happen to have another system on > > > > the same machine and that system boots instead of the Fedora > > system before my recovery actions. When I forced a boot from > > the fedora system using the machine's boot selection screen, it > > fails. (No diagnostic information in the BIOS setup screen -- > > just won't boot. I was forced to specify the USB Live system to > > start a recovery.) > > Screen shots or cell photo of the failure might be useful because > failure/won't boot doesn't tell us what is happening. And what is > happening is a hint as to what the source of the problem is, how to > prevent it, and how to fix it. But "won't boot" is not much to go > on. Understood. > Is this BIOS or UEFI? From any other Linux, what do you get for > 'parted -l u s p' or "fdisk -l" ? And what do you get for > 'efibootmgr -v' ? This is useful. I will try to document these results when I upgrade to F30, if the same happens again. The fdisk -l did show what I expected it to show: Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 4B21E327-DFE8-4105-AA9B-FEFF8AE8439F Device StartEnd Sectors Size Type /dev/sda1 20481026047 1024000 500M EFI System /dev/sda210260487317503 6291456 3G Microsoft basic data /dev/sda37317504 933572607 926255104 441.7G Linux filesystem /dev/sda4 933572608 1000214527 66641920 31.8G Linux swap Disk /dev/sdb: 477 GiB, 512110190592 bytes, 1000215216 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 9114D615-2FD0-4CF1-A601-DAD4507F6254 Device StartEnd Sectors Size Type /dev/sdb1 2048 411647409600 200M EFI System /dev/sdb2 4116482508799 2097152 1G Linux filesystem /dev/sdb3 2508800 1000214527 997705728 475.8G Linux LVM 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). (I was able to boot normally from Fedora immediately before doing the dnf system-upgrade. A reinstall was not accepted by dnf, so I used update instead.) > But the details you're giving only lead to speculation so you need > to provide specifics, just won't boot is identical to what happens > to a computer without a drive at all. Well, I will not be so fast to restore, if it occurs again (f30). Thank you for your suggestions. I am sorry for the assumptions I made. For what it's worth now: garry@vfr$ efibootmgr -v BootCurrent: 0002 Timeout: 1 seconds BootOrder: 0002,,0003,0004,0005,0006,0007,0008,0009 Boot ubuntuHD(1,GPT,3252a9ab-23eb-4fd4-9d11-6dc13c6f50ec, 0x800,0xfa000)/File(\EFI\ubuntu\shimx64.efi) Boot0002* FedoraHD(1,GPT,0534ef43-afb9-409c-8dc8-a1eff1e396ef, 0x800,0x64000)/File(\EFI\fedora\shim.efi) Boot0003* UEFI: SanDisk Extreme 0001PciRoot(0x0)/Pci(0x14,0x0)/ USB(17,0)/HD(1,MBR,0x3cb5dbe1,0x16960,0x2990)..BO Boot0004* Diskette DriveBBS(Floppy,Diskette Drive,0x0)..BO Boot0005* P0: SK hynix SC300 SATA 512GB BBS(HD,P0: SK hynix SC300 SATA 512GB ,0x0)..BO Boot0006* P2: INTEL SSDSC2KF512H6 SATA 5BBS(HD,P2: INTEL SSDSC2KF512H6
