Bug 15681

Please attach your /root/drakx/report.bug.xz

Keywords: (none) => NEEDINFO
CC: (none) => thierry.vignaud

That doesn't seem to exist.
The only contents in /root are a file called non-chrooted-marker.DrakX and a tmp directory which is empty.
Is there a way to generate what you request or find it elsewhere?

Created attachment 6243 [details]
report.bug for failed EFI partition install

Ha, thanks to vlad on qa-discuss, I've run 'bug' from Ctrl_Alt_F2.  
Report.bug attached

The problem is that the EFI partition was not formatted.  I took the offered EFI size of 300Mb, manually gave it the mount point of /boot/EFI, but the installer did not format it.

I later did a manual format (FAT32) of the EFI partition and re-ran the install, which then worked normally with a bootable system.

The installer needs fixing so it knows how to and does format the only EFI partition newly created on bare metal.

I cannot reproduce: it worked when I tested the same as you (custom partitionning)
In your report.bug, one can see:
* setting toFormatUnsure for sda1 because <> ne <>

Which means fs_type wasn't set for this partition and it fails to read fs magic from partition.
As the partition existed before, this means the partition was unformatted before this installer session...
Is this really the report.bug from the original installer?
Note that previous ones are kept & renamed in /root/drakx (unless you formatted / of course)

Keywords: (none) => NEEDINFO

I don't think we want to support system when an ESP is there but not formatted.
That shouldn't exist in the wild (but for people having tested bogus installers previously).
I think you should just format your ESP or delete it.

Correcting a matter of fact, this was a bare-metal installation, at least last night - to the point I'd written zeros to the disk so there was definitely nothing there before.  The central point has been obscured - the EFI partition was only there because mageia installer just created it, but failed to format/use it.
Accordingly comments 5 & 6 above are perhaps out of the real context.

Actually, as I write this I realise this is not exactly true - I re-ran the install from scratch this morning, but didn't format /dev/sda2 (the root directory) again, to get quickly to the point where it crashed last night (i.e left all the files on the disk from last night).  Install crashed at same point with same message when grub2 wouldn't install during configuration.  Maybe report.bug looks slightly different in consequence; the install last night was the bare-metal, disk-zero'ed install, but this morning's grub2 install failure was identical to last night. This would explain your comment about ESP being there but not formatted - this is exactly the problem as last-night's original install run should not have crashed because it left the ESP in this unformatted state I believe.

The critical issue is if the installer has just created the EFI partition, it should format and use it.  To be style-consistent with the way it formats e.g. the just-created Ext4 and Swap partitions, this should not require the user to step aside and do this manually - the installer should do it, as it does Ext4 and Swap

There wasn't anything in root/drakx when I looked at the crash point - in fact /root/drakx did not exist.  Hence me running 'bug' from Ctrl_Alt_F2 to get report.bug.

I can install again onto a zero'ed disk if the original report.bug is required, although I'm sure I'll again find a created but unformatted EFS if its left to the installer.

Thanks for your contributions this,
Tonyb

Could you reproduce the from scratch install (aka zeroing the disks) then once you reach the error:
- plug a USB key
- run the "bug" command on tty2
- attach the new report.bug file you'll found on the USB key
  to this bug report

Tony,
Just to confirm that when you reach the partitioning screen and select custom, do you then click on the disk's empty space, then click the blue Windows button?

Doing that in a clean VM here instantly creates a 300MB ESP with mount point set, and the install completes faultlessly. (I'm using boot.iso not a DVD iso)

I'm just wondering if using a different approach to the partition creation is triggering this. Maybe not creating the ESP first, or selecting the filesystem type from a menu rather than using the 'windows' button.

CC: (none) => zen25000

I cannot recreate this bug. I erased the first two MB of /dev/sdc, then installed
using the April 9th x86_64-DVD, in uefi mode, on real hardware.

I selected custom partitioning, advanced mode, specified a 300MB efi system
partition, a swap, and a / partiton, all on sdc. I did not select format
for any of the partitions.

All partitions were correctly formatted, installation was normal, and
booting into the installed system works.

CC: (none) => davidwhodgins

Since nobody can reproduce and since I think that's a leftover from older installers, let's decrease priority

Priority: release_blocker => Normal
Severity: critical => normal

The work-around is to manually format the newly created EFI partition before proceeding.  I still think in the context the installer should do this, just as it does / and if need be the swap partition automatically.

Given the manual work-around works, I'll close this.

Status: NEW => RESOLVED
Resolution: (none) => FIXED
Whiteboard: RC version 8 => RC version 9

That should never happen in the real world :-)