Description of problem: Using the Nonfree Netinstall ISO to install Cauldron Plasma while retaining /home of a Mageia 9 install, all seems to proceed normally until it attemps to install grub2. This message appears, with an "OK" button in the corner: grub2-install error: /usr/lib/grub/i386-ieee1275/modinfo.sh doesn't exist. Please specify --target or --directory. ...propagated. Clicking on the OK sends me back to the point just before grub2 is to be installed, and the loop takes another round. Hardware is an HP Probook 6550b, i3-M350, Intel graphics, non-EFI BIOS. There are three installs on this hardware, two Mageia 9 and (now) one Cauldron. The main production install is still Mageia 9. I shut down the machine with the power button, and rebooted, going to the production install, and ran update-grub. That detected the Cauldron install, and I was then able to boot into that and continue on.
Adding the 10alpha1 keyword, because if I remember correctly the netinstall uses virtually the same installer as the Classical isos
Keywords: (none) => 10alpha1
Summary: Grub2 install fails when using Nonfree Netinstall iso for a Plasma guest => Grub2 install fails when using Nonfree Netinstall iso for a Plasma install
As I get the same with Classic installer Iso 64bit installing LxQt I edit the title
Summary: Grub2 install fails when using Nonfree Netinstall iso for a Plasma install => Grub2 install fails when using Classic Installer isosCC: (none) => j.alberto.vc
As requested in the qa list This system can make efi boot, but I choose to use the legacy boot mode What is weird is in VM all goes well :S
This is similar to bug 34563 and bug 34541. The root cause for those cases was fixed, but it seems that GRUB still mis-identifies the system type on some hardware.
CC: (none) => mageia
Can someone affected by this bug boot from a live ISO and see if "/proc/device-tree" exists. Also confirm that the GRUB error message starts with grub2-install error: /usr/lib/grub/i386-ieee1275/modinfo.sh doesn't exist as there can be many other reasons for grub2-install to fail.
If you mean the /proc of the live system, no. I see a 'devices' in that directory, but not 'device-tree'. The /proc of the installed Cauldron appears to be empty. As for the error message, I quoted mine in comment 0, and it was about the same as the one in comment 5.
Thanks TJ. Sorry not to have been more clear - the request to confirm the error message was intended for katnatek and anyone else commenting on this bug. Just to be sure, what's the date on the netinstall ISO image you used?
The image itself is rather old, July 8, 2025, using kernel 6.12.36-desktop-1.mga10. I wanted to see if the problem with downloading a mirror list had "fixed itself" and it had. That was December 11, same day I filed this bug. But it is my misunderstanding that the actual installer is downloaded from the mirror(Princeton this time) at the time of install. So, wouldn't the date of the iso be irrelevant as long as it's a Cauldron iso for the current Cauldron (Mageia 10 this time)?
(In reply to Thomas Andrews from comment #8) > But it is my misunderstanding that the actual installer is downloaded from > the mirror(Princeton this time) at the time of install. So, wouldn't the > date of the iso be irrelevant as long as it's a Cauldron iso for the current > Cauldron (Mageia 10 this time)? In most cases yes. But the Linux kernel and drivers are loaded from the ISO image and persist even after the main installer is running. bug 34563 was caused by a mis-configuration of the kernel. If you are using an old ISO image, it won't have the fixed kernel.
Hmmm. Live and learn. I will download the latest available from the Mageia website and try again. If that isn't the latest, then perhaps the website needs an update...
Looks like we have a bigger issue. The December 13 nonfree netinstall won't boot on my Probook 6550b except in text mode. I went back and downloaded again,checked with md5, dumped it to the usb stick with Isodumper. No difference. I'll file another bug on that in a few minutes, once I get a chance to check the other isos, as well. In the meantime, I'm doing a new install on the Probook in text mode. Navigating is definitely more annoying than the normal mode, but I'm working it out. Packages installing now - 54% complete.
It was very painful to navigate the configuration page in text mode, but eventually I got through it. Grub2 was installed with no issues.
I just installed Plasma from the 64-bit CI iso on this hardware, and saw no grub2 errors.
(In reply to Martin Whitaker from comment #5) > Can someone affected by this bug boot from a live ISO and see if > "/proc/device-tree" exists. Also confirm that the GRUB error message starts > with > > grub2-install error: /usr/lib/grub/i386-ieee1275/modinfo.sh doesn't exist > > as there can be many other reasons for grub2-install to fail. <Note>From the 10alhpa1 CI, but note that I installed in EFI mode on _unreliable_ _hardware_ and that both using ReFind as bootloader and using Grub on the next attempt failed. Booting the CI in legacy mode only gave the grub menu of the iso, but after selecting to install I got a colorful screen full of artifacts, and there it stopped. However, booting from another legacy installation with grub succeeds, so omitting the EFI directory:<!Note> # LC_ALL=C grub2-install /dev/sda grub2-install: error: /usr/lib/grub/i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory. So slightly different error. I haven't yet tested a Live iso. I'm reluctant to report (10alpha1) bugs because of this unstable hardware (it was just as unstable using Windows, so nothing to do with Mageia). I'll download and test a Live.
CC: (none) => marja11
(Btw, not sure whether the command is correct: # LC_ALL=C grub2-install --directory /boot/EFI grub2-install: error: /boot/EFI/modinfo.sh doesn't exist. Please specify --target or --directory.)
This makes my head spin! Leaving it in all your competent hands.
Component: RPM Packages => Installer
No, Xfce 64bit, it does have a file /proc/devices, which lists a bunch of Character devices and Block devices. There is nothing else that starts with /proc/device, so also no /proc/device-tree.
Created attachment 15227 [details] Report when grub fail Sorry Martin perhaps for me is invalid look like the destination device (a usb memmory) has been manipulated so many times that is a few rotten https://www.imagebam.com/view/ME18TXWF But if the info is useful here is
(In reply to katnatek from comment #18) > Created attachment 15227 [details] > Report when grub fail > > Sorry Martin perhaps for me is invalid look like the destination device > (a usb memmory) has been manipulated so many times that is a few rotten > > https://www.imagebam.com/view/ME18TXWF > > But if the info is useful here is It is hard to read: * grub2-install failed: () Error: <Instalando para plataforma i386-pc. grub2-install: aviso: Intentando instalar GRUB en un disco con múltiples etiquetas de partición. TodavÃa no está soportado.. grub2-install: aviso: El embebido no es posible. GRUB podrá ser instalado con esta configuración únicamente usando listas de bloques. No obstante, las listas de bloques son INSEGURAS y su uso está desaconsejado.. grub2-install: error: no se procederá con las listas de bloques. And grub-gfxmenu is not needed? * program not found: grub-gfxmenu
Btw, after running urpmi --replacefiles grub2 "grub2-install /sda" works fine
@Marja, if you boot the installer in EFI mode and select GRUB as the bootloader, it will install the grub2-efi package, not the grub2 package, so you will only have the GRUB modules needed for EFI boot. The GRUB commands (e.g. grub2-install) are in the grub2-common package which is required by both grub2 and grub2-efi, so those commands are available either way. By running 'urpmi --replacefiles grub2' you installed the GRUB modules needed for legacy boot, which then allowed grub2-install to work. Note: when running grub2-install in EFI mode, you don't need to specify a target device. It expects the ESP to be mounted at /boot/efi (which in Mageia systems is a soft link to /boot/EFI, just to confuse matters) and automatically installs to the directory /boot/efi/EFI/mageia. You say it failed to boot on reboot after installation in EFI mode. Were there any errors reported by the installer before that? If not, the most likely cause is your BIOS doesn't properly observe the EFI NVRAM settings. If you wanted to experiment, you could try installing in the fallback boot location (\EFI\BOOT), which is an option in the installer for both rEFInd and GRUB. But it may be easier to just keep using that machine in legacy boot mode.
@katnatek, are you installing onto a USB flash drive that you've previously used with an ISO image? If so, your problem is most likely that the is9660 filesystem signature is still present on the drive. Try using wipefs to examine that drive and to remove any filesystem signatures that shouldn't be there.
(In reply to Martin Whitaker from comment #22) > @katnatek, are you installing onto a USB flash drive that you've previously > used with an ISO image? If so, your problem is most likely that the is9660 > filesystem signature is still present on the drive. Try using wipefs to > examine that drive and to remove any filesystem signatures that shouldn't be > there. Yes, THANK YOU! I didn't know how to fix that
(In reply to katnatek from comment #23) > (In reply to Martin Whitaker from comment #22) > > @katnatek, are you installing onto a USB flash drive that you've previously > > used with an ISO image? If so, your problem is most likely that the is9660 > > filesystem signature is still present on the drive. Try using wipefs to > > examine that drive and to remove any filesystem signatures that shouldn't be > > there. > > Yes, THANK YOU! I didn't know how to fix that But I think, isodumper should do that when you format the usb
(In reply to Martin Whitaker from comment #21) > @Marja, if you boot the installer in EFI mode and select GRUB as the > bootloader, it will install the grub2-efi package, not the grub2 package, so > you will only have the GRUB modules needed for EFI boot. The GRUB commands > (e.g. grub2-install) are in the grub2-common package which is required by > both grub2 and grub2-efi, so those commands are available either way. Well, since installing in EFI mode failed at the "installing bootloader" step, and booting into it from a Mageia 9 legacy installation worked, I wanted to install grub to /dev/sda instead of to the EFI directory. But I had forgotten grub2-efi is a package, I was confused that I couldn't find the grub2-efi command :-) > > By running 'urpmi --replacefiles grub2' you installed the GRUB modules > needed for legacy boot, which then allowed grub2-install to work. But then it only showed the oldest kernel, not the later installed ones. Installing kernels had given errors ending with "only creating initrd", IIRC because it couldn't find the bootloader. > > Note: when running grub2-install in EFI mode, you don't need to specify a > target device. It expects the ESP to be mounted at /boot/efi (which in > Mageia systems is a soft link to /boot/EFI, just to confuse matters) and > automatically installs to the directory /boot/efi/EFI/mageia. Thanks, didn't know > > You say it failed to boot on reboot after installation in EFI mode. Were > there any errors reported by the installer before that? This evening, it stopped at (translated from Dutch): grub2-install failed: Installing for x86_64-efi-platform Could not prepare boot variable: Function not implemented grub2-install: error: efibootmgr failed to register the boot entry, I/O error ... well, I/O error looks like it's caused by my hardware, doesn't it? (Btw, I couldn't put ddebug.log on a USB key, but I may have saved /root/drakx/* from the previous EFI-mode installation. If that shows something else than an I/O error, then I'll tell later) > If not, the most > likely cause is your BIOS doesn't properly observe the EFI NVRAM settings. > If you wanted to experiment, you could try installing in the fallback boot > location (\EFI\BOOT), > which is an option in the installer for both rEFInd and GRUB. But it may be > easier to just keep using that machine in legacy boot mode. Well, I'm happy to report that installing the CI in legacy mode succeeded this evening. I used the same USB-stick, and now it happily installed Mageia.
(In reply to Martin Whitaker from comment #21) > > You say it failed to boot on reboot after installation in EFI mode. Were > there any errors reported by the installer before that? The first attempt yesterday, I thought "let's try rEFInd", but I hadn't seen those alerts, only see them now in ddebug.log: ALERT: There were problems running the efibootmgr program! You may need to rename the refind_x64.efi binary to the default name (EFI/BOOT/bootx64.efi on x86-64 systems, EFI/BOOT/bootia32.efi on x86 systems, or EFI/BOOT/bootaa64.efi on ARM64 systems) to have it run! Creating //boot/refind_linux.conf; edit it to adjust kernel options. ALERT: Installation has completed, but problems were detected. Review the output for error messages and take corrective measures as necessary. You may need to re-run this script or install manually before rEFInd will work. _____________________________________________________________________________ The second attempt was an upgrade install of the first attempt, but now selecting to use Grub2 instead of rEFInd. In ddebug.log I see the same as I saw this evening (as mentioned in comment 25), but includes a path to any.pm line278: error: grub2-install failed: Installeren voor x86_64-efi-platform. Could not prepare Boot variable: Function not implemented grub2-install: fout: efibootmgr failed to register the boot entry: Invoer-/uitvoerfout. ...propagated at /usr/lib/libDrakX/any.pm line 278. ______________________________________________________________________________
Copying my summary from qa-discuss: This is three different issues: TJ's problem was caused by using an old copy of the netinstall ISO, from before bug 34563 was fixed. The alpha1 ISOs were built after that date, so don't suffer from that problem. katnatek's problem was caused by installing onto a USB flash drive that had previously held one of the ISO images. Repartitioning the drive and reformatting the partitions doesn't remove the iso9660 filesystem signature (which is located in the empty space between the MBR and the first partition), and GRUB refuses to install itself if it sees that leftover filesystem signature. Modifying the installer to identify such situations and fix them is not something I'd want to attempt when we are trying to make a release. Marja's problem looks to either be faulty UEFI firmware or a faulty EFI NVRAM. The workaround for that is to use the installer/drakboot option to install the bootloader in the EFI fallback location (\EFI\BOOT in the ESP), or to use the CSM and legacy boot. @Marja, if you are happy with that answer, this bug can be closed.
(In reply to Martin Whitaker from comment #27) > > @Marja, if you are happy with that answer, this bug can be closed. Yeah it's fine. Sorry for having commented in this report, I should first have asked on QA ml whether that would make sense, given the state of this laptop. I'll tag my comments as obsolete. However, I learnt new things, thanks for your patience with me :-) Closing as fixed, because the original issue got fixed. However, removing the 10alpha1 keyword, because it never affected 10alpha1 @ Katnatek I didn't touch your comments, although they're about a different issue. I saw you opened bug 34877 for it.
Resolution: (none) => FIXEDStatus: NEW => RESOLVEDKeywords: 10alpha1 => (none)
Summary: Grub2 install fails when using Classic Installer isos => Grub2 install fails when using netinstall ISO