Bug 742141

Summary: previous efibootmgr deletion step erroneously assumes the existing entry will always be identifiable as a single digit
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: anacondaAssignee: Brian Lane <bcl>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: anaconda-maint-list, fabian.deutsch, jonathan, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: anaconda-16.21-1.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-13 04:38:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Should fix this bug.
none
Rebased onto anaconda-16.20-1
none
log of successfull install none

Description Adam Williamson 2011-09-29 08:34:35 UTC
anaconda currently does this when trying to identify any existing Fedora efibootmgr entry and delete it, while doing a scratch EFI install (pyanaconda/bootloader.py):

---------

            if _product == productName:
                slot_id = slot[4:8]
                if not slot_id.isdigit():
                    log.warning("failed to parse efi boot slot (%s)" % slot)
                    continue

-----------

this is rather fragile. fabiand, our trusty EFI tester, has a pretty stuffed EFI bootloader, and his Fedora entry wound up as Boot000A, and he got:

10:00:50,584 WARN storage: failed to parse efi boot slot (Boot000A*)

further logs:

10:00:50,398 INFO program: Running... efibootmgr
10:00:50,577 INFO program: BootCurrent: 0008
10:00:50,578 INFO program: Timeout: 0 seconds
10:00:50,578 INFO program: BootOrder: 000A,0008,0007,0005,0006,0009
10:00:50,579 INFO program: Boot0000 Setup
10:00:50,579 INFO program: Boot0001 Boot Menu
10:00:50,580 INFO program: Boot0002 Diagnostic Splash Screen
10:00:50,580 INFO program: Boot0003 Rescue and Recovery
10:00:50,581 INFO program: Boot0004 Startup Interrupt Menu
10:00:50,581 INFO program: Boot0005* USB CD
10:00:50,581 INFO program: Boot0006* USB FDD
10:00:50,582 INFO program: Boot0007* ATA HDD0
10:00:50,582 INFO program: Boot0008* USB HDD
10:00:50,583 INFO program: Boot0009 PCI LAN
10:00:50,583 INFO program: Boot000A* Fedora
10:00:50,602 INFO program: Running... efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \EFI\redhat\grub.efi
10:00:50,692 ERR program: ** Warning ** : Boot000A has same label Fedora

so because of the 'failed to parse' it didn't remove the previous entry, tried to create a new one with the same label. Can't tell from there whether it actually created two, whether that works, or what, but this is clearly wrong.

The entry is at least going to be a *hex* digit (it looks like 'isdigit' doesn't cope with hex). I guess, if the bootloader is *really* stuffed, it could wind up as 10, or 1A, or FF...

Comment 1 Fabian Deutsch 2011-09-29 08:54:27 UTC
Created attachment 525488 [details]
Should fix this bug.

Matches a hex using regex.

Comment 2 Adam Williamson 2011-09-29 09:07:15 UTC
i guess that doesn't cover the >16 entries case (where it would roll over to two digits), but it should be better than at present.

Comment 3 Fabian Deutsch 2011-09-29 10:12:02 UTC
There was some irrittation if this patch also handles cases with more than 16 entries and if more than two chars/digits are passed to efibootmgr, and I can say: yes.

The line with slot = "Boot000A*"

                slot_id = slot[4:8]

extracts the chars 000A (using the slicing operator ':').
These four chars are the passed to efibootmgr

                rc = self.efibootmgr("-b", slot_id, "-B",
                                     root=ROOT_PATH,
                                     stdout="/dev/tty5", stderr="/dev/tty5")

So there is no room for ambiquity - as long as the format of the entries doesn't change. I just want to point out that anaconda already is using four digits (https://bugzilla.redhat.com/show_bug.cgi?id=741781#c5).

Comment 4 Fabian Deutsch 2011-09-30 14:53:47 UTC
Created attachment 525785 [details]
Rebased onto anaconda-16.20-1

This patch was tested with
  grub from here http://koji.fedoraproject.org/koji/buildinfo?buildID=265904 
and
  a custom updates.img (scripts/makeupdates -c -t anaconda-16.20-1)

the installation went fine, a previous entry was successfully removed and a new one created.

Comment 5 Fabian Deutsch 2011-09-30 15:14:13 UTC
Created attachment 525788 [details]
log of successfull install

Comment 6 Fedora Update System 2011-10-11 18:35:31 UTC
anaconda-16.21-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/anaconda-16.21-1.fc16

Comment 7 Fedora Update System 2011-10-13 04:38:09 UTC
anaconda-16.21-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.