Created attachment 5563 [details] ddebug.log.xz of failed install Hi Thomas, I'm aware we agreed to not file EFI bugs, but I'm also aware that the Mga4 efi-install method for traditional installer should still work. For me it hasn't worked since over 2 months ago, when you told me it should work for the boot(-nonfree).iso, too https://bugs.mageia.org/show_bug.cgi?id=13684#c8 It now doesn't work either with the QA pre-mga5beta1 traditional 64bits DVD iso (burned to a DVD) of October 31st. Now filing this report so the issue is tracked (and maybe someone else will tell some magic in a comment to make it work with this iso :-) ) I'll attach the compressed ddebug.log of what should have been an EFI-install, it failed for some other reason at the end of or right after of packages install and went back to the diskdrake step. After that I'll attach the ddebug.log of the upgrade install of above mentioned install, which failed because it tried to write a traditional grub2 bootloader.
Created attachment 5564 [details] ddebug.log.xz of failed upgrade of failed install
Summary: 5beta2 classical: EFI install doesn't work anymore (as it did in Mga4) => 5beta1 classical: EFI install doesn't work anymore (as it did in Mga4)Whiteboard: (none) => 5beta1
Created attachment 5565 [details] report.bug.xz of completed install better logs. Install was now completed, after I chose to install grub2 to the beginning of a partition instead of to sda. apart from grub2-efi not being installed and used (there is a line: > * preferring grub over lilo,grub2,grub2-efi ) I also don't see efibootmgr is installed. And, there seemed to be no handing over from uefi to console, at least there is no crash, no pause or anything like that at the beginning of install
Attachment 5563 is obsolete: 0 => 1 Attachment 5564 is obsolete: 0 => 1
hmm, I hadn't changed anything in the EFI-BIOS Before it worked with try to efi-boot first, and allowing old fashioned MBR booting if that failed. But maybe this time I should *only* allow efi-boot? I'll try that asap.
(In reply to Marja van Waes from comment #3) > hmm, I hadn't changed anything in the EFI-BIOS > > Before it worked with try to efi-boot first, and allowing old fashioned MBR > booting if that failed. > > But maybe this time I should *only* allow efi-boot? I'll try that asap. When set to EFI-boot only, and the DVD as boot-first, then the DVD won't boot at all
On the QA ml, Lewis wrote today (replying to Akien): >> * Classical installers are good to go > I am glad to hear this. But... > Perhaps not for EFI. The latest installation DVD does not boot on my > box. And if you frig the installation by booting from a frigged USB > stick, the result does not boot for me either.
As expected: also valid for today's 64bits classical DVD (mentioned by Lewis on QA ml and just verified by me)
As a side note it should be part of beta1 errata and will be fixed just after
Grateful to Marja for launching this, despite the subject being sort of taboo. Testing on real EFI *only* hardware, with an existing & well populated ESP. Secure Boot disabled - almost always necessary. No MBR bodging. Simply to re-state that since mid-way of M4 testing, most recently Mageia 4.1 (possibly M5 Alpha, I forget) the Classic DVD booted directly - at least if the device was selected in the EFI boot menu. [Note to Marja: if it does not boot directly of its own accord, can you raise an EFI boot menu which shows the DVD device to select to boot from?] This ability has disappeared in Mageia 5 Betas. > As a side note it should be part of beta1 errata and will be fixed just after OK.
CC: (none) => lewyssmith
Blocks: (none) => 14928
Blocks: (none) => 14330
This should be fixed with all new QA pre-5beta2 isos of today. It is certainly fixed for the LiveKDE64bitDVD (just tested, and it efi-boots fine and also efi-installs fine from Live mode) Please reopen if you find a 64bit iso for which it did not get fixed
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Sorry, I was too fast to close this one :-( I don't manage to efi-boot today's classical 64bit DVD, when burned on a DVD. I won't have time before Monday to try again with the iso contents dd'ed to a USB key
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Tested today Mageia-5-beta2-x86_64-DVD, copied on an USB stick. After having selected KDE, I got the error message: Installation failed, some files are missing /tmp/image/media/core/setup-2.7.21-3.mga5.noarch.rpm /tmp/image/media/core/run-parts-4.4-4.mga5.x86_64.rpm You may need to update your urpmi database. And then many other similar error messages, at the end : An error occurred, unable to access medium "Core release".
CC: (none) => lebarhon
(In reply to André DESMOTTES from comment #11) > Tested today Mageia-5-beta2-x86_64-DVD, copied on an USB stick. > After having selected KDE, I got the error message: Installation failed, > some files are missing > /tmp/image/media/core/setup-2.7.21-3.mga5.noarch.rpm > /tmp/image/media/core/run-parts-4.4-4.mga5.x86_64.rpm > You may need to update your urpmi database. > > And then many other similar error messages, at the end : An error occurred, > unable to access medium "Core release". thx for the report, André. Did you efi-boot this USB stick?
Yes, the boot is working, I had the "boot.iso like" boot (asking to choose between http, NFS, CDROM, hard disk...) I chose hard disk and then sdb. FWIW, in the wiki page "UEFI_how-to", it is said "mount -t iso9660 <iso-image> <a-mount-point>", it did not work for me, I used "mount -o loop <iso-image> <a-mount-point>"
On QA ml, Lewis and Vladimir reported they could not efi-boot this iso from DVD, either. Vladimir reported, like André in this bug report, that efi-booting did work when the iso was written to a USB-key, but he then hit bug 13471
Summary: 5beta1 classical: EFI install doesn't work anymore (as it did in Mga4) => 5beta1 classical: EFI install from DVD doesn't work anymore (as it did in Mga4), but efi-boot from USB works.Whiteboard: 5beta1 => 5beta2
Blocks: (none) => 15014
CC: (none) => stephane_oss
Created attachment 5804 [details] report.bug.xz about comment 15
I had a closer look to my USB stick and noticed that the copy wasn't correct. Files were missing in x86_64. sorry for that. I re-did the "copy of the contents" and the install. This time it went fine but at the first reboot the UEFI partition isn't detected, the PC boot with the Legacy mode only. see report.bug.xz in comment 15
The blog post asked people to report their EFI experiences, so I'll add a "me too" despite this being a known problem. Classic 64-bit installer copied to USB stick cannot be booted in EFI mode on either of my machines, boots fine in legacy mode.
CC: (none) => mageia
To be more precise, if I dd the ISO image onto the USB stick, it is just not seen in the boot menu. If I copy the contents of the ISO image into a FAT32 partition, the installer boots, but then displays a message saying it can't access a Mageia installation disc in my CDROM drive.
When that happends, it should ask you to select media to install from. Try to select harddisk, and it should continue...
I tried that, and selected sdb (the USB stick). It then gave the message "no partition found" and returned to the previous menu. I followed the instructions at https://wiki.mageia.org/en/UEFI_how-to, which creates an unpartitioned drive: Command (m for help): p Disk /dev/sdb: 3.8 GiB, 4018143232 bytes, 7847936 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Does it actually need to be partitioned?
As a followup to the blog post I tried installing Mageia 5 beta 2 in my UEFI hardware and this is my experience. If a simply dd the iso (classic) to an USB stick then the EFI firmware doesn't list USB in the boot menu. If I partition the USB stick to have a single VFAT partition and then I copy all the files from the ISO to the USB stick then the EFI firmware correctly sees the USB stick and but, when I try to boot from the stick, it blocks me with a generic "Security Error". I had secure boot enabled. I then disabled the secure boot option and then EFI booted correctly from the USB stick putting me on the installation program, which says "No CDROM found". I choosed "Hard Disk" as installation method and then selected the entry of the USB stick and the simple partition that I have created. When the installation program asked the directory where to find the installation packages I leaved the text field empty and let the program go. The installation program than tried to start Xorg but failed and the log file says: (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode (EE) FBDEV(0): mode initialization failed (EE) AddScreen/ScreenInit failed for driver 0 Seeing that the Xorg server isn't correcly starting the installation program tries with the VESA driver but the Xorg server won't go. The log file this time sais: (EE) VESA(0): V_BIOS address 0x0 out of range So I haven't succeeded installing Mageia 5 beta2 on this laptop in EFI mode. The laptop is an Acer Aspire V11 Touch with an Intel HD Graphics video card. I had Xorg running correctly on this laptop so I also tried dd the ISO directly to the USB device and configuring the BIOS to boot in the so called "Legacy Mode". This time the bios sees correctly the USB stick and start the installation program, which correctly detect the USB stick and started Xorg, which seems to work like a charm! The graphical installation program showed up correctly but, in this configuration, I can't use the laptop keyboard and touchpad. So I think that efi-boot is correctly working for me but the Xorg server doesn't work when I boot in EFI mode. Have I another instance of the bug 13471 ?
CC: (none) => leonardoce
This appears to be the place to discuss the bug that isn't a bug and isn't reported... My experience with UEFI hardware and M5b2 classical DVD. First UEFI is huge and usually poorly implemented. (It is as buggy as heck, so it is not necessarily your fault if things don't work.) My motherboard is an Asrock 970 Pro3 2.0 with firmware version 1.70. Version 1.80 exists, but I have not installed it yet. The DVD is recognized as an old style disc (not a new signed one) and booted if selected explicitly with F11 during powerup. It does not behave if rEFInd is run first and the DVD then selected, it complains that it can not make sense of the partition table on the hard drive. The hard drive has a GPT, of course. Installation to a single partition (sda15) seemed to work pretty well, except for a few bugs. (Custom partitioning did not work.) It mounts the /boot/efi partition, but does not seem to write anything to it. It installed grub somewhere, I'm not sure where. There is a 3MB bios boot partition at the start of the disk. Booting is a bit confused. Unattended, it does a bios boot to grub (no other installations found) and M5. Selecting the UEFI boot partition, rEFInd and Ubuntu, it runs Ubuntu. From the Ubuntu side this happens; $ sudo efibootmgr BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0004,0000,0003 Boot0000* rEFInd Boot Manager Boot0003* Hard Drive Boot0004* CD/DVD Drive $ sudo efibootmgr -v BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0004,0000,0003 Boot0000* rEFInd Boot Manager HD(2,1800,19000,3b46f559-a784-4e23-a104-30ebdce6c15c)File(\EFI\refind\shimx64.efi) Boot0003* Hard Drive BIOS(2,0,00)AMGOAMNO........o.W.D.C. .W.D.1.0.E.Z.R.X.-.0.0.L.4.H.B.0....................A...........................>..Gd-.;.A..MQ..L. . . . .W. .-.D.C.W.4.C.0.J.1.0.5.9.6.9......AMBO Boot0004* CD/DVD Drive BIOS(3,0,00)AMGOAMNO........m.D.R.W.-.2.4.D.3.S.T....................A.........................>..Gd-.;.A..MQ..L.H.K.E.7.C.5.1.9.4.7. .4. . . . . . . . ......AMBO $ I believe that the firmware is buggy and that the boot order is not being respected. Bug report raised with Asrock. The nVidia driver seems OK with my GT 610 card. More information available on request.
CC: (none) => 0123peter
Further update (testing 64-bit classic installer ISO). Hardware is: desktop: ASUS P8H77-V motherboard/Intel i5-3550 CPU laptop: HP Envy dv7-7332ea When the ISO file is burned to DVD or dd'd to USB stick, neither machine can boot from it in EFI mode (neither the BIOS nor rEFInd find the boot file). When the contents are copied to a USB stick with no partition table (superfloppy mode), both machines can boot from it in EFI mode (both the BIOS and rEFInd find the boot file), but when the USB stick is selected as the location of the installation media, display the message "no partition found". When the contents are copied to a USB stick with a single FAT32 partition, both machines can boot and reach the stage 2 installer. If the CSM (compatibility support module) is enabled, both will start the graphical installer on the second attempt (as described on the Wiki). If the CSM is disabled, the laptop will fail to start the graphical installer and fall back to the text-based installer. The desktop machine won't boot at all with the CSM disabled (from any source, not just the USB drive), reporting that the VGA card is not supported by the UEFI driver (so clearly not a Mageia issue). This is as far as I can get, due to bug 11988. I wish you luck with this, Thomas! Ask if you want more tests done.
Well - I should have read the errata first (I know better!)! Justwanted to report my experience with EFI here - I have an Acer Predator G3-605 desktop machine using an SSD for the OSs - Mageia with Cauldron was installed and working with EFI boot (and then heavily updated with Cauldron) - I wanted to perform a fresh install with M5b2 - using a USB (isodumper) Well - in CSM mode the USB will boot and I perfomed a successful install, but after reboot - it fails and dumps to "grub rescue" - says "error: file "/boot/grub2/x86_64-efi/normal.mod" not found Then I read the errate which states that EFI is broken in B2 and will be fixed in B3 - and the Mageia 4 EFI workaround will noe work :-( So I gues I have to wait until Beta 3 comes out . . . unless someone knows a trick?!?!?
CC: (none) => rfox
EFI is working on live medias, its the classical isos that have broken efi
Can I use the "rescue" mode with the live media and repair the already installed instance with a proper EFI boot?? Or do I have to re-install using the live version and then add everything back that I need (above and beyond what is on the live cd)??
CC: (none) => doktor5000
(In reply to Thomas Backlund from comment #25) > EFI is working on live medias, its the classical isos that have broken efi It works perfect with classical on DVD, now: no more need to mount /boot/EFI manually, no more need to remember selecting grub2 in the summary step :-) Here it doesn't work with the iso copied to a fat32 formatted USB key, but as long as no one confirms the following, that _might_ be caused by a _corrupt_USB-key_: stage2 wasn't found, stage1 seemed to search the file tree on a (not present) CD/DVD instead of on the USB-key When pressing "back" I can select Hard disk (as with boot.iso), but choosing the USB key and then setting "x86_64" for the path to the tree, doesn't work. However, giving the path to the same x86_64 tree on a local mirror on a different USB-disk works fine, and install continues.
(In reply to Marja van Waes from comment #27) Marja, have you tried leaving the path to the tree blank. That's what worked for me with beta2.
(In reply to Martin Whitaker from comment #28) > (In reply to Marja van Waes from comment #27) > > Marja, have you tried leaving the path to the tree blank. That's what worked > for me with beta2. No, I hadn't, that does indeed work fine! Now I still need to try what tmb suggested: edit /EFI/BOOT/grub.cfg and change: search --no-floppy --set=root -l 'Mageia-5beta3-x86_64' and change it to match your USB FAT32 label, and it will boot.
Btw, in the wiki it only says how to label the Live iso, so I had used that as label: MGALIVE
I confirm that with classical isos Mageia5 Beta3, booting on EFI USB, I had to use workaround mentioned by Marja : In stage 1 : Back, Hard disk, selecting USB, and setting "x86_64" or leaving blank solves the problem. I tried Thomas' suggestion (change label on in /EFI/BOOT/grub.cfg to match USB label) but that did not work for me.
CC: (none) => olchalWhiteboard: 5beta2 => 5beta2
See also bug 15290, the fix for that bug will fix this one (again), too
Depends on: (none) => 15290
(In reply to Marja van Waes from comment #32) > See also bug 15290, the fix for that bug will fix this one (again), too which happened weeks ago
Status: REOPENED => RESOLVEDResolution: (none) => FIXED