This looks like a critical issue in late RC8: hope I'm not duplicating report. Description of problem: > Following on from my recent comment that the installer could not format the EFI partition from clicking on 'format' at custom disk partitioning, I selected a root mountpoint and allowed install to proceed. At the end of install, it failed: > > "An error occurred. > grub2-install failed: installing for x86_64-efi platform. > grub2-install: error: cannot find EFI directory. > ... propagated" > > I had manually selected the mount point of /boot/EFI for the EFI partition. (As an aside, I also note in passing that I'd previously reported the installer incorrectly advising /boot/efi for this partition's mount point, when /boot/EFI was required. On this occasion RC8 actually had 'swap' as the suggestion when I went to manually assign the swap point. A regression?) > > Did the grub2-efi install fail because it hadn't formatted the partition? I'll investigate. > > My recent uneventful installs had been with preserving an existing EFI partition. This install started with an entirely blank disk. > Seems critical to me? > Is this covered by existing bug reports? > Tonyb Booted the install disk in rescue mode. Made /mnt "mount /dev/sda1 /mnt" fails I suspect sda1 was never formatted and had no files written to it, in this apparently routine install? Tonyb Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
Whiteboard: (none) => RC version 8
Please attach your /root/drakx/report.bug.xz
Keywords: (none) => NEEDINFOCC: (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.
Priority: Normal => release_blocker
Keywords: NEEDINFO => (none)CC: (none) => eeeemail, ennael1, tmb
Summary: critical EFI partition failure => newly created ESP wasn't formated
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
CC: (none) => rverschelde
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
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=15690
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 => NormalSeverity: 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 => RESOLVEDResolution: (none) => FIXEDWhiteboard: RC version 8 => RC version 9
That should never happen in the real world :-)