Context: I did a VM install of Cauldron this morning using boot-nonfree.iso. The process was a bit chaotic, with several conflicts and failed scripts, but I managed to install nevertheless. The system was working fine for a couple reboots, then I installed the latest vboxadditions to be in sync with the kernel, and remove the orphans (there shouldn't have been orphans at all after a clean install IMO, but whatever). Now on reboot I get directly to the grub prompt, my grub configuration seems to have been lost. Running the drakx rescue from Mageia 5 (or from boot-nonfree.iso directly), I tried to let it repair/regenerate a bootloader, but it errors with: => found a Mageia release 6 (Cauldron) for x86_64 root partition on /dev/sda1 => type ext4, version ' find_root_parts found sda1: Mageia (Cauldron) for x86_64 => Selecting /dev/sda1 as root fs [...] Cannot find a configured boot loader (See attached screenshot). Is it the expected behaviour, or should the rescue system be able to regenerate a new grub/grub2 configuration if none is found? IMO it would be a very useful feature if it did. Reproducible: Steps to Reproduce:
Created attachment 7087 [details] Screenshot of the output of the repair bootloader option
When pressing enter in the above screenshot, I just get: Error Program exited abnormally (return code 2) If there is a way to retrieve more debug info about this, please tell me how, I'm a bit lost with the various methods in the various stages or live/classical flavours :)
The purpose is to reinstall the bootloader if it was overwritten, eg: by Windows. We don't offer to create a new bootloader configuration. (basically we run lilo, /boot/grub{,2}/install.sh For further fixing, you need to rerun the drakx installer, choose update, then your bootloader will be reconfigured at summary time. The question is why did you lost your bootloader? Once you've run drakx in roder to fix it, you can look at the logs and see what you had removed with urpme --auto-orphans
Keywords: (none) => NEEDINFO
OK, I had assumed that the rescue application would do basically the same thing as rerunning the drakx installer, without having to go through all the installer steps. Is it by choice that it can't do the same as the post-install bootloader configuration step, or for technical reasons? It would be nice in such situations to have a rescue option that would generate a very basic grub config (i.e. just using the root partition it found, without trying to find other distros or Windows), so that one can boot again and fix the bootloader using drakboot. Regarding my VM, I probably borked it when running auto-orphans indeed. I did not check the list thoroughly but there were some relatively important packages like tk that got removed (the list was not too long however, maybe 20 packages or so). I'll try to fix it to see what was actually uninstalled that might have killed grub.
So I repaired the bootloader using the installer, and interestingly, there is no mention of any package removed by "urpme --auto-orphans" in "journalctl | grep RPM | grep erase". I just checked by installing buildrequires and removing the orphans again, and this time they show up in journalctl. So I really wonder how I messed this all up :)
Created attachment 7093 [details] journalctl output from last working boot Nothing really interesting in there, but I attach it just for the sake of consistency. It looks like it stops abruptly, so I guess I close my VM with Host+Q instead of doing a proper shutdown; wouldn't expect it to mess the grub config though.
I think it's safe to close this one...
Status: NEW => RESOLVEDResolution: (none) => OLD