Created attachment 8768 [details]
photo of issue

This reminds me of bug 15989

Can you reproduce this, Ben, or do other testers hit this, too?

If it's reproducable, then the severity & priority of this bug should be increased

Keywords: (none) => NEEDINFO
CC: (none) => isobuild, marja11, sysadmin-bugs
Component: Installer => Release (media or process)
Assignee: bugsquad => ennael1

The same here.
Papoteur

CC: (none) => yves.brungard_mageia

Ady, a contributor of The Syslinux Project, who tries to help users /distros wrt booting-related issues, even outside the scope of The Syslinux Project, and who has helped us with useful contributions, is wondering whether:


2016:12:17:18:14< Ady> Here is what I _think_ is happening.
2016:12:17:18:15< Ady> First, the iso image is dd'ed to the USB device, so when this device is booted in UEFI mode, the boot process goes first to 'isolinux/efiboot.img' (located inside the iso image).
2016:12:17:18:15< Ady> Inside this 'isolinux/efiboot.img', the boot process goes to 'EFI/BOOT/bootx64.efi', which in turns parses the "grub.cfg" file located in the same directory (i.e. 'EFI/BOOT/grub.cfg' inside the 'isolinux/efiboot.img' image, which is itself inside the iso image).
2016:12:17:18:15< Ady> And now _this_ grub.cfg says "linux /isolinux/x86_64/vmlinuz", but this command is trying to find '/isolinux/x86_64/vmlinuz' _inside_the_efiboot.img_, and of course the vmlinuz kernel is not in that exact location (inside the efiboot.img image).
2016:12:17:18:15< Ady> I do not know whether there is a way to change the root of that path (in this grub.cfg) "back" to the root of the iso image ("outside" efiboot.img) where the '/isolinux/x86_64/vmlinuz' kernel can be found.
2016:12:17:18:15< Ady> If such "new" root of that path cannot be changed in such manner, then the kernel and initrd files need to be also included inside the efiboot.img (e.g. in the same directory as this grub.cfg, inside efiboot.img) and then use an appropriate path for them in the relevant grub.cfg (the one inside the efiboot.img image).

