Description of problem: On upgrading to MGA9 of a dual-boot HP Pro Book PC with Windows, when choosing the partitioning, I chose to keep the existing partitions. The installation went smoothly, except that at the end the boot partition was installed on the USB key. To perform the installation, I used a key formatted with Ventoy. I flashed a key with the MGA9 iso and it refused to install MGA on the existing partitions because it couldn't find the fat32 /boot/EFI/ partition. I tried many times to change the mount point of the Windows boot partition but never succeeded in doing anything. I also tried to reinstall grub with the system booted, without success with always the same error. Same problem with rEfind.
Created attachment 14247 [details] install log
Created attachment 14248 [details] ddebug log
Your Windows boot partition does not have the correct partition type and format. From your ddebug.log: * running: blkid -o udev -p /dev/sda1 * blkid gave: ntfs-3g 5C3C80CE3C80A49C Réservé_au_système and Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 1187839 1185792 579M 7 HPFS/NTFS/exFAT /dev/sda2 1187840 185192447 184004608 87.7G 7 HPFS/NTFS/exFAT ... Compare with the USB stick: * running: blkid -o udev -p /dev/sdb2 * blkid gave: vfat B2C8-40D2 VTOYEFI and Device Boot Start End Sectors Size Id Type /dev/sdb1 * 2048 59998207 59996160 28.6G 7 HPFS/NTFS/exFAT /dev/sdb2 59998208 60063743 65536 32M ef EFI (FAT-12/16/32) The ESP must be FAT formatted with a partition ID of 0xEF.
CC: (none) => mageia
Okay, I can see that. Why is it that the MGA8 installer can see the partitions and install them without a problem, while MGA9 can't? I'll try to recover the ddbug and install log from the MGA8 installation, if they haven't been altered after the migration to MGA9 (done online).
Martin, thank you for jumping on this; I would have CC'd you anyway. Guillaume, it would have helped to say how you went about "upgrading to MGA9 of a dual-boot HP Pro Book PC with Windows". "I flashed a key with the MGA9 iso and it refused to install MGA on the existing partitions because it couldn't find the fat32 /boot/EFI/ partition" because there was not one. How was the machine booted previously? (In reply to Guillaume Royer from comment #4) > Why is it that the MGA8 installer can see the > partitions and install them without a problem, while MGA9 can't? Perhaps the partition details have changed since then. What Martin says "The ESP must be FAT formatted with a partition ID of 0xEF" is not new. I suppose the installer found one only on the USB.
CC: (none) => lewyssmith
(In reply to Lewis Smith from comment #5) > Martin, thank you for jumping on this; I would have CC'd you anyway. > > Guillaume, it would have helped to say how you went about "upgrading to MGA9 > of a dual-boot HP Pro Book PC with Windows". > "I flashed a key with the MGA9 iso and it refused to install MGA on the > existing partitions because it couldn't find the fat32 /boot/EFI/ partition" > because there was not one. How was the machine booted previously? The machine was boot on MGA8 LXDE, I booted up the machine to check that everything was working properly on MGA8, updates etc.. The owner asked me to install Plasma instead, so I chose to reinstall without formatting /home. > > (In reply to Guillaume Royer from comment #4) > > Why is it that the MGA8 installer can see the > > partitions and install them without a problem, while MGA9 can't? > Perhaps the partition details have changed since then. What Martin says "The > ESP must be FAT formatted with a partition ID of 0xEF" is not new. I suppose > the installer found one only on the USB. That's what I don't understand, after this failure the reinstallation of MGA8 on the principle of formatting "/" and keeping /home safe worked without any problem. If it was a partition problem, the 2 installers MGA8 and MGA9 should have failed.
We'd need the ddebug.log (or better, the report.bug.xz) from the MGA8 install to investigate. That should still be in /root/drakx even after an upgrade to MGA9.
Created attachment 14249 [details] install log mga8
Created attachment 14250 [details] ddebug log mga8
I managed to get ddebug and install log sent to me. It wasn't easy for my friend to do it. Is the bug report necessary? If so, I'll ask him, but it's going to take a bit of time.
From the MGA9 ddebug.log: * Is UEFI=yes From the MGA8 ddebug.log: * Is UEFI=no You've booted the MGA8 installer in legacy mode, so it doesn't search for or need an ESP to complete the installation. If you are subsequently booting the installed system in UEFI mode, I guess there's an old install of GRUB in the ESP that somehow still works.
Created attachment 14251 [details] report.bug
(In reply to Martin Whitaker from comment #11) > From the MGA9 ddebug.log: > > * Is UEFI=yes > > From the MGA8 ddebug.log: > > * Is UEFI=no > > You've booted the MGA8 installer in legacy mode, so it doesn't search for or > need an ESP to complete the installation. > > If you are subsequently booting the installed system in UEFI mode, I guess > there's an old install of GRUB in the ESP that somehow still works. Ok I understand what it happened. But that I don't understand, is why MGA9 didn't see Legacy mode? Surely the Windows 10 installed is a migration from a Windows 7 that had been done in legacy mode. But the installer didn't see it. If this is expected behavior on the part of the installer, that's okay, but for me it's not, because a person without support can't get by. And even I, with a little experience, didn't understand what was going on.
(In reply to Guillaume Royer from comment #13) > Ok I understand what it happened. But that I don't understand, is why MGA9 > didn't see Legacy mode? > Surely the Windows 10 installed is a migration from a Windows 7 that had > been done in legacy mode. But the installer didn't see it. If this is > expected behavior on the part of the installer, that's okay, but for me it's > not, because a person without support can't get by. And even I, with a > little experience, didn't understand what was going on. https://wiki.mageia.org/en/Installing_on_systems_with_UEFI_firmware#How_to_distinguish_between_UEFI_and_BIOS_mode_for_Mageia_boot_media The selection of uefi or bios mode is done during boot based on which menu entry is selected by you, It is not selected by the installer, as it can not switch modes once it's booted.
CC: (none) => davidwhodgins
Just to clarify. The menu where the selection is made is the one where the usb stick or optical drive is selected. It's not shown in the wiki or documentation as it varies between make and model of the uefi firmware.
Ok, that's I make on first install. But here it's not first install. I suppose if MGA8 can detect legacy, MGA9 can too. I didn't interfere with the bios so that the installer could make the right choice for MGA8, but I think the same should have been done for MGA9. It's true, though, that I wasn't discerning enough to check which mode the bios was in. As far as I was concerned, the installer was going to make the right choice depending on which fcon Windows was installed in. What do we do? Do we consider this state as a malfunction or as normal functioning? If so, we're likely to get more feedback like mine. We've already had one on the MLO forum and another acquaintance of mine has had it too.
Checking which mode windows or other installs were done in, opens up another set of possible problems, such as when a drive has been moved from an older system to a newer system, knowing that windows won't boot, but expecting that the newly installed linux system will boot. Unlike windows, linux gives the user choices and respects those choices. It is impossible for the installer to change between uefi and bios mode. Which mode is used can only be controlled by the uefi menu selection. By time the installer gets control, the decision has been made. When booted in bios mode, the installer can not read or write the nvram used to store uefi boot menu entries which makes installing boot loaders for both modes physically impossible. When the installer has been booted in uefi mode, it would generate a lot more complaints if the installer then created an installation that expects to be booted in bios firmware mode. It's possible, but would generate many more complaints. On my 2012 system, it can boot in either mode, but the default of booting in bios mode can not be changed. When Mageia first added support for uefi mode, I experimented with it for testing but had lots of problems working with both modes, so stick to bios legacy firmware mode. Unfortunately this is part of user education, so closing as invalid.
Resolution: (none) => INVALIDStatus: NEW => RESOLVED
Ok, thank you for these explanations, I'll be more vigilant for future installations.