On Tue, May 7, 2019 at 8:11 AM Ranbir <m3freak@xxxxxxxxxxxxxxxxxx> wrote: > > On Mon, 2019-05-06 at 17:00 -0600, Chris Murphy wrote: > > > > I see two minor anomalies: > > > > /boot is XFS, should not be a problem. > > NVRAM contains dup entries, Boot0001 and Boot0008. > > > > Boot0001 is pointing to the new naming for shim, and it's also the > > default and current boot. Therefore, Boot0008 can be deleted. It's > > not > > causing the problem, so you can also just leave it alone. > > I had a hell of a time getting Windows 10 installed and then Fedora > working. Originally I was doing the Fedora install first, but > eventually I realized I was setting up the dual boot incorrectly. I > wiped the drives and started again with Windows 10 first. > > I have no idea how the dupe entries got there except maybe I didn't > wipe the drives correctly. > > > What's the URL you get for this command? > > $ sudo cat /boot/efi/EFI/fedora/grub.cfg | fpaste > > Empty. That is, I get back nothing. That is the likely reason why grubby spits back an error message. > > > And also this: > > > > $ mount | grep vfat > > https://paste.ofcode.org/JbTd7BHQ9aNAwtprsLBEee OK the EFI system partition is present and mounted rw. Is the grub.cfg even present? Maybe it's zero length? # ls -l /boot/efi/EFI/fedora/grub.cfg > > A faster way to get where I'm going, but will erase any evidence of > > why you're stuck, is to just create a new grub.cfg and then reinstall > > the kernel you want. > > > > $ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg > > I do want to just fix it, but I want to know what's going on more. :) If it's missing or zero length, is curious, but after we know that, it must be be fixed so you can run the grub2-mkconfig command now. > > > Also, question, have you recently run 'grub2-install' on this > > computer? Don't do it. I'm just wondering if you have done it, it > > could be related. > > No, I didn't do that. All I've done is the release upgrade from F28 to > F29 (no errors, no left over rpms) and then my first F29 update, which > caused the grub problem. Weird. I'm not sure what happened to the grub.cfg. You could dig through the journal and find the upgrade portion of the log and search for grub. You can use 'sudo journalctl list-boots' to help narrow down which boot is the offline boot in which the upgrade was performed, all of those boots are negative values so you use them like 'sudo journalctl -b -5' and then you could grep your suspects for grub and see if maybe something crashed or spat out an error during the upgrade. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-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/users@xxxxxxxxxxxxxxxxxxxxxxx
