Description of problem: After successful installations from the new iso on older hardware the IntelNUC10 i7 system fails to proceed beyond bringing up the network. The same machine supports mageia8 systems without any problem which is why a bug is justified. The faulty boot freezes the machine - no access to consoles for instance so diagnostics are not available. The new bootloader lists the mageia9 system. Mounted the new partition and examined /boot/ All appears to be OK, with proper references to mageia9 and a long list of kernel modules. It is also worth noting that unlike in the case of mageia8 the alpha1 distribution baulks at installing the bootloader until the boot/EFI option is changed to EFI/BOOT/ - this applies to all hardware AFAICS. These mini-computers are becoming more popular so it is worth getting this right. Version-Release number of selected component (if applicable): Mageia9-apha1 How reproducible: Every time on the IntelNUC10 mini computer. Steps to Reproduce: 1. Plug in the 64-bit alpha1 iso. 2. Run the installer to completion. 3. Reboot after selecting the new system from the grub2 menu.
An addendum to the report: this issue affects upgrades as well.
> These mini-computers are becoming more popular > the IntelNUC10 i7 system fails Well, I have no such problem with an XDO cube, although mine has according to its leaflet 'Intel Gemini Lake J4125'; according to MCC Hardware info, Celeron. I doubt the processor matters. My own cube Cauldron system was born from an M8 Classic install, upgraded. > baulks at installing the bootloader until the boot/EFI option > is changed to EFI/BOOT/ This looks very strange (= wrong): boot/EFI (or boot/efi/) is the mount point under '/' for the ESP. EFI/ is what lies beyond, at the root of the ESP: /boot/efi/EFI/ [Unsure whether case matters, the ESP is FAT16]. Are you able to post the O/P (say from a live ISO) of: # fdisk -l /dev/sd... OR # gdisk -l /dev/sd... for the 'disk' in question (do not know how it will be seen by the a live system). > Mounted the new partition and examined /boot/ All appears to be OK Thus you can post the O/P of: $ sudo tree /boot/efi/EFI/ which with Grub alone should be quite small, something like: /boot/efi/EFI/ ├── Boot │ ├── bootx64.efi ├── mageia │ └── grubx64.efi Thought: Is the failing Mageia installation the only one on the 'disc'?
CC: (none) => lewyssmith
No, not the only system partition on the disk. There are three mga8 installations which were and are trouble free. Note that there was no need to configure the bootloader. The EFI/BOOT trick during configuration was the only way to get past the "EFI variables are not supported on this system" issue. It was recommended by Ben. This is something that has never happened in any of hundreds of earlier installations. The alpha1 system has been overwritten by mageia8 but I did mount the bad installation at one point and used tree to examine efi/BOOT but did not record anything unfortunately. This is how it looks now from system /dev/sda5: /boot/efi/EFI └── EFI ├── BOOT │ ├── BOOTX64.EFI │ ├── fbx64.efi │ └── mmx64.efi ├── mageia │ └── grubx64.efi └── ubuntu ....... The Ubuntu system is long gone. The IntelNUC machine is the fileserver for the network so it will not be used for any more testing until the alpha2 isos come along. There appears to be a problem with the kernel.
Another attempt to install on the Asus PN51 IntelNUC11 system succeeded albeit with various errors which need separate bugs. This bug should address the business of having to change the boot mount to EFI/BOOT in order to complete the installation.
Good progress. First, re-aligning the bug as you suggest: "the boot/EFI option is changed to EFI/BOOT/" Can you say exactly where this specific option is cited? Bootloader configuration? CC'ing Ben for his confirmation, as he discovered this necessary frig. Assigning to Tools for that. ------------------------------------------------------------------------------ Re the booting problem you started with, I smell a rat! > There are three mga8 installations which were and are trouble free > there was no need to configure the bootloader > alpha1 system has been overwritten by mageia8 Multiple instances of the same distribution are iffy using Grub[2]. See the Wiki about UEFI. The ESP I suggested at the end of comment 2 is included in your example comment 3 (and shown identical to mine in another of your bugs). Note there is only *one* ├── mageia │ └── grubx64.efi for *all* the installed Mageias. And just one corresponding NVRAM Mageia entry. Look with: # efibootmgr It is (I think) the most recent update/configure Grub that is there, leading to its host system's Grub boot menu, which will show all the others from which you have to chose; default itself. I suspect there was a twisted knickers situation where Grub did not load the system it was configured for, an inconsistency; possibly due to 'not configuraing the bootloader' once. Or some partial Grub update which did not update the ESP Mageia bootloader. This sort of situation would not arise in a normal user one-Mageia system. But multiple Mageias work as I said (and believe, but may be wrong) so long as Grub is updated - from any of the systems - when needed. That system then gets booted, and its Grub boot menu offers the others. The best way out of this, miles easier, is to use rEFInd. Which you can install on top of Grub to no advantage but no harm. rEFInd needs no configuration (it does have a file, but can live without it), and simply offers what it finds in NVRAM & ESP, and systems installed on the disc. It *must* be the bootloader used by the EFI system. This normally happens naturally on decent boxes, but may have to be forced using efibootmgr and/or fiddling the default bootloader in the ESP. See the 'About UEFI' Wiki. We really must make rEFInd normal/default for suitable systems. Grub is totally irrelevant where rEFInd can be used. Oh, to clean out Ubuntu etc references, as root: - use efibootmgr to remove their NVRAM entry ( -b xxxx -B ) - delete the relevant directory from /boot/efi/EFI/
Summary: mageia9-alpha1: newly installed system on IntelNUC10 fails to boot although mga8 partitions do boot. => mageia9-alpha1: "EFI variables are not supported on this system" during installation needs 'boot/EFI' option changed to 'EFI/BOOT/' to completeCC: (none) => westelAssignee: bugsquad => mageiatools
seems to be resolved for i586 UEFI install. will check x86_64 sometime later :)
(In reply to Lewis Smith from comment #5) > Good progress. > First, re-aligning the bug as you suggest: > "the boot/EFI option is changed to EFI/BOOT/" > Can you say exactly where this specific option is cited? Bootloader > configuration? 2nd page of bootloader configuration page. check box under *probe for foreign OSes* > CC'ing Ben for his confirmation, as he discovered this necessary frig. thanks
In reply to Lewis Smith from comment #5 : > Multiple instances of the same distribution are iffy using Grub[2]. > See the Wiki about UEFI. It is the only safe way to work if you want at least one fallback partition when testing isos. I gave up on rollbacks long ago. Could not get them to work - more trouble than they are worth. Thanks for the efibootmgr tip.
The second round of Mageia9-alpha1 solves this bug. Default configuration for bootloader works fine.
Status: NEW => RESOLVEDResolution: (none) => FIXED