Description of problem: After a windows upgrade (on a double boot machine), the grub has been lost, as it is usual. Booted from net install mga7, chose "Re-install Boot Loader", which performed its stuff until it finds the mga7 partition, and asks me to press enter to confirm. After confirmation, it runs /boot/grub2/install.sh with root /mnt, then following error occurs: grub2-install failed: () Error: (Installing for x86_64-efi platform. grub2-install: error: cannot find EFI directory. ) Version-Release number of selected component (if applicable): mga7 How reproducible: always Steps to Reproduce: 1. see above How I fixed this: Go to console cd /mnt/boot inside, the are 2 "efi" directories : "EFI" and "efi" * EFI is /dev/sda1, the EFI partition * efi is a directory, containing a EFI directory, itself being empty solution: Rm -Rf efi && ln -s EFI efi exit then again the first menu entry: "Re-install Boot Loader" and voilà! (must be a bug because /boot being case sensitive there are 2 folders, efi and EFI inside...)
PS: thanks to #mageia-fr (jeeebz, neoclust and pterjan :) who helped a lot :)
I will come back on this tomorrow, too much to say now.
CC: (none) => lewyssmith
Look at: https://wiki.mageia.org/en/About_EFI_UEFI Now running my M7 system, which has Grub2-efi + Windows 8 + rEFInd, whose presence I hide below because it clouds the picture. There seem to me two possible reasons for this bug: 1) On Mageia 7 (see below), the path to the ESP and below is: /boot/EFI/EFI/... ^ Boundary between root and mounted ESP This /boot/EFI/ was a Mageia special; everybody else used /boot/efi/ . On Mageia 8, to bridge this difference, we now have both: /boot/efi linked to /boot/EFI/ which is exactly what you created. Why was this necessary? Not for you to answer ! How did you ever come to have also (all in the root partition): /boot/efi/EFI/ [empty] which seems to have upset grub-install. 2) 'grub2-install' as invoked by the net-installer looks explicitly for /boot/efi/EFI/... which is OK for M8 but not M7 as-is. ---------- On my M7 system (for all the examples that follow): $ ls -l /boot | grep -i efi/ drwxrwxrwx 3 root root 4096 Ion 1 1970 EFI/ No /boot/efi/. On my M8 system, this shows both /boot/EFI/ & /boot/efi/. $ sudo tree /boot/EFI/ /boot/EFI/ ├── EFI │ ├── Boot │ │ ├── bootx64.efi ... │ ├── mageia │ │ └── grubx64.efi │ ├── Microsoft │ │ └── Boot ... │ │ ├── bootmgfw.efi │ │ ├── bootmgr.efi ... To understand these, see the Wiki. A lot depends on how honest your EFI firmware is, whether it homes in on Windows or follows the rules for NVRAM:- $ sudo efibootmgr BootCurrent: 0002 Timeout: 5 seconds BootOrder: 0002,0003,0006,0009,0004,0005,0001,0006,0000 Boot0000 mageia ... Boot0002* UEFI: ST1000DM003-9YN162 [I think this is the 'disc' default] Boot0003* Windows Boot Manager ... [On my box, BootOrder seems to be ignored!] When you do a Windows update, it will not destroy other bootloaders. You can look at the ESP from a Windows Administrator console. You need to be able to see exact sizes for all the .efi files shown above to see any similarities between them; particularly whether \EFI\Boot\bootx64.efi is a copy of one of the others. Windows may simply fiddle the NVRAM to put itself first in BootOrder, which in your case seems to be heeded by the EFI system. If this is all, it needs just # efibootmgr to put Mageia first (OK, but how?). Alternatively, if your box always boots from the default bootloader (it should not): \EFI\Boot\bootx64.efi Windows may overwrite that with one of its own. In this case, back up (copy) the original first, you need to replace it with the Mageia one \EFI\magiea\grubx64.efi . --- Coincidentally, my Mageia 7 system has just stopped booting from its ESP entry, so I shall try 'grub-install'. [rEFInd saves my day here, you can forget Grub2].
Before losing this: $ sudo grub2-install --target=x86_64-efi --efi-directory=/boot/EFI --bootloader-id=mageia Installing for x86_64-efi platform. Installation finished. No error reported.
I should have added: $ sudo ls -l /boot/EFI/EFI/mageia/ -rwxrwxrwx 1 root root 123904 Chw 8 11:51 grubx64.efi which shows that it wrote a new mageia/grubx64.efi and $ sudo efibootmgr BootCurrent: 0002 BootOrder: 0000,0002,0003,0006,0009,0004,0005,0001,0006 Boot0000* mageia Boot0002* UEFI: ST1000DM003-9YN162 Boot0003* Windows Boot Manager which shows it put mageia at the start of the list (& active). Now to re-boot.
Before doing so, I tried re-creating comment 0: $ sudo mkdir -p /boot/efi/EFI $ ls /boot/efi/EFI/ $ $ sudo grub2-install --target=x86_64-efi --efi-directory=/boot/efi/EFI --bootloader-id=mageia Installing for x86_64-efi platform. grub2-install: error: /boot/efi/EFI doesn't look like an EFI partition. which is not exactly the same original error message. Sigh.
@Jean-Christophe I discovered [/mnt]/boot/grub2/install.sh which does nothing but call 'grub2-install' with no parameters. My concern is how the Rescue system is calling it. Can you try this again exactly as per your original config? It is quicker than it looks; failures will not do anything. Ainsi... 1. Make sure with '$ mount' that the ESP is mounted on /boot/EFI 2. UNlink (rmdir) /boot/efi from /boot/EFI This should leave only /boot/EFI/, on which is mounted the ESP - the standard M7 setup. 3. $ sudo grub2-install What happens? 4. Re-create the mystery directory /boot/efi/EFI (in the root partition) 5. $ sudo grub2-install What happens? This is to try & ascertain what is due to the extra directoy. And whether grub2-install actually needs parameters (I gave it some). 6. Re-try from the boot ISO you used, Rescue Mode - Re-install Bootloader which should produce the fault you describe - and no harm done. Is the result the same as one of the two 'grub2-install' above? 7. Remove the spurious directory /boot/efi/EFI 8. Only if step 3 failed, re-make the link /boot/efi from /boot/EFI; if this *is* necessary, something is wrong. [I am back in M8, I should have done this myself before; sorry]. > (must be a bug because /boot being case sensitive there are 2 folders, > efi and EFI inside...) Still remains to discover from where.
@Jean-Christophe Good, I have got back here before you; you do NOT need to do any of the tests I asked of you. I have researched this bug more rationally. In short, the problem is due to that extra superfluous directory you had, /boot/efi/EFI . Without that, NO need for the symbolic link to provide both /boot/EFI (the norm) and /boot/efi ; grub2-install works with just /boot/EFI[/EFI etc]. The ESP mounted on /boot/EFI: 1. From the installed M7 system 1a) With *both* /boot/EFI/EFI/ & /boot/efi/EFI/ : # grub2-install installing for x86_64-efi platform [always shown, will not repeat] grub2-install: error: cannot find EFI directory [the exact bug] 1b) NO extra /boot/efi/EFI/, just /boot/EFI[/EFI/ : # grub2-install Installation finished. No error reported 2. From the Rescue system, Re-install bootloader, choosing (type) "grub2": 2a) With *both* /boot/EFI/EFI/ & /boot/efi/EFI/ : grub2-install failed Error: <Installing for... grub2-install: error: cannot find EFI directory> [the exact bug] grub2-install failed: Installing for... grub2-install: error: cannot find EFI directory [the exact bug] 2b) NO extra /boot/efi/EFI/, just /boot/EFI[/EFI/ : running: sh /boot/grub2/install.sh with root /mnt [NO output] All of which demonstrates that the problem lies with grub2-install, NOT the Rescue - Re-install bootloader. I checked that the system booted successfully from the grub2-installs: - the EFI boot menu 'mageia' entry -> the 'mageia' ESP bootloader - via rEFInd choosing the 'mageia' ESP bootloader This obscure bug is almost certainly upstream; I have raised a bug report (URL). --------------------------------------------------------------- Which leaves the problem of how did /boot/efi/EFI ever appear?
Summary: rescue (from net-install) fails to restore the boot loader => grub2-install (EFI) fails "cannot find EFI directory" if a spurious extra /boot/efi/EFI directory exists (ESP mounted on /boot/EFI/)Keywords: (none) => UPSTREAMSource RPM: (none) => grub2-2.02.0-15.mga7.src.rpmURL: (none) => https://savannah.gnu.org/bugs/index.php?60028
Hi Lewis Thanks for the explanation. If this helps on another BIOS machine I also have this folder created: [fred@localhost ~]$ sudo ls -l /boot/efi/EFI/mageia total 76 drwxr-xr-x 2 root root 4096 oct. 20 2018 fw -rwxr-xr-x 1 root root 69936 oct. 20 2018 fwupx64.efi I'm not using EFI on this machine, it seems it comes from the package fwupdate-efi-9-5.mga7. On the other machine, the one concerned by this bug, is it possible that these folders /boot/efi/EFI had been created by a package, removed later? confirmed: after removing this package, it leaves something behind: [fred@localhost ~]$ sudo ls -l /boot/efi/EFI total 0 Exactly the same thing that on the affected machine. Anyway, this should not make crash grub2-install... We will see how the upstream reacts, will you update here?
(In reply to Jean-Christophe Cardot from comment #9) > If this helps on another BIOS machine I also have this folder created: > [fred@localhost ~]$ sudo ls -l /boot/efi/EFI/mageia > total 76 > drwxr-xr-x 2 root root 4096 oct. 20 2018 fw > -rwxr-xr-x 1 root root 69936 oct. 20 2018 fwupx64.efi > I'm not using EFI on this machine, it seems it comes from the package > fwupdate-efi-9-5.mga7. You are right, I had already found that. In a Mageia 7 context, this is wrong - but would be OK for Mageia 8. Why it should be created at all on a BIOS/MBR machine is curious. Everything to do with fwupdate* is about UEFI. > Anyway, this should not make crash grub2-install... We will see how the > upstream reacts, will you update here? This bit is in their camp. Assigning this bug now for fwupdate-efi re /boot/efi/EFI . Even though /boot/EFI/EFI/ looks legitimate on an EFI box, the last \EFI bit should already exist on the ESP unless that is being created for the first time.
Source RPM: grub2-2.02.0-15.mga7.src.rpm => fwupdate-9-5.mga7.src.rpmSummary: grub2-install (EFI) fails "cannot find EFI directory" if a spurious extra /boot/efi/EFI directory exists (ESP mounted on /boot/EFI/) => grub2-install (EFI) fails "cannot find EFI directory" if a spurious extra /boot/efi/EFI directory exists (from fwupdate-efi) (ESP mounted on /boot/EFI/)Assignee: bugsquad => pkg-bugs
Hi bug reporter and hi assignee and others involved, Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly. This report is being closed as OLD because it was filed against Mageia 7, for which support ended on June 30th 2021. Thanks, Marja
Resolution: (none) => OLDStatus: NEW => RESOLVED