Was your existing FAT32 partition an "EFI System partition"?
To check run:
gdisk /dev/sda   (or whatever _device_ you are using)
i
1 (partition number of proposed ESP)

Example:
gdisk /dev/sdf
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): i
Partition number (1-8): 1
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
Partition unique GUID: 58C33984-8D3E-4C0D-95F2-EAA0BEF69935
First sector: 2048 (at 1024.0 KiB)
Last sector: 614399 (at 300.0 MiB)
Partition size: 612352 sectors (299.0 MiB)
Attribute flags: 0000000000000000
Partition name: 'EFI System'

The installer will not recognize it as an ESP unless it has the GUID code for 'EFI System' as above.

CC: (none) => zen25000

will check tonight and advise.
however, system had just previously successfully installed from live in UEFI mode,
so I will use the " assumed to be correct " phrase.

And as usual, please attach your /root/drakx/report.bug.xz

(In reply to Barry Jackson from comment #1)
> To check run:
> gdisk /dev/sda   (or whatever _device_ you are using)

Just attach the output of "fdisk -l" instead of running gdisk (simpler and fdisk is always installed).
And your /root/drakx/report.bug.xz of course.

info as requested

 gdisk /dev/sdb
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): i
Partition number (1-8): 8
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
Partition unique GUID: A43E1D9D-E265-4D36-8A39-8DDDFF99A6E4
First sector: 311818240 (at 148.7 GiB)
Last sector: 312578047 (at 149.0 GiB)
Partition size: 759808 sectors (371.0 MiB)
Attribute flags: 0000000000000000
Partition name: ''

