| Summary: | grub2 updates create several .rpmnew which removes boot menu | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Nicolas Pomarède <npomarede> |
| Component: | RPM Packages | Assignee: | Barry Jackson <zen25000> |
| Status: | RESOLVED FIXED | QA Contact: | Barry Jackson <zen25000> |
| Severity: | normal | ||
| Priority: | Normal | CC: | luke.nukem.jones, marja11, zen25000 |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | grub2-2.02-0.git10101.3.mga6.i586 | CVE: | |
| Status comment: | |||
| Attachments: | journalctl output from kernel before grub2 install | ||
|
Description
Nicolas Pomarède
2015-11-30 23:29:22 CET
Nicolas, Thanks for reporting it. The problem is that when a package is updated, config files that are owned by it are not re-installed, to avoid overwriting custom settings that the user may have applied. The original files in the package are offered by the GUI package manager as replacements for the currently installed ones. In this case it is too easy for a user to accept the original replacement empty file, making the system un-bootable. Since grub.cfg is hardly ever written by grub2 itself, there is no reason to have it owned by the grub2 package. So, I have removed the file from the grub2 files list, and ensured that on the first update to this new package that a fresh grub.cfg will be written. Thereafter grub2 will not touch it, and no enticing messages on update will appear. Another file that grub2 offers for replacement this way is /etc/default/grub, which could also cause boot problems if the wrong choice was made. In this case I arranged for the .rpmnew to be deleted after creation on update, so that now nothing is offered and updates should complete silently. I am uploading this version to cauldron/updates_testing initially for you and anyone else to test for a few days on both UEFI and PC-BIOS machines. I have done some update testing from the Mageia 5 version in view of Mga5-6 upgrades and have not hit any snags. Please test by using the MCC GUI updater and check that no .rpmnew files are offered related to grub2, and that it boots :) Thanks, Barry CC:
(none) =>
zen25000
Barry Jackson
2015-12-01 00:52:03 CET
Hardware:
i586 =>
All Thanks Barry for the clarification on what is happening. I was about to file a bug report on it also; good to see it has been resolved and put to testing quickly. CC:
(none) =>
luke.nukem.jones
Samuel Verschelde
2015-12-01 18:09:36 CET
Assignee:
bugsquad =>
zen25000 Tested ====== -Performed fresh install with Cinnamon, MGA5 -Removed and replaced repos with Cauldron -Enabled "Testing" repos for core updates + non-free. -urpmi --auto-update --auto No file update requests seen, no problems at all to report. Boots to grub2 fine with correct menu in place. From ML: Marja tested in cauldron, BIOS, 64bit, using MageiaUpdate started from MCC. The grub2 packages update fine, no .rpmnew files were offered. OK as we have not had any adverse feedback I will bump release and push to BS, This will give any testers a second update which should not now update grub.cfg or /etc/default/grub and again not offer any rpmnew's. ah, this bug report is indeed against cauldron ;-) This evening I updated two cauldrons with "urpmi --auto-update" The first one installed the new kernel before grub2. There a new /boot/grub2/grub.cfg.rpmsave was created, but /boot/grub2/grub.cfg had disappeared, so when rebooting I ended up in the grub2 shell. The second cauldron updated grub2 before the kernel, there everything went fine. CC:
(none) =>
marja11 (In reply to Marja van Waes from comment #6) > ah, this bug report is indeed against cauldron ;-) > > This evening I updated two cauldrons with "urpmi --auto-update" > > The first one installed the new kernel before grub2. > > There a new /boot/grub2/grub.cfg.rpmsave was created, > /boot/grub2/grub.cfg had disappeared, so when rebooting I ended up in the > grub2 shell. Had this been updated previously with the grub2 from update_testing, or was this the first update since before that went into updates_testing? (both are the same but handle things differently depending on the version being updated from) Can you tell from the logs if they were in the same transaction? > > The second cauldron updated grub2 before the kernel, there everything went > fine. Good Again. had this had the update from updates_testing? Created attachment 7264 [details] journalctl output from kernel before grub2 install (In reply to Barry Jackson from comment #7) > (In reply to Marja van Waes from comment #6) > > ah, this bug report is indeed against cauldron ;-) > > > > This evening I updated two cauldrons with "urpmi --auto-update" > > > > The first one installed the new kernel before grub2. > > > > There a new /boot/grub2/grub.cfg.rpmsave was created, > > /boot/grub2/grub.cfg had disappeared, so when rebooting I ended up in the > > grub2 shell. > > Had this been updated previously with the grub2 from update_testing, or was > this the first update since before that went into updates_testing? Not from updates_testing, but grub2-2.02-0.git10101.3.mga6 > Can you tell from the logs if they were in the same transaction? They weren't, the transaction the kernel was in finished had just finished when the transaction grub2 was was started, see attached log. > > > > The second cauldron updated grub2 before the kernel, there everything went > > fine. > > Good > Again. had this had the update from updates_testing? No, it didn't. I'll update the system where grub2 from updates_testing is installed asap. Is there a way to force installing the new kernel before upgrading grub2 while running urpmi --auto-update only once? Btw, in the past I've occasionally needed SuperGrub2disk because I was dropped to a grub2 shell. I don't remember having found out what caused that, but do know that running update-grub2 fixed the problem and that I'm very sure I never chose an rpmnew file. If I find a sure way to reproduce losing /boot/grub2/grub.cfg when kernel + grub2 are updated then I'll try the same in Mga5, to check whether this is an old issue. (In reply to Marja van Waes from comment #8) > Created attachment 7264 [details] > journalctl output from kernel before grub2 install > > (In reply to Barry Jackson from comment #7) > > (In reply to Marja van Waes from comment #6) > > > ah, this bug report is indeed against cauldron ;-) > > > > > > This evening I updated two cauldrons with "urpmi --auto-update" > > > > > > The first one installed the new kernel before grub2. > > > > > > There a new /boot/grub2/grub.cfg.rpmsave was created, > > > /boot/grub2/grub.cfg had disappeared, so when rebooting I ended up in the > > > grub2 shell. > > > > Had this been updated previously with the grub2 from update_testing, or was > > this the first update since before that went into updates_testing? > Not from updates_testing, but grub2-2.02-0.git10101.3.mga6 > > > Can you tell from the logs if they were in the same transaction? > > They weren't, the transaction the kernel was in finished had just finished > when the transaction grub2 was was started, see attached log. > > > > > > The second cauldron updated grub2 before the kernel, there everything went > > > fine. > > > > Good > > Again. had this had the update from updates_testing? > > No, it didn't. > > I'll update the system where grub2 from updates_testing is installed asap. > Is there a way to force installing the new kernel before upgrading grub2 > while running urpmi --auto-update only once? > If you use the GUI you can deselect grub2* - whether it will be ignored is debatable :\ > > Btw, in the past I've occasionally needed SuperGrub2disk because I was > dropped to a grub2 shell. I don't remember having found out what caused > that, but do know that running update-grub2 fixed the problem and that I'm > very sure I never chose an rpmnew file. If I find a sure way to reproduce > losing /boot/grub2/grub.cfg when kernel + grub2 are updated then I'll try > the same in Mga5, to check whether this is an old issue. Thanks, I'm wondering if this may not actually be related to grub2 at all. Grub2 has not been responsible for re-generating the menu for some time now - certainly not in Mga5, it's down to kernel triggers or drakboot/bootloader. The bug that this update was about was purely to avoid the GUI presenting rpmnew's for selection and stopping users from shooting themselves in the foot. I can't think how it could cause this. (In reply to Barry Jackson from comment #9) > > Thanks, I'm wondering if this may not actually be related to grub2 at all. > > Grub2 has not been responsible for re-generating the menu for some time now > - certainly not in Mga5, it's down to kernel triggers or drakboot/bootloader. > > The bug that this update was about was purely to avoid the GUI presenting > rpmnew's for selection and stopping users from shooting themselves in the > foot. > I can't think how it could cause this. Well, I now updated the system that had grub2 from updates testing. The new kernel was installed before grub2 was updated, like when I hit the missing grub.config issue, but now everything went fine. So, forget about it :-) AFAIK the occasional occurrences of being dropped to the grub2 shell, have always been on BIOS systems, and there Grub2 is not used by default, so the chance that this hits a newby is zero. OK closing then. Status:
NEW =>
RESOLVED |