Red Hat Bugzilla – Bug 444127
issue in partitions.py: can not reuse existed /boot/efi partition
Last modified: 2017-04-11 09:55:23 EDT
Description of problem:
I saw this issue when installing from the fedora ia64 beta candidate image. I
was unable to reuse an existed vfat partition to be the /boot/efi. When I tried
to this, an error window popped up saying "You must create an EFI System
Partition of type FAT and a size of 50 megabytes.". And then I need to reformat
it as "efi" fs type every time reinstall (since the formatted file system would
be recognized as vfat as well next time). I think this is inconvenience for users.
The cause of the issue is below lines in partitions.py:
if (not bootreq) or bootreq.getActualSize(self, diskset) < 50 or \
bootreq.fstype != fsset.fileSystemTypeGet("efi"):
errors.append(_("You must create an EFI System Partition of "
"type FAT and a size of 50 megabytes."))
Changing it to let existed vfat fs pass could be a simple fix for the issue.
Patch is attached.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Created attachment 303762 [details]
fix the efi issue in partitions.py
*** Bug 444203 has been marked as a duplicate of this bug. ***
Jeremy, I didn't re-use anything on my install; /dev/sdb was completely blank.
Is this really the same bug, then?
Not sure it's actually the same problem; I'll un-dupe it and handle them separately.
Created attachment 303817 [details]
patch to address the issue.
Can you try it with this patch instead?
Also, what boot media are you using? We may need to modify it to get the
I will try your patch once I have chance to, probably on Monday since it's
Saturday morning here and I'm leaving for weekend soon.
I have just took a look about 444203. They are almost the same issue. Yes as
your suggest the "efi option works. What I concerned is that the partition we
want to use for /boot/efi, say sdb3 in Glen's case, need to be formated even if
it has been formated to vfat or even and I just want to leave its content
unchanged. So if we use the efi option for sdb3 this time (and format it), we
can get the install done. But next time we need to install again and use sdb3 as
/boot/efi, we need to format it to "efi" again. Since the sdb3 is still
recognized as vfat when install next time.
Forget to mention that, my try is a text mode install via nfs. Using initrd.img
and vmlinuz under pxeboot dir to boot. But the issue actually no install method
relative. I'm co-maintaining the ia64's rawhide tree with Doug, seems the issue
is existing on our tree for quite a while.
I have tested my previous patch by put it under RHupdates in the nfs dir and it
worked. And I also have done some basic investigation using pdb when the error
window popped up. The bootreq.getActualSize(self, diskset) is of course bigger
than 50M. And the bootreq.fstype is actually fileSystemTypes[vfat], and the
fsset.fileSystemTypeGet("efi") returns fileSystemTypes[efi]. They are 2
different slots in the fileSystemTypes array which defined in fsset.py. So they
do not equal and cause the error.append statement to be run.
So the fix might be either to let vfat pass the if condition tests or to
recognize the type of filesystem which is vfat and to be mounted to /boot/efi
and as efi without manually change its type and format.
In a hurry, changed the flag in coincident, changing it back since I haven't
tested the patch.
(In reply to comment #5)
> Created an attachment (id=303817) 
> patch to address the issue.
> Can you try it with this patch instead?
> Also, what boot media are you using? We may need to modify it to get the
> expected results.
Seems the patch has been committed into anaconda-126.96.36.199-1. So I just rebuild
anaconda-188.8.131.52-1 for ia64, use it to compose a new rawhide-tree from koji
and then install from the tree. Things are getting better now, if I need to
format the partition for /boot/efi, the default option is "efi" other than
"vfat". But the issue still exist since we still have to format it whatever.
Taking this off of the main F9Blocker -- this blocks ia64, but according to
Doug, that's going to be lagging by about a month anyway.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
As Yi mentioned in comment #8 this does not quite fix the issue. We still have
the problem that a user cannot re-use an existing efi partition without
re-formatting it as "efi".
Is there a down side to Yi patch suggestion which tells anaconda to allow either
"efi" or "vfat" as the partition type? I am not sure what the difference is
between the two, as far as I can tell "efi" is just another name for vfat (at
least on ia64). Is this somehow related to x86 efi systems?
We would like to be able to get this into the F9 branch of anaconda for our F9
final release. How can we make that happen? We would prefer not to try to use
the F10 rawhide anaconda and take in other unrelated changes at this point in
This bug appears to pertain to an important F11 feature, EFI, which the Fedora Community will be testing in an upcoming Fedora Test Day. Your participation in the action would be greatly appreciated!
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.