| Summary: | bootloader does not run grub2-mkconfig when grub2 is not installed to MBR | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Barry Jackson <zen25000> |
| Component: | RPM Packages | Assignee: | Thierry Vignaud <thierry.vignaud> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | High | CC: | alien, ennael1, thierry.vignaud |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | bootloader-config/bootloader.pm | CVE: | |
| Status comment: | |||
| Bug Depends on: | |||
| Bug Blocks: | 416, 14069, 15532 | ||
| Attachments: |
output of urpmi install
syslog |
||
|
Description
Barry Jackson
2013-05-08 12:31:50 CEST
Barry Jackson
2013-05-08 12:32:33 CEST
Priority:
Normal =>
release_blocker I already told you to drop this filetrigger as kernel's using bootloader in order to create its initrd. CC:
(none) =>
thierry.vignaud (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) 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
Barry Jackson
2013-05-09 01:31:56 CEST
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 MBR 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 =>
RESOLVED (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
Barry Jackson
2015-03-21 12:23:45 CET
Status:
RESOLVED =>
REOPENED 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.
Barry Jackson
2015-03-21 12:32:37 CET
Blocks:
(none) =>
416
claire robinson
2015-03-21 13:45:41 CET
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 =>
RESOLVED |