Bug 16030 - install.sh in PC-BIOS mode needs to specify --directory for mixed BIOS mode hardware
Summary: install.sh in PC-BIOS mode needs to specify --directory for mixed BIOS mode h...
Status: RESOLVED INVALID
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: Thierry Vignaud
QA Contact:
URL:
Whiteboard: IN_ERRATA MGA5TOO
Keywords: NEEDINFO
Depends on:
Blocks: 416
  Show dependency treegraph
 
Reported: 2015-05-23 22:10 CEST by Barry Jackson
Modified: 2016-05-22 14:02 CEST (History)
3 users (show)

See Also:
Source RPM: drakxtools-16.99-1.mga5
CVE:
Status comment:


Attachments
add needed parameter (590 bytes, patch)
2015-05-24 00:00 CEST, Thierry Vignaud
Details | Diff
add needed parameter v2 (592 bytes, patch)
2015-05-24 12:26 CEST, Thierry Vignaud
Details | Diff

Description Barry Jackson 2015-05-23 22:10:52 CEST
Description of problem:
If a Mageia system with grub2 is installed in PC-BIOS mode it's /boot/grub2/install.sh assumes that the system is running in PC-BIOS mode.

However the above system may be listed in the grub2 menu of another system (system2) which was installed under UEFI. (hybrid BIOS hardware)

If system1 is booted from the boot menu of system2 it works fine - except when grub2-install is called from install.sh where it errors out as follows:

grub2-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory.

It seems that since it was booted from a UEFI version of grub2, that it thinks it is a UEFI system and tries to use the -efi modules which are not there.

Adding --directory=/usr/lib/grub/i386-pc to the grub2-install command in install.sh for PC_BIOS systems fixes this.

e.g.
grub2-install --directory=/usr/lib/grub/i386-pc --grub-setup=/bin/true /dev/sda8
grub2-install --directory=/usr/lib/grub/i386-pc /dev/sda

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce: As above
1.
2.
3.


Reproducible: 

Steps to Reproduce:
Barry Jackson 2015-05-23 22:13:24 CEST

Priority: Normal => release_blocker
Assignee: bugsquad => thierry.vignaud
Source RPM: drakboot => drakxtools-16.99-1.mga5
Severity: major => critical

Thierry Vignaud 2015-05-24 00:00:08 CEST

Blocks: (none) => 416

Comment 1 Thierry Vignaud 2015-05-24 00:00:26 CEST
Created attachment 6624 [details]
add needed parameter

Can you test this?
Comment 2 Barry Jackson 2015-05-24 11:24:14 CEST
I patched bootloader.pm locally on a new PC-BIOS install from yesterday's KDE live iso - All testing so far in purely PC-BIOS mode.

I ran mcc -> boot -> and selected / as target:-

The "drakboot" program has crashed with the following error:

  grub2-install failed: Installing for i386-pc platform.
  grub2-install: error: install device isn't specified.
  	...propagated at /usr/lib/libDrakX/any.pm line 268.
  	...propagated at /usr/libexec/drakboot line 64.
  Perl's trace:
  drakbug::bug_handler() called from /usr/libexec/drakboot:64

Used theme: oxygen-gtk

--------------------------------------------------------

To test grub2-install outside bootloader.pm I then ran:

[root@localhost grub2]# grub2-install --directory=/usr/lib/grub/i386-pc --grub-setup=/bin/true /dev/sdb18
Installing for i386-pc platform.
Installation finished. No error reported.

--------------------------------------------------------

To check it was patched ok here is a snippet from the patched bootloader.pm:

 my @options;
    if (is_uefi()) {
    } else {
	@options = '--directory=/usr/lib/grub/i386-pc', $boot =~ /\d$/ ? ('--grub-setup=/bin/true', $boot) : $boot;
    }
    renamef($f, $f . ($o_backup_extension || '.old'));


--------------------------------------------------------

Testing with /dev/sda as the target I get the same error:

The "drakboot" program has crashed with the following error:

  grub2-install failed: Installing for i386-pc platform.
  grub2-install: error: install device isn't specified.
  	...propagated at /usr/lib/libDrakX/any.pm line 268.
  	...propagated at /usr/libexec/drakboot line 64.
  Perl's trace:
  drakbug::bug_handler() called from /usr/libexec/drakboot:64

Used theme: oxygen-gtk

-------------------------------------------------------
Comment 3 Thierry Vignaud 2015-05-24 12:00:55 CEST
Please attach your /boot/grub2/install.sh

Keywords: (none) => NEEDINFO

Comment 4 Barry Jackson 2015-05-24 12:11:38 CEST
grub2-install --directory=/usr/lib/grub/i386-pc

So it's not adding target :\
Comment 5 Barry Jackson 2015-05-24 12:19:04 CEST
Reverting the patch and installing to / gives: (in install.sh)

