Re: Cannot Boot After Doing system-upgrade
On Sun, Oct 14, 2018, 01:35 Chris Murphy wrote: > 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. > 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@lists.fedoraproject.org > To unsubscribe send an email to test-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/test@lists.fedoraproject.org > ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@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
Re: Cannot Boot After Doing system-upgrade
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? >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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Re: Cannot Boot After Doing system-upgrade
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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Re: Cannot Boot After Doing system-upgrade
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? ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org