what have you configured ? and where ? on /, MBR, other ?

Keywords: (none) => NEEDINFO

Configuring grub2 on an  Asus X75VD-TY139H with EFI boot.
Can't configure MBR.

ok thanks

Keywords: NEEDINFO => (none)
Blocks: (none) => 416
Summary: drakboot crashed => drakboot crashed (grub2 with uefi)

(In reply to Daniel Tartavel from comment #2)
> Configuring grub2 on an  Asus X75VD-TY139H with EFI boot.
> Can't configure MBR.

Do you have grub2-efi installed and did you read /usr/share/doc/grub2/README.efi ?

CC: (none) => zen25000

We should install grub2-efi instead of grub2 on machines with EFI boot.
The question is how to detect them (I've no such hardware to test...)

CC: (none) => thierry.vignaud

Colin, Pascal: any idea how to detect machines booting through EFI?

CC: (none) => mageia, pterjan

Not sure. Perhaps efivars kernel module would not load?

Or if it loads, perhaps:
mount -t efivarfs efivarfs /sys/firmware/efi/efivars
would fail?

Actually, just thinking about it... there is likely something in /sys/firmware/efi that tells you.

Perhaps /sys/firmware/efi/systab?

e.g. mine contains:

ACPI20=0xaabbccdd
ACPI=0xaabbccdd
SMBIOS=0xaabbccdd

(not those values, but you get the gist)

This is booting with EFI via gummiboot.


Speaking of which, I'd like to add bootloader support for gummiboot as this seems to be the EFI bootloader gaining most traction just now - it's designed to be very light weight (i.e. it needs the kernel to have an EFI stub and doesn't contain any crazy filesystem drivers and basically a whole mini-OS like grub2 does. As the ESP partition is fat anyway, we can just keep the kernel and initrd (if the initrd is even needed for the given setup - I'm happily booting without one here on my cauldron box)

I was recently thinking we should consider to always creating a /boot ESP partition in vfat format even on non-UEFI machines (except in expert mode). This just helps reduce the delta on different configurations and as EFI boots mandate this, it's the lowest common denominator.

If we do do this, all the complexity of grub2 is basically unneeded as the whole "pre-boot Operating System" is already handled in the form of the initrd... Obviously this won't be acceptable to everyone, ("eugh fat is evil" etc). but it would certainly make the whole bootloader stage a lot simpler and more light weight.... food for through perhaps?

I'm going to take a crack at making our tools handle the lack of symlinks in /boot more gracefully and make bootloader-config generate gummiboot entries files.

*"food for thought" even :)

Created attachment 3601 [details]
install grub2-efi if needed

@Colin:
Can you check there's something in /sys/firmware/efi in installer?
If yes, can you try this patch?
It should install grub2-efi if needed

Checking for efi mode is simple.

If you boot a efi capable system/kernel in efi mode, the dir /sys/firmware/efi will exist.

if yout boot the same system/kernel with efi disabled, the /sys/firmware/efi will not exist.

Then we should make installer detect the ESP partition, it is type FE and formatted as FAT32, and must have boot flag set.


As installer does not know how to do gpt partitioning I guess we should document it on wiki for mga3 and se if we can add proper gpt partitioning in installer for that. 

And suggest some 512M for ESP

CC: (none) => tmb

(In reply to Thomas Backlund from comment #10)
> Checking for efi mode is simple.
> 
> If you boot a efi capable system/kernel in efi mode, the dir
> /sys/firmware/efi will exist.
> 
> if yout boot the same system/kernel with efi disabled, the /sys/firmware/efi
> will not exist.
> 
> Then we should make installer detect the ESP partition, it is type FE and
> formatted as FAT32, and must have boot flag set.
> 
> 
> As installer does not know how to do gpt partitioning I guess we should
> document it on wiki for mga3 and se if we can add proper gpt partitioning in
> installer for that. 

for mga4 that is.

> And suggest some 512M for ESP

(In reply to Thomas Backlund from comment #11)
> (In reply to Thomas Backlund from comment #10)
> > Checking for efi mode is simple.
> > 
> > If you boot a efi capable system/kernel in efi mode, the dir
> > /sys/firmware/efi will exist.
> > 
> > if yout boot the same system/kernel with efi disabled, the /sys/firmware/efi
> > will not exist.
> > 
> > Then we should make installer detect the ESP partition, it is type FE and
> > formatted as FAT32, and must have boot flag set.
> > 
> > 
> > As installer does not know how to do gpt partitioning I guess we should
> > document it on wiki for mga3 and se if we can add proper gpt partitioning in
> > installer for that. 
> 
> for mga4 that is.
> 
> > And suggest some 512M for ESP

So is there anything that needs to be done now for mga3?

If this bug cannot be fixed for mga3 then it no longer needs to be release critical. ( i.e. blocking 416 )

*** Bug 10096 has been marked as a duplicate of this bug. ***

CC: (none) => joequant

(In reply to Colin Guthrie from comment #7)
...
> Speaking of which, I'd like to add bootloader support for gummiboot as this
> seems to be the EFI bootloader gaining most traction just now - it's
> designed to be very light weight (i.e. it needs the kernel to have an EFI
> stub and doesn't contain any crazy filesystem drivers and basically a whole
> mini-OS like grub2 does. As the ESP partition is fat anyway, we can just
> keep the kernel and initrd (if the initrd is even needed for the given setup
> - I'm happily booting without one here on my cauldron box)
> 
> I was recently thinking we should consider to always creating a /boot ESP
> partition in vfat format even on non-UEFI machines (except in expert mode).
> This just helps reduce the delta on different configurations and as EFI
> boots mandate this, it's the lowest common denominator.
> 
> If we do do this, all the complexity of grub2 is basically unneeded as the
> whole "pre-boot Operating System" is already handled in the form of the
> initrd... Obviously this won't be acceptable to everyone, ("eugh fat is
> evil" etc). but it would certainly make the whole bootloader stage a lot
> simpler and more light weight.... food for through perhaps?

I'd like to see something like gummiboot that would support booting non-efi matchines.
Would this be possible on systems without gpt, without modifying gummiboot ?
If not, on non-efi systems with gpt ?

To me, having a light-weight universal boot loader that is os-agnostic (including different versions of linux) is certainly the way to go.

CC: (none) => andre999mga

*** Bug 10796 has been marked as a duplicate of this bug. ***

I suppose my KDE-automated bug report was the one that duplicated this. Tant pis.

Necessarily using the latest beta1 64-bit Live KDE DVD (USB stick) for installation.

So, installation on a real EFI box with Cymraeg language (which had caused boot failure previously), French time & k/b, with a more recent grub2-efi (2.00-54.1.mga4.x86-64.rpm) failed in a like manner.

I write now re a simpler install with English language, French time & k/b which fails similarly with the the default grub2-efi (cannot cite its ID, sorry).

Same problem. No Mageia4.

CC: (none) => lewyssmith

Pardon me for letting loose, but I have only just read through this bug.

I have a real EFI box (necessarily GPT) with the ghastly Win8. Most computers bought since 2012 will be thus. EFI is too often tied to 'secure boot' *which is a separate issue*. Never mind. I have now installed 5 Linux's, with varying degrees of difficulty from non at all to outright failure; only Mageia either fails to install, or does not boot subsequently. All the others boot OK and work - mostly.

The problem is (I think) *just in the grubx64-efi put into \EFI\mageia\ *. All the other distributions basically just do that, plus a bit more to varying degrees like adding themselves to the NVRAM OS list and BootOrder, just a few efibootmgr calls - more or less necessary, but one distro did not even do that! - to at worst overwriting the default bootloader \EFI\Boot\bootx64.efi and putting a load of secure boot related stuff in its own EFI directory.

I do not know about the need to build special 'stub' kernels, the makeup of the various kernels involved. It is worth noting that one of the distros I have started by putting, in addition to grubx64-efi, a kernel (stub?) and 2 different initrd's into its \EFI\distro\ directory. It has now retreated to just grubx64.efi .

The fact that I got 1 variant of the M4beta1's to not just install, but boot by obscure means, shows that Mageia is very nearly there.

Now to boot managers. Comment 7 says 
> "I'd like to add bootloader support for gummiboot as this seems to be the EFI
> bootloader gaining most traction just now - it's designed to be very light
> weight (i.e. it needs the kernel to have an EFI stub and doesn't contain any
> crazy filesystem drivers and basically a whole mini-OS like grub2 does." 

By chance, the first distro I tried (with kernel & initrd as well as Grub in its EFI directory) got by by installing as well *rEFInd* into \EFI\refind\* , which has been a lifesaver ever since. I have no experience of GumiBoot, but rEFInd is marvelous; it detects *dynamically* available OS's, you do not even need its config file. (In fact I am considering one to by-pass a couple of inconveniences).

You must always:
 Put a working grubx64.efi into \EFI\mageia\ . This is already done (when it gets that far), it is just the Grub itself that is problematic.
 Add a Mageia entry into the EFI NVRAM and BootOrder list. Again, this is already done if it gets that far.
Even at this point, you should be able to boot Mageia from at least the EFI boot menu, raised in my case by F12 *quickly* on startup. This is not ideal, but better than nothing.

If rEFInd is already installed, and presumably active, it will find Mageia. Perhaps the same is true of GummiBoot. If neither exists, it is certainly worth installing it as well, since this involves no more than creating \EFI\refind\ and copying it there, then adding it also into the NVRAM and BootOrder [1st]. More radically...
 *Backup the existing* \EFI\Boot\bootx64.efi .
 Copy refind's equivalent (was refind.efi but may be now bootx64.efi) to that location/filename.

What exactly happens depends on how well behaved the EFI BIOS is. Mine is iffy, so I know nothing of the effect of the 'active' flag for EFI OS entries. Getting rEFInd automatically started (rather than Win8 in my case) is a "your mileage may vary" situation. I won after months.

Keep up the good work!

This bug still has the status "NEW", so installing Mageia on an EFI system still doesn't work out of the box?

I can help test, but would like to know (in case several tests are needed) what the best and fastest way is to revert to the current state of my EFI / GPT laptop. 

How should I clone all partitions: 3 ntfs-3g, 1 vfat, 2 other (I can't see what those 2 contain, maybe they only contain empty space :-/) and restore them for the next test, using the Mageia *3* live DVD?

CC: (none) => davidwhodgins, eeeemail, marja11, qa-bugs

 (In reply to Marja van Waes from comment #18)

> How should I clone all partitions: 3 ntfs-3g, 1 vfat, 2 other (I can't see
> what those 2 contain, maybe they only contain empty space :-/) and restore
> them for the next test, using the Mageia *3* live DVD?

*3*  because Mga4rc and beta2 Lives don't work on it

Marja: do you see the QA mail list? I have posted EFI success there.

Briefly, I eventually got 64-bit Mag4Beta2 KDE Live DVD to install on a multi-system EFI box, and the RC first round equivalent. You have to follow special procedures (posted originally in the QA mail list), so 'out of the box' is not yet true. More so because EFI is only available for *live* installations, not Classic ones. It does not matter what other systems are already installed. Don't understand the cloning business you mention.

Can we talk either directly or via the QA mail list to discuss your questions? This bug does not seem the best place.

(In reply to Lewis Smith from comment #20)
> Marja: do you see the QA mail list? I have posted EFI success there.
> 
> Briefly, I eventually got 64-bit Mag4Beta2 KDE Live DVD to install on a
> multi-system EFI box, and the RC first round equivalent. You have to follow
> special procedures (posted originally in the QA mail list), so 'out of the
> box' is not yet true. More so because EFI is only available for *live*
> installations, not Classic ones. It does not matter what other systems are
> already installed. Don't understand the cloning business you mention.


Well, I'm interested in helping test an "out of the box" solution. If there is nothing to test, yet, then I'll either wait, or workaround it and revert the laptop to its original state as soon as there is something to test.

With cloning I meant making an exact backup of every bit and partition on the disk. I've now only run "cp -a" for the nfts-3g and vfat partitions, but the other partitions can't be copied like that. There must be a better solution. 

> 
> Can we talk either directly or via the QA mail list to discuss your
> questions? This bug does not seem the best place.

Well, we could maybe talk about getting your method in the wiki (assumed it is pretty universal), AFAIK all we have is
https://wiki.mageia.org/en/Installation_with_GPT_Partition_Table
https://wiki.mageia.org/en/UEFI_booting
and about what to say in the Mageia 4 errata

cc'ing documentation team

CC: (none) => doc-bugs
Whiteboard: (none) => 4RC

Marja
I still think that this bug is not the best place to sort this matter. BTAIM...

> Well, I'm interested in helping test an "out of the box" solution. If there
> is nothing to test, yet, then I'll either wait, or workaround it
The solution *is* effectively out-of-the-box since it started working for Mageia4. It is just that you have to do certain specific things for installation - which will need to be communicated to the public until incorporated as automatic. You certainly have something you can easily test! Do not despair.

> I'll either wait, or workaround it and revert
> the laptop to its original state as soon as there is something to test.
> With cloning I meant making an exact backup of every bit and partition on
> the disk. I've now only run "cp -a" for the nfts-3g and vfat partitions, but
> the other partitions can't be copied like that. There must be a better
> solution. 
I am puzzled by both these requirements:

* Revert the box to its original state.
If you have (or can make) >=10Gb spare disc space for Mageia, this should not have anything to do with other installed systems. Why the need to revert when you can keep all that you have already have alongside Mageia?

* Cloning.
I know what cloning is! I wonder about why you want to do it, whether you need to. Certainly using cp is *not* the way to do it. Things like Clonezilla, FSarchiver are. I use partclone on my MBR box, but do not know if it handles GPT.
 
> Well, we could maybe talk about getting your method in the wiki (assumed it
> is pretty universal), AFAIK all we have is
> https://wiki.mageia.org/en/Installation_with_GPT_Partition_Table
> https://wiki.mageia.org/en/UEFI_booting
It is not 'my' method, but that prescribed by the development people to QA. Certainly it needs documenting somewhere until Magiea takes EFI in its stride, and I am happy to to that. I have looked at both Wikis and think that they are now effectively out of date, unnecessarily tortuous. I would need advice about how to combine and update them.

*Please* can we talk privately so that you can tell me what you have, what you want, why you need (or think you need) to clone partitions and revert your box. If I can get Mag4 (Live 64-bit) to install on my EFI box, it should work for anyone: currently, who can boot the box from USB stick. It is only the ultimate booting which is iffy, but you should be able to always manage it somehow.

@ Lewis

thanks for all the effort you put in replying.

I should have commented here that I started a page with tmb's dev-ml instructions
https://wiki.mageia.org/en/UEFI_how-to

*** Bug 13270 has been marked as a duplicate of this bug. ***

CC: (none) => gramo.gnu

*** Bug 13319 has been marked as a duplicate of this bug. ***

CC: (none) => linuxero

Fixed in cauldron

Please reopen and set version to 4 if this still needs to be fixed in Mageia 4

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