You downloaded the iso itself from where?
Have you checked that the md5 sum is correct?
How did you burn the ISO?
Does any of the Live iso's boot?
Have you check the support page of this laptop to see if there's a newer BIOS released?

CC: (none) => hamnisdude

The two things I know are different about the Fedora ISOs is that they support secure boot and they support 32-bit EFI. From the links below, I don't think you have 32-bit EFI, but you can check by booting Fedora and running

  cat /sys/firmware/efi/fw_platform_size 

Mageia uses GRUB2 for EFI boot, not syslinux. This shows it's not just a Mageia problem:

  https://lists.gnu.org/archive/html/bug-grub/2017-12/msg00010.html

Here's another similar report for a different machine using the same CPU type:

  http://rglinuxtech.com/?p=2021

CC: (none) => mageia

P.S. Which ISO(s) did you try. I assume 64-bit, as we don't currently support EFI on the 32-bit ISOs. There is a difference in the boot structure between the classical installer ISOs and the Live ISOs, which shouldn't be important, but you never know...

I'm reminded of when I tried but failed to install Mageia on my relatively new Skylake platform.  There was an arcane procedure I was lucky to find at google that detailed removal of a PK (platform key) in the 'Secure Boot' section of BIOS.
https://www.technorms.com/45538/disable-enable-secure-boot-asus-motherboard-uefi-bios-utility

HP docs for your machine are characteristically hard to find and not very comprehensive about BIOS settings, afaict, but maybe the solution would be similar for you.

CC: (none) => rolfpedersen

I had many problems with an HP 450 Probook 2 years ago, mainly because of shortcomings with its 'boot menu' facilities; e.g. efibootmgr was useless, and eventually had to use Windows to change the boot menu (in my case to default boot the excellent rEFInd boot manager, which - by the way - does not need GRUB).

You have turned Secure Boot off in the UEFI/BIOS?

CC: (none) => maurice