(In reply to Marja van Waes from comment #4)
> Ady, a contributor of The Syslinux Project, who tries to help users /distros
> wrt booting-related issues, even outside the scope of The Syslinux Project,
> and who has helped us with useful contributions, is wondering whether:
> 

Well, we dont use syslinux for efi boot...

> 
> 2016:12:17:18:14< Ady> Here is what I _think_ is happening.
> 2016:12:17:18:15< Ady> First, the iso image is dd'ed to the USB device, so
> when this device is booted in UEFI mode, the boot process goes first to
> 'isolinux/efiboot.img' (located inside the iso image).

Nope, efiboot.img only gets read on isos as it's mapped with eltorito alt-boot

EFI boot spec from usb only reads the /EFI and goes from that

> 2016:12:17:18:15< Ady> Inside this 'isolinux/efiboot.img', the boot process
> goes to 'EFI/BOOT/bootx64.efi', which in turns parses the "grub.cfg" file
> located in the same directory (i.e. 'EFI/BOOT/grub.cfg' inside the
> 'isolinux/efiboot.img' image, which is itself inside the iso image).
> 2016:12:17:18:15< Ady> And now _this_ grub.cfg says "linux
> /isolinux/x86_64/vmlinuz", but this command is trying to find
> '/isolinux/x86_64/vmlinuz' _inside_the_efiboot.img_, and of course the
> vmlinuz kernel is not in that exact location (inside the efiboot.img image).
> 2016:12:17:18:15< Ady> I do not know whether there is a way to change the
> root of that path (in this grub.cfg) "back" to the root of the iso image
> ("outside" efiboot.img) where the '/isolinux/x86_64/vmlinuz' kernel can be
> found.


The thinking is wrong. That is what we did on isos while using gummiboot as efi loader.

But as that means duplicating kernel/initrd -> wasting space we switched to grub2-efi as efi loder since it has a nice feature no other efi loaders have afaik (atleast not last time I checked)

When you boot in UEFI mode from an ISO, it reads the efiboot.img.

There we instruct grub2 to switch root to the full iso contents with:

search --no-floppy --set=root -l 'Mageia-6-GNOME-LiveDVD'

and then we find the needed:
/isolinux/x86_64/vmlinuz
and so on...

but I see this line is in the /EFI/boot/grub.cfg too, and thats what confusing grub2-efi when loading from usb.

remove that line, and it should continue properly

CC: (none) => tmb

(In reply to Thomas Backlund from comment #5)
> Nope, efiboot.img only gets read on isos as it's mapped with eltorito
> alt-boot
> 
> EFI boot spec from usb only reads the /EFI and goes from that

No, it's the other way round. isohybrid uses the efiboot.img mapped by eltorito alt-boot to create a fake ESP, and that's used to boot from USB sticks. When booting from DVD, the UEFI BIOS boots from EFI/BOOT/bootx64.efi in the iso9660 file system (at least, that's what my UEFI BIOS does, and Vbox does the same).


> When you boot in UEFI mode from an ISO, it reads the efiboot.img.
> 
> There we instruct grub2 to switch root to the full iso contents with:
> 
> search --no-floppy --set=root -l 'Mageia-6-GNOME-LiveDVD'
> 
> and then we find the needed:
> /isolinux/x86_64/vmlinuz
> and so on...
> 
> but I see this line is in the /EFI/boot/grub.cfg too, and thats what
> confusing grub2-efi when loading from usb.
> 
> remove that line, and it should continue properly

The search command is redundant when booting from DVD, but it does no harm. I use the same grub.cfg in /EFI/BOOT and in efiboot.img on the Live ISOs, and they boot without problem in either mode.

The problem with the classic installer ISOs is that the grub.cfg inside efiboot.img is out of date, and is still searching for 6-RC, not 6-sta2.

I suggest copying the changes I made to draklive to the bcd script. There I automatically update the label in grub.cfg (based on the label that is passed to xorriso), and automatically rebuild efiboot.img. That should guarantee everything remains consistent as we progress towards release.

CC: (none) => mageia

I'm having a look now

I have just compared the .iso of Mageia 5.1 Classic x64 with latest pre-testing M6 sta2 dated 17 Dec. Some differences that may or may not matter:

                        5.1           sta2
/EFI/BOOT/bootx64.efi   8 Nov 2016     28 Jan 2015

/isolinux/              40.3Mb         88.9Mb
" /x86_64/              31.2Mb         79.8Mb
"  "  all-nonfree.rdz    x             47.4Mb
"  "  all.rdz           present        present
"  "  vmlinuz           4.5Mb          4.7Mb
" isolinux.bin          41.0Kb         38.9Kb
" tools.cfg              x             94b

This looks more interesting:

/x86_64/                3.9Gb         4.0Gb
" doc/                  present       present
" EFI/                  4.1Mb         x
" " BOOT/bootx64.efi    802.8Kb       x
" install/              83.5Mb        240.3Mb
" " extra/              1.7Mb         1.7Mb
" " images/             196.7Kb       141.9Mb
" " stage2/             81.6Mb        96.7Mb
" isolinux/             40.1Mb        x
" " x86_64/             31.0Mb        x
" " " vmlinuz           4.3Mb         x
" media                 present       present
" misc                  present       present

So I wonder whether the problem may be due to the lack of the
/x86_64/isolinux/ directory with its x86_64/vmlinuz;
or /x86_64/EFI/ directory.
Or perhaps grub2 confusion about the changed directory structure which seems to eliminate isolinux/ duplication. Intended?

CC: (none) => lewyssmith

efiboot.img has been updated, especially grub.cfg with proper label. Tested by Charles Edward in last DVD64 test iso. 

=============

ISO:  Mageia-6-sta2-x86_64-DVD.iso
DATE: Sun Dec 18 18:14:14 CET 2016
MD5:  OK     SHA1: OK     SHA512: OK

UEFI boot works

Iso dumped to usb key from dorsuncpre.
It boots UEFI without problem.
Am currently running the install now.
Will advise, here and on pad, when it completes.


    Charles

Status: NEW => RESOLVED
Resolution: (none) => FIXED

For future reference, and because the commit that fixed this is not yet in http://gitweb.mageia.org/software/build-system/bcd  

Similar issue bug 15989 seems to have been fixed by this commit:

 http://gitweb.mageia.org/software/build-system/bcd/commit/?id=a2a6e44ae80dc9790bc69fd6fcfdcdddbbffc3e8

No it's not. I fixed efiboot.img locally for now on rabbit so that grub.cfg is using proper string for the current version. I have to find a better way fr the coming releases.