12:39 p.m.
I recently did this on an up-to-date F28 system:
$ sudo dnf system-upgrade download --refresh \
--releasever=29 --allowerasing --best
$ sudo dnf system-upgrade reboot
Now system will not boot.
I had to boot from a live usb stick and do:
$ sudo su -
# vgdisplay
# vgchange -ay fedora
# mount /dev/fedora/root /mnt
# mount /dev/sdb2 /mnt/boot
# mount /dev/sdb1 /mnt/boot/efi
# mount --bind /proc /mnt/proc
# mount --bind /tmp /mnt/tmp
# chroot /mnt
# dnf --disablerepo=updates-testing upgrade grub2-efi shim
None of this was obvious to me at first. I got here only after a lot
of searching the Web for answers. It seems that grub2-install won't
work on my setup, even after disabling secure boot on this machine.
What am I doing wrong here that I cannot boot after a system-upgrade?
$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 7.8G 0 7.8G 0% /dev
tmpfs 7.8G 91M 7.7G 2% /dev/shm
tmpfs 7.8G 1.2M 7.8G 1% /run
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
/dev/mapper/fedora-root 50G 11G 36G 24% /
tmpfs 7.8G 64K 7.8G 1% /tmp
/dev/sdb2 976M 287M 623M 32% /boot
/dev/sdb1 200M 7.9M 192M 4% /boot/efi
/dev/mapper/fedora-home 412G 12G 379G 3% /home
tmpfs 1.6G 44K 1.6G 1% /run/user/1000
--
Garry T. Williams
2:12 p.m.
On 10/13/18 10:39 AM, Garry T. Williams wrote:
I recently did this on an up-to-date F28 system:
$ sudo dnf system-upgrade download --refresh \
--releasever=29 --allowerasing --best
$ sudo dnf system-upgrade reboot
Now system will not boot.
Some more details on what the problem is would help.
None of this was obvious to me at first. I got here only after a
lot
of searching the Web for answers. It seems that grub2-install won't
work on my setup, even after disabling secure boot on this machine.
grub2-install is only for non-EFI systems and shouldn't be used
otherwise. Nothing to do with secure boot.
What am I doing wrong here that I cannot boot after a system-upgrade?
"Doesn't boot" is no information. What exactly is happening?
2:30 p.m.
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. 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.)
The system-upgrade somehow wiped out my boot record on /dev/sdb.
--
Garry T. Williams
4:42 p.m.
On Sat, Oct 13, 2018 at 1:30 PM, Garry T. Williams <gtwilliams(a)gmail.com> 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?
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.
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' ?
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.
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.
--
Chris Murphy
5:44 p.m.
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(a)gmail.com> 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 Start End Sectors Size Type
/dev/sda1 2048 1026047 1024000 500M EFI System
/dev/sda2 1026048 7317503 6291456 3G Microsoft basic data
/dev/sda3 7317504 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 Start End Sectors Size Type
/dev/sdb1 2048 411647 409600 200M EFI System
/dev/sdb2 411648 2508799 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,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)
Boot0003* UEFI: SanDisk Extreme 0001 PciRoot(0x0)/Pci(0x14,0x0)/
USB(17,0)/HD(1,MBR,0x3cb5dbe1,0x16960,0x2990)..BO
Boot0004* Diskette Drive BBS(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 5 BBS(HD,P2: INTEL
SSDSC2KF512H6 SATA 5,0x0)..BO
Boot0007* USB Storage Device BBS(USB,SanDisk Extreme 0001,0x0)..BO
Boot0008* CD/DVD/CD-RW Drive BBS(CDROM,P1: PLDS DVD+/-RW DU-8A5LH
,0x0)..BO
Boot0009 Onboard NIC BBS(Network,IBA CL Slot 00FE v0106,0x0)..BO
Boot000B* P2: INTEL SSDSC2KF512H6 SATA 5 BBS(HD,P2: INTEL
SSDSC2KF512H6 SATA 5,0x0)..BO
garry@vfr$ sudo parted -l u s p
[sudo] password for garry:
Model: ATA SK hynix SC300 S (scsi)
Disk /dev/sda: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name
Flags
1 1049kB 525MB 524MB fat32 EFI system partition
boot, esp
2 525MB 3747MB 3221MB fat32 Basic data partition
msftdata
3 3747MB 478GB 474GB ext4
4 478GB 512GB 34.1GB linux-swap(v1)
swap
Model: ATA INTEL SSDSC2KF51 (scsi)
Disk /dev/sdb: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name
Flags
1 1049kB 211MB 210MB fat16 EFI System Partition
boot, esp
2 211MB 1285MB 1074MB ext4
3 1285MB 512GB 511GB lvm
Warning: The driver descriptor says the physical block size is 2048
bytes, but
Linux says it is 512 bytes.
Ignore/Cancel? i
Model: SanDisk Extreme (scsi)
Disk /dev/sdc: 251GB
Sector size (logical/physical): 2048B/512B
Partition Table: mac
Disk Flags:
Number Start End Size File system Name Flags
1 2048B 10.2kB 8192B Apple
2 47.4MB 52.8MB 5448kB EFI
3 52.8MB 64.8MB 12.0MB EFI
garry@vfr$
--
Garry T. Williams
6:30 p.m.
On Sat, Oct 13, 2018 at 4:44 PM, Garry T. Williams <gtwilliams(a)gmail.com> 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(a)gmail.com> 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
6:01 p.m.
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
6:34 p.m.
On Sat, Oct 13, 2018 at 5:01 PM, Garry T. Williams <gtwilliams(a)gmail.com> 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
6:57 p.m.
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
7:24 p.m.
On Sat, Oct 13, 2018 at 5:57 PM, Garry T. Williams <gtwilliams(a)gmail.com> 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
10:57 p.m.
On Sat, 2018-10-13 at 17:34 -0600, Chris Murphy wrote:
On Sat, Oct 13, 2018 at 5:01 PM, Garry T. Williams <
gtwilliams(a)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
3:12 a.m.
On Sun, Oct 14, 2018, 01:35 Chris Murphy <lists(a)colorremedies.com> wrote:
On Sat, Oct 13, 2018 at 5:01 PM, Garry T. Williams
<gtwilliams(a)gmail.com>
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.
This error happened to me too when I tried to upgrade to f29 about a week
ago. fedora boot item is still there, but fails silently, and boot falls
back to second item (Windows 10 in my case). Only reinstalling older
versions of grub2 and shim from f28 "fixed" it.
So the intermittently broken grub2/shim version theory seems plausible.
Upgrading to f29 results in a booting system now.
(Side note, fedora 29 continues to be unusable for me because of gdm/gnome
issues with the nvidia driver, and nouveau is ... not good on 1000 series
cards.)
Fabio
--
Chris Murphy
_______________________________________________
test mailing list -- test(a)lists.fedoraproject.org
To unsubscribe send an email to test-leave(a)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/test@lists.fedoraproject.org
2047
days inactive
2048
days old
11 comments
5 participants
participants (5)
-
Chris Murphy -
Fabio Valentini -
Garry T. Williams -
Jon Burgess -
Samuel Sieb