Description of problem: I just upgraded my Mga 3 system to Mga 4 (RC) with Urpmi. On rebooting into the new system, Grub2 dumped me into a minimal rescue prompt, with the error "error symbol GRUB_TERM_HIGHLIGHT_COLOR not found". At this prompt, some of the grub2 modules could be loaded (eg "insmod cat", but not others (including the critically important "insmod linux" or "insmod normal"). Booting into a live CD and then chrooting to Mageia and re-running update-grub solved it. [I don't think I had to run grub2-install again, but I may have done; I can't recall for certain.] My guess is that the version of grub has been changed, but that the installer hasn't kept the grub bootloader itself in sync with the version of the modules. ----- Aside: the minimal grub rescue prompt appears to have been compiled without enabling the "help" builtin. (Marking this as critical because it left my system non-functional). Reproducible: Steps to Reproduce:
On mga3, what for bootloader did you have ?
Keywords: (none) => TriagedAssignee: bugsquad => zen25000
Hi. I was using grub2 previously.
(In reply to Richard Neill from comment #0) > Description of problem: > > I just upgraded my Mga 3 system to Mga 4 (RC) with Urpmi. > > On rebooting into the new system, Grub2 dumped me into a minimal rescue > prompt, with the error "error symbol GRUB_TERM_HIGHLIGHT_COLOR not found". > > At this prompt, some of the grub2 modules could be loaded (eg "insmod cat", > but not others (including the critically important "insmod linux" or "insmod > normal"). > > Booting into a live CD and then chrooting to Mageia and re-running > update-grub solved it. [I don't think I had to run grub2-install again, but > I may have done; I can't recall for certain.] > I'm guessing you did run grub2-install, or the modules would have remained out of sync with MBR. > My guess is that the version of grub has been changed, but that the > installer hasn't kept the grub bootloader itself in sync with the version of > the modules. > I agree and was sort of expecting a problem with urpmi updates. Could you check if /boot/grub2/drakboot.conf exists on your system? If it is not there, could you go through the motions of using drakboot to re-install grub2 (mcc > boot > set up boot system) and then check that /boot/grub2/drakboot.conf exists. To explain a little... When the grub2 package is updated - as happened with your upgrade, it needs to re-run grub2-install, however to do this it needs to know the target. It gets this from /boot/grub2/drakboot.conf but this did not exist in Mga3, and if it is not found then grub2-install cannot be run. I think a note in Mga4 errata is needed to require that drakboot is used to re-install grub2 before re-booting after upgrading with urpmi. drakboot should run grub2-install and create drakboot.conf so doing this once in Mga4 should fix this for the future, although it's not ideal. > ----- > Aside: the minimal grub rescue prompt appears to have been compiled without > enabling the "help" builtin. > OK thanks - I will investigate > (Marking this as critical because it left my system non-functional).
Blocks: (none) => 11979
Summary: Upgrade: grub rescue, with "error symbol grub_term_highlight_color not found" => Upgrading Mga3 with grub2 to Mga4 using urpmi fails to reboot
CC: (none) => thierry.vignaud
Thanks for your explanation. Your guess is correct: I do not have a /boot/grub2/drakboot.conf I ran MCC, as you suggested: screen 1: "Set up boot system:" No bootloader found, creating a new configuration -> press OK screen 2: Stick with the default choices: i.e. bootloader = Grub2 graphical menu boot device = /dev/sda delay = 10 security = [empty] -> Next screen 3: boot menu entries * linux linux-nonfb failsafe -> Finish Now, drakboot.conf exists, containing one line: boot=/dev/sda Also, my /etc/default/grub file has been altered, changing from GRUB_CMDLINE_LINUX_DEFAULT="nomodeset vga=794" to: GRUB_CMDLINE_LINUX_DEFAULT=" nokmsboot resume=UUID=cf30d5a7-0cc3-4860-84c0-b8324f21d975" Finally, I reverted this last change (and ran update-grub2), because I had real difficulty getting the machine to previously boot. (It's a desktop machine with Intel embedded i7 graphics, and an ATI card which has to use fglrx; as far as I can tell, KMS combined with an intel graphics card causes the machine to crash early in the boot process.) ---------------------- I think there's a fundamental problem here, in that intervention with the graphical MCC and drak-tools are required, even though one is using urpmi. If installing an RPM update to grub2 can leave the system in an inconsistent and unbootable state, then that's a serious packaging bug. The grub2 rpm preinstall script should: - see if it can identify the disk where the bootloader is already installed - else, try to read /boot/grub2/drakboot.conf [is there a standard distro-independent way of remembering the target?] - else, ask the user - else, refuse to install the package. - at least print a message referencing this erratum/bug report. urpmi should never be able to install grub2 updates in this broken way, and yet report success.
(In reply to Richard Neill from comment #4) > > Thanks for your explanation. > > Your guess is correct: I do not have a /boot/grub2/drakboot.conf > > I ran MCC, as you suggested: > screen 1: "Set up boot system:" > No bootloader found, creating a new configuration -> press OK > > screen 2: Stick with the default choices: i.e. > bootloader = Grub2 graphical menu > boot device = /dev/sda > delay = 10 > security = [empty] > -> Next > > screen 3: boot menu entries > * linux > linux-nonfb > failsafe > -> Finish > > Now, drakboot.conf exists, containing one line: > boot=/dev/sda > > Also, my /etc/default/grub file has been altered, changing > from > GRUB_CMDLINE_LINUX_DEFAULT="nomodeset vga=794" > to: > GRUB_CMDLINE_LINUX_DEFAULT=" nokmsboot > resume=UUID=cf30d5a7-0cc3-4860-84c0-b8324f21d975" > That is expected (and in the errata) as drakxtools is not yet sufficiently integrated to set vga=xxx etc. in /etc/default/grub > > Finally, I reverted this last change (and ran update-grub2), because I had real > difficulty getting the machine to previously boot. > (It's a desktop machine with Intel embedded i7 graphics, and an ATI card which > has to use fglrx; as far as I can tell, KMS combined with an intel graphics > card causes the machine to crash early in the boot process.) > > ---------------------- > > I think there's a fundamental problem here, in that intervention with the > graphical MCC and drak-tools are required, even though one is using urpmi. It will not require intervention if grub2 is installed by the Mga4+ (distro) installer or by drakboot (Mga4) this is only an issue when updating without the installer as drakboot is bypassed. It also should only affect updates from Mga3 done with urpmi as from now (Mga4) onwards systems should have drakboot.conf. I agree it's currently far from perfect and I did foresee this situation arising many months ago when I emailed Thierry on the subject, and also had discussions with grub2 devs. > If installing an RPM update to grub2 can leave the system in an inconsistent > and unbootable state, then that's a serious packaging bug. The grub2 rpm > preinstall script should: > - see if it can identify the disk where the bootloader is already installed I am open to suggestions as to how that could be achieved, as I am not a developer, just the package maintainer :/ > - else, try to read /boot/grub2/drakboot.conf Which it currently does. > [is there a standard distro-independent way of remembering the target?] No - although imagine the situation where a user manually uses grub2-install on a different drive to the regular boot drive - this would change the stored target and cause mayhem if a grub2 update came along :/ > - else, ask the user Maybe possible > - else, refuse to install the package. Possible > - at least print a message referencing this erratum/bug report. Yes I think that a message should go into a README.urpmi to be shown during the grub2 update. > urpmi should never be able to install grub2 updates in this broken way, and yet > report success. > Thanks for your input - I appreciate your comments and any help in solving this is welcome. Barry
@Richard I just did a clean installation of Mga3 with grub2 (in VM) and it does have /boot/grub2/drakboot.conf (I was not aware of this, but it's good news) After fully updating this installation I then switched to Mga4 mirrors and ran urpmi--auto-update. It updated fully and re-boots fine. /var/log/grub2_post.log shows that grub2-install was run twice successfully (once during Mga3 install and once during upgrade to Mga4) So, there is no problem updating a Mga3 to Mga4 that was originally installed with grub2. ...and I am quite confident that this would also be the case if grub2 had been installed in Mga3 using drakboot. How did you install grub2 in Mga3? Was this manually using urpmi, after an initial install opting for grub? If so this seems to be the corner case that causes a problem.
Summary: Upgrading Mga3 with grub2 to Mga4 using urpmi fails to reboot => Upgrading Mga3 with manually installed grub2 to Mga4 using urpmi fails to reboot
If I remember rightly, this was originally a Mandriva system, which has been updated repeatedly (via urpmi) through Mga1->Mga2->Mga3->Mga4. I think I switched it from grub to grub2 back in the Mga2 days. Anyway, I think the real bug is that the grub2 RPM doesn't treat updating /boot/grub2/i386-pc/* and updating the boot sector as a single atomic operation, which should either complete, or rollback (or at very least, throw a loud warning). Also, why are the drak-tools doing something over-and-above what urpmi is doing? If there is any special "magic" in drakboot that is not in the grub2 rpm scriptlets, I think this is likely to bite a lot of server administrators.
Summary: Upgrading Mga3 with manually installed grub2 to Mga4 using urpmi fails to reboot => Upgrading Mga3 (with a manually installed grub2) to Mga4 using urpmi fails to reboot
(In reply to Richard Neill from comment #7) > If I remember rightly, this was originally a Mandriva system, which has been > updated repeatedly (via urpmi) through Mga1->Mga2->Mga3->Mga4. > I think I switched it from grub to grub2 back in the Mga2 days. > OK fine. > Anyway, I think the real bug is that the grub2 RPM doesn't treat updating > /boot/grub2/i386-pc/* and updating the boot sector as a single atomic > operation, which should either complete, or rollback (or at very least, > throw a loud warning). Exactly, but it cannot if the target is not known. During the grub2 package installation (when done using urpmi) the target is not known either. It is only supplied by the user when grub2-install is run manually. So, I fail to see how this can be automated - it's a catch 22 over which I have been scratching my head for months. The use of drakboot.conf is my attempt to avert a major update issue during upgrade to Mga4, since the Mga4 grub2 is a fairly major update on the Mga3 version due to patching and I knew it would cause MBR version incompatability without re-running grub2-install. I will look into 'failure with warning' for the missing drakboot.conf case, which should allow rebooting with the original installed version, allowing the user to manually create drakboot.conf before updating grub2. > > Also, why are the drak-tools doing something over-and-above what urpmi is > doing? drakx-tools has to be involved to some degree to integrate grub2 into the installer and drakboot. > If there is any special "magic" in drakboot that is not in the grub2 rpm > scriptlets, I think this is likely to bite a lot of server administrators. I agree, however the only 'magic' used as far as grub2 installation is concerned is the use of drakboot.conf to record the target when grub2 is installed the 'official' way, where grub2-install is run by drakboot. @Thierry Is there likely to be any bad drak* side effect of manually adding /boot/grub2/drakboot.conf to a system that has had grub2 installed manually rather than through drakboot/installer?
Yes, I see why this is problematic to solve properly, because the bootloader isn't part of the OS - fundamentally, the problem is arises because the whole of grub2 can't be fitted into the boot sector. I think you can safely create drakboot.conf with a default target, when there is only one drive present (though this wouldn't have helped me, given that I have two drives). Also, what about the situation when grub-0.97 is the bootloader that is in use, and grub2 is merely installed in the filesystem? Should updating the grub2 RPM also change the bootloader? (Ubuntu partly solve this by making grub and grub2 packages conflict, whereas Mageia allows them both to be installed in parallel).
(In reply to Richard Neill from comment #9) > ... > Also, what about the situation when grub-0.97 is the bootloader that is in > use, and grub2 is merely installed in the filesystem? Should updating the > grub2 RPM also change the bootloader? > You are right, this is a situation I overlooked. I am uneasy about running grub2-install at all from a scriplet, as there may be other corner cases where it may be undesirable. I do think that grub2 itself should keep track of what it has installed and where, and be capable of keeping itself in sync without manual or scriptlet intervention, however grub2 devs think otherwise. > (Ubuntu partly solve this by making grub and grub2 packages conflict, > whereas Mageia allows them both to be installed in parallel). This would throw up more problems. If grub was in use and grub2 was then installed using urpmi/rpmdrake, boot would fail since without manually running grub2-install the MBR would still point at a non-existent grub. Likewise if grub2 was in use, simply installing grub would (among other things) not create a menu.lst and so that would also fail. And then there is efi... :\ This is where full drakboot integration is really required to get the input from the user and do the housekeeping, which so far it does quite well.
I see the point. What do the grub2 devs think ought to happen when the grub2 package is updated? What about patching grub2-install so that the modules in /boot/grub are only updated at the time of updating the bootloader. Then the grub2 package could put them in /lib/grub2/modules.$VERSION_NUM, and update-grub2 can move them into place? Or even simply version numbering the grub modules, and leaving the older ones around (like we do with kernels). Ultimately, there are 3 different "owners" here, each of which expects to be authoritative: the bootloader [version clash with modules], the package-manager [modules in the filesystem], and the user [which boot device to use]. It doesn't really matter which one wins, as long as there is only one, which the others accept. Otherwise, we get "split-brain". Meanwhile, whatever we decide to do, I think that a strident error message is called-for, in any case where (grub2.rpm is updated, AND update-grub2 is not run, or fails). Is there any way that a script could discover and verify: - which device the BIOS intends to boot by default - which bootloader (type and version) is already installed there - is that bootloader compatible with the modules it expects to find in /boot? That way, at least we could know whether we had left the system broken. P.S. What happens in the nasty case where 2 operating systems are installed in parallel? Let's say that /dev/sda contains grub2, /dev/sda6 contains a Mageia root (including Mageia's grub2) and /dev/sda7 contains an Ubuntu root (including Ubuntu's grub2). Now we have all sorts of "fun" with conflicts when the OSs take turns to update grub2 packages. P.P.S. Another nasty corner case is RAID devices. If I have a software Raid-1 array, with 2 identical drives, the bootloader is usually only installed on one of them (and the BIOS is then set to pick that drive as "the" boot device). After a drive failure, there is often no bootloader on the other drive!
(In reply to Richard Neill from comment #11) > I see the point. What do the grub2 devs think ought to happen when the grub2 > package is updated? IIRC they just expect the user to re-run grub2-install, or the OS to wave a magic wand. > What about patching grub2-install so that the modules in /boot/grub are only > updated at the time of updating the bootloader. Then the grub2 package could > put them in /lib/grub2/modules.$VERSION_NUM, and update-grub2 can move them > into place? Or even simply version numbering the grub modules, and leaving > the older ones around (like we do with kernels). Ouch - getting too complicated for my liking. > > Ultimately, there are 3 different "owners" here, each of which expects to be > authoritative: the bootloader [version clash with modules], the > package-manager [modules in the filesystem], and the user [which boot device > to use]. It doesn't really matter which one wins, as long as there is only > one, which the others accept. Otherwise, we get "split-brain". Like mine just now :) > > Meanwhile, whatever we decide to do, I think that a strident error message > is called-for, in any case where (grub2.rpm is updated, AND update-grub2 is > not run, or fails). Yes. And with that in mind I tried a little test to see if a simple approach would work, but hit an old bug https://bugs.mageia.org/show_bug.cgi?id=1670 see my last comment. > Is there any way that a script could discover and verify: > - which device the BIOS intends to boot by default I doubt it. > - which bootloader (type and version) is already installed there I tried several scripts that are supposed to do that but they don't seem to be able to differentiate between grub and grub2 (or I was going to pinch some code). > - is that bootloader compatible with the modules it expects to find in > /boot? I doubt it > > That way, at least we could know whether we had left the system broken. I think that as long as either the update fails or the update goes ahead and grub2-install is run then the system is not broken. > > P.S. What happens in the nasty case where 2 operating systems are installed > in parallel? Let's say that /dev/sda contains grub2, /dev/sda6 contains > a Mageia root (including Mageia's grub2) and /dev/sda7 contains an Ubuntu > root (including Ubuntu's grub2). Now we have all sorts of "fun" with > conflicts when the OSs take turns to update grub2 packages. No, not a problem, because the one that wrote the MBR is the one providing grub2 and the menu. When the other system is booted then grub2 of system1 just passes control directly to the kernel/initrd or whatever of system2 and that system's grub2 is not involved. > > P.P.S. Another nasty corner case is RAID devices. If I have a software > Raid-1 array, with 2 identical drives, the bootloader is usually only > installed on one of them (and the BIOS is then set to pick that drive as > "the" boot device). After a drive failure, there is often no bootloader on > the other drive! IIRC grub devs always recommend to run grub2-install on both drives in a raid array.
A quick test on 2 systems shows the following: If either Grub2 or 0.97 are installed, then: # head /dev/sda | grep -ao "GRUB" GRUB On the other hand, you can detect 0.97 by looking for: # head /dev/sda | grep -ao "Loading stage1.5" Loading stage1.5 (which is not true for Grub 2.) Also, you're right that the dual-OS situation is not too much of a problem, until something horrible happens (eg the user decides he doesn't want the 2nd OS, and reuses the partitions, but the bootloader's libraries are there!
Thanks Richard that's useful. I had played around using dd but only grabbing the first 512 bytes. I have tested a little script in a VM and it correctly detects grub, grub2 and lilo when the bootloader is switched repeatedly between the three using drakboot. #!/bin/sh getloader() { ldr= if head $1 | grep -q "GRUB"; then if head $1 | grep -q "stage1.5"; then ldr=grub else ldr=grub2 fi elif head $1 | grep -q "LILO"; then ldr=lilo fi } getloader $1 echo $ldr I have incorporated this logic into a test spec for grub2 to avoid the possibility of over-writing an active grub legacy bootloader when grub2 is updated. Still needs testing as I have been busy with other things.
grub2-2.02-0.git9752.1.mga5 (now in Cauldron) incorporates the solutions discussed here and if it causes no new issues I will submit it as an update candidate for Mga4 in due course.
######################## Update Advisory grub2-2.00-59.mga4 has been submitted to 4/core/updates_testing to fix this bug, and another discovered during discussions above at comment #10. Files affected: grub2-2.00-59.mga4.src.rpm grub2-2.00-59.mga4.<arch>.rpm grub2-debuginfo-2.00-59.mga4.<arch>.rpm grub2-efi-2.00-59.mga4.<arch>.rpm grub2-mageia-theme-2.00-59.mga4.noarch.rpm ######################## grub2 update testing procedure in VBox: N.B. This involves completing 4 updates from Mga3 to Mga4, so best done with a local mirror available. Create a master Mga3 VM using default grub legacy and fully update it. //---------------------------------- To demonstrate bug (part relating to clobbering legacy MBR discussed at comment #10: Clone the master VM into "clone1" Boot into clone1 In clone1 switch to grub2 using drakboot and reboot to check it works. Using drakboot switch back to grub legacy and reboot to check it works. Remove Mga3 media and replace with Mga4 media and then upgrade system to Mga4 using: urpmi --replacefiles --auto-update --auto (re-run it until all packages are up to date) then... reboot Note that reboot uses grub2 when it should still be using grub legacy. Also see: $ cat /var/log/grub2_post.log Installation finished. No error reported. Installation finished. No error reported. //-------------------------------- To test updated grub2 package does not clobber grub legacy MBR on update. //-------------------------------- Create a second clone (clone2) from the master VM. Boot into clone2 In clone2 switch to grub2 using drakboot and reboot to check it works. Using drakboot switch back to grub legacy and reboot to check it works. Remove Mga3 media and replace with Mga4 media *** Now enable Core/Updates_Testing *** Upgrade system to Mga4 using: urpmi --replacefiles --auto-update --auto (re-run it until all packages are up to date) then... reboot Note that it boots correctly using grub legacy. Also see: $ cat /var/log/grub2_post.log MBR not grub2 so skipping grub2-install //-------------------------------- To demonstrate main bug - non booting Create a third clone (clone3) Install grub2 manually using urpmi: su urpmi grub2 grub2-install /dev/sda reboot Remove Mga3 media and replace with Mga4 media and then upgrade system to Mga4 using: urpmi --replacefiles --auto-update --auto (re-run it until all packages are up to date) (I hit a bug here with urpmi - it refused to update with --replacepkgs so I updated without) then... reboot Boot will fail. //------------------------------ To test updated grub2 Repeat the previous test with a clone4 but upgrade with core/updates_testing enabled. Boot should succeed. //----------------------------- Since the modified %post and %post-efi in this version have now been in the grub-2.02 version in Cauldron for a month or so now without any new issues I think the above is sufficient to prove this bug fix. I have already tested the above for x86_64.
Assignee: zen25000 => qa-bugs
Thanks for the procedure Barry but could you give a better advisory than this please. --- Update Advisory grub2-2.00-59.mga4 has been submitted to 4/core/updates_testing to fix this bug, and another discovered during discussions above at comment #10. --- It is meaningless when posted on http://advisories.mageia.org or updates-announce ML.
Whiteboard: (none) => has_procedure mga4-64-ok
Version: Cauldron => 4
######################## Update Advisory 2nd attempt ;) grub2-2.00-59.mga4 has been submitted to 4/core/updates_testing to fix Two issues: 1. If grub2 is installed manually (not via drakboot) in Mga3 and installed to MBR, then on upgrade to Mga4 the system will not boot. 2. If the grub2 package is installed in Mga3 but grub legacy is in use (i.e. installed to MBR) then upgrade to Mga4 will cause the MBR to be overwritten by grub2. This update to grub2 in Mga4 fixes these issues. Files affected: grub2-2.00-59.mga4.src.rpm grub2-2.00-59.mga4.<arch>.rpm grub2-debuginfo-2.00-59.mga4.<arch>.rpm grub2-efi-2.00-59.mga4.<arch>.rpm grub2-mageia-theme-2.00-59.mga4.noarch.rpm ######################## grub2 update testing procedure in VBox: N.B. This involves completing 4 updates from Mga3 to Mga4, so best done with a local mirror available. Create a master Mga3 VM using default grub legacy and fully update it. //---------------------------------- To demonstrate bug (part relating to clobbering legacy MBR discussed at comment #10: Clone the master VM into "clone1" Boot into clone1 In clone1 switch to grub2 using drakboot and reboot to check it works. Using drakboot switch back to grub legacy and reboot to check it works. Remove Mga3 media and replace with Mga4 media and then upgrade system to Mga4 using: urpmi --replacefiles --auto-update --auto (re-run it until all packages are up to date) then... reboot Note that reboot uses grub2 when it should still be using grub legacy. Also see: $ cat /var/log/grub2_post.log Installation finished. No error reported. Installation finished. No error reported. //-------------------------------- To test updated grub2 package does not clobber grub legacy MBR on update. //-------------------------------- Create a second clone (clone2) from the master VM. Boot into clone2 In clone2 switch to grub2 using drakboot and reboot to check it works. Using drakboot switch back to grub legacy and reboot to check it works. Remove Mga3 media and replace with Mga4 media *** Now enable Core/Updates_Testing *** Upgrade system to Mga4 using: urpmi --replacefiles --auto-update --auto (re-run it until all packages are up to date) then... reboot Note that it boots correctly using grub legacy. Also see: $ cat /var/log/grub2_post.log MBR not grub2 so skipping grub2-install //-------------------------------- To demonstrate main bug - non booting Create a third clone (clone3) Install grub2 manually using urpmi: su urpmi grub2 grub2-install /dev/sda reboot Remove Mga3 media and replace with Mga4 media and then upgrade system to Mga4 using: urpmi --replacefiles --auto-update --auto (re-run it until all packages are up to date) (I hit a bug here with urpmi - it refused to update with --replacepkgs so I updated without) then... reboot Boot will fail. //------------------------------ To test updated grub2 Repeat the previous test with a clone4 but upgrade with core/updates_testing enabled. Boot should succeed. //----------------------------- Since the modified %post and %post-efi in this version have now been in the grub-2.02 version in Cauldron for a month or so now without any new issues I think the above is sufficient to prove this bug fix. I have already tested the above for x86_64. [reply] [â] Comment 17 claire robinson 2014-06-25 14:17:28 CEST Thanks for the procedure Barry but could you give a better advisory than this please. --- Update Advisory grub2-2.00-59.mga4 has been submitted to 4/core/updates_testing to fix this bug, and another discovered during discussions above at comment #10. --- It is meaningless when posted on http://advisories.mageia.org or updates-announce ML.
CC: (none) => zen25000
Claire - I accidentally copy/pasted your reply at the bottom - sorry.
Thanks Barry
Advisory uploaded.
CC: (none) => remiWhiteboard: has_procedure mga4-64-ok => has_procedure mga4-64-ok advisory
Successfully tested on MGA4 on i586 using procedure from Comment #18 (https://bugs.mageia.org/show_bug.cgi?id=12423#c18). Was able to replicate the same bug. No issues once the testing repo installed the proper grub2 files.
CC: (none) => markkuehnWhiteboard: has_procedure mga4-64-ok advisory => has_procedure mga4-64-ok advisory mga4-32-ok
Validating update. Please push grub2 to Mageia 4 core/updates.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGAA-2014-0155.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
As said several times, the real issue is that grub2 post script tries to do drakboot job and install grub2 which it shouldn't Adding workarounds is insane, just stop doing that...
(In reply to Thierry Vignaud from comment #25) > As said several times, the real issue is that grub2 post script tries to do > drakboot job and install grub2 which it shouldn't But drakboot does not always know to re-install grub2 when needed or this bug would not have existed. You have been cc'd on this since early on and I emailed you long before Mga4 release with my concerns about this potential issue. > > Adding workarounds is insane, just stop doing that... So leave it broken? OK - I give up - passing grub2 to 'nobody' - maybe he will do better than me.
Count to ten and change your mind Barry please.
As the original reporter, may I suggest that it doesn't really matter what you do, as long as, if the system is left inconsistent, the user is presented with a big fat warning. Either way, it is never OK to leave the bootsector and the filesystem out of sync with one another: at the very least, the scripts should exit with a failure, and a warning message. It's easy to detect this conflict, and warn about it, even if you can't decide how to automatically correct it. In pseudo-code, both drakboot and the grub2 post script should do: if [ $(detect version of grub on the bootloader of the disk that contains /boot) != $(detect version of grub in /boot/grub) ]; then print a warning that the system will not reboot safely, and that the user must invoke either drakboot, or grub-install. fi This problem doesn't just arise in changing from grub-legacy -> grub2; it is also going to arise every time that a routine urpmi --auto-update brings in a new package of grub2 (which updates /boot/grub, without updating the bootloader). Lastly, in my view, the primary tool for system administration is urpmi. The drak* tools are graphical helpers, used only via MCC, and only as an aid to beginners. Graphical sysadmin tools are always nice to have, but they wrap the command-line utilities, and shouldn't do any magic of their own, especially when the server might not even be running X.
(In reply to Richard Neill from comment #28) > As the original reporter, may I suggest that it doesn't really matter what > you do, as long as, if the system is left inconsistent, the user is > presented with a big fat warning. > He now is > Either way, it is never OK to leave the bootsector and the filesystem out of > sync with one another: at the very least, the scripts should exit with a > failure, and a warning message. > It now does > It's easy to detect this conflict, and warn about it, even if you can't > decide how to automatically correct it. In pseudo-code, both drakboot and > the grub2 post script should do: > > if [ $(detect version of grub on the bootloader of the disk that contains > /boot) > != $(detect version of grub in /boot/grub) ]; > then > print a warning that the system will not reboot safely, and that the user > must invoke either drakboot, or grub-install. > fi > It now does > This problem doesn't just arise in changing from grub-legacy -> grub2; it is > also going to arise every time that a routine urpmi --auto-update brings in > a new package of grub2 (which updates /boot/grub, without updating the > bootloader). > If the package is updated then the bootloader is re-installed 'if possible' or a warning is given. > Lastly, in my view, the primary tool for system administration is urpmi. > The drak* tools are graphical helpers, used only via MCC, and only as an aid > to beginners. Graphical sysadmin tools are always nice to have, but they > wrap the command-line utilities, and shouldn't do any magic of their own, > especially when the server might not even be running X. Difficult when the bootloader has to be integtrated with the installer, but I agree in principle.