You must select the MBR (aka the whole disk) not a partition for grub2

CC: (none) => thierry.vignaud

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

CC: (none) => mike.crecelius

Confirm install off x64 KDE livecd, grub2 has multiple issues. Some are inherent brain damage.

1)cannot install to partition (above "bug", although has been a known issue for years with grub2)

2) cannot "find itself" (if installed, gui config tool says "no config found, generating default config or somesuch)

3)If you can get it to reinstall to the MBR, it does not use the new, generated default config, but the one generated on initial install.

(item #2,3== Poor >no integration with drakconf tools)


Good news: At least it does work, and grub1/2 no longer seem to be stepping on each other probably leaving you with an unbootable system as with MGA3b1.


IMHO, I strongly urge grub2 be REMOVED from the default install media, esp as item 1) has been the case for many years and is apparently not considered a bug at all upstream.

CC: (none) => gjmcgee

(In reply to comment #3)
> Confirm install off x64 KDE livecd, grub2 has multiple issues. Some are
> inherent brain damage.
> 
> 1)cannot install to partition (above "bug", although has been a known issue for
> years with grub2)

If it did not try then there would be no problem, the installer should just do nothing in this case as the grub2 install has already created a core.img for multibooting. 

> 
> 2) cannot "find itself" (if installed, gui config tool says "no config found,
> generating default config or somesuch)

This needs fixing.

> 
> 3)If you can get it to reinstall to the MBR, it does not use the new, generated
> default config, but the one generated on initial install.

Well that depends how you "re-install" it. Read /usr/share/doc/grub2/README.Mageia
What problems have you had "getting it to reinstall"? 
It's one command:

grub2-install /dev/sda

That will install grub2 to the MBR of sda and create a new menu of all installed OS's it can find.

> 
> (item #2,3== Poor >no integration with drakconf tools)
> 
> 
> Good news: At least it does work, and grub1/2 no longer seem to be stepping on
> each other probably leaving you with an unbootable system as with MGA3b1.
> 

Yes it's getting there. This is a beta.

> 
> IMHO, I strongly urge grub2 be REMOVED from the default install media, esp as
> item 1) has been the case for many years and is apparently not considered a bug
> at all upstream.

Please no!
 1. is not a problem - just multiboot into /boot/grub2/i386-pc/core.img from grub2 or grub.

CC: (none) => zen25000

At least they aren't stepping on each other now, but I admit I did not try leaving both grub and grub2 installed when doing the install... I urpme grub2 prior to install.( i or someone needs to try this on B2 and see if the menus are getting updated when using grubm open bug with B1)

(IMHO) if it doesn't work from the MGA boot GUI and _requires_ manual configuration/command line operation to function, it's a poor choice to SHOW it as an option in the boot config GUI, as folks who don't know better will actually try it and end up with a completely hosed system.

Leave it as a manual install ONLY unless some advanced option with a huge warning is shown, clearly explaining grub2s huge limitations (mainly, too huge to install on a partition per the developers, so it greatly limits your options unless you are a grub2 guru)

I realize this is a b2 for MGA3, but I also understand grub2 is alpha software, it always has been, and likely always will be.

Debian and Ubuntu still really can't make it work right, for the better part of a decade.

It needs to fully work, or go//be disabled before rc, getting it working is fine for cooker^^^^^^Cauldron. Borken GUI driven config does not belong in a release purportedly for normal users.

Sorry I fatfingered the first bit--- 

I installed b2 with grub2 uninstalled on the live cds prior to installing to HDD.
This results in a working system.(this to check another bug on b1 that resulted in boot menus not updating when kernels did, urpmi grub2 on the live cd/dvd prior to install to disc)

If the default grub+grub2 install works properly on b2 I do not know, if it does it fixes a bug in b1.


>Please no!
> 1. is not a problem - just multiboot into /boot/grub2/i386-pc/core.img from
>grub2 or grub.
in the gui 
Do it from the gui or disallow the function if it does not work.
re: The bug we are responding to, as installing grub2 to a partition _does_not_work_ , and _will_not_work_ per the grub2 documentation.