grub2-install --grub-setup=/bin/true /dev/sdb18
Comment 6 Thierry Vignaud 2015-05-24 12:26:37 CEST
Created attachment 6632 [details]
add needed parameter v2

(sorry, missing parenthesis)

Attachment 6624 is obsolete: 0 => 1

Comment 7 Barry Jackson 2015-05-24 12:50:29 CEST
Yes that's better :)

for / install, install.sh now has:

grub2-install --directory=/usr/lib/grub/i386-pc --grub-setup=/bin/true /dev/sdb18

and for MBR install it has:

grub2-install --directory=/usr/lib/grub/i386-pc /dev/sda

I will now re-test with the same system but booted via grub2 menu from a UEFI system.
Comment 8 Barry Jackson 2015-05-24 13:15:59 CEST
Hmm..  

drakboot does not give bootloader options when booted this way, so it must have decided that the system is UEFI because it was booted via a UEFI bootloader, despite the system being on a non-GPT drive and having grub2 (not grub2-efi) installed.

grub2-install --directory=/usr/lib/grub/i386-pc --grub-setup=/bin/true /dev/sdb18
...runs without error when booted this way.

How does drakboot decide whether the system it is running on is PC-BIOS or UEFI?

Out of interest I continued in drakboot and tried to set bootloader to /

  grub2-install failed: grub2-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory.
  	...propagated at /usr/lib/libDrakX/any.pm line 268.
  	...propagated at /usr/libexec/drakboot line 64.
  Perl's trace:
  drakbug::bug_handler() called from /usr/libexec/drakboot:64


Maybe hybrid BIOS support should be left for Mga6 and resigned to errata for now?
Comment 9 Barry Jackson 2015-05-24 13:20:26 CEST
install.sh has been set to:

grub2-install

so drakboot has definitely decided it's a UEFI system when it's not :\
Comment 10 Thierry Vignaud 2015-05-24 13:34:48 CEST
We check for /sys/firmware/efi
Comment 11 Barry Jackson 2015-05-24 15:34:58 CEST
Hmm.. That exists - could it be because it was an install from LIVE which now works for both modes?
Comment 12 Barry Jackson 2015-05-24 16:13:12 CEST
Ah - no it does not exist when booted from PC-BIOS mode directly, only when boot is via a bootloader on a UEFI system.

So is there any way to workaround this, like maybe [ -e /sys/firmware/efi ] && [ -e  /boot/EFI ] (or similar) to be sure this is really an EFI install?

If someone boots a legacy BIOS system from a UEFI bootloader and then uses drak* tools there is potential for system breakage and boot failure.
Comment 13 Thierry Vignaud 2015-05-24 16:38:37 CEST
That's bogus, we wouldn't create the /boot/EFI mount point on UEFI then...
That's the egg & chicken problem.
All distro check for UEFI mode by checking for /sys/firmware/efi.

If it exits, you ARE in UEFI mode.

CC: (none) => thierry.vignaud, tmb

