I queried this upstream and a possible fix is being discussed in this thread:

http://lists.gnu.org/archive/html/grub-devel/2015-03/msg00077.html

From the sidelines, does this particularly matter, if the desired boot-loader can just be re-elevated to first priority in the UEFI BIOS on re-boot?  I'm assuming the original boot-loader is not actually 'clobbered', but still available in the UEFI?

Tonyb

CC: (none) => tablackwell

(In reply to Tony Blackwell from comment #2)
> From the sidelines, does this particularly matter, if the desired
> boot-loader can just be re-elevated to first priority in the UEFI BIOS on
> re-boot?  I'm assuming the original boot-loader is not actually 'clobbered',
> but still available in the UEFI?
> 
> Tonyb

No, if the original bootloader is called "mageia" then it is overwritten, using the workaround (calling it "tmp") avoids this.
A better solution would be to have an option in grub2 to leave the ESP totally untouched, as in my request to grub-devel ML in link above.

Barry

The actual boot order can be left untouched by using the --no-nvram option I think, but I have not tested it. This combined with "tmp" could possibly be a full workaround.

I have done some testing and using:

grub2-install --bootloader-id=tmp --no-nvram

Re-installs grub2 to /boot/grub2 and creates a new core.efi, whilst not changing the EFI bootloader entries or boot order.

So can we use the following for the grub2 install commands, and entries in install.sh?

PC-BIOS 
normal install:
      grub2-install /dev/sdX 
install to root:
      grub2-install --grub-setup=/bin/true /dev/sdXY

UEFI
normal install:
      grub2-install
install to root:
      grub2-install --bootloader-id=tmp --no-nvram

CC: (none) => thierry.vignaud

In the above I'm not 100% sure what you use in PC_BIOS mode, but that is working fine as it is.

My main point is about the UEFI case, where this bug overlaps partly with
https://bugs.mageia.org/show_bug.cgi?id=15692

"--bootloader-id=tmp --no-nvram" did not work in Thomas tests.

Keywords: (none) => NEEDINFO
Blocks: (none) => 416

I will work on it after RC is out.

Could you make progress on this one Thomas?

tmb: " I'd say it's an errata issue... the efi system can handle several bootloaders on esp / nvram, so even if we dont properly support installing to "/" we can live with it and try to fix it for mga6"

CC: (none) => ennael1

It will be added to the errata, decreasing priority.

Keywords: NEEDINFO => (none)
Priority: release_blocker => Normal
Whiteboard: (none) => ERRATA

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

CC: (none) => oberaldo

I think you should look at Bug 16058 discussion (https://bugs.mageia.org/show_bug.cgi?id=16058) because there is more information there. 

If we don't support installing grub2 on /, why this option is still available on the installer? It's not possible to remove this option? 

Thanks!

CC: (none) => woitze

For Mageia 6, I guess we should have a look at at least disabling the option to select an install partition for the bootloader on UEFI (as it only makes sense with a MBR IIUC), and maybe also add an option to put Mageia last in the BootOrder.

(In reply to Geraldo  Witeze Junior from comment #13)

> 
> If we don't support installing grub2 on /, why this option is still
> available on the installer? It's not possible to remove this option? 
> 


For someone with the needed knowledge + the needed amount of time: yes

We do certainly have bright enough people around. However: they have many other obligations and need to earn a living, too. They are volunteers, like all of us.


In case you'd like to help fix the code, it comes from one or more of the following files. I'm not smart enough to know from which one(s):

http://gitweb.mageia.org/software/drakx/tree/perl-install/any.pm
http://gitweb.mageia.org/software/drakx/tree/perl-install/install/steps_interactive.pm  
http://gitweb.mageia.org/software/drakx/tree/perl-install/bootloader.pm               
http://gitweb.mageia.org/software/drakx/tree/perl-install/install/any.pm

CC: (none) => marja11

You want to look at write_grub2_install_sh() function in bootloader.pm :
http://gitweb.mageia.org/software/drakx/tree/perl-install/bootloader.pm?id=ab9277b3b0d#n1830

(In reply to Rémi Verschelde from comment #14)
> For Mageia 6, I guess we should have a look at at least disabling the option
> to select an install partition for the bootloader on UEFI (as it only makes
> sense with a MBR IIUC), and maybe also add an option to put Mageia last in
> the BootOrder.

Well no, it makes sense to be able to install grub2 without touching the the ESP, so / is still correct in this case as the grub2 files are installed under /.

From my testing in a normal environment, the solution that I proposed in #5 worked fine:

grub2-install --bootloader-id=tmp --no-nvram

The only issue was that for some reason it apparently failed in the installer.

@Thierry
Could you add that to drakboot anyway?
It would then at least work correctly after install.

(In reply to Marja van Waes from comment #15)
> (In reply to Geraldo  Witeze Junior from comment #13)
> 
> > 
> > If we don't support installing grub2 on /, why this option is still
> > available on the installer? It's not possible to remove this option? 
> > 
> 
> 
> For someone with the needed knowledge + the needed amount of time: yes
> 
> We do certainly have bright enough people around. However: they have many
> other obligations and need to earn a living, too. They are volunteers, like
> all of us.
> 
> 
> In case you'd like to help fix the code, it comes from one or more of the
> following files. I'm not smart enough to know from which one(s):
> 
> http://gitweb.mageia.org/software/drakx/tree/perl-install/any.pm
> http://gitweb.mageia.org/software/drakx/tree/perl-install/install/
> steps_interactive.pm  
> http://gitweb.mageia.org/software/drakx/tree/perl-install/bootloader.pm     
> 
> http://gitweb.mageia.org/software/drakx/tree/perl-install/install/any.pm

Marja, I don't know how to fix the code because I'm not a programmer. I can help only relating a bug (or, as in the present case, translating the problem as related by another user). I always hear that we need to relate the bugs for they could be corrected and I just tried to do this. 

Thank you all for the attention, work and time dedicated to this project. I appreciate it so I'm trying to help as I can. I believed that raising some questions would be useful, but maybe I was wrong. That's ok, I'm sorry if it was the case. If I knew how to program be sure that I would do that and not only relate the bug. Everyone helps as possible.

(In reply to Geraldo  Witeze Junior from comment #18)

> 
> Marja, I don't know how to fix the code because I'm not a programmer. I can
> help only relating a bug (or, as in the present case, translating the
> problem as related by another user). I always hear that we need to relate
> the bugs for they could be corrected and I just tried to do this. 

That is perfect, thanks
> 
> Thank you all for the attention, work and time dedicated to this project. I
> appreciate it so I'm trying to help as I can. I believed that raising some
> questions would be useful, but maybe I was wrong. 

It was certainly *not* wrong :-D

> If I knew how to program be sure that I would do that and not
> only relate the bug. Everyone helps as possible.

Indeed, and that's fine.

However, if you know any non-programmers in the Mageia community with _spare_time_, please tell them that all our programmers were non-programmers before they became programmers ;-)

http://perl-begin.org/

(In reply to Thierry Vignaud from comment #16)
> You want to look at write_grub2_install_sh() function in bootloader.pm :
> http://gitweb.mageia.org/software/drakx/tree/perl-install/bootloader.
> pm?id=ab9277b3b0d#n1830

Thanks, Thierry!

(In reply to Barry Jackson from comment #17)
> (In reply to Rémi Verschelde from comment #14)
> > For Mageia 6, I guess we should have a look at at least disabling the option
> > to select an install partition for the bootloader on UEFI (as it only makes
> > sense with a MBR IIUC), and maybe also add an option to put Mageia last in
> > the BootOrder.
> 
> Well no, it makes sense to be able to install grub2 without touching the the
> ESP, so / is still correct in this case as the grub2 files are installed
> under /.
> 
> From my testing in a normal environment, the solution that I proposed in #5
> worked fine:
> 
> grub2-install --bootloader-id=tmp --no-nvram
> 
> The only issue was that for some reason it apparently failed in the
> installer.
> 
> @Thierry
> Could you add that to drakboot anyway?
> It would then at least work correctly after install.

After further testing on real hardware I can find no problem with the above, can it be implemented until a better solution is found for the installer? 

Also:
Why is this flagged as depending on
https://bugs.mageia.org/show_bug.cgi?id=16440
I see no connection.

Thomas (In reply to Thomas Backlund from comment #8)
> I will work on it after RC is out.

Ping?

Do we've a grub2 fix yet?

(In reply to Thierry Vignaud from comment #22)
> Do we've a grub2 fix yet?

No new option for grub2-install if that is what you mean.
The thread on grub ML died here:
http://lists.gnu.org/archive/html/grub-devel/2015-03/msg00081.html

I just gave Vladimir another ping on IRC about it but I would not hold your breath.

I think we will need to use the workaround somehow.

Ah!
I just found a mail that I had missed on this, and have replied to Andrei who may just be able to come up with a patch, so there is hope.

Created attachment 8044 [details]
do not overwite ESP if not installing on it

In the meantime, can you test this patch?
To be applied as root:
cd /usr/lib/libDrakX
patch -p1 < /where/it/was/downloaded/0001-do-not-overwite-ESP-if-not-installing-on-it.patch

Perfect!

That works fine from drakboot in a running system here.

It correctly re-writes install.sh and on re-boot it has not affected nvram.

The machine boots correctly into my 'Master' grub2 bootloader and the Mageia 6 system that was modified by drakboot still chainloads correctly from it.

I will try to test this in the installer tomorrow if I can find space for another net install.

The only minor (unrelated) issue that I notice in drakboot is that the 'Please Wait' dialog which appears during the grub2-install/os-prober operation is just plain black (like a small terminal screen).

That's a gtk+3.0 issue

commit 9b6c7b4d612acc1ad8c6f9d573f50993e7e10832
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Wed Jun 22 00:44:03 2016 +0200

    do not overwite ESP if not installing on it
    
    temporary hack for mga#15583
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=9b6c7b4d612acc1ad8c6f9d573f50993e7e10832

Closing

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

I have done an upgrade test from Mageia5 to 6 by doing a clean net-install of Mageia5 on real UEFI h/w and then a net-install upgrade to Cauldron.

The upgrade goes fine, but despite selecting "Don't write into MBR/ESP" option at Summary the nvram was clobbered.

I suspect that the install.sh from the original Mageia5 was used.

There is now an install.sh with the correct --no-nvram etc. and an install.sh.old containing just "grub2-install" which is how it would have been in the clean Mga5 install.

When I previously tested an upgrade from Mga6 to Mga6 (when testing a newer stage2) the old install.sh would have already had the --nonvram etc. and this did not happen.

If you need logs just let me know which.
(Note to self: /dev/sda2)

Please attach your /root/drakx/report.bug.xz file

Created attachment 8072 [details]
report.bug.xz from mga5 (drakx v16.105)

Created attachment 8073 [details]
report.bug compressed into xz

The above was for the the initial Mga5 install, this report.bug is for the upgrade AFAICT which I have compressed.
There was only the one report.bug.xz

That's just grub2-common 's %posttrans running the old /boot/grub2/install.sh

Drakx is fine.
Closing as there's nothing DrakX can do there and that was a rare use case.
If you do care, just skip running /boot/grub2/install.sh on grub2-common upgrade if DURING_INSTALL env variable is set

See msec, mageia-theme-Default or radeon-firmware for examples.

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

Thanks, so does this look OK?

--- SPECS/grub2.spec	(revision 1037736)
+++ SPECS/grub2.spec	(working copy)
@@ -20,7 +20,7 @@
 %global tarversion	2.02~beta3
 %global pc_arch i386-pc
 %define git	10457
-%define rel	7
+%define rel	8
 
 Name:		grub2
 Version:	2.02
@@ -339,7 +339,7 @@
 %posttrans common
 # On update re-install grub2 to where it was installed by drakboot if possible,
 # otherwise next boot may fail due to mismatched boot code.
-   if [ -f /boot/grub2/updtrans ] && [ -f /boot/grub2/install.sh -a -x /usr/sbin/detectloader ]; then
+   if [ -f /boot/grub2/updtrans ] && [ -f /boot/grub2/install.sh -a -x /usr/sbin/detectloader ] && [ "$DURING_INSTALL" != "1" ] ; then
 		LOADER=$(/usr/sbin/detectloader)
 		[ "$LOADER" = "GRUB2" ] && /boot/grub2/install.sh ||:
 		rm -f /boot/grub2/updtrans

Yep.
Boot loader will be set up by drakx anyway later at summary step.

Should this

# Don't let rpmdrake ask users to shoot themselves in feet! Mga#17263
rm -f /etc/default/grub.rpm*

now be moved outside that conditional so it's always applied?

Maybe it always should have been.

Yes that's unrelated

OK changes pushed - forgot to mention this bug so will propedit /o\

(W.r.t. Comment 17)

> grub2-install --bootloader-id=tmp --no-nvram
> The only issue was that for some reason it apparently failed in the installer.

  Is this vital "Do not touch MBR..." Advanced option component now working in the 19/1/2017 classical .iso's installer?

CC: (none) => maurice

(In reply to Maurice Batey from comment #40)
> (W.r.t. Comment 17)
> 
> > grub2-install --bootloader-id=tmp --no-nvram
> > The only issue was that for some reason it apparently failed in the installer.
> 
>   Is this vital "Do not touch MBR..." Advanced option component now working
> in the 19/1/2017 classical .iso's installer?

Sorry Maurice I don't understand your question - please expand.

Comment 17 reported that the "--no-nvram" setting  'apparently failed in the installer'.

I need it NOT to fail in the installer (as do not want NVRAM changed)!

Hence the big question: Is it now working....?"

(In reply to Maurice Batey from comment #42)
> Comment 17 reported that the "--no-nvram" setting  'apparently failed in the
> installer'.
> 
> I need it NOT to fail in the installer (as do not want NVRAM changed)!
> 
> Hence the big question: Is it now working....?"

If you are talking about upgrade from Mga5 to Mga6 using the installer, then I would edit /boot/grub2/install.sh and add at least the --no-nvram to it in Mga5 before the upgrade.
A clean install should be OK if you select the "Do not touch..."

No, I never do upgrades - just fresh installs.

'should' be OK?! I think perhaps I'll wait for first-hand confirmation, as I cannot afford to have an NVRAM Boot array change on the UEFI/GPT HP laptop, after all the hassle I had a year ago trying to get it to boot anything but Windows!

Alternatively - just to get Mageia-6 installed on it, I'm considering aborting the install as soon as it gets onto 'boot configuration', i.e. once the Mageia-6 non-grub files have been installed in its /.
  (I don't need the grub_64.efi file (or any other Grub file) , as rEFInd can boot straight into /boot's vmlinuz.)

(No feedback yet on my https://bugs.mageia.org/show_bug.cgi?id=19949 )