If you have a trick allowing grub2 to natively, reliably install to a partition, rather than mbr, please pass it upstream. 
(It has never worked due to grub2 being too large for anything but the mbr.)

I'm going to go and try to find an efi/biosuniversal loader I can get to work on an install cd.

A suitable tool exists on SF already and is GPL, cd integration is the only issue.

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

CC: (none) => lists.jjorge

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

CC: (none) => mageia.phikappa

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

CC: (none) => lukazoids

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

CC: (none) => patrick.leny

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

CC: (none) => contact

(In reply to comment #3)
> 1)cannot install to partition (above "bug", although has been a known issue for
> years with grub2)
Maybe a simple fix for now : repopulating the partitions list when grub2 is selected, to only leave MBR ones.

(In reply to comment #12)
> (In reply to comment #3)
> > 1)cannot install to partition (above "bug", although has been a known issue for
> > years with grub2)
> Maybe a simple fix for now : repopulating the partitions list when grub2 is
> selected, to only leave MBR ones.

No - it needs to do nothing if a partition is selected.

The installation of the grub2 package should have already written /boot/grub2/i386-pc/core.img and also created the /boot/grub2/grub.cfg (menu).

This is all that is needed to multi-boot into the installation, as described in the grub2 README.Mageia.

So... manually typing a valid boot configuration from the grub shell prompt going to be the official fix?


Is that menu being updated with new kernel installs?

It appears to get DESTROYED if you attempt to reconfigure grub2 via the gui.
(always says "no boot configuration found, creating default" or some such)

Installing GRUB2 to a partition always leaves be with an unbootable system, including Windows, BTW. Also not supported per the grub documentation, and via years of testing by MANY pissed off people.

It should be disabled in the gui at least until it can be fixed.
(perhaps add a "testing" flag somewhere to enable it for the folks who so desire)

(In reply to comment #14)
> So... manually typing a valid boot configuration from the grub shell prompt
> going to be the official fix?
> 

I don't understand that comment.

> 
> Is that menu being updated with new kernel installs?
> 

Yes

> It appears to get DESTROYED if you attempt to reconfigure grub2 via the gui.
> (always says "no boot configuration found, creating default" or some such)
> 

The GUI currently does not support this.

> Installing GRUB2 to a partition always leaves be with an unbootable system.

That's correct behaviour.
You need to arrange your own multi-boot bootloader to launch a system that has no bootloader in the MBR.

> including Windows, BTW. Also not supported per the grub documentation, and via
> years of testing by MANY pissed off people.
> 

AFAIK we don't actually support Windows ;)

> It should be disabled in the gui at least until it can be fixed.
> (perhaps add a "testing" flag somewhere to enable it for the folks who so
> desire)

The GUI currently does not support this. 

Please read all the bug reports blocking bug 416.

This is still Cauldron - until these are dealt with all these issues will be present.

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

CC: (none) => pradhanphy

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

CC: (none) => michalng

I think this topic is going nowhere, it is about an error when trying to install grub2 to a partition's boot sector (see the description).

This occurs when the user wants the Mageia bootloader to be a secondary bootloader that will be loaded by a (usually already installed) primary bootloader (usually from another linux distribution).

I think many people don't understand how a secondary grub2 is to be loaded by a primary bootloader (it is not to be loaded like grub1).

grub1 way to load another grub1 was to chainload it:
   install secondary grub1 to the boot sector of a partition
   chainload that partition from the primary grub1

A secondary grub2 is not to be loaded this way, but instead, its 'core.img' file is to be loaded as a kernel (in fact, this file is a kind of kernel)

The way to load grub1 from another bootloader is to install it to a partition's boot sector (instead of installing it to the MBR), then to chainload that partition from the primary bootloader:
   from grub1:
      root (the partition where the secondary grub1 is installed)
      chainload +1
   from grub2:
      set root=(the partition where the secondary grub1 is installed)
      chainload +1

The way to load grub2 from another bootloader is to not install anywhere (instead of installing it to the MBR), then load the /boot/grub2/i386-pc/core.img file as a kernel (a multiboot kernel):
   from grub1:
      root (the root partition)
      kernel /boot/grub2/i386-pc/core.img
   from grub2:
      set root=(the root partition)
      multiboot /boot/grub2/i386-pc/core.img
		
(all these grub commands are to be adapted if /boot/ is on a separate partition.)

From the Mageia point of view, there are 2 main situations when the user installs multiple linux systems:
   1. The user wants the Mageia's bootloader to be the primary bootloader:
         Mageia must install its bootloader to the MBR, whichever the user chooses (grub1 or grub2)
   2. The user wants the Mageia's bootloader to be a secondary bootloader that will be loaded by his (usually already installed) primary bootloader:
         Mageia must NOT install its bootloader to the MBR, what it must do depends on the Mageia bootloader choosen by the user:
            grub1: must be installed to a partition's boot sector
            grub2: must NOT be installed to any boot sector

So here are the options that the Mageia installer should provide to the user:
   If the user chooses grub1 as the Mageia bootloader:
      a list of all whole disks, plus all partitions
   if the user chooses grub2 as the Mageia bootloader:
      a list of all whole disks, plus a "NONE" option
		
For the "NONE" option, the installer would not install grub2 to the MBR (passing the '--grub-setup=/bin/true' option to grub2-install and any disk as the target disk).

Currently, the user who wants to set the Mageia's grub2 as a secondary bootloader on his computer either:
   a. is forced to overwrite the MBR, then restore his primary bootloader
or:
   b. selects a partition, has the error message, and is stuck there
both are not acceptable in my opinion.

CC: (none) => nowahn

(In reply to comment #18)

Exactly.

As I said in comment 13, no action is required by the installer if a partition is selected - but I agree that maybe a better option would be "none" in this case.

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

CC: (none) => zxr250cc

ixed in SVN: we prevent installing grub2 not on MBR

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

(In reply to comment #21)
> ixed in SVN: we prevent installing grub2 not on MBR

I hope I misunderstand.

Are you saying that the option has been totally removed, or that the implementation has been fixed to do nothing when a partition is selected?

nothing if a partition is selected http://svnweb.mageia.org/soft/drakx/trunk/perl-install/any.pm?r1=7350&r2=7349&pathrev=7350

(In reply to Manuel Hiebel from comment #23)
> nothing if a partition is selected
> http://svnweb.mageia.org/soft/drakx/trunk/perl-install/any.
> pm?r1=7350&r2=7349&pathrev=7350

Well that looks to me (I may be wrong) as though it's not going to allow a partition to be selected.

For a *partition* the installer needs to install grub2 with:-

grub2-install --grub-setup=/bin/true /dev/sdxy

This creates /boot/grub2/i386-pc/core.img 

so the system can be multi-booted from grub or grub2.

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

I just made a new net-install and things were going well until after the summary, having selected grub2 and sdg4 as bootloader location (since I had booted the installer boot.iso from a USB currently assigned to sda)

An error message appeared which indicated that an attempt had been made to install grub2 to sdg4 using block lists.

I then used CTRL/F2 to get to a tty and then used CTRL/ALT/DEL to abort the installer and re-boot.

At a grub2 prompt (accessed via my "master" MBR bootloader I then manually multi-booted into the new installation using:

root=(hd0,msdos4)
multiboot /boot/grub2/i386-pc/core.img
boot

Whereupon the new installation's themed Mageia grub2 menu appeared and the system booted perfectly.

The installer needs to just skip the grub2-install step if a partition is selected (as I have commented many times previously), as this is already done during the grub2 package installation.

Fixed with 15.21 tools that should be uploaded today

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

For grub2 on partition, please open a different bug report. Thx
This one was about a crash and is already too long

Let say Bug #8742