Please, next time, do not paste the whole changelog here.

And for mageia 1, the goal is to not have any intrusive and big changes. And a major migration to a new grub version is such a change, so this will not be done before June. Grub2 is a totally different beast that would requires change to drakx, to to various drakxtools, and changes to various packages ( like kernel , and install-kernel ).

CC: (none) => misc

(In reply to comment #1)
> Please, next time, do not paste the whole changelog here.
Sorry, it is to help to identify if the upgrade is needed 
and with grub, I didn't find a url with the changelog. 
 
> And for mageia 1, the goal is to not have any intrusive and big changes. 
I know. This ticket is reminder for the next upgrade tasks for Mageia 2.
As the ticket for module-init-tools that I have opened.

> And a major migration to a new grub version is such a change, so this will not > be done before June. 
OK

>Grub2 is a totally different beast that would requires change
> to drakx, to to various drakxtools, and changes to various packages ( like
> kernel , and install-kernel ).
OK, can you add the tag Mageia2 for the field "Target Milestone:" in Mageia's bugzilla ?

At http://blog.mageia.org/fr/2011/03/15/mageia-1-alpha-2-primavera-arrive/ , there is a use that said that he have problem when testing Mageia 1 alpha 2 in  Virtualbox because he uses Ubuntu. He said thar Ubuntu's startupmanager software that manage the boot for several operating system as MS Windows, other Linux distributions, recognize well Mageia, but that his system is blocked.
He think that it is because a problem with grub.

I think that when we can have Grub 1.9x with Mageia, it will be more easy for the users to switch from their previous Linux distribution to Mageia.

(In reply to comment #3)
I don't see the logic in your last comment.
Surely that would only apply to someone coming from Debian or Ubuntu.

Since grub legacy is still more common than grub2 then Mageia is better placed as it is.

There is nothing to stop anyone booting from one version into the other - it just needs some care and research.

I currently boot all my systems using grub2 including Mandriva. I do this purely to learn about grub2 which I have also patched to use only labels.

Despite this I would be the last person to recommend a sudden switch to grub2 for Mageia or Mandriva - it is a different animal.

CC: (none) => zen25000

grub is not upgraded from 0.97 to 1.98 in Mageia 1 Beta 1.
Then now, is it for Mageia 2 release ?

(In reply to comment #5)
> grub is not upgraded from 0.97 to 1.98 in Mageia 1 Beta 1.
> Then now, is it for Mageia 2 release ?

Definitely not for Mageia 1.

Maybe for Mageia 2.

(In reply to comment #6)
> (In reply to comment #5)
> > grub is not upgraded from 0.97 to 1.98 in Mageia 1 Beta 1.
> > Then now, is it for Mageia 2 release ?
> 
> Definitely not for Mageia 1.
> 
> Maybe for Mageia 2.

Ok, then change Field "Target Milestone" to Mageia 2 in this ticket.

Well, I said it's a maybe, unfortunately I don't know for sure when the switch will happen...

And as i said, this would requires more work that just upgrading the rpm.

I just built a package of grub2 1.99 (today's trunk) for x86_64 Mageia and it is installed and working.
http://forum.mandriva.com/en/viewtopic.php?f=17&t=134598&p=844642#p844642
However I am not an official packager and I don't have any upload rights, but if anyone wants to experiment with this I can upload it to a server and a private email will get you the URL. ;-)

There is one file needed for the graphical menu :-
/usr/share/grub/unicode.pf2
it was not available other than in Ubuntu, so I pinched it and built it into my package - I have no idea about the license issues involved with this. :-/

Well, have you tested with raid, lvm, encrypted root, brtfs ?
Have you installed another kernel, was it took in account by itself ? 

Did you have to do anything besides installing the rpm ? ( ie, creating the grub image, hunt for the differents modules etc ).

If not, then this is work that need to be done before hoping to replace grub.

> Well, have you tested with raid, lvm, encrypted root, brtfs ?
> Have you installed another kernel, was it took in account by itself ?
No, however kernel update should trigger a re-build of grub.cfg if the spec file is correct.

> Did you have to do anything besides installing the rpm ? ( ie, creating the
> grub image, hunt for the differents modules etc ).
grub2-install --grub-setup=/bin/true /dev/sdb5  (to / in my case)
grub2-mkconfig -o /boot/grub2/grub.cfg

> If not, then this is work that need to be done before hoping to replace grub.
I agree entirely and I do not advocate a change to grub2 unless it becomes absolutely essential.
I simply offered this to anyone (OP maybe?) who would like to experimant with the latest state of grub2.
It does (AFAICT reading #grub irc) have issues with brtfs, and documentation is improving, but still minimal.
If people experiment with grub2 now, then issues can be ironed out well before a possible change in the (hopefully quite distant) future. ;-)

Still on grub 0.97 today, so this enhancement didn't silently happen

CC: (none) => marja11

Copying Blocks field from duplicate bug report 2121, to be able to close that one

Summary: upgrade grub from 0.97 to 1.98 (latest stable) to fix bugs and GRUB 0.9x (Legacy) is no longer being developed => Integrate Grub2 in Mageia 2 (upgrade grub from 0.97 to 1.98 (latest stable) to fix bugs and GRUB 0.9x (Legacy) is no longer being developed)
CC: (none) => ennael1, marcello.anni, olav
Blocks: (none) => 1994
Target Milestone: --- => Mageia 2
Source RPM: grub => grub2

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

(In reply to comment #12)

> It does (AFAICT reading #grub irc) have issues with brtfs, and documentation is
> improving, but still minimal.

More than 8 months later now. At first sight, documentation seems to be OK

http://www.gnu.org/software/grub/manual/html_node/index.html

And I don't see an open brtfs bug, so that issue got fixed.

But I suppose there are other serious issues left, version is 1.99 atm and not 2.x

I second this idea as well.

CC: (none) => kristoffer.grundstrom1983

I have packages of grub2-pc and grub2-efi almost ready.

It is my intention to import these into Cauldron after the launch of mga2 and the dust has settled, unless anyone has serious objections.

This will probably coincide with the next stable release of grub2 which coincidentally will be 2.00 (current is 1.99). (I am currently working with 2.00b2)

I have not tested with raid, lvm, etc., but no one person has all the hardware available to do this sort of testing - which is the whole point of making these packages available.

PC works fine for me and EFI is also working and tested in Mageia but not by me.

They will include basic instructions in README files to enable anyone interested to install and experiment with grub2 with minimal risk to their existing systems. 
These packages will co-exist alongside grub-legacy.

I think that the feedback we get from users will be a good basis for making decisions about any possible later integration of grub2 into maybe mga3 or 4.

Thoughts anyone?

Most all new distro have moved to grub2. I use it to boot mageia2 from ubuntu grub. Its easier to use and update than legacy.I had to make a small change in mageia menu 1st.to make it boot.The two grubs handle the uuid differently.In the beginning it had a lot of problems But most have been worked out.I vote to move to it as soon as possible.  thanks

CC: (none) => bigdavesr

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

This is definitely still valid for Mageia 2. I have a UEFI-based laptop that cannot boot with any bootloader supported by Mageia. At this point, I can only use a third-party bootloader on a USB drive (super grub2 disk), until I figure out how to properly install grub2 by hand.

I suspect many people with recent hardware will be in the same situation soon.

Jerome

CC: (none) => heninj

Grub2 is in cauldron since some weeks thanks to barjac, but the integration needs to be done, if we need a new bug for that we can open a tracker later, so closing this one.

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

The target for Grub2 integration is Mageia 3, so this kind of UEFI hardware will not be supported by Mageia 2 at any point. I can perfectly understand that backporting to Mageia 2 would be a large amount of work that is better invested elsewhere.

Then, maybe there should be a warning about this somewhere in the release notes, so that users don't try to install Mageia 2 on unsupported hardware? (or make sure that they are able to set up their own bootloader by hand)

Jérôme, feel free to complete the feature page https://wiki.mageia.org/en/Feature:Grub2AsDefault with your point of view.

(In reply to comment #21)
> This is definitely still valid for Mageia 2. I have a UEFI-based laptop that
> cannot boot with any bootloader supported by Mageia. At this point, I can only
> use a third-party bootloader on a USB drive (super grub2 disk), until I figure
> out how to properly install grub2 by hand.
> 
> I suspect many people with recent hardware will be in the same situation soon.
> 
> Jerome

There is the package grub2-efi in Cauldron, it has been tested and the tester's notes are in README.efi which is installed with the package.
He is using it in mga1 having re-built it from the src.rpm.
  
I personally have no uefi hardware, but if there are any questions regarding install or any clarification required regarding the notes in the README.efi then I will be happy to pass them on.

Barry <barjac>

Okay, I have set up grub2-efi successfully, but there was a catch-22: to set grub2-efi as default, you need efibootmgr, and that requires to be booted in EFI mode, which is not simple until grub2-efi is installed.

One bootstrap process that works on my hardware:
1 - install mga (bootloader on MBR is non-functional)
2 - use a "super grub2" boot drive to boot in BIOS mode
3 - install grub2-efi as per README.efi instructions
4 - download and compile efibootmgr (I didn't find an mga package)
5 - use a rEFInd boot drive to reboot via grub2-efi, in EFI mode
6 - modprobe efivars; run efibootmgr as per Ubuntu's UEFIBooting page to set Grub2 as default.

This whole process will become entirely unnecessary only once the installer istelf boots in EFI mode, and can setup EFI boot. However, things could alreadyh be made a bit easier if:
a - the kernel config had CONFIG_EFI_STUB=y (skip step 2 above)
b - there was an efibootmgr package (skip step 4 above)

I wonder where this is best discussed. It is connected to Grub2, but the EFI install problem is more general, so it doesn't really belong on the Grub2AsDefault page.

(In reply to comment #26)
Good that's encouraging. I can see that I have a lot to learn about efi ;)

I will look into importing efibootmgr package into Cauldron.

As regards a discussion forum, I think we need to open a tracker bug for grub2 integration, and then re-open this bug (or open a new one) as a place for the actual discussion which will be linked to the tracker.
I agree that the wiki features page seems to be the wrong place for discussion which will become protracted and the ML is busy enough.
A bug report seems the best place to me.

Anyone else got a better idea?.

We can reopen this bug or a make a new one as tracker ( a new will be more clear in my opinion) and then add inside this tracker, two other: one for real bugs / absolutly integration needed, and one for a less priority enhancement (not like in mga2 where there was a mix beetween blocker and feature)
https://wiki.mageia.org/en/Mageia2_Postmortem#Bad_2

not sure if it's a better ideas, since I'm new in "devs/QA" side ;)

Re-opening for now.
Update:-
Grub2 in Cauldron is now Version 2.0 Final Release.
efibootmgr is now in Cauldron for testing, and is suggested by grub2-efi.

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

Should we keep an eye on this one too: https://plus.google.com/u/0/115547683951727699051/posts/gDfHgApPma1 ?

CC: (none) => sander.lepik

(In reply to comment #30)
> Should we keep an eye on this one too:
> https://plus.google.com/u/0/115547683951727699051/posts/gDfHgApPma1 ?

This looks very interesting: now that mga kernels have the EFI stub option enabled (Bug 6598), they should be able to boot directly through gummiboot (as long as kernel images are copied to the ESP).

There's basic support in drakxtools-15.1 in core/updates_testing

(In reply to comment #32)
> There's basic support in drakxtools-15.1 in core/updates_testing

mcc -> boot -> set up boot system ....slight pause - bang.
#-------------

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

  unknown bootloader method grub2 (read) at /usr/lib/libDrakX/bootloader.pm line 194.
  Perl's trace:
  standalone::bug_handler() called from /usr/lib/libDrakX/bootloader.pm:194
  bootloader::read() called from /usr/sbin/drakboot:53

Used theme: oxygen-gtk
#-------------

grub2 is installed - this is in a vbox i586 install fully updated with updates-testing enabled.

(In reply to comment #33)
should be fixed in the new one (according to the changelog)

Source RPM: grub2 => (none)

(In reply to comment #34)
> (In reply to comment #33)
> should be fixed in the new one (according to the changelog)

Yes it works, I can now switch to grub2 using drakboot - no problem in vbox, I have not yet tested in real hardware.

I just did a clean net-install on real hardware and attempted to install grub2 to sda7 (system root) rather than MBR, as I have a dedicated grub2 partition to multiboot/chanload into various systems.

The install failed with grub2-install complaining that it was not possible and /usr/sbin/grub2-bios-setup warnings about block lists, It also referred to /usr/lib/libdrakX/any.pm line 267 

I changed to MBR install and that worked OK. I then booted using the new grub2 menu into my current main Cauldron installation (on sda6) and chrooted into the new installation of Beta 1, (on sda7) where I issued:-

[root@localhost baz]# grub2-install --grub-setup=/bin/true /dev/sda7
Installation finished. No error reported.

Now why could the installer not do that? Maybe it's trying to do something else?

After correcting my overwritten MBR and updating my master boot menu for the new installation it now boots from my dedicated grub2 menu via multiboot:-

menuentry 'Mageia-3 Beta 1' {
search --no-floppy --label --set=root mageia-3b1
multiboot /boot/grub2/i386-pc/core.img

There is a long delay before the KDE login appears, but I am guessing that is unrelated to the bootloader.

Also:-
During the installation (after the user setup) the next screen asked:
"You decided to install the bootloader on a partition. This implies you already have a bootloader on the hard disk drive you boot (eg: System Commander)."
However at that stage I had not entered anything at all about boot configuration, as this was prior to the summary!

I have opened a separate bug about the last point above.
https://bugs.mageia.org/show_bug.cgi?id=8534

On a second net-install, to avoid overwriting the MBR I killed the install with 3 fingers at the grub2-install failure screen. I then chrooted into the new installation and continued as in #36.
It boots perfectly.

moving out enhancement bugs :
https://bugs.mageia.org/buglist.cgi?quicksearch=sw%3Agrub2_enhancement

to have a better view of what is still really needed

Perhaps I might add bug #9991 to this, as memtest86+ is missing from the grub2 boot options.

CC: (none) => mageia

(In reply to Richard Neill from comment #39)
> Perhaps I might add bug #9991 to this, as memtest86+ is missing from the
> grub2 boot options.

Yes you could change that bug to enhancement. It's not actually 'missing' BTW as we have never had it there. ;)

I'm going to consider this bug tracker as fixed. Grub 2 is integrated. Remaining bugs can be found via the sourcerpm field of bug reports.

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

\o/