(In reply to Martin Whitaker from comment #2)
> The two things I know are different about the Fedora ISOs is that they
> support secure boot and they support 32-bit EFI. From the links below, I
> don't think you have 32-bit EFI, but you can check by booting Fedora and
> running
> 
>   cat /sys/firmware/efi/fw_platform_size 

It gives 64. And I am sure secureboot is disabled, and Microsoft CA keys removed.

> 
> Mageia uses GRUB2 for EFI boot, not syslinux. This shows it's not just a
> Mageia problem:
> 
>   https://lists.gnu.org/archive/html/bug-grub/2017-12/msg00010.html
> 

That's it, it is not just a Mageia problem, but at least Fedora works... so I wonder if we can make anything better @Mageia EFI boot?

(In reply to José Jorge from comment #6)
> That's it, it is not just a Mageia problem, but at least Fedora works... so
> I wonder if we can make anything better @Mageia EFI boot?

If you tell me which Fedora ISO you are using, I can take a look and see if I can see what's different about it.

(In reply to Martin Whitaker from comment #7)
> If you tell me which Fedora ISO you are using, I can take a look and see if
> I can see what's different about it.

Also which Mageia ISO(s) you tried.

Keywords: (none) => NEEDINFO

(In reply to Martin Whitaker from comment #7)
> If you tell me which Fedora ISO you are using, I can take a look and see if
> I can see what's different about it.

For Fedora this one : 

https://download.fedoraproject.org/pub/fedora/linux/releases/28/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-28-1.1.iso

For Mageia both Live 64 Kde and Netinstall 64 bit. I think netinstall uses the same boot loader as classic installer?

Status: NEW => ASSIGNED
Keywords: NEEDINFO => (none)

Please try this experiment. First plug in your Fedora USB. If it gets auto-mounted, unmount it. For me, this is done by

  umount /run/media/martin/Fedora-WS-Live-28-1-1

but if you are using a different DE, the mount point may be different. Then

  mount /dev/sdX2 /mnt
  cp /mnt/EFI/BOOT/BOOTX64.EFI .
  umount /mnt

Replace sdX with the actual device name assigned to the USB stick, e.g sdb if you only have one other disk in the system. Use a different mount point if you already have something mounted on /mnt.

Then plug in your Mageia Live USB. Again unmount anything that is auto-mounted. Then

  mount /dev/sdX2 /mnt
  mv /mnt/EFI/BOOT/bootx64.efi /mnt/EFI/BOOT/grubx64.efi
  rm /mnt/EFI/BOOT/fonts/unicode.pf2
  cp BOOTX64.EFI /mnt/EFI/BOOT/
  umount /mnt

Now see if you can boot from the modified USB. Check it boots on another machine if not, just to make sure I've written the procedure correctly.

And if it doesn't work, try replacing the /EFI/BOOT/grubx64.efi file on the Mageia USB with the /EFI/BOOT/grubx64.efi file from the Fedora USB.

(In reply to Martin Whitaker from comment #11)
> And if it doesn't work, try replacing the /EFI/BOOT/grubx64.efi file on the
> Mageia USB with the /EFI/BOOT/grubx64.efi file from the Fedora USB.

You had good idea with this one. While only Comment 10 did not boot in this system, replacing the grubx64.efi allows to boot. Then, it cannot go further than our menu "error: can't find command 'linux'".

I have ensured that after comment 10 the key still booted in another EFI system.

(In reply to José Jorge from comment #12)
> You had good idea with this one. While only Comment 10 did not boot in this
> system, replacing the grubx64.efi allows to boot. Then, it cannot go further
> than our menu "error: can't find command 'linux'".

Good, that narrows down where the fault is a lot. I expected it to fail after the boot menu - the Fedora grub image doesn't include the grub modules we use.

Now to compare Fedora's version of grub2 with ours...

@Barry, any advice you could give would be welcome. I see we have some but not all of Fedora's patches.

CC: (none) => zen25000

I have not looked recently, but a few months ago I did try to build a more recent grub2 snapshot which failed to build so I left it alone (if it ain't broke don't fix it).

Regarding Fedora patches there are a lot that are related to secure boot which break things for us, so they are excluded. Some others are simply cosmetic GUI tweaks or arch specific that we don't use. There may be new ones that I have not yet seen.

I can't really help much with this as deciding which Fedora patches to include is rather a case of ill-informed guesswork and intuition (in my case :\ ), they certainly can't all be applied blindly.

Barry

Created attachment 10245 [details]
GRUB EFI boot image built from latest upstream code

OK, thanks Barry. Trial and error it is.

@José, please could you try replacing the grubx64.efi file with this one, which is built using the latest upstream grub-mkimage with no patches.

(In reply to Martin Whitaker from comment #16)
> Created attachment 10245 [details]
> GRUB EFI boot image built from latest upstream code
> 
> OK, thanks Barry. Trial and error it is.
> 
> @José, please could you try replacing the grubx64.efi file with this one,
> which is built using the latest upstream grub-mkimage with no patches.

Done, it does not boot anymore with the attachment 10245 [details].

Thanks José. It will take me a bit longer to prepare the next test. There are a lot of Fedora patches :-(

Another test please José. Could you delete both BOOTX64.EFI and grubx64.efi from /EFI/BOOT on the USB stick, then copy the Fedora grubx64.efi there, but rename it BOOTX64.EFI. That will check whether there is any dependency on the Fedora secure boot shim. I'm hoping not...

Keywords: (none) => NEEDTEST

(In reply to Martin Whitaker from comment #19)
> Another test please José. Could you delete both BOOTX64.EFI and grubx64.efi
> from /EFI/BOOT on the USB stick, then copy the Fedora grubx64.efi there, but
> rename it BOOTX64.EFI. That will check whether there is any dependency on
> the Fedora secure boot shim. I'm hoping not...

And again this solution shows the boot menu.

CC: (none) => lists.jjorge
Keywords: NEEDTEST => (none)

I've now reviewed all the other Fedora patches, and can't find anything that would help with this problem. I'm surprised the upstream patch that fixed bug 23268 didn't work for you, as both the HP and the Direkt-Tek machines are using the same Celeron N3350 processor.

I don't know what else to try.

Mageia 6 changed to end-of-life (EOL) status on 2019-09-30. It is no longer 
maintained, which means that it will not receive any further security or bug 
fix updates.

Package Maintainer: If you wish for this bug to remain open because you plan 
to fix it in a currently maintained version, simply change the 'version' to 
a later Mageia version.

Bug Reporter: Thank you for reporting this issue and we are sorry that we 
weren't able to fix it before Mageia 6's end of life. If you are able to 
reproduce it against a later version of Mageia, you are encouraged to click 
on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a more recent
Mageia release includes newer upstream software that fixes bugs or makes them
obsolete.

If you would like to help fixing bugs in the future, don't hesitate to join the
packager team via our mentoring program [1] or join the teams that fit you 
most [2].

[1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
[2] http://www.mageia.org/contribute/

Best regards,
Aurélien
Bugsquad Team

Status: ASSIGNED => RESOLVED
CC: (none) => ouaurelien
Resolution: (none) => OLD