(In reply to Thierry Vignaud from comment #4)

> And your /root/drakx/report.bug.xz of course.

unfortunately I have since tested a non-uefi install.
will re-burn iso to disk and then attach /root/drakx/report.bug.xz

Created attachment 6254 [details]
as requested fdisk -l

I have reinstalled Mageia-5-RC-LiveDVD-KDE4-x86_64-DVD, again, /boot/EFI not presented in custom disk partitioning drop-down list

how do I create /report.bug.vx from the install?(In reply to Thierry Vignaud from comment #3)
> And as usual, please attach your /root/drakx/report.bug.xz

how do I create /report.bug.vx from the install?
sorry for asking.

It's already there, /root/drakx/report.bug.xz

The way I do it is:

su
cp /root/drakx/report.bug.xz /home/$USER/report.bug.xz
chown $USER:$USER /home/$USER/report.bug.xz
exit

Then attach it here from your home folder.

The Live's don't create one Ben, unless something changed recently, attach the journal instead.

# journalctl -a > /home/ben/bensjournal.txt
# chown ben:ben /home/ben/bensjournal.txt

You may have to do that from the live system which shows the error, not sure whether the live journal is transferred to the installed system.

any news on that bug ?

CC: (none) => ennael1

(In reply to Barry Jackson from comment #9)
> It's already there, /root/drakx/report.bug.xz
> 
in the installed and rebooted system this file does not exist.


(In reply to claire robinson from comment #11)
> You may have to do that from the live system which shows the error, not sure
> whether the live journal is transferred to the installed system.

in the installed and rebooted system this journal is unable to be found

[root@localhost ben]# journalctl -a /home/ben/benjournal.txt
Couldn't stat file: No such file or directory
Failed to add filters: No such file or directory
[root@localhost ben]# journalctl -a /home/ben/bensjournal.txt
Couldn't stat file: No such file or directory

I will attempt to find both in from the Live

(In reply to ben mcmonagle from comment #13)
> > It's already there, /root/drakx/report.bug.xz
> > 
> in the installed and rebooted system this file does not exist.

You must be root in order to access it...
 
> in the installed and rebooted system this journal is unable to be found
> 
> [root@localhost ben]# journalctl -a /home/ben/benjournal.txt
> Couldn't stat file: No such file or directory
> Failed to add filters: No such file or directory
> [root@localhost ben]# journalctl -a /home/ben/bensjournal.txt
> Couldn't stat file: No such file or directory

Please copy the commands given to you instead of retyping them with typos...

The '>' is important Ben, it redirects the output of the journalctl command into the file mentioned. On a live system, the live user is called 'live' (so /home/live/filename.txt) and root has no password, once installed it is whatever you have set it to.

(In reply to Anne Nicolas from comment #12)
> any news on that bug ?
It is a minor but persistant fault in the Live ISOs on EFI hardware, custom disc partitioning. When selecting the ESP -> Moint Point, the drop-down list of suggested mount points includes /boot, but *not* /boot/EFI - which *is* offered on the Classic ISO.
One can (must) easily specify the /boot/EFI manually.

Created attachment 6401 [details]
output of [root@localhost live]# journalctl -a > /home/live/bensjournal.txt

(In reply to claire robinson from comment #10)
> The Live's don't create one 

this is output from comment #9:

[live@localhost ~]$ su
[root@localhost live]# cp /root/drakx/report.bug.xz /home/live/report.bug.xz
cp: cannot stat â/root/drakx/report.bug.xzâ: No such file or directory
[root@localhost live]# cp /root/drakx/report.bug.xz /home/$USER/report.bug.xz
cp: cannot stat â/root/drakx/report.bug.xzâ: No such file or directory
[root@localhost live]# 

so you are correct Claire.

[root@localhost live]# journalctl -a > /home/live/bensjournal.txt- success
[root@localhost live]# chown live:live /home/live/bensjournal.txt.

I manually created entry /boot/EFI

tmb: "a missing line from drop-down list, but can be entered manually... so worst case an errata thing... If I have time I'll poke the drakx code"

Martin, would you have a look? According to tmb, the logic seems to be in place to add this entry, but it's not working as expected. (I'll see if I can locate the lines that need looked at).

CC: (none) => mageia

I found a reference to /boot/EFI here:
http://gitweb.mageia.org/software/drakx/tree/perl-install/fsedit.pm#n44

It looks like diskdrake also uses this procedure to some extent, so I wonder if the issue might not be:

    # only suggests /boot/EFI if there's not already one:
    return if !is_uefi() || grep { isESP($_) } @$fstab;

If the current disks already have an ESP, the creation of /boot/EFI won't be suggested to the automatic partitioning options, which is good, but maybe it also makes that the /boot/EFI mountpoint won't be proposed in the custom partitioner?

(In reply to Rémi Verschelde from comment #19)
> Martin, would you have a look? According to tmb, the logic seems to be in
> place to add this entry, but it's not working as expected. (I'll see if I
> can locate the lines that need looked at).

I'll take a look.

(In reply to Rémi Verschelde from comment #20)
> If the current disks already have an ESP, the creation of /boot/EFI won't be
> suggested to the automatic partitioning options, which is good, but maybe it
> also makes that the /boot/EFI mountpoint won't be proposed in the custom
> partitioner?

Yes, that's exactly what's happening, and as you suggest, I think it's required to make sure the automatic partitioning options don't create another ESP.

I suggest the best thing to do here is to automatically set the mount point for an existing ESP when the custom partitioning option is selected. But is there any good reason why the default mount points for Windows partitions shouldn't also be set (as is done by the classic installer)?

Created attachment 6588 [details]
proposed fix

If the answer to my last question is no, the attached patch fixes the problem for me.

Note that I have made it only apply to the live installer. If the classic installer is run in local install or testing mode, it will still not propose these mount points. I assume this was intentional.

First, thanks for the fix which answers the bug title.

Re Comment 22
> I suggest the best thing to do here is to automatically set the mount point
> for an existing ESP when the custom partitioning option is selected.
Agree entirely. We used to have to nominate Swap partitions which nowadays get done automatically; why not the same for an existing ESP?

As for Windows partitions, if mount points are proposed for them these need to be completely generic - without guessed drive letters. EFI boxes with Win8.1 have several related partitions whose usage is obscure.

Thierry, can you review Martin's patch and push it if it's good?

Keywords: (none) => PATCH
Assignee: bugsquad => thierry.vignaud
Source RPM: Mageia-5-RC-KDE4-LiveDVD-x86_64 => drakxtools

I'll note (before Thierry does ;-) ) that the method of detecting we're running in the Live installer is a bit ugly - but I wanted to change as little as possible this close to release.

Applied to my git tree.
We'll need to look at classic/live differences after mga5 is out (git blame will be needed)

commit 4525579cc2f70223c3b6ffe2c977621e081f4e08
Author: Martin Whitaker <mageia@...>
Date:   Mon May 25 05:35:19 2015 -0400

    fix not always suggesting /boot/ESP mount point
    
    thus fixing mga#15689 for live installs
    
    The check for whether an ESP needs to be created or not seems to prevent
    us to suggest a mount point for the existing one in some cases
    
    to be reviewed for mga6...
    
    diff --git a/perl-install/fs/partitioning_wizard.pm b/perl-install/fs/partitioning_wizard.pm
    index f3b9973..b222c07 100644
    --- a/perl-install/fs/partitioning_wizard.pm
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=4525579cc2f70223c3b6ffe2c977621e081f4e08

Closing

Status: NEW => RESOLVED
Resolution: (none) => FIXED