Description of problem: Timing of initrd creation during kernel update has changed causing filetrigger in grub2 to create grub.cfg before the initrd is available. Thierry, I have tested kernel updates without grub2's filetrigger enabled and I see "no bootloader found" (running urpmi --debug) and grub2-mkconfig is not run. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
Priority: Normal => release_blockerBlocks: (none) => 416
I already told you to drop this filetrigger as kernel's using bootloader in order to create its initrd.
CC: (none) => thierry.vignaudSource RPM: grub2-2.00-41.mga3, bootloader.pm => grub2-2.00-41.mga3
(In reply to Thierry Vignaud from comment #1) > I already told you to drop this filetrigger as kernel's using bootloader in > order to create its initrd. Yes - however when I do that the menu is not updated on kernel update. I'm now suspecting that it's only in cases where the bootloader is "installed to partition" that fail, since nothing is written to MBR, and so grub2 is not detected. I will test the MBR case in VM later.
Yes, I have confirmed that a kernel update is handled correctly when grub2 is installed to MBR, but *not* when it is not in the MBR. grub2-mkconfig needs to *always* run on kernel update if the grub2 package is installed, whether it 'appears' to be in use or not.
Humm it should be in both cases. Can you provide the kernel install logs in such a case? Is there any "grub2-mkconfig failed:..." ?
Keywords: (none) => NEEDINFO
I have removed the filetrigger for kernel update and will push grub2-2.00-45 to updates/testing.
Keywords: NEEDINFO => (none)Assignee: bugsquad => thierry.vignaud
In bootloader-config it's the line 70 warn I'm seeing.
Created attachment 3905 [details] output of urpmi install I can't see anything in logs (unless there is a log that I can't find). I have rsyslog installed. This is the terminal output of urpmi (--debug adds nothing useful) Also attaching syslog from the same kernel install.
Created attachment 3906 [details] syslog
Summary: initrd created after grub2 filetrigger on kernel update since kernel stuff was moved to %posttrans => bootloader does not run grub2-mkconfig when grub2 is not installed to MBRSource RPM: grub2-2.00-41.mga3 => bootloader-config/bootloader.pm
Humm, we could try to see if grub2 is installed on a partition instead of MBR in bootloader::read() if we detected nothing
(In reply to Thierry Vignaud from comment #9) > Humm, we could try to see if grub2 is installed on a partition instead of > MBR in bootloader::read() if we detected nothing Well it can't be detected by looking at the PBR as it writes nothing there when "install to partition" is selected. Maybe just check for existence of /boot/grub2/grub.cfg ? I can't think of a problem with that. I have not asked yet for push on grub2 (without filetrigger) as it's less broken as it is now, until this is fixed.
To be clear:- At present, in a system with grub2 in the MBR, grub2-mkconfig gets run twice, first by the filetrigger and then by bootloader-config Not ideal, but unless there are very many systems and os-prober is installed then the delay is acceptable. In a system without grub2 in MBR, grub2-mkconfig is only run by the filetrigger, which produces correct entries for all except the second entry in the sub-menu for the current system (which has the initrd line missing and panics). In practice this menu entry is unlikely to be used as it points to the same kernel version as the default (top) selection. Running update-grub once fixes it, so this could be easily handled in errata. So, not really a showstopper if bootloader cannot be fixed, although this would be preferable.
Severity: critical => major
This bug is tagged as release blocker. What shall we do about this?
CC: (none) => ennael1
Tested in Mga5 B2 in VM and this seems to now be fixed. I installed gnome from classic install DVD iso using grub legacy. On the same vdi I installed the same again but using grub2 installed to / (sda6) I modified menu.lst on the first installation (sda1) to boot into core.img of the second installation. Works fine. Previously core.img was not being created. Closing
Status: NEW => RESOLVEDResolution: (none) => FIXED
(In reply to Barry Jackson from comment #13) > Tested in Mga5 B2 in VM and this seems to now be fixed. > > I installed gnome from classic install DVD iso using grub legacy. > On the same vdi I installed the same again but using grub2 installed to / > (sda6) > I modified menu.lst on the first installation (sda1) to boot into core.img > of the second installation. > Works fine. > Previously core.img was not being created. Correction to last line: "Previously grub.cfg was not updated, now it is, as the entry for the system on sda1 is included in the /etc/grub.d/30_os-prober section of grub.cfg" Sorry for confusion - my mind was on another issue ;) > > Closing
Status: RESOLVED => REOPENEDBlocks: 416 => 15532Resolution: FIXED => (none)
Re-opened as this issue has re-appeared in 15532 - and I appear to have been somewhat distracted when testing this as reading from #13 now I seem to have checked for the wrong issue - and thought later it was merely a typo.
Blocks: (none) => 416
Blocks: (none) => 14069
(In reply to Thierry Vignaud from comment #9) > Humm, we could try to see if grub2 is installed on a partition instead of > MBR in bootloader::read() if we detected nothing if anyone else wants to have a go at fixing this, where would that person look?
CC: (none) => alien
http://gitweb.mageia.org/software/drakx/tree/perl-install/bootloader.pm But AFAIC that cannot be release a blocker as this was opened in 2013....
Added in errata for Mageia 5
Priority: release_blocker => High
No need to have duplicated bugs. The new issue is followed in bug #15532
Status: REOPENED => RESOLVEDResolution: (none) => FIXED