This is because for now, we assume you use grub2 when grub2 is installed

CC: (none) => thierry.vignaud
Source RPM: ? => drakxtools

But I chose to use and did set up grub at installation ? 

Grub2 was just one of the many packages installed, I had no control over that.
It's not installed on the mbr.

but you use currently grub2 or grub1 ?

Blocks: (none) => 416

During the installation process for M3B1, using Mageia-3-beta1-LiveDVD-KDE4-x86_64-DVD.iso, I chose to use grub1 (I don't want use grub2 because it can only be installed on the mbr). I installed grub1 on the / partition (sdb4) for M3B1 so that I can boot M3B1 from my Mageia2 installation which is on sda and which has grub1 on the mbr of sda. This fact was also specified during the installation process. This all worked as I expected it would, and grub1 is definitely the boot loader on sdb4.

When I did the first update of M3B1 I vaguely remember seeing that grub.cfg was updated when the new kernel was installed.

In my /boot/ on M3B1 I now have /grub and /grub2.

Since the grub1 code won't have been taken out, why not just update grub1 and grub2 independently ?  Of course, that assumes you can actually detect which one is in use for the MBR and PBR.

CC: (none) => ftg

I'm only using this M3B1 release for testing purposes and something in this Beta 1 release is not working properly and needs to be corrected. I took the choice to use grub1 at installation and for some reason grub2 has been installed as well but only grub2 got updated when the new kernel was installed.

Thanks for your comment but I'm not looking for a workaround.

I didn't propose a workaround, I proposed a solution.  As long as we intend to support both, both should be updated.  The only tricky part is making sure you apply the correct updated file to a particular MBR/PBR, to match what's already there.

Sorry for my misunderstanding Frank.

To be clear, by "supporting both" do you mean that both grub and grub2 will always be installed in /boot by the installer, irrespective of which one the user chooses as their boot manager ?
I assumed that only the boot manager chosen would be installed in /boot.

No, I'm simply saying that if grub is installed, its control files should be updated.  If grub2 is installed, then *its* control files should be updated.  And if they're both installed, then *both* sets of files should be updated.

That leaves the problem of knowing which bootloader to refresh for a particular system.  While you can have them both installed, only one can be in use.  I'm not exactly sure how you can tell which one.  Probably both install some default version of their control files, and running grub install.sh if grub2 was really the one in use, or vice-versa, would probably screw the pooch.

If we want to allow people the flexibility to install both and switch off at will, we'd probably have to examine each product's control files and check the MBR/PBR mentioned to see if its format matches that product.

barjac, maybe you know where we gave some limitations ?

CC: (none) => zen25000

I agree with Frank. I see no reason to change the behaviour of grub (if it's installed) just because grub2 is installed.
I have been using grub2 installed alongside grub for the life of Mageia 2 and AFAIK grub has always been kept updated at kernel updates despite not actually being used.
We use filetriggers in Mageia to update grub2's menu at kernel update/removal - I have no idea how it is done for grub.

It seems that the grub legacy menu updates stopped in Cauldron with kernel 3.7.0rc8-1.mga3.
That is the latest one in menu.lst.

In Mga2 both grub and grub2 are up to date.

but grub2 don't need initrd.img or vmlinuz ?

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

CC: (none) => tmassimi

Confirm bug, same issue, grub2 menu.cfg updates, grub menu.lst does not.

New kernel and initrd can be manually switched to in control panel of course

CC: (none) => gjmcgee

Well, I guess we need to "rethink" the installer a little bit...

The reason for adding grub2 in addition to grub on livecds was to be able to test both installs from livecds...

But I guess we should make the boot loader selector urpme the one not selected...

so selecting grub2 would uninstall grub 

or make grub conflict grub2 and keep grub2 in /var/cache/urpmi* (if that is possible) and install it only if they select grub2...

CC: (none) => tmb

(In reply to comment #16)
> ...
> But I guess we should make the boot loader selector urpme the one not
> selected...
> 
> so selecting grub2 would uninstall grub 
> 
> or make grub conflict grub2 and keep grub2 in /var/cache/urpmi* (if that is
> possible) and install it only if they select grub2...

Maybe I missed something, but why should one conflict or urpme the other?

They do not conflict in any way. (I am maintainer of grub2) 

I have had both installed for over a year and use whichever is installed to MBR (or when using a dedicated master grub partition I can select to chainload into Mageia with grub legacy or multiboot into Mageia with grub2 using separate menu entries.

Please don't remove that feature.

It is a recent change that has stopped menu.lst being updated on kernel updates when grub2 is present. IMHO this change should be reverted.

Why don't we just patch grub install.sh and whatever the equivalent is on grub2 to touch a dummy file in /boot whose name is indicative of grub or grub2 and delete the one corresponding to the other bootloader ?  That would give an easy way to know which was installed on an MBR/PBR, and therefore which script to run when the lists are updated.

(In reply to comment #18)
> Why don't we just patch grub install.sh and whatever the equivalent is on grub2
> to touch a dummy file in /boot whose name is indicative of grub or grub2 and
> delete the one corresponding to the other bootloader ?  That would give an easy
> way to know which was installed on an MBR/PBR, and therefore which script to
> run when the lists are updated.

Please no!
If they are both installed they should both be updated.
grub2 does this automatically if it is installed - so no change needed.
grub always has done until recently.
If whatever was changed in the way grub is updated is reverted, then there will be no problem.

>Please no!

Barry, you misunderstand.  There are two parts to updating a grub bootloader.  One is to update menu.lst, the other is to rerun install.sh to reinstall grub on the MBR/PBR.

I agree that the first step should be done unconditionally.  But if you do the second unconditionally, you risk overlaying a grub2 MBR/PBR with a grub one.  I assume the same is true in reverse.

So, while menu.lst should be updated for both, only the install.sh corresponding to what's currently installed on the MBR/PBR should be run.

(In reply to comment #20)
> Barry, you misunderstand.  There are two parts to updating a grub bootloader. 
> One is to update menu.lst, the other is to rerun install.sh to reinstall grub
> on the MBR/PBR.
>

Yes we have some confusion here. I am only referring to kernel updates.
I see no reason to re-install grub/grub2 to anywhere for a kernel update, only the grub/grub2 menus should be updated.

Also, if grub or grub2 (packages) are being installed to a running system, then it's safe to assume that it can be booted already and the MBR should not be touched.

However, I now recall a long-standing problem in the way we (Mdv/Mga) handle kernel updates with grub and I think this is related. See my comments and Pascals explanations here:-
https://qa.mandriva.com/show_bug.cgi?id=43911#c13

If grub-install *must* be run (for now) - as the above suggests, then in the MBR case it needs to know whether the MBR contains a grub2 (or other)
bootloader and avoid overwriting it.

> I agree that the first step should be done unconditionally.  But if you do the
> second unconditionally, you risk overlaying a grub2 MBR/PBR with a grub one.  

Well that is exactly what happened to my MBR when grub was updated recently. My MBR pointing to grub2 in my dedicated grub2 partition was overwritten by a grub version pointing to grub in Cauldron. 
This should not have happened, as grub is installed to the root not the MBR.

> I assume the same is true in reverse.

No - grub2 uses os-prober to detect the systems and only regenerates the menu.

> So, while menu.lst should be updated for both, only the install.sh
> corresponding to what's currently installed on the MBR/PBR should be run.

Well no, think of my case where the bootloader in the MBR is totally unrelated to the running system.

(In reply to comment #21)

> Yes we have some confusion here. I am only referring to kernel updates.
> I see no reason to re-install grub/grub2 to anywhere for a kernel update, only
> the grub/grub2 menus should be updated.

In grub, install.sh must be re-run for the menu.lst changes to be reflected.

> 
> Also, if grub or grub2 (packages) are being installed to a running system, then
> it's safe to assume that it can be booted already and the MBR should not be
> touched.

That depends on what's in the MBR.  At the least, you won't see the menu changes.  At worst, if the absolute disk address of the kernel was in the MBR, it will now be wrong.

> If grub-install *must* be run (for now) - as the above suggests, then in the
> MBR case it needs to know whether the MBR contains a grub2 (or other)
> bootloader and avoid overwriting it.

My point exactly.

> > So, while menu.lst should be updated for both, only the install.sh
> > corresponding to what's currently installed on the MBR/PBR should be run.
> 
> Well no, think of my case where the bootloader in the MBR is totally unrelated
> to the running system.

Using the file approach I mentioned above, if the running system has never installed an MBR or PBR, there will be no file and nobody's install.sh will be run as a result of the update.

(In reply to comment #22)

> In grub, install.sh must be re-run for the menu.lst changes to be reflected.

Why is that?

I see nothing in install.sh that is changed by a kernel update, and menu.lst changes are usable instantly when modified manually.
Grub is already set up, so why run grub setup again?

>menu.lst changes are usable instantly when modified manually.

Looks like you're right.  It's a surprise to me, as most prior bootloaders, e. g. LILO, had to have a command run when the config was changed, and when I started with grub, I just assumed it was the same.

In that case, we should just update both, and the existing MBR/PBR will use the one belonging to it.

That's one of grubs main features, the bootlooader looks at whatever you point it at, and if a config is present, runs with it.

There needs to be a big set of bold/flashing disclaimers for Grub 2 use: It is incapable of being reliably installed on a partition, (*read the grub2 docs, it's sadly true)

effectively you are limited to Windows and ONE linux install, unless you have a common boot partition for all your Linux installs (asinine)

Grub2 also does really doesn't like to chainload grub1 IME, iirc there is a32/64 bit incompatibility as well that was still unresolved after many YEARS last I looked.

Grubv1 or something else needs to remain the default bootloader until those fatal flaws are solved with grub2, which is still alpha class software after all these years IMHO.

(I don't CARE if Ubuntu/Debian and everyone else chooses to use brain damaged software as a default, it's still stupid)

My apologies for the rant, but testing Debian/Ubuntu over the years has hosed more machines than I can count for me. 

GPL Universal uefi loaders exist... even for non-efi machines.
New machines coming out eventually won't even offer another option.

Wouldn't it make more sense to adopt something like that vs. grub2, that is still horribly broken after 10+ years??

(In reply to comment #25)
> That's one of grubs main features, the bootlooader looks at whatever you point
> it at, and if a config is present, runs with it.
> 
> There needs to be a big set of bold/flashing disclaimers for Grub 2 use: It is
> incapable of being reliably installed on a partition, (*read the grub2 docs,
> it's sadly true)

The same shortcoming is true of grub legacy, but there is only a warning.

> effectively you are limited to Windows and ONE linux install, unless you have a
> common boot partition for all your Linux installs (asinine)

Not true, and we don't support Windows. 
A dedicated grub/grub2 partition is certainly the best approach if you have multiple systems.
> 
> Grub2 also does really doesn't like to chainload grub1 IME, iirc there is
> a32/64 bit incompatibility as well that was still unresolved after many YEARS
> last I looked.

I have no issues chainloading into grub from grub2 or into grub2 from grub with mixed arch, although Ubuntu certainly had a buggy os-prober (pre 1.53) for years that caused issues. It was fixed before Mageia adopted it. 
 
> Grubv1 or something else needs to remain the default bootloader until those
> fatal flaws are solved with grub2, which is still alpha class software after
> all these years IMHO.

Grub2 is not the default bootloader - nor will it be, certainly for the life of Mageai3 - it is a proposed *option*, under test.

Development is ongoing as with all software - grub2 has come a long way in the last few years. 

> (I don't CARE if Ubuntu/Debian and everyone else chooses to use brain damaged
> software as a default, it's still stupid)

Having read your next post I'll ignore the rant, except to say that yes - my only brief exploits with *buntu caused damage too, mainly down to the broken os-prober, and the installation insisting on re-formatting swap and changing it's uuid.

I say again - it's not intended yet as the default - it's a choice. :)

(In reply to comment #24)
> In that case, we should just update both, and the existing MBR/PBR will use the
> one belonging to it.

Exactly :)

urpme grub2 restores normal operations.
(the boot menu being auto-updated with new kernels, the "bug")

I may be a little hard on grub2, but all past experiences over many years with it have always ended very badly.

The (unresolvable) non-installable on a partition issue, non-human readable config files and automagic-only operation (that doesn't work half the time) are enough to keep it banned from my systems forever.

(In reply to comment #29)
 
> The (unresolvable) non-installable on a partition issue, non-human readable
> config files and automagic-only operation (that doesn't work half the time) are
> enough to keep it banned from my systems forever.

This is not a problem - just install core.image to /boot/grub2/i386-pc using:

# grub2-install --grub-setup=/bin/true /dev/sda5  (if root is on sda5)
(When the grub2 package is installed in Mageia this is done automatically BTW)

and boot into it from a dedicated grub2 grub.cfg using:

menuentry 'Mageia-2 sda5' {
search --no-floppy --label --set=root mageia-2
multiboot /boot/grub2/i386-pc/core.img
}

or from grub legacy using:

title Mageia-2 sda5
root (hd0,4)
kernel /boot/grub2/i386-pc/core.img

All methods work for me - I have dozens of installed systems on multiple hard drives - mixed grub and grub2 and they boot from a small dedicated grub2 partition with a manually written simple grub.cfg that is not related to or updated by any system.

I'll have to give grub2 another shot, my experiences with grub2 on Fedora, Debian and Ubuntu have given me a violent distaste for it over the years.

All distros work now with grub2 and allow installing on partitions?

Ubuntu 12.04 doesn't BTW. Not even if forced, using your instructions.

It borks the system, rendering it completely unbootable. 
(tried that again on a test box just to see, partclone and dd are my good friends)

I still see grub2 as an OS in search of a problem.

Gave grub2 a try using the automated tools.(drakconf/boot) installing on several partitions using grub2. Never got that far.

After initial install, it denies there is an existing grub config on any drive.
Does not update the selections, and show NO selections on the (very nice) boot screen.

Does not work _at_all_ with grub (legacy) installed or uninstalled.
Works properly ONLY with grub2 uninstalled.

I'm done. At least it gave me an excuse to blow away win8.

That actually didn't even work, left an unbootable system menu.lst and the std /boot/grub contents apparently never got reinstalled.

I'm done with grub2. Again.
I "uninstalled" (urpme grub2) it before I started a fresh install to see if the updated kernel gets picked up as it should.

That did not go well, grub still didn't generate a proper menu.lst (messed up the initrd symlink or generation)

Trying one more time, I'm ~out of time to play as work starts Monday.
Will leave both grub and grub2 intact until all is updated/installed, manually verify menu.lst, then try uninstalling grub2 again as I did successfully 1st time through.
Then will see what happens.

(In reply to comment #32)
> Gave grub2 a try using the automated tools.(drakconf/boot) installing on
> several partitions using grub2. Never got that far.
> 

Yes we know drakconf/drakboot are currently broken. This bug is only one issue.
I did not imply that you could currently use drakboot to install to a partition.

However, you can install grub2 package and then multiboot into the installation using the grub/grub2 menu entries I gave in comment #30.

It actually got worse whan I tried the last scenario, seems that something is generating bad initrds (not the entries, (the generated initrds were missing essential stuff to boot, eventually rendering the system unbootable, the grub menu entries looked OK)

I never got into it enough to see what was causing that, it didn't happen the first time around.

Good luck, mga2 reinstalled, I'm headed back to work.

Had a chance to try it on another system i'm fixing up, MGA3b1+updates (cauldron0 got all the hardware on the Lenovo X300,(something Win8 can't, apparently), but I digress.

Managed to get a working system by uninstalling grub/grub2 and only reinstalling grub2.

Grub(legacy) or the combination of grub1+2 left me with an unbootable system or one that the boot list would not update on.

The corrupt initrd's did not recur.

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

CC: (none) => pierre-malo.denielou

Still valid bug mga3b2 (x86 and x64)

Removing grub2 in live environment prior to hdd install or after first boot prior to running first updates is still valid work around. 

Grub2 MAY (stress MAY) work by itself, but grub then needs to be uninstalled, they still will not play together. grub2 is only installable to mbr both per documentation and in all tests, so it is of very limited use.

(IMHO) grub2 Needs to be removed as option on install media or fixed prior to RC1.
Considering the probability of the grub2 devs fixing the essential "install on partition" capability is not expected before the heat death of the universe, now would be a good time to kill it off and find a better alternative.

Barry"> 
> There needs to be a big set of bold/flashing disclaimers for Grub 2 use: It is
> incapable of being reliably installed on a partition, (*read the grub2 docs,
> it's sadly true)

The same shortcoming is true of grub legacy, but there is only a warning."

The difference is grub gives you a warning but it works anyway, every time.

grub2 gives you a warning--- and an unbootable system (without grub-fu heroics) absolutely every time I have ever tried it.

Hardware: x86_64 => All

Tried out LinuxMint14, was expecting the worst as it is an Ubuntu derivative, but it actually appears LM14 is able to do some grub2-fu and install Grub2 to a partition successfully, leaving the primary booloader in the MBR alone.
(grub is not an option via the gui, but no foul if grub2 actually works automagically)

I'm going to poke at it awhile and figure out how it does that.

why not removing the else here http://svnweb.mageia.org/soft/drakx/trunk/perl-install/standalone/bootloader-config?r1=3577&r2=6629#l170 ?

testing myself, bug still present even without it

It works using the old version http://svnweb.mageia.org/soft/drakx/trunk/perl-install/standalone/bootloader-config?revision=3577&view=markup

AND even grub2 config is updated, from were I don't know. It seems that we can come back to the previous state of bootloader-config without caring about grub2.

Source RPM: drakxtools => drakxtools-backend

Yes exactly.
Please lets revert the changes and put legacy back into a working state.
Grub2 looks after itself as far as kernel updates are concerned.

Fixed with 15.21 tools that should be uploaded today

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