description taken from qa rise up. Booted up, selected UEFI install from BBS pop up, UEFI banner present during plymouth screen. selected install: went into disks, custom disk partitioning as i always do, clear all, auto-allocate. auto-allocate would not create the UEFI partition (ive rechecked this under mga7.1 and it does work there so a definite bug) ...... rebooted again, back to the UEFI: usb drive and checked EFI banner on plymouth. went install, keyboard selection, disk partitioning, custom disk partitioning, clear all, auto-allocate, just in case i got it wrong, missed something first time round, but no it did it again, which id now tested does work correctly under mga7.1
Summary: partitioner -> custom partition -> clear all -auto-allocate => custom partition auto allocate under UEFI
(would not create the UEFI partition Installing on real h/w, presumably. Wonder how it would get on with a drive that already has UEFI partition and other installs already using rEFInd...
CC: (none) => maurice
so the workaround was to "use existing partitions", from the mga7.1 install and that worked no problem at all. and yes it is on real hardware, SSD on a asus crosshair v formula one of the early desktop PC's with uefi. regards peter
(In reply to peter winterflood from comment #2) > so the workaround was to "use existing partitions", In what install context did that occur? Seems at odds with creating e.g. new / & /home partitions during install!
sorry I dont understand your question, so ill list the steps, so its 100% clear. boot UEFI from BBS popup select install select keyboard onto disk partitioning layout choice is: 1 use existing 2 use entire disk 3 custom choose custom. click clear existing click auto-allocate. under mga7 auto-allocate will create blue UEFI, red /, green swap, red home. under mga8 auto-allocate creates red /, green swap, red home. thats the bug. no UEFI partition created. regards peter
CC: (none) => peter.winterflood
(In reply to peter winterflood from comment #4) ... > onto disk partitioning layout > choice is: > 1 use existing > 2 use entire disk > 3 custom > > choose custom. > > click clear existing > > click auto-allocate. > > under mga7 auto-allocate will create blue UEFI, red /, green swap, red home. > under mga8 auto-allocate creates red /, green swap, red home. Thank you for that, Peter! The above seems so different from what I recall from all my years of doing clean installs of Mandriva and then Mageia 1-7, so I'm going to find it all most interesting adding a new Mga8 install within my existing Mga6 & 7 UEFI/rEFInd drive. Good luck!
It's working here, testing in VirtualBox. Please repeat the test, click on Done in the custom partitioning screen, and let it write the partition table to disk. It should then display the message "You must have an ESP FAT32 partition mounted in /boot/EFI". Whether it does or not, at that point use Ctrl-Alt-F2 to switch to the debug shell, insert a formatted USB stick in another USB socket, and enter the command "bug". That should write a report.bug file to the USB stick, which you should compress and attach to this report.
CC: (none) => mageia
Keywords: (none) => NEEDINFO
Late on the scene... To re-interpret the original complaint: > auto-allocate would not create the UEFI partition Do you mean the EFI System Partition, alias ESP? > (I've rechecked this under mga7.1 and it does work there, so a definite bug) > under mga7 auto-allocate will create blue UEFI, red /, green swap, red home. > under mga8 auto-allocate creates red /, green swap, red home. Neatly put. But countermanded by Martin (thanks for intervening): > It's working here, testing in VirtualBox. Assigning to Mageia Tools for the installer, Martin has already CC'd himself.
Summary: custom partition auto allocate under UEFI => EFI install, custom partition clear all, auto allocate does not create the ESPAssignee: bugsquad => mageiatools
just to add, 32bit UEFI failed for me. see also bug 26721
CC: (none) => westel
choosing rEFInd as boot option completes installation- did not find my dual boot win10
and it boots to win10 with no bootloader installed
Created attachment 11675 [details] report.bug.xz installed into a efi ex-chromebook with coreboot bios auto create of required partitions failed - created one large partition, then complained that a /boot/EFI partition required. choose c.d.p, deleted single partition and created /boot/EFI, / and /swap. install continued until bootloader installation, where it failed. chose the advanced option to *not touch mbr or esp*. install now completes, but reboot failed to efi shell. Coreboot allows useful editing of the boot sequence, so I made necessary changes and booted system have attached report.bug.xz
in reply to martin whitaker i appreciate your comment, but expected behaviour i have reported is clearly working in mga7.1 but not mga8 even if as you suggest hitting done warns you, it successfully pre fills out all 4 partitions in mga7 but not in 8 i have if you follow my pad description found issue during mga8 alpha qa rebooted tested under mga7 and then retested in mga8 alpha it is repeatable martin, i suggest you try on real hardware. keep well everyone regards peter winterflood
Created attachment 11677 [details] Acer C710 install report.bug.xz installed 64 CI.iso to a ex-chromebook with Coreboot bios. Acer C710 / 320HDD at disk partitioning page, chose erase drive and auto-create partitions no /boot/EFI partition was created chose c.d.p. and edited partition scheme to include /boot/EFI. at DE option, chose LXDE, install proceeded with no further issue.
@Peter, Repeatability and reproducability are not the same thing. I have now retested on real hardware and still can't reproduce your bug. Also, I am not employed to work on Mageia and don't have infinite amounts of spare time. I spent most of my weekend building and testing the ISOs. Is it really too much to ask that you spend a few minutes to provide the information I asked for? @Ben, Thanks for your installer logs. I can reproduce the issue you report, i.e. when choosing the "Use entire disk" option.
The root cause of this bug is that the installer is no longer excluding the installer medium (USB stick) from the disks you can install on. At the partitioning stage, it sees the ESP on the installer medium, so thinks it doesn't need to create another one. But there is no mount point set for that ESP, so the following check fails. I'm trying to find where in the code the installer medium is/was excluded. @Thierry, if you can give me a pointer, that would save me some time.
Keywords: NEEDINFO => (none)CC: (none) => thierry.vignaudSource RPM: partitioner during UEFI based install => drakx-installer-stage2
sorry martin, i read your post of it works here as dismisive. that was wrong of me, hence the reply. and now that you have provided an explanation, i should add 1 bit of info i omited, as it did not appear relivant at the time. the mga7 working test was booted from cdrom, whereas mga8 was booted from usb. i did not see the relevance of that difference till now. and ditto, im also not employed by mageia, and have contributed to the M since 1999. regards peter winterflood
Indeed, this bug only manifests when booting from USB. It doesn't occur on the Mageia-7.1_x86_64 ISO but does occur on the Mageia-7.1_i586 ISO. With the 64-bit ISO, the installer USB stick gets excluded from the available disks because its first partition starts at sector 0 (whereas on the 32-bit ISO it starts at sector 1). This appears to be more by accident than by design. It got broken for Mageia 8 by my change to allow diskdrake to be used to add a persistent partition on Live USB sticks. I'll look at implementing a better fix for excluding the installer USB stick from the available disks. draklive-install does it better.
Assignee: mageiatools => mageia
Fixed in drakx-installer-stage2-18.29-1.mga8. To be verified with the next ISO build.
thanks again Martin for the quick fix looking forward to testing for it
I believe this was fixed in the 8-beta1 ISOs. Please reopen if I'm wrong.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED