Hi Chris,
Am 03.04.2016 um 21:42 schrieb Chris Murphy:
> You can delete Boot0019 through Boot0129. Use either 'efibootmgr -b
> XXXX -B'
Funny enough, the first delete failed due to lack of memory! So there
was some hard limit reached.
> or rm from efivars/ but I wouldn't try deleting 0000 through
> 0018.
Deleting a couple through `efivars` also got `efibootmgr -b XXXX -B`
back to work.
> Basically don't delete anything you don't know exactly what it
> does. But any boot entry that's pointing to shim.efi can be removed.
I deleted the kubuntu and all the fedora boot entries using a little
script that I just wrote to clean up entries.
> Next make sure you have a current shim.efi. I can't tell you if the
> Fedora shim package overwrites EFI/BOOT/ so I would just remove
> whatever is in there, and then 'dnf reinstall shim grub2-efi' and
> that'll repopulate both EFI/BOOT/ and EFI/fedora/ with the right
> things. While it shouldn't matter, you could top it all off with
> 'grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg' to get it back to a
> stock state.
Done all that.
> # sha256sum /boot/efi/EFI/BOOT/BOOTX64.EFI
> 475552c7476ad45e42344eee8b30d44c264d200ac2468428aa86fc8795fb6e34
> /boot/efi/EFI/BOOT/BOOTX64.EFI
This checksum matched before and after the process.
> What you should have now at reboot is a one time fallback to
> BOOT/BOOTX64.EFI which won't find a proper boot entry, and it'll
> create one and one only. And you won't even notice that happen
> probably.
The first time, there was some message there, but it was too quick to
read fully.
> So reboot a few times and check 'efibootmgr -v' to see if
> you start getting accumulating boot entries again or not.
Sadly, they keep accumulating. After the first boot I had 32 Fedora
entries, then a couple of rounds got me to 35 and now I am at 37.
> And if you haven't done it already make certain the firmware is up to date.
I tried to update the UEFI firmware using Windows (as UEFI does not boot
a 16-bit DOS from USB-Stick), but that was not the very latest version.
But still newer than the one that was previously installed.
All in all I can make changes in the UEFI again, they actually work and
the machine reboot. Then I dared to to a suspend-to-ram and the laptop
actually woke up. So thank you very, very much! Do you want a box of
beer or something? :-)
The core problem (accumulating boot entries) apparently persists, but I
can now use my script at startup as a workaround to clean up those
entries again.
What can I do to fix the core problem?
Regards
Martin
#!/usr/bin/python3
# -*- coding: utf-8 -*-
# Copyright © 2016 Martin Ueding <dev@xxxxxxxxxxxxxxxx>
import argparse
import re
import subprocess
PATTERN = re.compile(r'Boot([0-9A-F]{4})\*?\s+([^\t]+)\s(\S+)')
def main():
options = _parse_args()
lines = subprocess.check_output(['efibootmgr', '-v']).decode().split('\n')
entries = {}
for line in lines:
m = PATTERN.match(line)
if m:
number, kind, details = m.groups()
if kind not in entries:
entries[kind] = []
entries[kind].append(number)
for kind, numbers in sorted(entries.items()):
count = len(numbers)
print('{}, ({} {})'.format(kind, len(numbers), 'entry' if count == 1 else 'entries'))
print(sorted(numbers))
print()
if options.delete is not None:
to_delete = []
for name in options.delete:
if name in entries:
to_delete += entries[name]
print()
print('The following ones will be deleted:')
print(', '.join(sorted(to_delete)))
input('Confirm with enter â?¦')
for number in to_delete:
print('Deleting {} â?¦'.format(number))
subprocess.check_call(['efibootmgr', '-b', number, '-B'])
def _parse_args():
'''
Parses the command line arguments.
:return: Namespace with arguments.
:rtype: Namespace
'''
parser = argparse.ArgumentParser(description='')
parser.add_argument('--delete', nargs='*')
options = parser.parse_args()
return options
if __name__ == '__main__':
main()
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