Comment 14 Barry Jackson 2015-05-24 16:51:46 CEST
(In reply to Thierry Vignaud from comment #13)
> That's bogus, we wouldn't create the /boot/EFI mount point on UEFI then...
> That's the egg & chicken problem.

OK yes, bad example - maybe look for grub2-efi installed then? 

> All distro check for UEFI mode by checking for /sys/firmware/efi.
> 
> If it exits, you ARE in UEFI mode.

OK - but if the running system was installed in PC-BIOS mode and the user is expecting to continue using it that way then grub2-* tools need to be run that way too, and the usual legacy bootloader options etc. need to be available in drakboot.

OR....

there should be a trap set with an error dialog to warn the user that the system is running under the wrong mode.
Comment 15 Thierry Vignaud 2015-05-25 14:36:29 CEST
(In reply to Barry Jackson from comment #14)
> OK yes, bad example - maybe look for grub2-efi installed then? 

Same problem, that would prevent fixing an install with the wrong grub2 flavor.
What's more, that's not the right way to detect UEFI.

> > All distro check for UEFI mode by checking for /sys/firmware/efi.
> > 
> > If it exits, you ARE in UEFI mode.
> 
> OK - but if the running system was installed in PC-BIOS mode and the user is
> expecting to continue using it that way then grub2-* tools need to be run
> that way too, and the usual legacy bootloader options etc. need to be
> available in drakboot.
> 
> OR....
> 
> there should be a trap set with an error dialog to warn the user that the
> system is running under the wrong mode.

Well, I guess you manually picked grub2 instead of grub2-efi, didn't you?
Drakx would have picked grub2-efi b/c of /sys/firmware/efi

Or do you have a UEFI hybrid machine where you performed an install in legacy mode then switched back to UEFI?
That's not supported by other OSes.
UEFI rule of thumb is once you picked a mode for installing an OS, you must stick by it.

AFAIC, this can be closed as INVALID
Comment 16 Rémi Verschelde 2015-05-25 19:28:22 CEST
Decreasing priority for now, it seems clear to me that we do not support mixed BIOS modes using the same bootloader. It should probably be documented in the release notes though if not already.

Priority: release_blocker => Normal
Severity: critical => major

Comment 17 Barry Jackson 2015-05-25 21:26:08 CEST
(In reply to Thierry Vignaud from comment #15)

> Well, I guess you manually picked grub2 instead of grub2-efi, didn't you?

NO not at all. The legacy system was already there along with many others.

> Drakx would have picked grub2-efi b/c of /sys/firmware/efi
> 
> Or do you have a UEFI hybrid machine where you performed an install in
> legacy mode then switched back to UEFI?

No, as above the legacy installs pre-existed any UEFI install. I came across this testing both types of install on hybrid hardware, and was not aware of this issue previously.

Users with installs in legacy mode on a dual bios machine who then create a new install in UEFI mode (because it's the 'new way' to go) will have all the old legacy BIOS installs *shown* in their new (UEFI) grub2 menu.

They will no doubt boot those old installs from the new menu and this is where the problem arises.

> That's not supported by other OSes.

It's Mageia I'm interested in ;)

> UEFI rule of thumb is once you picked a mode for installing an OS, you must
> stick by it.

Of course, but by simply booting into an old system from a new menu it's not obvious to a user that using MCC tools will probably break his old system. It caught me out.

> AFAIC, this can be closed as INVALID

Well maybe it is, but the problem is still there.
Comment 18 Barry Jackson 2015-05-25 21:31:11 CEST
(In reply to Rémi Verschelde from comment #16)
> Decreasing priority for now, it seems clear to me that we do not support
> mixed BIOS modes using the same bootloader. It should probably be documented
> in the release notes though if not already.

Yes, although it's less than obvious to a user that he may be doing something that is unsupported, which is why I feel that this should be caught and a warning given.

Maybe errata for Mga5 and something more robust for Mga6.
Comment 19 Thierry Vignaud 2015-05-25 22:58:40 CEST
(In reply to Barry Jackson from comment #17)MCC tools
> Of course, but by simply booting into an old system from a new menu it's not
> obvious to a user that using MCC tools will probably break his old system.
> It caught me out.

To be rephrased as: "it's not obvious to a user that using THE SAME GRUB2-INSTALL COMMAND will probably break his old system."

Due to /sys/firmware/efi existing, grub2-install looks for /usr/lib/grub/x86_64-efi/ and yells that error msg:
"grub2-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh"

That has nothing to do with drakxtools...
Comment 20 Barry Jackson 2015-05-26 00:38:37 CEST
(In reply to Thierry Vignaud from comment #19)
> (In reply to Barry Jackson from comment #17)MCC tools
> > Of course, but by simply booting into an old system from a new menu it's not
> > obvious to a user that using MCC tools will probably break his old system.
> > It caught me out.
> 
> To be rephrased as: "it's not obvious to a user that using THE SAME
> GRUB2-INSTALL COMMAND will probably break his old system."
> 

Same as what? - I don't follow.

> Due to /sys/firmware/efi existing, grub2-install looks for
> /usr/lib/grub/x86_64-efi/ and yells that error msg:
> "grub2-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh"

Because drakxtools has changed the content of install.sh to just grub2-install (for uEFI) and has not used --directory=/usr/lib/grub/i386-pc

> 
> That has nothing to do with drakxtools...

drakxtools writes install.sh

We seem to be struggling with communication here :\

As I see it, if a system was installed in PC-BIOS mode then it should be treated as such by drakboot etc.

How to detect that I have no idea.
Comment 21 Rémi Verschelde 2015-05-27 12:35:12 CEST
I've added this in the UEFI section of the release notes:

Moreover, running mixed UEFI and non-UEFI systems from the same bootloader is not supported (mga#16030).
Samuel Verschelde 2015-05-31 18:59:30 CEST

Whiteboard: (none) => IN_ERRATA MGA5TOO

Comment 22 katnatek 2015-06-26 19:20:35 CEST
May be a bad suggetion, but what if the affected user create a file runining something like

touch /boot/grub2/bios-mode

And make draktools check for it and the decide the right command for install.sh
This at less allow to update from a running mageia 4 without crashing the system after update 

For new installations i don't know, as long as in some case boots in uefi mode no matter the UEFI setup

CC: (none) => j.alberto.vc

Comment 23 Barry Jackson 2016-05-22 14:02:30 CEST
I think that this should be closed as INVALID since we don't support mixed modes.

So closing then.

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


Note You need to log in before you can comment on or make changes to this bug.