Also effects:

Mageia-6-sta1-LiveDVD-PLASMA5-x86_64-DVD.iso
md5sum: eab7b1ca91523be67efffbdffcbaa37b

All live isos released on 06/19/16 suffer from the same install error.

also occurs real hardware, custom disk partitioning, GPT HDD, bootloader to MBR HDD

CC: (none) => westel

Created attachment 8029 [details]
report lspcidrake -v

Sigh, so installer is really not triggering grub2 install anymore :/

It used to do so when grub legacy was default and user switched to grub2 (or installer detected efi and switched to grub2-efi by itself)


I'm starting to think switching to grub2 by default was /is a really idiotic choice (and yeah I was one of the guilty ones deciding so...) since the other bugs and limitations of grub2 keeps biting us too...


@Thierry,

are we missing something like "$do_pkgs->ensure_binary_is_installed()" on bootloader section that would cope with this?

The problem is because of grub2 <-> grub2-efi conflict, as a last step on iso generation I do a "rpm -e --nodeps grub2" so installer can pick either grub2 or grub2-efi from "Live Core" media during install without getting hit by installer giving up on rpm conflict as found in bug 18712

Really adding Thierry in cc would probably help.... 

Thierry, see comment 5

CC: (none) => thierry.vignaud

That's because both grub2{,-efi} provides the same grub2-reboot binary we check in order to see if we need to install the package or not.
I'll alter that.

Yeah, but since I "rpm -e" the grub2-reboot is not on the iso, so shouldn't it still trigger install?

Ah, now I see... in mga5 it was both in grub2 and grub2-efi, but now it's in grub2-common that is still on iso

So will you just remove grub2-common from the ISO in the short term?

Thanks all for the quick action confirming this.

Is this basically the same thing as:

https://bugs.mageia.org/show_bug.cgi?id=18724

(In reply to Thierry Vignaud from comment #10)
> So will you just remove grub2-common from the ISO in the short term?

yeah, I can do that

(In reply to Thomas Backlund from comment #13)
> (In reply to Thierry Vignaud from comment #10)
> > So will you just remove grub2-common from the ISO in the short term?
> 
> yeah, I can do that


ok, that didnt help :/

doing "rpm -e --nodeps grub2-common" on a live system before starting the install only results in "Could not install the gub2 package!" at bootloader stage.

And if I read the code correctly it's because the whereis_binary() checks for grub2-reboot -> tries to install grub2-common ->  gets the choice of grub2 vs grub2-efi and stops there...

But come to think of it, checking for grub2-reboot is now incorrect since its in common package and not in primary loader package anymore...

I guess rewriting that code part to check based on is_uefi() to check for grub2 vs grub2-efi package is the way to go...

commit 0f32b38048f50cceed0f01b693086691909418ab
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Mon Jun 20 17:24:00 2016 +0200

    ensure we've the right grub2 flavor (mga#18739)
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=0f32b38048f50cceed0f01b693086691909418ab

Fixed.
You'll need drakxtools-17.40 for draklive-install & the same version of stage2 for the regular ISOs (though that's not a problem there as we picked the right grub2 flavor first)

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

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

Sorry. but still a no-go :/


Now I get "The package grub2 needs to be installed, Do you want to install it?"

pressing next gives "Could not istall the grub2 package!"

The only thing I see when started from terminal is that when it fails to install, it writes:

(gurpmi:21965): Gtk-WARNING **: cannot open display: :0
No protocol specified
Unable to init server: Could not connect: Connection refused


doing a manual "urpmi grub2" installs it without problems

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

Well we use gurpmi since forever.
There's sg fishy for you as DISPLAY=:0 is broken.

Is that when running draklive or draklive-install?

thats draklive-install running...

Hm, I guess this is now a fallout of gnome needing polkit to allow draklive-install to start at all (as it need root privilegies)...

in mga5 draklive-install got started with:

/usr/sbin/draklive-install-lock-storage

but for mga6 I now call a wrapper

cat draklive-install-wrapper 
#!/bin/sh
/usr/bin/pkexec /usr/sbin/draklive-install-lock-storage



and the matching policy config

# cat org.mageia.draklive-install-lock-storage.policy
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>

 <vendor>Mageia</vendor>
 <vendor_url>http://www.mageia.org/</vendor_url>

 <action id="org.mageia.draklive-install-lock-storage.pkexec.run">
    <description>Run draklive-install</description>
    <message>Authentication is required to run Mageia Draklive Installer</message>
    <icon_name>draklive-install</icon_name>
    <defaults>
     <allow_any>yes</allow_any>
     <allow_inactive>no</allow_inactive>
     <allow_active>yes</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/draklive-install-lock-storage</annotate>
    <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
 </action>
</policyconfig>


(and yes, I really need to commit all my changes to git as soon as I get them to work)

Created attachment 8032 [details]
enable to disable gurpmi usage

Can you try this?
If this works, we can patch drakxtools & make draklive-install set/export DISABLE_GURPMI=1 as environment variable.

But if polkit makes a forked process fails to access X.org just after the parent process verified the said X.org access, something is really fishy...

@Colin: please see my latest comment. WDYT is happening?

CC: (none) => mageia

Adding the following line in /etc/pam.d/polkit-1:
session optional pam_xauth.so

makes gurpmi work, and it it installs grub2 in the chroot, but after that I get "mandatory package grub2 missing"

Are you sure it's in your repo?

Yep. as pointed out in comment 23 it gets installed...

and:
# urpmq --sources grub2
/var/local/mga_rpms/core/grub2-2.02-0.git10457.7.mga6.i586.rpm

Hm,
come to think of it... does the "mandatory package grub2 missing" check read the live media and not the chrooted one ?

the /var/local/mga_rpms/core/grub2-2.02-0.git10457.7.mga6.i586.rpm is both ins live and chroot, but if it does rpm -q  in live media it wont see anything as it was installed in the chroot

My bad.
I don't pass a right path to check:
http://gitweb.mageia.org/software/drakx/commit/perl-install/bootloader.pm?id=0f32b38048f50cceed0f01b693086691909418ab
My check is OK for guessing if we need to install the package, but not for the after install check

Created attachment 8033 [details]
fix the grub2 post-install check (mga#18739)

Can you try this?

commit 60af921c04dda14b5a6f9cf8c134dda4a28448a6
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Mon Jun 20 22:53:03 2016 +0200

    fix the grub2 post-install check (mga#18739)
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=60af921c04dda14b5a6f9cf8c134dda4a28448a6

OK, this time I rerun drakboot after having manually run "urpmi grub2" so that I checked:
- that the 1st time, it installs the right "grub2-efi"
- and that the 2nd time there wasn't any error

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

@Barry: Interestingly, grub & grub2-efi can coexist on FC24
(binaries are shared in grub2-tools)

(In reply to Thierry Vignaud from comment #31)
> @Barry: Interestingly, grub & grub2-efi can coexist on FC24
> (binaries are shared in grub2-tools)

We did discuss this possibility some time ago, however I did not want to risk strange issues arising as a result of both being available, and there was also the unnecessary bloat of having both sets of modules when only one is required.

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

CC: (none) => bequimao.de