Something is updating on my Fedora 33 system and destroying my grub loader on a dual boot system. I have reinstalled a couple times and even tried Fedora 34. Fedora 34 won't install giving an error about not being able to update the /boot/efi directory. Fedora 33 at least starts the first time until the updates run. The first boot I get the grub menu. The second time after updates, I get a grub command line screen.
1. Automatic updates keep installing before I can troubleshoot. The first time I login, I disable and stop packagekit. But either it already sets automatic updates on next boot, or something else is running updates on next boot which is killing the grub menu.
2. I am assuming the grub loader is getting replaced when a kernel is updated. The original Fedora 33 kernel installed with the install media works. But after the updates, it does not work.
Any help on disabling the automatic updates and then troubleshooting the dual boot issue would be appreciated.
John
On 2021-05-09 2:14 p.m., John List wrote:
Something is updating on my Fedora 33 system and destroying my grub loader on a dual boot system. I have reinstalled a couple times and even tried Fedora 34. Fedora 34 won't install giving an error about not being able to update the /boot/efi directory. Fedora 33 at least starts the first time until the updates run. The first boot I get the grub menu. The second time after updates, I get a grub command line screen.
- Automatic updates keep installing before I can troubleshoot. The
first time I login, I disable and stop packagekit. But either it already sets automatic updates on next boot, or something else is running updates on next boot which is killing the grub menu.
- I am assuming the grub loader is getting replaced when a kernel is
updated. The original Fedora 33 kernel installed with the install media works. But after the updates, it does not work.
Any help on disabling the automatic updates and then troubleshooting the dual boot issue would be appreciated.
First quick check to do - Did you lock the boot sectors in the BIOS settings, preventing updates from occurring?
Secondly, run the SMART tests on your disk. Windows is extremely hard on your boot sectors and as a result those tend to be the most failed parts of the disk. More than a few manufacturers do not allow the boot sectors to be relocated by the disk firmware.
Third, run a memory test. I has a failing SSD, and the real problem was a bad stick of memory. Also, are you overclocking anything? Linux is decidedly less friendly to hardware faults caused by overclocking.
Lastly, on Dell, HP or Lenovo machines, do you have those stupid and buggy Intel remote admin capabilities enabled? There are several setting in that crud that can mess up your machine.
--
John Mellor
On Sun, May 9, 2021 at 2:36 PM John Mellor john.mellor@gmail.com wrote:
On 2021-05-09 2:14 p.m., John List wrote:
Something is updating on my Fedora 33 system and destroying my grub loader on a dual boot system. I have reinstalled a couple times and even tried Fedora 34. Fedora 34 won't install giving an error about not being able to update the /boot/efi directory. Fedora 33 at least starts the first time until the updates run. The first boot I get the grub menu. The second time after updates, I get a grub command line screen.
- Automatic updates keep installing before I can troubleshoot. The
first time I login, I disable and stop packagekit. But either it already sets automatic updates on next boot, or something else is running updates on next boot which is killing the grub menu.
- I am assuming the grub loader is getting replaced when a kernel is
updated. The original Fedora 33 kernel installed with the install media works. But after the updates, it does not work.
Any help on disabling the automatic updates and then troubleshooting the dual boot issue would be appreciated.
First quick check to do - Did you lock the boot sectors in the BIOS settings, preventing updates from occurring?
Secondly, run the SMART tests on your disk. Windows is extremely hard on your boot sectors and as a result those tend to be the most failed parts of the disk. More than a few manufacturers do not allow the boot sectors to be relocated by the disk firmware.
Third, run a memory test. I has a failing SSD, and the real problem was a bad stick of memory. Also, are you overclocking anything? Linux is decidedly less friendly to hardware faults caused by overclocking.
Lastly, on Dell, HP or Lenovo machines, do you have those stupid and buggy Intel remote admin capabilities enabled? There are several setting in that crud that can mess up your machine.
--
John Mellor _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Disabling and stopping packagekit in systemctl allowed me to update packages without the system doing it. I think if packagekit is updated, it may reenable in systemctl. I'm not positive about that.
I narrowed the packages I am having issues with down to grub2-*. It is updating to version 2.06. I installed all other updates on Fedora 33 and the system booted. Then I installed 11 grub2-* packages and the system booted into the grub command line menu.
Again this is a dual boot system that had windows 10 installed first. Fedora is reusing the /boot/efi partition that windows created. I don't think that it is an issue with the hard boot sector, boot sector being locked, or memory since when do a clean install of Fedora 33 from the install media, it boots normally. I have reinstalled about five times to isolate the issue.
John
A grub> prompt means GRUB wasn't able to find the grub.cfg.
1. On x86_64, reinstall the bootloader(s) by:
sudo dnf reinstall shim-* grub2-efi-* sudo grub2-mkconfig -o /etc/grub2-efi.cfg
* In no case should grub2-install be used on UEFI.
2. Check GRUB_ENABLE_BLSCFG=true is set in /etc/default/grub
3. grub2-mkconfig -o /etc/grub2-efi.cfg
* On Fedora 33 /etc/grub2-efi.cfg->/boot/efi/EFI/fedora/grub.cfg * On Fedora 34 /etc/grub2-efi.cfg->/boot/grub2/grub.cfg
4. On Fedora 34, there is a /boot/efi/EFI/fedora/grub.cfg but it's a simple four line file that merely forwards to the real one at /boot/grub2/grub.cfg. In case this stub file was accidentally stepped on by using grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg it can be fixed by:
sudo dnf reinstall grub2-common
This reruns the f33->f34 upgrade script that will move /boot/efi/EFI/fedora/grub.cfg to /boot/grub2/grub.cfg, and then create the proper forwarding /boot/efi/EFI/fedora/grub.cfg stub file.
5. Another possible source of difficulty is the bootorder and boot entry stored in NVRAM. The bootorder should have the boot number for the Fedora entry first in the list. And the Fedora entry should point to the EFI system partition and path to shimx64.efi or shim.efi.
Boot order can be reset by:
efibootmgr --bootorder $xxxx
Where $xxxx is the four digit boot number for the Fedora boot entry. No other entries need to be specified but you could optionally add a fallback entry, e.g. --bootorder 0006,0002
-- Chris Murphy
-
Chris Murphy -
John List -
John Mellor