Bug 25542

Summary:	Current kernel install leaves grub unusable
Product:	Mageia	Reporter:	Frank Griffin <ftg>
Component:	RPM Packages	Assignee:	Mageia tools maintainers <mageiatools>
Status:	RESOLVED FIXED	QA Contact:
Severity:	critical
Priority:	Normal	CC:	thierry.vignaud, tmb
Version:	Cauldron	Keywords:	NEEDINFO
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:	bootloader-utils, drakxtools-backend, grub2?	CVE:
Status comment:
Attachments:	Failing grub.cfg

Description Frank Griffin 2019-10-09 21:16:19 CEST

This is a follow-on to bug#25541.  In two of the freeze cases, rebooting the system results in a text-mode grub2 prompt rather than the graphical grub2 screen which was previously configured.

Analysis shows that the problem is that /boot/grub2/ contains a grub.cfg.old file but no grub.cfg file.  If I copy grub.cfg.old to grub.cfg and reinstall the bootloader via the rescue disk, the system boots fine.

My guess is that something in the course of updating grub for the new kernel is renaming grub.cfg to grub.cfg.old and the install is getting interrupted before a new grub.cfg can be built.  This should not happen.  The existing grub.cfg should be *copied* to grub.cfg.old, the new grub.cfg should be built as grub.cfg.new, and then grub.cfg.new should be atomically moved to grub.cfg via "mv -f".

This is a critical error since it leaves the system unbootable.  Using "Reinstall Bootloader" from the rescue disk has no effect without a grub.cfg, so unless someone knows enough to mount the correct root partition as /mnt and manually repair the situation, the machine's a brick without a reinstall.

Comment 1 Lewis Smith 2019-10-09 21:44:30 CEST

Because this is tied to bug 25541, assigning it also to the kernel team.

Assignee: bugsquad => kernel

Comment 2 Thomas Backlund 2019-10-09 22:26:10 CEST

This is a toolchain or grub(2) issue

Assignee: kernel => mageiatools
Source RPM: grub2 => bootloader-utils, drakxtools-backend, grub(2)?
CC: (none) => tmb

Comment 3 Frank Griffin 2019-10-30 22:34:24 CET

This has happened again, but in a slightly different way.  This time, there was no interruption, and there *was* a grub.cfg left, but the symptom was the same: grub boots to a grub prompt.

I'll attach the grub.cfg that causes the problem.  The resolution was to save off grub.cfg as grub.cfg.old and copy grub.cfg.old to grub.cfg, followed by reinstall of the boot loader from the rescue disk.

Comment 4 Frank Griffin 2019-10-30 22:35:33 CET

Created attachment 11337 [details]
Failing grub.cfg

Frank Griffin 2019-10-30 22:36:50 CET

Summary: Interruption of kernel install leaves grub unusable => Current kernel install leaves grub unusable

Comment 5 Thierry Vignaud 2019-10-31 09:48:54 CET

Can you provide the diff between the bogus & the right files?
(that one would be a grub2's update-grub bug)

As for the original report, yes we rename the grub2.cfg file prior to run update-grub2:
http://gitweb.mageia.org/software/drakx/tree/perl-install/bootloader.pm#n2099

So the issus is that the kernel freeze while running update-grub2.
Could be update-grub2 (via os-prober) doing sg harmful on some partitions.
Did you try disabling "Probe Foreign OS" in drakboot?

CC: (none) => thierry.vignaud
Source RPM: bootloader-utils, drakxtools-backend, grub(2)? => bootloader-utils, drakxtools-backend, grub2?
Keywords: (none) => NEEDINFO

Comment 6 Thierry Vignaud 2020-03-20 17:00:42 CET

Fixed in git

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