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.
Because this is tied to bug 25541, assigning it also to the kernel team.
Assignee: bugsquad => kernel
This is a toolchain or grub(2) issue
Assignee: kernel => mageiatoolsSource RPM: grub2 => bootloader-utils, drakxtools-backend, grub(2)?CC: (none) => tmb
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.
Created attachment 11337 [details] Failing grub.cfg
Summary: Interruption of kernel install leaves grub unusable => Current kernel install leaves grub unusable
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.vignaudSource RPM: bootloader-utils, drakxtools-backend, grub(2)? => bootloader-utils, drakxtools-backend, grub2?Keywords: (none) => NEEDINFO
Fixed in git
Status: NEW => RESOLVEDResolution: (none) => FIXED