Bug 444127 - issue in partitions.py: can not reuse existed /boot/efi partition
issue in partitions.py: can not reuse existed /boot/efi partition
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
9
ia64 Linux
low Severity medium
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks: fedora-ia64 f9-ia64-blocker
  Show dependency treegraph
 
Reported: 2008-04-25 04:56 EDT by Zhan, Yi
Modified: 2017-04-11 09:55 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 14:15:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
fix the efi issue in partitions.py (755 bytes, patch)
2008-04-25 04:56 EDT, Zhan, Yi
no flags Details | Diff
patch to address the issue. (3.37 KB, patch)
2008-04-25 15:58 EDT, Peter Jones
no flags Details | Diff

  None (edit)
Description Zhan, Yi 2008-04-25 04:56:33 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):
anaconda-11.4.0.75-1

How reproducible:
Always

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Zhan, Yi 2008-04-25 04:56:33 EDT
Created attachment 303762 [details]
fix the efi issue in partitions.py
Comment 2 Jeremy Katz 2008-04-25 15:44:12 EDT
*** Bug 444203 has been marked as a duplicate of this bug. ***
Comment 3 Glen A. Foster 2008-04-25 15:48:08 EDT
Jeremy, I didn't re-use anything on my install; /dev/sdb was completely blank. 
Is this really the same bug, then?
Comment 4 Peter Jones 2008-04-25 15:51:40 EDT
Not sure it's actually the same problem; I'll un-dupe it and handle them separately.
Comment 5 Peter Jones 2008-04-25 15:58:28 EDT
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
expected results.
Comment 6 Zhan, Yi 2008-04-25 20:51:27 EDT
Hi Peter, 

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. 

Thanks, 
Yi
Comment 7 Zhan, Yi 2008-04-25 21:01:51 EDT
In a hurry, changed the flag in coincident, changing it back since I haven't
tested the patch. 
Comment 8 Zhan, Yi 2008-04-28 23:49:45 EDT
(In reply to comment #5)
> Created an attachment (id=303817) [edit]
> 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-11.4.0.77-1. So I just rebuild 
anaconda-11.4.0.77-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. 
Comment 9 Jeremy Katz 2008-05-01 21:24:00 EDT
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.
Comment 10 Bug Zapper 2008-05-14 06:08:35 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Doug Chapman 2008-05-20 16:25:09 EDT
Peter,

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
the release.
Comment 12 Chris Ward 2009-04-06 05:30:12 EDT
~Attention~

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!

More information:
https://fedoraproject.org/wiki/QA/Test_Days/2009-04-09
https://fedoraproject.org/wiki/Features/EFI
Comment 13 Bug Zapper 2009-06-09 20:26:05 EDT
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Bug Zapper 2009-07-14 14:15:38 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.